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).
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.
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.
Yes, but it's a compromise, because I'm not happy spinning up tons of kernels and trying to share access to devices that do not want to be shared, either.
You're right that the trusted codebase is huge, but I sincerely do not know how big a problem this is in practice, hence the question.
Qubes does have answers to the device stuff, like sticking network devices in a network vm, which only talks to a firewall vm, which talks to your other vms. There is a reasonable gui interface where you can just plug devices into particular VMs for other things.
In my usage I've never felt the need to share stuff other than the network/sound/storage stuff that qubes make just work. Other devices tend to be just plug them into the particular VM that needs them. YMMV.
I would say that perhaps containers could do just as well, or some other technology. The thing qubes brings to the table is that other people are doing most of the heavy lifting to make a usable desktop out of a highly virtualized system.
There may be path dependent reasons why qubes approach isn't the best possible... but it doesn't matter because so much stuff just working is worth so much. That the compromise we always make when running a distribution... one could meta-x butterfiles and write your own kernel from scratch, or whatever. Or you can run a system created by others. Their system may have decisions you disagree with or are objectively bad, but they saved you 12 months of tinkering with the dynamic linker-- well worth it. :)
For me, the alternative of having my whole laptop compromised by some browser zero day or because a malicious party sent me some malware document was just not viable. I was already carrying two laptops for isolation, and suffering some anxiety from the residual risk. But in my case I've been targeted specifically (due to cryptocurrency bullshit), a friend and former colleague was hit with an astonishingly sophisticated attack that used stuff like BMC vulnerabilities on his web server and then traversal with X11 forwarding and stuff like that all to just break into his desktop.
So I'd probably be using qubes today even if I could only move the mouse with my tongue and the computer was slowed down to the speed for a 486sx. But the incorrect belief that it would be that kinda hit really delayed my adoption. It's a hit, it's real, but at least for my usage it was far smoother than I expected.
I think right now the only obvious wart I experience is that full screen video stutters pretty badly. So I just don't watch video full screen on the laptop now. There are things that might fix it, but I haven't bothered even trying.
There are benefits I didn't expect too. For example, The operating system image in a normal application VM isn't persistent, only your home directory. So you can just scribble all over the OS install in an app vm and it'll go away when you restart it. If you want it to be persistent you change the underlying templatevm. So to get something working I can totally take a chainsaw to my configuration confident I won't get stuck with anything broken. Once I figure out the changes I can apply just the required steps in a template.
Another benefit is that updating fedora versions is a riskless breeze--- install a new template vm. shut down your app vms, click to change template. Restart them if some particular app vm is broken, switch it back and worry about it when you have time.