I would like to echo @balko in that the community recommended list is completely useless in 2023, and in my opinion is in fact detrimental to a new user trying out Qubes. It de-facto does not add any hardware that isn’t certified. If you tell someone that your software product works best on computers 5+ years old only, I get a really bad first impression.
Currently the community recommended list only works for people with extremely restrictive threat models, and makes absolutely 0 sense for the average person. The average person works with what they have, or can reasonably get, and do not have 100 hours to throw into getting a minor in cybersecurity and flashing Heads on a T430.
I think this could be remedied by splitting it → have a list for people that need absolute security, and have a list for people that need a computer that will boot qubes and will work without issue. There is value in describing the sad state of modern computer security and noting that newer hardware may have serious flaws, but at the end of the day I think it is a disservice to everyone to discourage use of newer hardware when it does give you a better experience/compute power which is something people like and need.
The list clearly isn’t useless, both the X230, T430 and the other certified hardware are all very well suited for running Qubes OS. Anyone who actually needs Qubes OS for its designed purpose isn’t going to go wrong with the certified hardware, saying the list is useless is beyond hyperbolic.
I do think the list should be expanded with more easily available and cheaper hardware, but that doesn’t mean the current version of the list is useless.
I also don’t understand what prevents anyone from maintaining a list to their liking. All the data is public, the people who generate that data when submitting their HCL reports are on the forum, and the existing list of recommended hardware is a forum topic.
I’d love to see folks go ahead and creating better documentation and sharing it when they feel the need for it. I’m pretty sure that would be useful, assuming that there is as much need for it as stated.
I don’t see why it would have to compete with the list of recommended hardware. Multiple lists can very well co-exists, as soon as someone is maintaining them.
Now, wishing that existing tools were different, and that people maintaining them were working more for use case X, Y or Z doesn’t strike me as useful or likely to succeed. Folks putting work into Qubes OS community projects usually think a lot about what to do and why, believe me.
On the other hand, I don’t know anyone in that position who wouldn’t love to see other people create, maintain and nurture community interest in tooling for use cases that are closer to their hearts. I sure would love to see that, and would peruse those new hardware lists myself!
Well, I think, @hypercube and I were talking about community recommended list. And you say it is not useless, because it contains X230 and other certified hardware. But we are not talking about certified hardware, we are talking about community recommended list.
Does it exist? What does it include (I would love to see THE LIST)? Except certified hardware that can be considered Qubes OS Team recommended list, not community.
Maybe I am missing something.
But it does not mean I am against the community recommended list. Quite the opposite, I think it should exist (unlike now), and it should include mass-market solutions, like some of modern gen10+ Thinkpads for example. With detailed list of what works and what does not.
The current rules and criteria for including to the community recommended list make the list empty => these limitations should be removed.
I am fine to buy a laptop that will work well with Qubes OS, even if I will have to add a script or two (that will be explained by the link in the list/table) or set permissive mode for wifi or something. It is way-way more valuable to have such good laptop instead of Intel Gen3 one, that stuggles with HD video playback and has dead battery, with possible modified firmware from previous owner.
Max memory column – might be useless. First, this is likely in the specs. Second, I don’t expect many users to test it. And unless something has changed, it should be usually enough to check the CPU specs and ignore MoBo specs, because memory controller is in the CPU.
My uses of HCL:
a. Find specific HW.
b. Find experience with similar HW (maybe filtering by manufacturer and year would make it easier)
Reminder (or highlight for anyone who hasn’t seen it yet): the folks maintaining the list of community-recommended computers have created a built-in feedback mechanism in it!
I tried to get the T480 added to the list, it’s by far the most cost-effective ThinkPad you can get at the moment, and it works flawlessly with QubesOS which is documented by more than 10 HCL reports.
It got rejected for no clear reason, which to me makes it seem like the feedback mechanic doesn’t work, or it works and there is no interest from the maintainers to expand the list.
Does not look like community recommended list. Almost all laptops from this short list are certified ones, Purism with preinstalled OS and several outdated by 6-15 years. Why would we have 2 lists of certified laptops, one of each named “community recommended”? Also, certified models are not easy to buy for some countries and users, because those are not mass-market, unlike e.g. Thinkpads.
I saw several reports of Thinkpads with Intel 11/12 gen that work great on Qubes OS, but for some non-inessential reason they were not accepted. Mine included.
For me it will be decisive. And whole the point of compare tables is that user does not have to manually search for all specs to compare them manually. Max possible memory is must-have column.
I see maximum RAM is important for you. For me, it is also important. But:
For many users (including me), the maximum RAM on the currently available CPUs are enough.
What would you put there?
a. Maximum RAM specified by CPU manufacturer? This can be easy automatable, but it also has low added value, as you can easily look it up in Intel Ark or AMD’s specification.
b. Maximum RAM specified by MoBo manufacturer? Somewhat harder and in my experience, this is often irelevant. My last two laptop MoBos (both Dell) worked with double of maximum officially supported RAM by the MoBo, because CPU supports it.
c. Someone would test what maximum RAM it can accept. This would be great to have. The problem is, someone would have to do it. I don’t think this is realistic with community-maintained HCL
That is, if you have a realistic suggestion how to obtain and maintain the information, I don’t mind if the HCL has it. I am still not convinced that many people would appreciate it, but it is OK for me. (I am not the one who decides, though.)
I see your point, thank you. Please note, that selecting laptop is much bigger deal, because it can have:
irreplaceable wifi module with major issues on Linux/Qubes.
irreplaceable bluetooth module with major issues on Linux/Qubes.
soldered memory, one or all slots, so Max Mem can be == initial Mem.
and etc.
Maybe you have in mind desktop PCs, not laptops, that is why you do not value some specs?
About Max RAM, I would put Max RAM from specs of laptop (like from Lenovo, not Intel Ark). And in case somebody reports that bigger amount is working than it will be change to a bigger value in the table with additional *-cite.
Once again, yes, for each laptop users can search for specs themselves, but the point is that user can open table, select year, like “from 2021”, select Max RAM, like “32GiB or more” and have relevant list of laptops.
OK, I considered soldered RAM as something exceedingly rare, but it might be more common today. In this case, I agree that it might have some value, expecially given the memory requirements of Qubes OS.
OTOH, how would you obtain the info?
a. If this information could be obtained automatically in qubes-hcl-report (I doubt a bit), then OK.
b. If you know how to obtain the information from some vendors in an automated way (API, web scrapping, …), then it sounds reasonable.
c. If the way would be requesting users to check the manual, then I doubt many users would do that. Then, you would get an additional column, which would be mostly blank.
I would not be surprised if there are more modern laptops with soldered RAM than without it.
From specs by table/list maintainer and/or the user reporting. It is not possible to find out automatically by qubes-hcl-report.
I user is too lazy, their report would be added to the table, it is a community recommended list after all. Blank cells will not be allowed for such basic specs. No info, no recommendations from community.
Currently we have the different situation, a bunch of users that eager to report and provide information, but almost empty list of laptops recommended by community (excluding certified ones).
After you spend 45 minutes installing Qubes OS. A live image with that HCL dump functionality in it would be a good incentive for more people, including hardware vendors, to provide report and, potentially, to get broader hardware support in Qubes OS.
Mine too. And that is exactly why I don’t publish HCL report. Why would I force someone to put it on any list helplessly, while compromising my privacy/anonymity.
I can’t not to have an impression that only certain models are favored.
At the end of the day: I choose each of my laptops carefully studying Qubes specs and requirements, eventually and actually never needed HCL list.
Are you more interested in resurrecting Qubes OS LiveCD support or just report tool that is possible to run without installation from any other LiveCD (e.g. from any GNU/Linux distro)?
Good question! I didn’t think of that live CD until I realized it would make for an easier entry point to coĺlecting broader hardware information for the HCL and, possibly, allow to identify alternative workig hardware for Qubes OS. However, a live CD could also ease newcomers into Qubes OS in general, so it is not a bad idea from that standpoint either. And the immutable medium would also provide useful properties too (similar to Tails).
But this discussion would need a different thread to avoid derailing the HCL one.