Hacker News Reader

Comment by fransje26 | Hacker News Reader

From your experience, what are the system requirements needed to use that as comfortably as your daily driver?

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.

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

Doesn't Flatpak also solve this?

No, flatpack is very much not a security sandbox.

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

repeated myself somehow

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.

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?

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.

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

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.

> "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?

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

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.

It depends on how you use it. The more you leverage its strengths (by splitting out AppVMs), the larger the overhead in memory and CPU.

I've run through a few QubesOS installations over the years and would say for me it's ~2x memory and a couple of cores overhead.

So aim for at least 64GB of memory?

Yeah. I have to stay conscious of resource usage and can't run all the stuff I'd really want (which TBF is a bit) at 32.

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.

Important consideration, thank you.

Edit: Seems like someone has managed to get CUDA to work, with some effort.

https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin...

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.

Reply on news.ycombinator.com