zlacker

I love Qubes a lot, I daily drove it for a few years and still have it on a laptop. but i would not recommend it even to most technical people, mainly because you forfeit the ability to run things on bare metal. "dom0" is the same as on normal xen - it is a VM and has the associated overhead still. On top of that, the official Qubes dom0 runs a very outdated fedora version.

I am instead writing my own code to automate libvirt to replicate much of Qubes' functionality (ephemeral roots for vms, disposable vm support, GUI isolation) so i can still have Qubes security for most of my apps but fully exercise my hardware when I want.

There are also some minor criticisms i have of Qubes' default, mainly that appvms have passwordless sudo by default and less importantly, no MAC such as apparmor. Passwordless sudo arguably makes it somewhat easier to break out of the VM and no in-vm sandboxing means you have to run every in a separate VM unless you want to set that up yourself.

For example i don't really want my work thunderbird to have access to my work browser, so a single "work" domain isn't enough for me.

>>beardo+(OP)
To add, it works quite well if you can accept the caveats of no (easy/default) GPU access (so no gaming). It is not a lot slower if you have enough ram to keep your VMs booted, i mainly noticed a difference in i/o speed but that may have been my particular setup.

You aren't meant to mess with dom0 (so also your desktop) much, so ricers won't like it unless they are willing to break the security model somewhat.

It is also not meant to be a shared PC.

Windows (10) support is pretty mediocre but it does work. I was able to do a WFH job that required windows using it without pain - you don't get seamless windows though.

>>beardo+(OP)
The threat model assumes that any code in a VM can, with some application of effort, access anything else in that VM. Given the relatively low cost of local root exploits and kernel exploits, this is reasonable. Passwordless sudo is simply a reminder that you can't rely on intra-vm separation of anything you care about separating.

If you wanted to add additional hardening within a VM, it's supported - create your own templateVM for it, and use it. It's just not the default, and I generally agree with it. If you trust the OS kernel and features to keep things separated, there's no reason to run Qubes in the first place.

>>Syonyk+I3
>If you trust the OS kernel and features to keep things separated, there's no reason to run Qubes in the first place.

Yeah i see the argument - thats why I would still call Qubes very secure as is - but i personally prefer defense in depth. Mainly it would be helpful on machines with limited ram that can only run a few domains at once.

>>beardo+(OP)
> the official Qubes dom0 runs a very outdated fedora version

Why does it matter? You do not run anything in dom0: https://www.qubes-os.org/doc/supported-releases/#note-on-dom...

>>beardo+(OP)
What do you personally want to run on bare metal? I've been using Qubes for 7 years and the only thing I've missed is running MAME since Qubes doesn't do nested virtualization. But I do everything else I need on there - software dev, office productivity, web browsing, email, video transcoding, Spotify etc etc. It's rare I would ever need bare metal. (I'm not a PC gamer though...)

>>educti+Da
Pretty much everything you listed, plus games. All of that minus games is still usable on Qubes but there is a noticeable speed decrease.

>>fsflov+L5
As i said in my comment I personally want to run (some) things on bare metal, and Qubes is not good for that, which is good for their security model but is a deal breaker for me.