You should be safe with most options. There used to be a compatibility database that was more general and based on commonly available hardware. I couldn’t seem to find that, or I would have linked it here. Complexity is the enemy of security and reliability. Most issues that are hardware related come from making things more complex and adding more hardware. Then there are other factors we can’t control. The state of the hardware, the power source, the internet connection and equipment. That’s what I mean by a moving target. We could generalize (and feel free to do that in a list), but it may still not cover everything that we may never even know is a factor, and we may only discover by having a one on one interaction involving testing.
1 Like
I don’t understand this. People test on whatever hw or vm they have and know how to use. When I lived in the US I tested on 4-5 different computers now I have one laptop. I do not test as much because I am older and retired and have other things I want to do, not because I only have the one laptop. I am still testing and reporting things pretty much weekly.
Automatic testing can test certain things with the emphasis on things. This is used primarily in package management, at least for now. But to test the user experience is best done by being a user and reporting things that appear to not be working properly. For example: A developer and a user using identical computers frequently catch entirely different problems. This is way beyond common. Why? Because the machine part may be the same but the human part is not.
1 Like
OK.
I’ve used Rock 6.0. Everything has worked on my vanilla x86/64 system. A couple of hiccups with some flatpacks that I was able to deal with without asking for support here. The act of minimising support requests here is, IMHO, the act of putting more resources elsewhere.
1 Like
Obviously, there isn’t anything we can do about Flatpacks. So, I am glad you got that fixed.
Minimizing support is very noble, but not always realistic and I’ll tell you why. Things that get missed will get passed on through the legacy of the distro. By that, I mean if we don’t fix it in Cooker, it doesn’t make its way to ROME or Rock. Maybe it’s not our issue, but something in the upstream. The whole process is to discover that and handle the issue appropriately. What we need, is a simpler way to do that without impacting or waiting for people in an unnecessary way. Does that make sense?
1 Like
We deeply appreciate this. The fact that people are interacting with you indicates your input is valued and respected.
As you can tell I do not agree with any concept of buying hw specifically for testing some operating system. I bought computers to do work, or the old “want this old laptop, you can have it”. I started testing with Mandriva QA-Team as a way of contributing to the project.
3 Likes
I would be happy to be able to base my hw buying choices on what OMLx works well with, or at least have the knowledge to do so should I so choose.
By perusing these forums, I have a good idea about that, but, being essentially lazy, I asked for a list of the hw that was used to test before a release.
Well excuuuuse me! 
VirtualBox, and probably QEMU. I test on a 990FX/FX 8350 with a RX 580 8GB and a 2TB Samsung nvme with a heatsink.
1 Like
Scroll up to @LeeTalbert reply. Hardware drivers are part of the Linux kernel, not something specific to OM. If it works with Linux, then it works with OM.
Except for nvidia because they choose to not publish to the kernel or mesa.
2 Likes
I agree and I do not buy hardware for testing, that is a complete waste of my resources and is the manufacturers job, not mine.
My computation hardware is bought for work purposes and all the peripherals are either mostly hardware I have collected over the years for my own needs or hardware devices bought for work purposes that can optionally be connected to a computer, if I can test that equipment I do purely for the reason that I own it already. 
Some of the issues with the most recent Rome update seems to indicate otherwise. Every distro has its quirks.
At any rate, I simply requested the option to know what has been tested before a release, to maximise my chances of having a system “just work.” The fact that others may not want to use this info as a criterion to help choose their own systems means nothing to me.