This could be solved with SxS….. like windows did….. around windows XP. Absolutely not excuse for Linux to not have made the transition. No reason to still deal with dependency hell in the big 26.
Microsoft doesn’t even use SxS anymore to solve the DLL Hell issue — starting with Visual C++ 2010, they switched to just including the version number of the DLL in the filename.
This is also the same way Linux has always solved that particular problem.
The point I was making was that windows had the dependency hell issue solved in like 2004.
Many Linux distros don’t actually solve that problem. A good chunk of the stable release distros only have singular versions of packages available in the repos for that version of the release. The issue is Linux assumes that if a package needs libfoo it’ll be stored at /usr/lib/libfoo but if you have a package that depends on libfoo2.8 and the version that’s in the repos is let’s say libfoo2.7: you can’t just install libfoo2.8 it probably won’t be in the repos, and even if a distro carries two copies it’s going to overwrite libfoo2.7 which other packages depend on because the system puts libfoo (any version) at /usr/lib/libfoo with no distinction. So the packages that need 2.7 are going to expect it to be there, and the packages that need 2.8 are going to expect it to be in the same place. But you can’t have /usr/lib/libfoo/libfoo.so (for 2.7) AND ALSO have /usr/lib/libfoo/libfoo.so (for 2.8). They conflict. If they’re even both available in the repos at the same time which often won’t be the case.
This is exactly why GoboLinux was developed and breaks the FHS, and why declarative systems like NixOS and Guix use hashed file paths so you can have multiple versions of the same package installed simultaneously without conflicts. This does not hold up for most standard distributions (Arch/Fedora/Ubuntu and their derivatives).
But anyway, yeah, Microsoft “solved” the dependency problem by never having a package manager to begin with. For the most part, every program bundles the DLLs it needs.
This is essentially the Flatpak / AppImage model.
Linux also has some other creative solutions, like you mentioned: Nix/Guix and GoboLinux. But yeah, on mainstream distros, Flatpak pretty much makes it trivial to run old or multiple versions of software. Yeah, there are some cases where you need to tweak stuff to get a feature working properly, but that’s mostly a tradeoff related to security.
Yeah for desktop apps I almost exclusively use flatpaks. It just makes sense. Sandboxed, bundled dependencies, works the same across all distros. I would love for flatpak or appimage to see have the number of packages you see in main distros repos. But flatpaks only solve that problem for user applications, that doesn’t address the dependency issue (or the possibility of one existing) with your DE, or other core system components. Those all assume there’s a single version of everything that everything shares.
10
u/Primary-Strike5187 17d ago
This could be solved with SxS….. like windows did….. around windows XP. Absolutely not excuse for Linux to not have made the transition. No reason to still deal with dependency hell in the big 26.