4 ms·

Dynamic Library hell is why Docker exists. If operating systems had less global state and less ambient authority, our systems would be vastly more tractable. In

Dynamic Library hell is why Docker exists. If operating systems had less global state and less ambient authority, our systems would be vastly more tractable. Instead we still create environments that look like replicas of whole hosts. Might as well go all in and use something with pervasive virtualization like Qubes. https://www.qubes-os.org/ https://www.qubes-os.org/

deleted 3y ago
[deleted]
palata 3y ago
To be fair, QubesOS does not really solve the problem of bad libraries creating dependency hell. If you need to ship every app with its own rootfs because you can't handle dependencies, then you will have to do that on QubesOS as well (you don't want one VM per app). Also the biggest problem I had with QubesOS is that it doesn't support GPU (for security reasons). It feels like that was a big cause for the reduced performance. I wish there was a solution for the GPU, and then I would love to daily-drive QubesOS.
- soulofmischief 3y ago
  Same, I love Qubes' philosophy and UX, but GPU passthrough support was a dealbreaker in the end and I switched to a KVM system.
  - TimeBearingDown 3y ago
    I’m pretty sure GPU passthrough does work in Qubes HVMs, although I haven’t tried it myself. Here are three quick and recent tutorials I found including one with a newer VirtualGL approach that offloads work instead of passing the entire card. https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-linux-hvms-for-cuda-applications/9515 https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin... https://forum.qubes-os.org/t/seamless-gpu-passthrough-on-qubes-os-with-virtualgl/20265 https://forum.qubes-os.org/t/seamless-gpu-passthrough-on-qub... Yes, the passthrough is probably a huge avenue for attacks. Possibly VirtualGL too, I know less about that.
    - TimeBearingDown 3y ago
      One more, site won’t let me edit. https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html
      - Qwertious 3y ago
        That's the same as the first link in your previous comment. Did you manage to edit it after all?
        TimeBearingDown 3y ago
        Yes, thank you.
    - soulofmischief 3y ago
      Does this fix the Code 14 issue with NVIDIA cards? That is why I had to switch to KVM back in 2016, as KVM has support for bypassing NVIDIA's "bug" which prevents using consumer cards in a virtual environment. I have been away from Qubes for 7 years now so I'd hope some form of improvement has been made.
      - TimeBearingDown 3y ago
        Are you referring to Code 43? I believe the NVIDIA drivers after version 465 may not have this issue. Here’s a report of this working on Qubes/Xen: https://forum.qubes-os.org/t/qubes-gpu-passthrough/661/12 https://forum.qubes-os.org/t/qubes-gpu-passthrough/661/12 However you may need to hide the virtualization from some games or other software, where Qemu/KVM can be more flexible. There’s a project and some discussion to use these with Qubes, but it’s early days: https://github.com/nrgaway/qubes-kvm-dev https://github.com/nrgaway/qubes-kvm-dev https://forum.qubes-os.org/t/porting-qubes-to-hypervisors-other-than-xen-abstracting-the-functionality-early-stage/23478 https://forum.qubes-os.org/t/porting-qubes-to-hypervisors-ot...
        3y ago
IshKebab 3y ago
Exactly this. Windows apps aren't distributed as Docker images. Guess why...
- palata 3y ago
  Well nothing prevents you from dynamically linking only glibc and statically linking everything else, without Docker at all. The fact that people distribute their app with a full rootfs in a Docker containers says more about the fact that they don't know how to link stuff properly, IMHO.
  - IshKebab 3y ago
    It's not about static vs dynamic linking at all. It's about bundling dependencies or not. And yes, you totally can do it. Most Linux software just doesn't bother because - while you can do it, in a lot of languages (C, Python, etc.) it's quite a pain to do. Especially if you have lots of dependencies. It's much easier to bundle dependencies in languages that statically link by default (Go, Rust) because of course statically linking implicitly bundles them.
    - palata 3y ago
      > Dynamic Library hell is why Docker exists. > It's much easier to bundle dependencies in languages that statically link by default > It's not about static vs dynamic linking at all. Sorry I'm confused :/. What did I say that you disagree with?

deleted 3y ago

[deleted]

palata 3y ago

To be fair, QubesOS does not really solve the problem of bad libraries creating dependency hell. If you need to ship every app with its own rootfs because you can't handle dependencies, then you will have to do that on QubesOS as well (you don't want one VM per app). Also the biggest problem I had with QubesOS is that it doesn't support GPU (for security reasons). It feels like that was a big cause for the reduced performance. I wish there was a solution for the GPU, and then I would love to daily-drive QubesOS.

soulofmischief 3y ago
Same, I love Qubes' philosophy and UX, but GPU passthrough support was a dealbreaker in the end and I switched to a KVM system.
- TimeBearingDown 3y ago
  I’m pretty sure GPU passthrough does work in Qubes HVMs, although I haven’t tried it myself. Here are three quick and recent tutorials I found including one with a newer VirtualGL approach that offloads work instead of passing the entire card. https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-linux-hvms-for-cuda-applications/9515 https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin... https://forum.qubes-os.org/t/seamless-gpu-passthrough-on-qubes-os-with-virtualgl/20265 https://forum.qubes-os.org/t/seamless-gpu-passthrough-on-qub... Yes, the passthrough is probably a huge avenue for attacks. Possibly VirtualGL too, I know less about that.
  - TimeBearingDown 3y ago
    One more, site won’t let me edit. https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html
    - Qwertious 3y ago
      That's the same as the first link in your previous comment. Did you manage to edit it after all?
      - TimeBearingDown 3y ago
        Yes, thank you.
  - soulofmischief 3y ago
    Does this fix the Code 14 issue with NVIDIA cards? That is why I had to switch to KVM back in 2016, as KVM has support for bypassing NVIDIA's "bug" which prevents using consumer cards in a virtual environment. I have been away from Qubes for 7 years now so I'd hope some form of improvement has been made.
    - TimeBearingDown 3y ago
      Are you referring to Code 43? I believe the NVIDIA drivers after version 465 may not have this issue. Here’s a report of this working on Qubes/Xen: https://forum.qubes-os.org/t/qubes-gpu-passthrough/661/12 https://forum.qubes-os.org/t/qubes-gpu-passthrough/661/12 However you may need to hide the virtualization from some games or other software, where Qemu/KVM can be more flexible. There’s a project and some discussion to use these with Qubes, but it’s early days: https://github.com/nrgaway/qubes-kvm-dev https://github.com/nrgaway/qubes-kvm-dev https://forum.qubes-os.org/t/porting-qubes-to-hypervisors-other-than-xen-abstracting-the-functionality-early-stage/23478 https://forum.qubes-os.org/t/porting-qubes-to-hypervisors-ot...
      - 3y ago

IshKebab 3y ago

Exactly this. Windows apps aren't distributed as Docker images. Guess why...

palata 3y ago
Well nothing prevents you from dynamically linking only glibc and statically linking everything else, without Docker at all. The fact that people distribute their app with a full rootfs in a Docker containers says more about the fact that they don't know how to link stuff properly, IMHO.
- IshKebab 3y ago
  It's not about static vs dynamic linking at all. It's about bundling dependencies or not. And yes, you totally can do it. Most Linux software just doesn't bother because - while you can do it, in a lot of languages (C, Python, etc.) it's quite a pain to do. Especially if you have lots of dependencies. It's much easier to bundle dependencies in languages that statically link by default (Go, Rust) because of course statically linking implicitly bundles them.
  - palata 3y ago
    > Dynamic Library hell is why Docker exists. > It's much easier to bundle dependencies in languages that statically link by default > It's not about static vs dynamic linking at all. Sorry I'm confused :/. What did I say that you disagree with?