I'll take bloat over dependency hell every day of the week. Feels like every single app is a bundled web browser these days anyways.
Might as well go all in and use something with pervasive virtualization like Qubes.
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.
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.
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...
> 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?
https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html
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.
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.
> 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?
Dependency hell comes from bad dependencies that don't do semver properly. Choose your deps carefully, and that's perfectly fine.
> Feels like every single app is a bundled web browser these days anyways.
Yep, that's apparently the best way to use the bad libraries people want to use and not give a damn about semver.
Most things might be solved by everyone doing SemVer. And for all I know some communities might be running like greased pigs in a chute exactly because they use SemVer (I don’t tend to hear about the everyday everything-is-working stories on HN). But also doing static linking a bit more seems like it would help a lot with the same problem.
[1] All based on discussions I’ve seen. Not really personal experience.
[2] Again, making a spec/manifesto which is both about machine-readability and about shaming people for vague things is very muddled. Although I don’t know how much the latter is about the culture around it rather than the spec itself.
> It seems impossible to solve this by just everyone adopting a manifesto that one GitHub guy wrote many years ago
Well by "semver" I mostly mean "change the major number to indicate a change of ABI", I don't mind so much about the other numbers in this case. But that's a good question: I don't know when it started being a thing. I would guess much, much earlier than GitHub, though.
> human judgement about what is breaking and not
Hmmm... ABI compatibility for the public interface is not really subjective, or is it?
> weird implicit social taboos about doing major releases “too often”
Yes I don't get that one and I fight hard against it.
> But also doing static linking a bit more seems like it would help a lot with the same problem.
Well I am not fundamentally against static linking; to me it makes sense to do a mix, with the caveat that if you link something statically, then you are the maintainer of that code. Whereas if you link a system library dynamically, you merely depend on it.
My problem is about moving to "static linking only" (or "by default", but I don't even know if Rust allows dynamic linking at all?).
1. Software depending on versions of libraries that are newer than the latest version available on the distro you have to use (cough RHEL 8). E.g. this very day I ran into a bug where some Asciidoctor plugin craps out with an error because my version of Ruby isn't new enough. Ruby's advice for how to install Ruby is "use your package manager; you will get an old version btw fuck you".
90% of the time it's bloody glibc. Every Linux user has run into the dreaded glibc version error dozens of times in their career.
2. Software that can't install multiple versions of the same package, leading to diamond dependency issues. Python is very bad for this.
That is a fair point, but it raises a question: if you absolutely need to use software that is not packaged by your distro of choice and that you cannot package yourself (are you sure you can't maintain a "community" package yourself with RHEL?), maybe you don't want that distro.
Different distros come with different goals. If you take a "super slow but secure" distro, it will be slow and secure. If you take a rolling distro, you get updates very quickly but it has drawbacks. It depends on the use-case, but going for a "slow and secure" distro and then building tooling to work around that choice ("nevermind, I'll ship new and less mature software anyway, statically linked") seems to defeat the purpose of the distro... right?
Well I definitely don't want RHEL 8 but unfortunately I have to use it because some software I use requires it (RHEL 9 doesn't have old enough versions of some libraries) or is only certified on it (this is for work).
But even if I was using a more modern distro, none of them have all software packaged. And no I obviously don't want want to become a packager. Some of the software I use is closed source so that's not even an option.
The only real option is Docker (or Apptainer/Distrobox etc), which sucks.
The fundamental model of "we'll just ship all software that exists; all software is open source" that most distros try to use is just fundamentally wrong.
Snap and Flatpak are trying to fix that but in my experience they aren't remotely ready yet.
It's usually straightforward with end user applications, such as bash or git or ruby. Things more likely to be tied to the rest of the operating system, such as SELinux or PAM, are less likely to work. If there are dependencies to things that is release dependent, it's not worth the bother.
Maybe you can argue you don't want to "become a packager", but someone has already done the work for you and you don't need more than superficial knowledge about the system to do it. In most distributions, source packages aren't harder to install than binary packages.
That's where I disagree. It's not that hard, and if more people did it, more software would be packaged. Actually I am yet to find a library that I actually need and that is not already packaged and maintained by someone from the community. Then I could finally maintain one myself.
To me, you're basically saying: "I don't want to learn and commit to maintain a package for my distro, because reason, but I am fine spending time with all that tooling that I say "sucks" (Docker/Apptainer/Distrobox)". That's what I don't really get. There is a solution that works well (for me, at least): package the software that is not already available yourself.
> Some of the software I use is closed source so that's not even an option.
I would not want to maintain a package with proprietary binaries that I don't own, that's for sure. But if you need to, you can. As long as the author distributes binaries for your platform, it's not much harder than making an open source package.
I would leap for joy to see Red Hat or Debian or even Gentoo make inroads here, but I haven’t looked closely enough and recently at Debian, and .ebuild files hurt my brain. I do believe I recall Gentoo requiring more work to get my packages available and listed anywhere.
Well we'll have to agree to disagree on that, but I think if you told most people that the normal way to install third party software for Linux was to become a package maintainer they would rightly laugh you straight to the asylum.
> That's what I don't really get.
The reason is that Docker, Apptainer etc are much easier than creating packages for all the dependencies of the software I want to run. Multiplied by the number of distros I need to use. Pretty obvious no?
Take it like this: in the current state, I am struggling to find a single interesting library for which I could become a package maintainer for my non-mainstream Linux distro, because there always exists one. Maybe not in the core repo, maybe only in the community repo. But still: I don't maintain a single package today, because I haven't found one that I use and that it not already maintained by somebody else.
Really, if you decide to create packages for all the dependencies of the software you want to run, congratulations: you have just created a new distro from scratch. But even most new distros don't do that :-).
In other words, there are way more developers than libraries that are worth being depended on. So even if we wanted to, not everybody can maintain a single package. There are just not enough packages out there for that, by very, very far.
> Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive.
If it's not in the API, it is not bound by the rules. Many ecosystems come up with various norms, like Rust has, to help guide people in this. But it's almost certainly not a semver violation to make the change described in the XKCD because "handle unknown unknowns" is not possible. That doesn't mean that we should throw out the entire idea of software assisted upgrades to dependencies.
The breaks happen regardless, but you have a principled way of defining whose fault/problem it is.
That's the thing: I feel like people tend to call "dependency hell" what I would consider downright malpractice. "Shared libraries don't work because they require good practice" is, IMO, not a good argument against shared libraries. If you need to design your tool with the constraints that "users will use it wrongly", then it's already lost.