Hacker News new | past | comments | ask | show | jobs | submit login

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/




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.


Same, I love Qubes' philosophy and UX, but GPU passthrough support was a dealbreaker in the end and I switched to a KVM system.


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://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin...

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.


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.


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

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://forum.qubes-os.org/t/porting-qubes-to-hypervisors-ot...


Yes sorry, I meant 43. It's been a long time :)

> However you may need to hide the virtualization from some games or other software, where Qemu/KVM can be more flexible.

How prevalent is this? Is it basically just multiplayer games employing anticheat?



That's the same as the first link in your previous comment. Did you manage to edit it after all?


Yes, thank you.


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


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.


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.


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




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: