They're increased, and some things are just obviously slow at least without extra effort to setup things like gpu pass-through. But is it worth basically turning back the clock on your computer's performance a few years to live in a world where a random click from HN or reddit can't quietly compromise your entire computer? I think so.
Probably the biggest thing is to have a lot of ram, because if you're really using the virtualization it's a bit ram inefficient.
Many things I expected to be hard or annoying just turn out to be non-issues. Qubes has lots of good automation to make it pretty seamless to use multiple VMs.
I was already a fedora user, so I just copied my old home into a new app vm and was instantly productive. Then over time I weaned myself off the monolithic legacy vm into partitioned VMs.
Please define GPU intensive. Using a gpu for video decoding can mean smaller battery usage in some cases.
Also it is not only about doing these tasks at a time, but if you need to shut down to be able to start another VM context because they can't be used concurrently it makes it very tedious user experience.
A normal qubes user workflow doing all your gpu requiring stuff in a single appvm-- you're not forced into isolation that doesn't work for you.
But you're also not running qubes if minimizing battery usage is a high priority for you.
As far as the tedium, perhaps a little, but bringing up a terminal on a non-currently-running app vm takes about 5 seconds for me, so it's faster than you might expect.
I think in general my view is that qubes has serious operating costs but they are much less than I anticipated.
And whats the real alternative? It's still better than carrying 5 laptops in terms of ease and usability.
We live in a world where browsers are constantly required but where their probably hasn't been a single day since their initial releases where Chrome and Firefox were without a RCE vulnerability (though often not a publicly known one).
USB-C PD has made laptop battery life less of an issue than it used to be, because carrying around extra battery life with external batteries is so easy. I typically carry one or two of these in my backpack: https://iniushop.com/products/iniu-b64-140w-27-000mah-fast-c...
That's enough for hours of intensive usage on my laptop, like running nodes and compiling stuff. And as you know, I run Qubes too!
I originally got an external battery when I went to Ukraine while Russia was trying to destroy the electricity grid; I got the largest battery I could legally carry on a plane (typically 100Wh is the limit). I ended up liking them enough to buy a few more.
flatpak or firejail would have protected you from this vulnerability, not sure what they're on about here. They are 100% proof against everything of course.
I couldn't reproduce the tty example, but it might as well be a mistake on my side. Other than this, the sandboxing spec itself is as safe as I'd expect. I reckon that Wayland applications not packaged to require $HOME access or some dbus services are not known to escape the sandbox. This seems to be the case of Firefox, afaict.
If you anything with a GPU anywhere, you can essentially forget it. Or at least this was the case a few years ago when I briefly toyed with using qubes seriously.
The situation has indeed improved and things have gotten smoother over the past few years IME! (AMD)
If you run multiple GPUs (so one for your GUI and the rest for whatever else you want to do), PCIe passthrough for the latter is pretty straightforward these days.
You can set up a dedicated gpu qube for the former - recommended but optional.
Probably the biggest thing is to have a lot of ram, because if you're really using the virtualization it's a bit ram inefficient.
Many things I expected to be hard or annoying just turn out to be non-issues. Qubes has lots of good automation to make it pretty seamless to use multiple VMs.
I was already a fedora user, so I just copied my old home into a new app vm and was instantly productive. Then over time I weaned myself off the monolithic legacy vm into partitioned VMs.