The HCL provides a comprehensive list of PC & laptop builds, which are confirmed to be fully compatible with Qubes.
The HCL also lists compatible motherboards, which is necessary, but not sufficient. Furthermore, the information in System Requirements additionally indicates the CPU functionality needed for virtualisation, but otherwise only makes generic performance-related recommendations.
My question is, if I wanted to purchase a machine which is a vendor variation of compatible builds, what should I specifically pay attention to? In other words, what are the relevant variables at play? What determines whether Qubes will ultimately run and be usable?
After reading around the forum, it seems that failures on a laptop platform can be due to: error during Qubes installation, lack of support for sleep mode, energy management, USB controllers, Wifi cards, etc. So, it would be great to either: understand where those issues stem from compared to other hardware setups (in order to avoid the problematic ones); or, have a general troubleshooting approach for finding solutions, in case it happens.
While I think this is a useful question to ask in general, currently my interest is in trying to guess which Macbook model with 32GB RAM will be supporting Qubes. At the moment, there is one complete success reported for Macbook 11.1, but this model only has up to 16GB. So my inclination is to ask: can I diff compare the specs of individual models, to find the one with 32GB, but otherwise minor differences? In order to succeed, I need to define what “minor” means.
System requirements give factually correct information, but this doesn’t guarantee that setup will function smoothly. The fact that a machine has IOMMU doesn’t mean that the implementation is good.
Personally, I would scour the Internet for some additional data:
IOMMU groups, performance
How easy / hard it is for others to do dGPU passthrough, etc (not only with Qubes)
USB performance
I don’t know the exact way sys-usb passes devices, but it feels like under heavy load performance may degrade. Not sure if this is due to usb bus bottleneck or my controller being weird. Good advice to past me would be to try and find hardware with more performant USB system / multiple controllers.
16GB listed in System Requirements is not enough. Or it is enough, but only technically. Qubes tends to awaken something in me, and it tells me that I need more RAM.
This is very vague, and I have no idea how to find most of this information from a typical modern hardware specification sheet. This is why HCL exists. If you have rationale to risk it, please add an entry.
I say, you definitely have done your research. I’m impressed
I’m guessing you haven’t really used Qubes OS (your post reads like you haven’t). If you did, you would understand what each of those things mean (and would have some level of psychological trauma related to them, like the rest of us have .
“error during Qubes installation”
This is mostly people who booted the installer, didn’t understand what the on-screen text mean, and went “oh, it’s NOT WORKING. I give up”
Often times, the issue was how they created the installer ISO drive
Battery Life
Qubes OS does use more battery, because it’s doing more than other OSes
But it’s not noticeable on any laptop with a high-capacity battery
There are models you can buy with features to mitigate this
Laptops with dual batteries (eg most Thinkpads, Toughbooks, etc.) are fantastic for this
All-day battery life means simply taking six removable batteries with you
S0iX Sleep
Currently, Qubes OS “isn’t quite there yet” when it comes to S0iX sleep. You will likely encounter undefined behaviour if you try.
It’ll be ready soon, but just not yet…
What you can do is try to find a laptop that supports at least S3 sleep in the BIOS. If you can find one, then you will not encounter any issues at all.
USB Controllers
This is a difficult one to check without actually being hands-on with the laptop itself
Some revisions of the same model will have different internal configurations
Hey, as long as the end user is none the wiser, that’s considered a win for hardware designers…
Generally, what it boils down to is:
If the internal HIDs (Human Interface Device: keyboard, trackpad, mouse, touchscreen, etc.) use USB, or some other interface (e.g. PS/2, UART, I2C, or some proprietary frankenstein abomination)
If they’re USB devices, then if they’re on their own USB controller, then that’s a win. That means you can keep them separate from the USB ports.
If they’re not on their own dedicated USB controller, then that means you can pass USB devices through to other qubes
…but you will have to set up Qubes OS to blindly trust any USB device that declares itself to be a HID device
Otherwise, you will not be able to give any input to your computer
RAM
This one is simple
RAM is like the size of your work desk
The larger the footprint of your work desk (amount of RAM), the more pieces of paper, blueprints, maps, etc. (files, programs) you can have on it at the same time, without having to pack any of them up and store them in your filing cabinet (hard drive).
The more RAM you have, the more qubes you can have open simultaneously
Nowadays, you can never have too much RAM
But if you’re doing server workloads on a laptop
Your laptop will get pretty warm (by warm, I mean HOT)
Your fans will likely NEVER spin down
Your battery will likely not last that long will all those things open
But it’s such a flex to have that much RAM
Apple Hardware
Honestly, I would stay well clear of Apple hardware
nVIDIA GPUs
Broadcom wifi cards
Usually only one USB controller in it, which includes the internal keyboard and trackpad
Newer models require “special” drivers for the webcam and the touchbar (if present)
Newer models aren’t repairable or upgradable
Not a big deal in the short-term, but throwing it in for completeness
Also, definitely a deal-breaker for me, personally…
They were designed by a company that also built the software to run on it
That means they cut corners where their software development allowed them to
…and boyyyyyyyyyyyyyyy did they cut corners
So that means you have to do quite a lot of workarounds to get anything not written by Apple to run as expected on it
Linux on Apple hardware is essentially a gigantic ball of workarounds that “trick” the onboard firmware into thinking it’s macOS
Most of these workarounds are now written into the codebase (which sort of makes them not really workarounds anymore, but still…)
To be fair, Jony Ive did design some pretty nice-looking hardware. He deserves credit for that.
…on the OUTSIDE. If you open it up, on the inside, it’s a mess. Multiple types of screws, screw-heads, unnecessarily custom components, and for lack of a better word, “booby-traps”; all of which are intended to make you “just give it back to Apple for repairs”…
It would be absolutely awful if Jony had anything to do with the inside of Apple hardware…
But, if you do choose to endeavour to run Qubes OS on a piece of Apple hardware, we will be here to help you through it, and it would be awesome if you were able to submit to the HCL, partly to help others, but mostly for pride. “I got this working!”
Everything that @otter2 said as well, plus an explanation to this:
I’ve come across an important caveat regarding Macbook 16,1 models from 2019, which are the first to come with 64GB RAM. The issues are due partly from having a separate T2 chip [1]. First, the chip provides a secure boot functionality; but this can be disabled trivially. More importantly, the trackpad + keyboard are no longer using a USB controller [2], but an SPI one and they seem to rely on interfacing with T2. So, this is consistent with the warning from @alzer89’s post:
Originally, it caused issues with all Linux installations, whereby the trackpad + keyboard would not work at all. In the meantime, patches have become available [3], which can get a standard Linux distro to be almost [4] fully operational; the issue appears to be solved by creating [5] a communication interface with T2, and a virtual USB host controller, plus an audio driver; the latter 2 then connect to the former. It is unclear how practical it is to reproduce this setup in Qubes, and I think this is the reason for the lack of successful installations reported [6] in the HCL so far. But comments are welcome.
.
