4 ms·

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 turnin

by nullc 2y ago

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.

mikedelfino 2y ago
> a world where a random click from HN or reddit can't quietly compromise your entire computer Doesn't Flatpak also solve this?
- nullc 2y ago
  No, flatpack is very much not a security sandbox.
  - mikedelfino 2y ago
    Do you mean you don't trust it? Because they do describe its sandboxing as a security feature.
    - EasyMark 2y ago
      repeated myself somehow
    - EasyMark 2y ago
      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 2y ago
        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 2y ago
        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 2y ago
      it's easy for something with arbitrary code execution to escape the sandboxing. https://hanako.codeberg.page/ https://hanako.codeberg.page/
      - mikedelfino 2y ago
        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.
prmoustache 2y ago
> "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 2y ago
  I dunno about that? do you use more than one gpu intensive task at a time?
  - prmoustache 2y ago
    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 2y ago
      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 2y ago
        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-charge-1-000-devices-140w-max-output-from-one-port 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.

by nullc 2y ago

mikedelfino 2y ago

> a world where a random click from HN or reddit can't quietly compromise your entire computer Doesn't Flatpak also solve this?

nullc 2y ago
No, flatpack is very much not a security sandbox.
- mikedelfino 2y ago
  Do you mean you don't trust it? Because they do describe its sandboxing as a security feature.
  - EasyMark 2y ago
    repeated myself somehow
  - EasyMark 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
    it's easy for something with arbitrary code execution to escape the sandboxing. https://hanako.codeberg.page/ https://hanako.codeberg.page/
    - mikedelfino 2y ago
      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.

prmoustache 2y ago

> "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 2y ago
I dunno about that? do you use more than one gpu intensive task at a time?
- prmoustache 2y ago
  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 2y ago
    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 2y ago
      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-charge-1-000-devices-140w-max-output-from-one-port 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.