To be clear, I never presume to speak for the Qubes team.
When I comment here or in the mailing list I speak for myself.
I believe that I am identified as a “Team member” in some way - I wasn’t
asked about this, and did not request it.
@fslover -
I don’t believe the “Qubes team” is biased against Purism. There was a
bad experience in the past, which has been discussed elsewhere. But you
are right - this is not the place for that discussion - as I said
As to whether Purism should be included, the issue is where you say:
“Every machine has been working with Qubes flawlessly…Except maybe
temporary problems with the support of newer hardware…”
That’s a real issue for someone who uses the list to buy a laptop, and
then has to wait for new releases to get their machine working well with
Qubes, don’t you think?
Let’s promote the people who actively support Qubes, and treat the rest
the same.
Thank you. I will let this sit for ~48 hours before taking further action and hope to get some more feedback until then. If the consensus is that the table worked better, I will roll back and restore the table / update the links to point to the new machine pages.
In that case I’d remove the “Heads” column and extend the “USB” to “USB Ctrls”. The machine pages have the detailed Coreboot, Heads, ME break down.
I’d like to keep those as dedicated “super threads” for each machine with pointers into the HCL and respective support threads as well as more detail and spec links for each machine. That way the HCL entries link to the threads and the threads to the HCL table.
Thank you! That’s exactly as I intended it. Adding more info to the main table will make it less readable again due to the limited size. I will restore one more column (comments: certified, tested) but all the other stuff should go on the machine specific pages.
I’ve added a history detail to this page too, please use it with further edits.
Thank you for the update! I still don’t understand, why “developer-tested” is relevant, whereas “vendor-tested” isn’t. In both cases, there is no official recommendation/guarantee here, just the community recommendation, right? Don’t they both mean in principle community-tested (given enough HCL reports)?
Also, those “developer-tested” laptops, in my view, (when alone) make unfair advertisement to Lenovo, who multipletimescompromisedsecurity and privacy of the customers – something against the Qubes values.
I still don’t understand, why “developer-tested” is relevant, whereas “[vendor-tested]” isn’t.
By using Qubes OS and being part of this community I am implicitly and explicitly placing a huge amount of trust in Marek and the development team. There is just no helping it. If I don’t trust them, I might just as well use Windows. Of course it is relevant which computers they are using to test Qubes OS. Naturally bugs will be found and fixed on those machines first. Note that this has nothing whatsoever to do with Lenovo or placing any trust in them.
On the other hand, all I ever heard about Purism so far is: they got certified and then the certification needed to be removed because of hardware changes. @Michael was open to restart the process with them and aborted it again because he got reminded how Purism “as a company” works. All this does NOT imply bad intent on either side, but that at least one side is more or less flying by the seat of their pants. Which might be OK in some circumstance, but not to certify hardware. So this is explicitly NOT about trust. Nobody here thinks that Purism is malicious as far as I can tell. They have just decided to develop hardware in a way that does not work well with getting certified.
Qubes OS doesn’t even come preinstalled and all we have is one sentence on their website saying that they test their hardware to work well with Qubes OS (which version?, how often?, what process?). To consider a “vendor-tested” comment at the very least there would need to be a dedicated page on their website showing which version of Qubes OS was tested against which version of their hardware and with which result. And what “tested” means in the first place: what was tested … just that it installs?
That’s why community submitted HCL reports offer much more insight and confidence than a vendor claiming to test their hardware on their website. Makes sense?
well my suggestion near the beginning of this thread was to remove “developer-tested” since I don’t think it is very relevant, and instead leave certified and community-tested.
I think Andrew did a great job of incorporating this new community-tested list into the website so that it shows up on a lot more pages than the “developer tested” content, and maybe we can decommission the dev-test list at some point. i would love to know if it accurately reflects the current hardware used by the dev team (my guess is there is additional hardware being used). this would also reduce the need for dev team to keep such a list accurate & updated, and if they are using some machine not on the community-tested list than they can submit an HCL and get it put on the list.
i think focusing on integrating & promoting the community-tested list is the most productive avenue, since it is much more thorough and informational than the dev-tested list, and avoids the “advertisement” feelings you have @fsflover with the dev-tested list.
I think there is some extra value in knowing which machines the developers use. It’s a simple calculation: if there is an issue with those machines, it will annoy the devs and most likely get fixed sooner than later.
If you want to decommission the page on the website that makes a lot sense. However, do you see an issue with calling out explicitly on the community list if a specific machine is being used for testing by the core team?
I think having it be mentioned on the community list is a very fine idea for the reasons you mentioned. I just like it embedded within that list (which is more up-to-date and informative) rather than its own “thing” which feels a bit lost in the website content - but i don’t have particularly strong feeling about it.
and thanks for all your work on the community list, it is really excellent and i’m hoping others find it helpful! maybe you want to share with qubes-users mailing list?
I asked Marek about this above, but I guess he’s too busy to reply. I’ll just go ahead and decommission it. We can always restore it later, if needed, and of course all current content will forever be in the Git history.
@Sven, the old https://www.qubes-os.org/doc/hardware-testing/ URL now redirects to https://forum.qubes-os.org/t/5560, so I’ve edited the wiki post to un-hyperlink the “developer tested” comments and documented this change in the history log (revision 35).
Currently the List sates “OEM” in the first column (e.g. Lenovo, Nitrokey, Librem). I would suggest instead using the word “Vendor”.
Original Equipment Manufacturer (OEM), although technically more precise, may lead to more confusion. And even this is not correct because for Nitrokey’s laptops it’s arguable the OEM is Lenovo and not NitroKey… So maybe set it to Vendor (or equivalent) and add a foot-note about it (if justified).
The performance is acceptable for every day tasks (web incl. audio/video, view/edit documents)
Excuse me, can we please therefore delete the 9+ year old CPUs which can’t offer anywhere near adequate performance browsing on basic websites (software rendering).
When I get through researching I’m happy to upload HCLs but think recommending models which have such inadequate performance on most modern software is going to hurt the project. Can we please draw a line at say 6 year old discontinued CPUs / Intel Ivy?
