I started looking at Qubes OS, a self-described "reasonably secure operating system", early this year after I accepted a job offer. I didn't want to use the same machine for personal and work tasks, but bringing multiple laptops around is inconvenient; Qubes's virtualisation-backed isolated environments seemed like a good middle ground.
Most of what would be running on this machine would be Google Chrome instances and SSH clients; my local security needs aren't very high. Under slightly different circumstances, multiple Chrome profiles would've done the job just fine.
Back to January though.
I wanted to test Qubes before committing to it, so I swapped a spare SSD into my laptop at the time (Thinkpad X13 Gen4 AMD), went through the very slow installation process, and ended up with a broken system.
Huh?
This is when I found out about the HCL. Qubes is a bit picky with hardware; the underlying OS is actually the Xen hypervisor rather than the Linux kernel. On my Thinkpad, this exhibited as wifi/trackpad not working, missing USB isolation, and kernel panics hot-plugging USB devices - as a HCL entry from a few months prior had mentioned.
Basic functionality did work, however, and I got to play around with qubes a little. I quickly grew attached to the idea of separate environments on the same machine, and soon it was time to find some proper hardware to run Qubes on.
A VM inside Qubes OS is called a "qube", the plural of which is "qubes"... a little confusing, but we can handle confusing terminology. Capitalisation is important here: the OS name is always uppercase, while the VMs are lowercase (ref).
A friend recommended the Framework laptop. At the time, it seemed like Intel models were better supported by Qubes than the AMD models. I ended up getting a 12th gen Intel i7... err, Ultra 7... with more than enough memory and disk to spare.
The installation process on the Framework was simple, though still slow. On the first boot, I ran into an issue where no VMs would start; apparently there is a bug with system time being incorrect at installation time. Well, nothing a reinstall couldn't fix.
It was reasonably smooth sailing from here, after adding a kernel parameter for NVMe timeouts (this is a hardware issue not related to Qubes OS). After porting my swaywm configuration to i3, I created a "personal" qube and a "work" qube; I'd separate it more later, but this was good enough for now.
An AppVM is a qube with an app installed, right? Nope, it only stores data persistently, while the root filesystem is recreated at boot from the qube's parent template. A DispVM actually has nothing to do with displays, and dom0 is not one! qrexec has nothing to do with QR codes... okay, okay, let's not get too carried away.
Most of my qubes actually ended up being StandaloneVMs (persistent root and data), with the parent template being the Fedora/Debian template directly. You're not really supposed to do this, but hey, it works for me.
The moment I knew Qubes was the right OS for me was when a long-standing Signal bug came up again. I'd been having issues for some time where keyboard input to the Signal desktop client was occasionally sent to a Chrome window on a different workspace. (I recall it possibly being related to Electron, but was never able to find the root cause.) On my previous XWayland setup, there wasn't any practical solution that I knew of; on Qubes, I was able to move the Signal client into its own qube and avoid this type of issue altogether.
My "personal" qube died a few weeks later. The root disk filled up; following a painful disk extension process (mainly for the VM getting killed by the startup timeout) the GUI agent failed to start. I cut my losses and, at the suggestion of a friend, split it up into three for better isolation: a data qube with my password manager, Obsidian notebook, and email client; a browser qube with a Chrome instance; and the Signal qube I mentioned above. All in all, it was a better setup than the single VM, and I was quite happy with it.
The next few months were mostly uneventful. I set up a Debian qube for a work codebase that needed dependencies I couldn't figure out how to set up in NixOS; Qubes made this really easy as creating the VM was automatic and took only a few seconds.
There were a few occasional issues... I mostly just got used to them.
Audio/video playback is a bit troublesome. I set up an AudioVM as to not run the audio stack in the privileged dom0. This setup sometimes needs an AudioVM restart to pick up new qubes (amusingly, a friend has the opposite issue, where only qubes started after the AudioVM are able to connect to it); YouTube struggles a bit due to lack of video acceleration, though mpv doesn't seem to have any trouble.
Chrome crashes once in a while - either the whole browser or individual tabs with SIGILL. It's been suggested that this is due to memory pressure, but the VM is assigned more than enough memory; it might be due to the difference between initial memory and maximum memory, but the crashes are infrequent enough that I haven't experimented with it.
One particularly bothersome issue occurs when adding a new display after boot. Due to qube video memory configuration, clicking on parts of the screen doesn't register the input. There is a fix for this issue; I quickly tried it at one point but couldn't get it working, and also left it at that since I rarely add displays.
It's buggy, yes, but isn't every other piece of technology? Qubes is not for everyone; I'm happy to trade some bugs for some convenience.
Or you're just too lazy to actually fix issues. You're forgetting the time you spend every day working around them!
Hey, that's unfair! I choose my battles!
I recently got a second external display to use at my desk. I couldn't quite get it working at first: it would enable the screen but not render windows, or the screen would appear enabled in xrandr while giving a "no signal" message; dom0's dmesg had a drm error that I couldn't make heads or tails of. Eventually, I got it working somehow.
This morning I got a new keyboard for my desk. It didn't immediately work even though it appeared to be connected to dom0 (I later found out I had to enable a keyboard policy); as part of troubleshooting, I rebooted the machine... and the external display stopped working. After some more futile troubleshooting, I tried turning off the laptop's internal display. This did, reproducibly, fix the external display.
I was at a loss. Surely a modern GPU, even a mobile one, could drive three modest-resolution displays? Right?
That's it, I'm done with this buggy mess, I'm switching away from Qubes!
...so I thought to myself. I flashed an Ubuntu live USB, booted into it, plugged in my external displays, and after a few screen refreshes...
The display session crashed. That's... not what I expected.
Maybe it's time to stop trying to fix this, and start looking to replace the hardware. The AMD Framework mainboards are tempting (there is a promising HCL report)... though going back to a Thinkpad doesn't seem like a bad option either.
We'll see!
