You don’t necessarily need QubesOS to get better isolation. You can package unsupported applications as Flatpaks yourself and run them with minimal permissions. The downside is the maintenance burden, and Flatpak sandboxing isn’t as strong as Qubes’ VM-based isolation. It’s a useful middle ground, but it doesn’t completely solve supply-chain risk. Qubes can be good, but it's all about your friction budget.

Humans optimise for convenience eventually.

I would try Secure blue first, if you are still comfy then try Qubes. Real security can be annoying. Test what's your limit.

I use it as a daily driver for years now. Just a few things to learn on top of regular linux and you are good to go. Feel free to ask anything.

You are more protected from supply chain attacks but I think it's not a long term solution

I haven't even tried it. GPU is too important these days. They recommend using a separate system entirely for GPU-intensive tasks. I actually do have that setup in a way, but only for the most GPU-intensive tasks. I don't want to have to switch devices just to watch a video without draining half my battery.

It's the GPU companies' fault, of course, but that doesn't change much.

I adore Qubes!

Until a new version of Fedora gets EOLed. Or Qubes itself.

Setting up ALL of those distros every 3-6 months is a pain in the dick even when nothing goes wrong. And something always goes wrong with enough complexity.

QubesOS is not meant for app sandboxing. Running each app in its own qube is very expensive, and hard to maintain. QubesOS are designed around the concept of domain compartmentalization, letting you to limit blast radius.

I use QubesOS for finance related stuff, and also thinking to use it for sysadmin tasks on my homelab. Daily driving it seems too complicated for me

I've always been curious about it, but felt like it might be a pain to try to use as a daily driver.

I've fairly thoroughly hardened my Void install, have an update and CVE audit workflow, and use firejail to sandbox any apps that make sense to sandbox. That feels more than enough for me.

A couple of tricks I use:

• an apparmor profile tied to a shell script that wraps other commands .. it restricts read & write access to a scratch directory ... perfect for builds or one off scripts.

• iptables rules & cgroups to restrict network access.. I have a setuid wrapper that drops privs again..

• bwrap and mounting only what's necessary... quick to get going.

• custom landlock wrapper, similar to apparmor but allows for quick userspace wrapping.

They can be combined too.

I've been daily driving Qubes OS for last 6 years. You don't need to be an Linux expert but you should know basic things. And few common commands and maybe simple bash scripting if you want some level of customization

Main thing is divide your personas,and create a Qubes for each of them. and if you just want to search for some random shit use disposable VMs

My setup is something like this I've 3 debian and 3 fedora templates 1 minimal used for sys VMs and vault, 2 normal template here I only install packages only available in official debian/fedora, repos 3 in this template I add custom repos which are still trustworthy

Then depending on what I need in which app on I assign the template.

I'm forced to use zoom and other very intrusive apps for them I've just setup the rc.local script (this runs with start of any Qube) to install them

Also even though Qubes provides isolation at Qube level I still use firejail inside all the VMs it just takes few minutes to setup and gives a peace of mind

Also Hassel depends on what you use it for. Few pain points for me are

1. Nested virtualization isn't possible* there are some workarounds and in most cases it's okay. The only problem is for Android app development. In that case the best solution is to just use adb and connect your own device

2. PCI passthrough it was really terrible few years ago but now it works in most cases but for me sometimes my Laptop overheats. I don't need it much often so i haven't spent time to fix it.

The latest attack on the AUR would be solvable by Nix, in theory, Qubes would still suffer from this, only it's compartmentalized, whereas Nix would be safe from my understanding.

No. Security and privacy are necessary but are nothing if not balanced with convenience. A little sacrifice of convenience is necessary but Qubes and even Secureblue passed the mark in my rule. This comes from one that has in its installation: LUKS, Secure boot, TPM PCR 7 verification, Apparmor.d updates and enforced, UFW, dnscrypt, run0, AIDE, Lynis, auditd, checking reproducible packages, etc...

I've never daily driven it as my main machine but I've used it as an auxiliary driver for a more high-security machine. Afaik things like gaming are sort of a no-go on Qubes still.

Qubes does not just do sandboxing. It runs all user programs in VMs, which adds non-negligible overhead and makes it an unsuitable OS for many more lightweight systems like laptops. And even if your PC can run Qubes without issue, you may not want that additional overhead if you want to do anything computationally intensive.