[nullc]

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.

[prmoustache]

> "obviously slow at least without extra effort to setup things like gpu pass-through."

AFAIK unless you have a desktop computer filled with gpus on pciexpress slots there is no way you can use GPU passthrough on multiple VMs.

That kind of defeat the purpose of qubes os no?

[nullc]

I dunno about that? do you use more than one gpu intensive task at a time?

[prmoustache]

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.

[nullc]

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).

[petertodd]

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.

[mikedelfino]

> a world where a random click from HN or reddit can't quietly compromise your entire computer

Doesn't Flatpak also solve this?

[nullc]

No, flatpack is very much not a security sandbox.

[mikedelfino]

Do you mean you don't trust it? Because they do describe its sandboxing as a security feature.

[EasyMark]

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.

[nullc]

The firefox flatpak has write access to your home directory. So it can simply edit your bashrc even if there are no more direct escapes, no?

[mikedelfino]

Firefox Flatpak has neither write or read permission to your home directory. At least that's my take from browsing file:///home/myuser. If you try to open or save a file using the native dialogs, you do grant the appropriate permission on demand, but that's using the xdg portal, outside the app scope, specifically designed for this.

[nullc]

it's easy for something with arbitrary code execution to escape the sandboxing. https://hanako.codeberg.page/

[mikedelfino]

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.

[EasyMark]

repeated myself somehow