I've been using it as my daily dev machine for ~5 years now.<p>As per the article, the usability tradeoffs are considerable. But the separation of domains into separate VMs is really lovely. If nothing else, having a separate VM per client just feels "right". No intermingling of code and, even more importantly, secrets or credentials or even comms. Being able to use the same physical machine for personal stuff as well as work is also a bonus.
One of the killer features of Qubes when I used it was the ability to "pause" a VM and all of the apps running in it. That's something I've tried to replicate with tools like tmuxp but I've never found an abstraction as clean as "serialize the whole process tree to disk" like Qubes has.<p>I gave up on it for usability reasons, but that feature is killer. Anybody else aware of anything similar?
More reasons to use it: <a href="https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15" rel="nofollow">https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15</a>.<p>And also, one reason could be ascetism, <a href="https://news.ycombinator.com/item?id=42099398">https://news.ycombinator.com/item?id=42099398</a>.
This is the same concept as CoreOS, which now lives on as Flatcar, though with harder isolation guarantees because VMs.<p>I love the idea. Extremely minimal attack surface.<p>At the moment, I'm working on building a virtual version of the NUC that I purchased that will also run Flatcar so that I can test the configuration of my Docker Compose services.
I hope Qubes OS developed a solution for GPU passthrough by now, as, reading the article, that's the only thing that's missing, back in 2023. Similar to how sys-net and sys-usb work, we need sys-pci and ... done.