9 ms·

The state of GNU/Linux and a case against shared object libraries

marssaxman 2y ago
> Shared dependencies were a mistake! Couldn't agree more.
EdwardDiego 2y ago
Fedora is a "move fast maybe sometimes break things" distro, e.g., early adoption of Btrfs as the default, Wayland etc. So yeah, these things sometimes happen.
shams93 2y ago
That's Fedora, its a bleeding edge experimental distro when it comes to the desktop at least. Ubuntu has become really popular because it is stable and reliable. My friends who use linux to perform live electronic music all use ubuntu studio and have been for over 15 years now.
- shams93 2y ago
  However these days its much easier to run a linux desktop on a system that comes with it, some of these laptops have driver issues where they can work but then can run into things like thermal and display issues due to closed code with very complex non-standard low level drivers.
- yesco 2y ago
  While Ubuntu is a great distro to get things up and running, a lot of their decision making around snap has begun to make me hesitant to recommend it to people. While there is the political/open source angle in regards to how they are handling the servers for snap, my main issue is primarily the stability. Randomly I'll install something with apt and it will not give me an apt package, it will give me a non-standard snap package that becomes difficult to troubleshoot. In the case of firefox, it basically makes it less stable than a nightly build considering how often it crashes, and subtly breaks screen sharing in weird non-obvious ways. This experience has me guessing that Canonical probably cares more about server Ubuntu now than it does about desktop Ubuntu, which is a real shame. While there are workarounds, I specifically endorsed Ubuntu in the first place to many people because these kinds of workarounds used to not be necessary. It's a real bummer honestly, not sure what else to recommend in this category either.
andrewstuart 2y ago
If “gnu” gets headline billing for providing some user land tools then really “systemd/Linux” should be the current operating system title because systemd pervades the distros mentioned in this article. In many ways systemd IS the operating system outside the kernel.
- johnea 2y ago
  And in fact systemd/linux is what I consider the biggest digression in linux over the last decade. It pushes for a single upstream for all of userland. With IBM being that single upstream. After decades, I'll leave archlinux in my next migration because of this.
  - sho_hn 2y ago
    Neither of the systemd lead maintainers works for IBM (or the same company).
  - ChocolateGod 2y ago
    > It pushes for a single upstream for all of userland. With IBM being that single upstream. I hate to break it to you but what do you think the GNU Project is?
  - pessimizer 2y ago
    It's astounding how easily people slipped from defending Red Hat owning so much of Linux with their giant labyrinthine subsystems to literally defending IBM ownership. When Google or Facebook buy IBM, they'll be calling everyone purists for even mentioning it.
- nixdev 2y ago
  Yeah.. it's rather unfortunate. I am grateful for https://chimera-linux.org/ https://chimera-linux.org/ and https://wiki.gentoo.org/wiki/OpenRC https://wiki.gentoo.org/wiki/OpenRC
enriquto 2y ago
The world needs a static linux distribution more than ever.
- mcflubbins 2y ago
  Oasis is one: https://github.com/oasislinux/oasis https://github.com/oasislinux/oasis
- ChocolateGod 2y ago
  I can't think of how much worse Heartbleed would of been if everything was statically compiled.
anotherhue 2y ago
Since I switched to nixos all these articles read like people fiddling with struct-packing and optimising their application memory layout. The compiler does it well enough now that we don't have to, so it is with nix and your application filesystem.
- jeltz 2y ago
  The C compiler does not optimize struct packing at all. Some languages like Rust allows optimizing struct layouts but even for Rust struct layout can matter if you care about cache locality and vector operations.
- __MatrixMan__ 2y ago
  I had a similar feeling during the recent crowdstrike incident. Hearing about how people couldn't operate their lathe or whatever because of an update, my initial reaction was: > Just boot yesterday's config and get on with your life But then, that's one of those NixOS things that we take for granted.
  - sshine 2y ago
    Not just NixOS. Ubuntu with ZFS creates a snapshot of the system on every `apt install` command. But yeah, it’s pretty great to know that if your system fails, just `git restore --staged` and redeploy.
- thot_experiment 2y ago
  Using shared libraries is optimizing for a very different set of constraints than nixos, which iirc keeps like 90 versions of the same thing around just so everyone can have the one they want. There are still people who are space constrained. (I haven't touched nix in years so maybe i'm off base on this) > The compiler does it well enough now that we don't have to You know I see people say this and then I see some code with some nested loops running 2x as fast as code written with list comprehensions and I remember that it's actually. "The compiler does it well enough now that we don't have to as long as you understand the way the compiler works at a low enough level that you don't use patterns that will trip it up and even then you should still be benchmarking your perf because black magic doesn't always work the way you think it works" Struct packing too can still lead to speedups/space gains if you were previously badly aligned, which is absolutely something that can happen if you leave everything on auto.
ChocolateGod 2y ago
> I am all in for AppImages or something like that. I don't care if these images are 10x bigger. Disk space now is plenty, and they solve the issue with "libFlac.8.so is missing They don't solve the dependency problem, they solve a distribution problem (in a bad for security way), what the AppImage provides is up to the author and once you go out of the "Debian/Ubuntu" sphere, you run into problems with distributions such as Arch and Fedora whom provide newer packages or do things slightly differently. You can have them fail to run if you're missing Qt, or your Qt version does not match the version it was compiled against, same GTK, Mesa, Curl etc. The moment there's an ABI incompatibility with the host system (not that uncommon), it breaks down. Meanwhile, a Flatpak produced today should run in 20 years time as long as the kernel doesn't break user-space. They don't run on my current distribution choice of NixOS. Meanwhile Flatpaks do.
- AshamedCaptain 2y ago
  I really doubt a X11 Flatpak from today will run in Fedora from 10 years time, much less 20 years time. They will break XWayland (in the name of "security") much before that. They will break D-Bus much before that. In addition, the kernel breaks ABI all the time; sometimes this is partially workarounded thanks to dynamic linking (e.g. OSS and solutions like aoss). Other times not so much. I feel that everytime someone introduces a "future proof" solution for 20 years they should make the effort to run 20 year old binaries on their Linux system of today and extrapolate from it.
  - o11c 2y ago
    As someone who actually has run at-least-15-year-old binaries (though admittedly not x11 ones for my use case), I can strongly state the following advice: * do not use static linking for libc, and probably not for other libraries either C-level ABI is not the only interface between parts of a program. There are also other things like e.g. well-known filepaths, and the format of those can change. A statically-linked program has no way to work across a break, whereas a dynamically-linked one (many important libraries have not broken SOVERSION in all that time) will know how to deal with the actual modern system layout. During my tests, all the statically-linked programs I tried from that era crashed immediately. All the dynamically-linked ones worked with no trouble.
cherryteastain 2y ago
AppImage does not always solve these dependency issues. I've had AppImages refuse to run because of e.g. missing Qt libraries (at least on Debian + Gnome). Flatpak and Snap are much better solutions for this problem. As for the Nvidia issues, especially the "system refuses to boot" kind, that's on Nvidia.
- amlib 2y ago
  As soon as nvidia was mentioned in the article a chill went down my spine reminding me of my treacherous experience trying to use ubuntu with the nvidia drivers back in 2007. Every second reboot the drivers would break and I would wind up having to reinstall it trough a VT. Re-installing the system multiple times didn't matter, following multiple different guides didn't matter, following nvidias own instructions to the teeth on a fresh system... didn't matter. Those drivers on Archilinux would also constantly break, but at least it was as a result of the system updating and not just rebooting. It took many years but I've been nvidia free for 6 years now and my system couldn't be more stable. I haven't seen Fedora break in the last 2 years I've been using it, aside from a beta release upgrade I was curious to test that went wrong. I really think it's silly to put all the blame on shared libraries when there is a 99% chance it's the nvidia drivers fucking up again.
anon291 2y ago
The main issue is mutability, not shared objects. Shared objects are a great memory optimization for little cost. The dependency graph is trivially tracked by sophisticated build systems and execution environments like NixOS. We live in 2024. Computers should be able to track executable dependencies and keep around common shared object libraries. This is a solved technical problem.
- tremon 2y ago
  Immutabililty actually destroys the security benefits that shared objects bring, because with every patch the location of the library changes. So you're back to the exact same situation as without dynamic linking: every dependency will need to be recompiled anyway against the new library location. And that means that even though you may have a shared object that's already patched, every other package on your system that's not yet been recompiled is still vulnerable.
  - saagarjha 2y ago
    Applications rarely link against versioned shared libraries. It is rare that a security patch would require every application to have its list of dependent libraries edited.
    - whytevuhuni 2y ago
      And yet, even a compatible change that doesn't break the ABI, will cause NixOS to rebuild all packages that depend on that library. That's because while tracking dependencies is a solved problem, tracking whether each dependency correctly follows semver (especially in C land), and which packages and which "minor" patches break or don't break ABI, is not a solved problem.
      - saagarjha 2y ago
        This sounds NixOS exercising an abundance of caution rather than actually needing to do this.
      - 2y ago
dannyobrien 2y ago
I wonder what the author thinks of Nix/Guix-type distributions? Seems like that's something that gets the best of both worlds, with a minimum (but not non-zero) amount of futzing around.
- mitjafelicijan 2y ago
  I like Nix and have been using it as a nix-shell for about 2 years and been loving it. Maybe I should just go full in and install it as my OS.
odo1242 2y ago
Something worth noting with shared dependencies is that yes, they save on disk space, but they also save on memory. A 200MB non-shared dependency will take up 600MB across three apps, but a 200MB shared dependency can be loaded on it's own and save 400 megabytes. (Most operating systems manage this at the physical page level, by mapping multiple instances of a shared library to the same physical memory pages.) 400 megabytes of memory usage is probably worth more than 400 megabytes of storage. It may not be a make-or break thing on it's own, but it's one of the reasons Linux can run on lower-end devices.
- whatshisface 2y ago
  Isn't 200MB a little large for a dependency? The Linux kernel is ~30MB.
  - odo1242 2y ago
    It's around the size of OpenCV, to be specific. I do see your argument though.
- packetlost 2y ago
  When you statically compile an application, you only store text (code) of functions you actually use, generally, so unless you're using all 400Mb of code you're not going to have a 400Mb+ binary. I don't think I've ever seen a dependency that was 400Mb of compiled code if you stripped debug information and weren't embedding graphical assets, so I'm not sure how relevant this is in the first place. 400Mb of opcodes is... a lot.
  - vvanders 2y ago
    Yes, this is lost in most discussions when it comes to DSOs. Not only do you have the complexity of versioning and vending but also you can't optimize with LTO and other techniques(which can make a significant difference in final binary size). If you've got 10-15+ consumers of a shared library or want to do plugins/hot-code reloading and have a solid versioning story by all means vend a DSO. If you don't however I would strongly recommend trying to keep all dependencies static and letting LTO/LTCG do its thing.
mfuzzey 2y ago
I haven't seen such problems on Debian or Ubuntu guess it's par for the course with a bleeding edge distro. The author seems to be focusing on the disk space advantage and claiming it's not enough to justify the downsides today. I can understand that but I don't think disk space savings are the main advantage of shared dependencies, rather it's centralized security updates. If every package bundles libfoo what happens there's a security vulnerability in libfoo?
- cbmuser 2y ago
  > If every package bundles libfoo what happens there's a security vulnerability in libfoo? That’s actually the key point that many people in this discussion seem to miss.
  - pmontra 2y ago
    What happens is that libfoo gets fixed, possibly by the maintainers of the distro, and all the apps using it are good to go again. With multiple versions bundled to multiple apps, a good number of those apps will never be updated, at least not in a timely manner, and the computer will be left vulnerable.
  - sunshowers 2y ago
    Then you get an alert that your libfoo has a vulnerability (GitHub does a pretty good job here!) and you roll out a new version with a patched libfoo.
    - kelnos 2y ago
      As a user, I don't want to assume that every single maintainer of every single app that uses (a statically linked) libfoo is keeping up to date with security issues in their dependencies and has the time and ability to promptly update their software. But I feel pretty safe believing that the debian libfoo package maintainer is on top of things and will quickly release an update to libfoo.so that all apps running on my system will be able to take advantage of.
jeltz 2y ago
Seems the author should just stop using a experimental bleeding edge distro like Fedora and go back to Debian Stable for example.
- mitjafelicijan 2y ago
  Author of this little hit piece against shared libraries here. You are correct. I went to Debian stable :)
senzilla 2y ago
The abysmal state of GNU/Linux is exactly why I moved to OpenBSD many years back. It's small, simple and very stable. The BSDs are definitely not for everyone, and they come with their own set of tradeoffs. However, it is safe to say that all BSDs are better today than 10 years ago. Small and steady improvements over time.
Arnavion 2y ago
Distributions optimize for software in their repos. Software in their repos is compiled against libraries in their repos, so dynamic linking has no downsides and has the upside of reducing disk usage and runtime memory usage (sharing pages). Your problem with "libFlac.8.so is missing" happens with using software not from the distro repos. Feel free to statically link it, or run it via AppImage or Flatpak or Podman or whatever you want that provides the environment it *was* compiled for. Whether the rest of the distro is dynamically linked or not makes no difference to your ability to run this software, so there's no reason to make the rest of the distro worse. I personally do care about disk usage and memory usage. I also care about using software from distro repos vs Flatpak etc wherever possible, because software in the distro repos is maintained by someone whose values align with me and not the upstream software author. Eg the firefox package from distro repos enables me to load my own extensions without Mozilla's gatekeeping, the Audacity package from distro repos did not have telemetry enabled that Audacity devs added to their own builds, etc.
- anotherhue 2y ago
  If you're in an adversarial relationship with the OEM software developer there's not a whole lot the distro maintainers can do, probably time to find a fork/alternative. (Forks exist for both your examples). I say this as a casual maintainer of several apps and I'm loathe to manually patch versus upstream any fix.
  - Arnavion 2y ago
    I'm not going to switch to a firefox fork over one line in the configure script invocation. Forks have their own problems with maintenance and security. It's not useful to boil it down to one "adversarial relationship" boolean.
- cbmuser 2y ago
  The main argument for using shared libraries isn’t memory or disk usage, but simply security. If you have a thousand packages linking statically against zlib, you will have to update a thousand packages in case of a vulnerability. With a shared zlib, you will have to update only one package.
cogman10 2y ago
Perhaps this is a hard/impossible problem to solve, but I feel like the issue isn't so much the shared libraries, it's the fact that you need different versions of a shared library on a system for it to function. As a result, the interface for communicating that "I have version 1, 2, 3" has basically just been linking against filenames. But here's the part that feels wasteful that I wish could be solved. From version 1.0 to 2.0, probably 90% of most libraries are completely unchanged. Yet still we duplicate just to solve the problem. What if instead of having a .so per version, we packaged together a computable shared object and had the compiler/linking system incorporate versions when making a link? From there, we could turn the requests for versions be something like "Hey, I need 1.2.3" and the linking system say "1.2.3 consists of these chunks from the shared repository". That could be manifest and cached by the OS. For example, imagine fooLib has functions foo, bar, baz in version 1.2.3 and foo, bar, baz, blat. in 1.4.3. You could have a small hash of each of the functions in foo and store off the hash of those functions in a key value store for foo. From there you could materialize the runtime of foo 1.2.3 when requested by a library. New versions would essentially be the process of sending down the new function chunks and there would be no overriding of versions. But, it would also give OS maintainers a route to say "Actually, anything that requests version 1.2.3 will get 1.2.3.1-patched because of a CVE". Or you could even hotpatch in the same function on all versions in the case of CVE having a more targeted patching system. I've often wondered about if we could do a really granular dependency graph like this. Mainly because I like the idea of only shipping out the smaller changes and not 1gb of stuff because of what might break.
einpoklum 2y ago
> I am all in for AppImages or something like that WTF? On the contrary! > And Snaps and Flatpaks tried to solve some of these things, Made things worse. > I don't care if these images are 10x bigger. ... the size is just part of the problem. The duplication is another part. A system depending on a 100K different versions of libraries/utils instead of, oh, say, 5K. And there's the memory usage, as others mentioned. Also, there really isn't more trouble locating shared libraries today than 10 years ago; if anything, the opposite is true. Not to mention how there is even more searchable "crowd support" resources today than back then, for when you actually do have such issues. So... > How come GNU/Linux is worse than it was 10 years ago? I think it's actually better overall: * Less gotchas during installation * Better apps for users' basic needs (e.g. LibreOffice) * Less chance of newer hardware not being supported on Linux (it still happens though) but if you asked me what is worse, then: 1. systemd. 2. Further deterioration of the GNOME UI. Although TBH a lot of that sucked 10 years ago as well (e.g. the file picker) 3. Containerization instead of developers/distributors having their act together but certainly not what the author is trying to push. (shrug)
- ChocolateGod 2y ago
  > * Less chance of newer hardware not being supported on Linux (it still happens though) This is one area I think Linux is really bad on compared to Windows. AMD makes a new graphics card, it pushes out a driver update for Windows and it's all golden. On Linux? They have to spend months getting it into the kernel release cycle, then wait on distributions to test that update, trickle it down to users and if you're on some kind of LTS distribution you might as well not bother.
  - trelane 2y ago
    It's not like they only start developing the driver when the card is released. In either case, they work with the OS vendor for months or years prior to develop the driver. One often sees this in e.g. Intel drivers coming out in the Linux kernel well before the hardware is available to the consumer. You're not entirely wrong, either, though; it's more of a concern with LTS support. Though this is reduced somewhat by most things not actually needing custom drivers by using existing standards, e.g. HID, and/or by userspace drivers. And, of course, you don't have it at all if you only buy hardware with Linux pre-installed and supported by the vendor. You know, like you do with Windows and Mac.
AshamedCaptain 2y ago
If anything, I'd argue that the "abysmal state of GNU/Linux" is because programs now tend to bundle their own dependencies, and not the opposite.
- sebastos 2y ago
  Grrr - I strongly, viscerally disagree! All of these new dependency bundling technologies were explicitly created to get out from under the abysmal state of packaging - from Docker (in some ways) and on to snap, flat pack, appimage, etc. This state of affairs was explained in no uncertain terms and widely repeated in the various manifestos associated with those projects. The same verbiage is probably still there if you go look. It seems crazy to act as if this recent memory is obscured by the mists of time, leaving us free to speculate on the direction of causality. We all lived this, and that’s not how it happened! Besides, in your telling, thousands of people and multiple separate organizations poured blood sweat and tears into these various bundling technologies for no good reason. Why’d they do that? I can’t help but suspect your answer is something like “it all worked fine, people just got lazy. Just simply work with the distro maintainer to get your package accepted and then … etc etc etc”. What do people have to do to communicate with the Linux people that this method of distribution is sucky and slow and excruciating? They’ve built gigantic standalone ecosystems to avoid doing it this way, yet the Linux people are still smugly telling themselves that people are just too stupid and lazy to do things The Right Way.
  - zrm 2y ago
    > thousands of people and multiple separate organizations poured blood sweat and tears into these various bundling technologies for no good reason. Why’d they do that? Because stability and rapid change are incompatible, and they wanted rapid change. Which turns into a maintenance nightmare because now every app is using a different, incompatible version of the same library and somebody has to backport bug fixes and security updates to each individual version used by each individual package. And since that's a ton of work nobody wants to do, it usually doesn't get done and things packaged that way end up full of old bugs and security vulnerabilities.
fullspectrumdev 2y ago
It strikes me that Linux seems to have basically reinvented DLL Hell.
- bachmeier 2y ago
  Not really. This has always been possible, and by definition, it has to be possible. If you use a stable distro and stick with your distro's repositories it's not a problem. If you want to install stuff outside the repos and you aren't willing to compile it yourself, it's absolutely going to be a problem.
Dwedit 2y ago
How about the part where Shared Objects take a performance penalty due to being position-independent code?
- kelnos 2y ago
  But they also can reduce memory pressure and cache misses, so maybe that evens out.
  - Dwedit 2y ago
    I know that on Windows, DLL files get optimized a lot. If a DLL file can be loaded without any relocation, then it becomes a memory mapped-file rather than an additional copy of the program. All the system DLLs have different pre-defined base addresses, so they won't conflict with each other. If relocation is required, then the DLL becomes a private copy in the process's address space rather than a memory-mapped file.
BeetleB 2y ago
Been running Gentoo for over 20 years. It's as (un)stable now as it was then. It definitely has not regressed in the last N years. I don't see this as a GNU/Linux problem, but a distro problem. Regarding shared libraries: What do you do when a commonly used library has a security vulnerability? Force every single package that depends on it to be recompiled? Who's going to do that work? If I maintain a package and one of its dependencies is updated, I only need to check that the update is backward compatible and move on. You've now put a huge amount of work on my plate with static compilation. Finally: What does shared libraries have to do with GNU/Linux? I don't think it's a fundamental part of either. If I make a distro tomorrow that is all statically compiled, no one will come after me and tell me not to refer to it as GNU/Linux. This is an orthogonal concern.
DemocracyFTW2 2y ago
> the issue with "libFlac.8.so is missing" and I have version 12 installed I believe this is one of the core issues here, and it is nicely illustrated by comparing what e.g. one Isaac Schlueter (isaacs of npm fame) thinks about dependencies and the critique to this offered by Rich Hickey (of Closure fame). Basically what Isaac insists on is that Semantic Versioning can Save Us from dependency hell if we just apply it diligently. The advancement that npm offers in this regard is that different transitive dependencies that refer to different versions of the same module can co-exist in the dependency tree, which is great. But sometimes, just sometimes folks, you need to have two versions of the same dependency for the same module, and this has taken a lot of effort to get into the system, because of the stubborn insistence that somehow `foo@4.1` and `foo@4.3` should be the 'same only different', and that really it makes no sense to use both `foo@3` and `foo@4` from the same piece of code, because they're just two versions of the 'same'. Rich Hickey[1] cuts through this and asserts that, no, if there's a single bit of difference between foo version A and foo version B, then they're—different. In fact, both pieces of software can behave in arbitrarily different ways. In the real world, they most of the time don't, it's true, but also in the real world, the part of knowledge that I can be really sure of is that if foo version A is not bit-identical to foo version B, then those are different pieces of software, potentially (and likely) with different behaviors. Where those differences lay, and whether they will impact my particular use of that software remains largely a matter of conjecture. Which brings me back to the OP's remark about libFlac.8.so conflicting with libFlac.12.so. I think they shouldn't conflict. I think we have to ween us off the somewhat magical thinking that we just need an agreement on what is a breaking change and what is a 'patch' and we can go on pretending that we can share libraries system-wide on a 'first-name basis' as it were, i.e. disregarding their version numbers. I feel I do not understand Linux deeply enough but my suspicion has been for years now that we don't have to abolish shared libraries altogether if only we would stop to see anything in libFlac.8.so that ties it particularly closely to libFlac.12.so. Well there is, probably, a lot of commonalities between the two, but in principle there need not be any, and therefore the two libraries should be treated like any two wholly independent pieces of software. [1] https://youtu.be/oyLBGkS5ICk?list=PLZdCLR02grLrEwKaZv-5QbUzK0zGKOOcr https://youtu.be/oyLBGkS5ICk?list=PLZdCLR02grLrEwKaZv-5QbUzK...
tannhaeuser 2y ago
> Sure, we now have PipeWire and Wayland. We enjoy many modern advances and yet, the practical use for me is worse than it was 10 years ago. That's what has made me leave Linux for Mac OS, and I'm talking about things like the touchpad (libinput) causing physical pain and crashing every couple minutes while the "desktop" wants to appeal to a hypothetical casual tablet user even Microsoft left long behind in the Windows 8.1 era (!). Mind, Mac OS is far from perfect and also regressing (hello window focus management, SIP, refactored-into-uselessness expose, etc, etc) but Mac OS has at least a wealth of new desktop apps created in this millenium to make up for it, unlike the Linux desktop struggling to keep the same old apps running as it's on a refactoring spree to fix self-inflicted problems (like glibc, ld.so) and then still not attracting new developers. I wish I could say, like the author, that containers are the solution, but the canonical example of browser updates also is a case of unwarranted and rampant complexity piling up without the slightest actual benefit for the user as the web is dying.
- desumeku 2y ago
  > while the "desktop" wants to appeal to a hypothetical casual tablet user even Microsoft left long behind in the Windows 8.1 era This sounds like a GNOME issue, not a Linux one.
- imiric 2y ago
  I agree to an extent, but Linux is actually very usable if you stick to common quality hardware, and a collection of carefully curated robust and simple software. I realize this is impractical for most people, but having a limited ecosystem is what essentially allows Apple to deliver the exceptional user experience they're known for. The alternative of supporting an insane amount of hardware, and making it work with every combination of software, both legacy and cutting-edge, is much, much harder to achieve. It's a miracle of engineering that Linux works as well as it does, while also being developed in a globally distributed way with no central company driving the effort. Microsoft can also pull this off arguably better, but with a completely different development and business model, and all the resources in the world, so it's hardly comparable. The sad part is that there is really no alternative to Linux if you want full control over your devices, while also having a decent user experience. Windows and macOS are walled gardens, and on the opposite spectrum BSDs and other niche OSs are nowhere near as usable. So the best we can do is pick a good Linux distro, something we're thankfully spoiled for choice, and customize it to our needs, which unfortunately does take a lot of time and effort. I still prefer this over the alternatives, though.
ramon156 2y ago
> This is why I am a massive proponent of AppImages I joined Linux late-game, and only recently discovered that AppImages were in some cases much nicer to work with. The thing that I was missing though was.. a package manager. If there was any distro that would build their package manager around AppImages, then I would gladly use it.
- idle_zealot 2y ago
  What would that even mean? A package manager is for tracking and installing dependencies, and putting things in the right place in the filesystem. AppImages bundle their dependencies and don't expect to unpack into a filesystem, you just put them in an /apps directory. Do you just mean that you want a repository of AppImages to search? Otherwise your "package manager" is 'curl $APPIMAGE_URL > ~/apps/$APP_NAME' and 'rm ~/apps/$APP_NAME'.
- 3eb7988a1663 2y ago
  I have no appreciation for the differences between AppImage and Flatpak, but Flatpak does at least have a package manager which will pull in newer versions for you.
deleted 2y ago
[deleted]
zrm 2y ago
The old reason for shared libraries was to share memory/cache and not waste disk space. That's not gone, but maybe it's less important than it used to be. The modern reason is maintenance. If 100 apps are using libfoo, in practice nobody is going to maintain a hundred separate versions of libfoo. That means your choices are a) have hundreds of broken versions nobody is maintaining spread all over, or b) maintain a small number of major releases forked at the point where compatibility breaks, so that every version of 1.x.x is compatible with the latest version of 1.x.x and every version of 2.x.x is compatible with the latest version of 2.x.x, and somebody is maintaining a recent version of each series, so you can include it as a shared library that everything else links against. But then you need libraries to limit compatibility-breaking changes to once or twice a decade.
- JackSlateur 2y ago
  The maintenance reason is not really serious: you can maintain one version of the library and still do only static binaries: when you need to upgrade the library, you recompile it, and relink every binaries that uses it. The whole process is slower that doing dynamic linking, but still quite fast. It does require tooling, though.
  - zrm 2y ago
    If you're only maintaining one version of the library that everything uses then what do you get from static linking? The reason people want static linking is to be able to use all different versions of the library, which is what causes the maintenance problem.
neilv 2y ago
> Just a normal update that I do many times per week. [...] At this point, using GNU/Linux is more like a second job, and I was so stoked when this was not a case anymore in the past. This is why I feel like the last 10 years were a regression disguised as progress. But the author already knows the solution... > My best memories were always with Debian. Just pure Debian always proved to be the most stable system. I never had issue or system breaking after an update. I can't say the same for Fedora. You've always had the power... tap your heels together three times, and just install Debian Stable.
- kelnos 2y ago
  Hell, these days I switch from Debian stable to testing around 6 months after each stable release, and I still have fewer issues than I've had with most other distros in the past.
kelnos 2y ago
I feel like these sorts of articles come up every so often, but still don't buy it. While I agree that disk usage is no longer a driver for shared libraries, memory usage still is, to some extent. If I have 50 processes using the same libaray (and I do), that shared library's readonly data sections get loaded into RAM exactly once. That's a good thing. But even if that problem wasn't an issue, security is still a big one for me. When my distro releases a new version of a library package to fix a security issue, every single package that uses it gets the security fix, without its each maintainer having to rebuild each package against the fixed version. (Sure, some distros manage this more centrally and won't have to wait for individual maintainers, but not all are like that.) I don't have to wonder what app has been fixed and what hasn't been. I don't have to make sure every single AppImage/Flatpak/Snap on my system that depends on that library (which I may not even know) gets updated, and possibly disable or uninstall those that haven't been, until they have. I like shared libraries, even with the problems they sometimes (rarely!) cause.
zajio1am 2y ago
Main argument for shared libraries is not space reduction, but uniformity. I do not want in my OS ten different versions of GTK, Freetype, Guile or Lua, each with its own idiosyncrasies or bugs.
kelnos 2y ago
> How come GNU/Linux is worse than it was 10 years ago? This hasn't been my experience at all, as someone who's been using it for more than 20 years now. Today, for the most part I don't have to tinker with anything, or think about the inner workings of my distro. Even just a decade ago that wasn't true.
NotPractical 2y ago
> Some interesting talks and videos [...] GNU is Bloated! by Luke Smith Strange reference because that video isn't relevant to the topic at all. It's about the difference between GNU coreutils command line options and other standards such as BSD and POSIX (the title is mostly a joke). In fact Luke Smith is vehemently against the idea of AppImages/Flatpaks/Snaps and believe they go against the spirit of GNU/Linux [1]. [1] https://www.youtube.com/watch?v=JPXLpLwEQ_E https://www.youtube.com/watch?v=JPXLpLwEQ_E
- mitjafelicijan 2y ago
  That's a fair point.
hi-v-rocknroll 2y ago
This is a "Unabomber"-style prescription to the problem. The problem isn't shared libraries and the solution isn't static linking everything because that's wasteful for repetitive binary code duplicated N times consuming disk and RAM pointlessly. The problem is solved by management and cooperative sharing of shared libraries that don't rely on a fixed, singleton location or only allowing a single configuration of a shared library, but allow side-by-side installations of multiple version series and multiple configurations. Nix mostly solves these problems, but still has teething problems of getting things to work right especially for non-code shared file locations and dlopen program plugins. I think Nix is over-engineered and learning-curve user-hostile but is generally a more correct approach. There is/was a similar project from what was Opscode called Habitat that did something similar. Before that, we used Stow and symlink forests.
- wmf 2y ago
  allow side-by-side installations of multiple version series and multiple configurations So now every app requires a different library version and you've achieved all the disadvantages of static linking combined with all the disadvantages of dynamic linking.
  - hi-v-rocknroll 2y ago
    No, you're being unreasonable because that's not the goal at all. The goal is to minimize variations while still allowing the possibility of variations that traditional distros like dnf/RPM Fedora/RHEL disallow without jumping through hoops such as renaming/prefixing or alternate toolsets like scl.
nektro 2y ago
sounds like OP would love nixos
pnathan 2y ago
I mean I don't disagree. But this is a bazaar problem and a rebundling problem. I have used Debanoids for decades and they just work. It's very nice. Gentol works very nice too. I usually whack systemD and enjoy. I do want to get a Fedora system going but eh. Just work is nice.
cxr 2y ago
> It would be an interesting exercise to make a prototype distribution that does not rely on shared objects, but has everything packed in AppImages. Frankly, I don't think people are ambitious enough—whether it be the author of this post or those posting here in this thread. We're at a good enough place with modern hardware—for personal/business computers, at least—that we should perhaps not even be thinking about object files at all. All software and all distros should focus on shipping software as source code; JIT everything at run time, but in such a way that JIT results aren't ephemeral—they get re-used, so by the second time (or nth time) it's the same as if all your utilities and system components had been AOT compiled. Neither the system operator, administrators, nor package maintainers should care any more about the object file format and the linking model than they care about... I dunno, the on-disk format of their browser cache for Web resources. (Quick, quick: do you know how your browser stores its cache items? Probably not, since it's not something anybody but browser developers think about.) Fabrice Bellard already demonstrated with TCCBOOT the viability of applying this approach to the Linux kernel with acceptable results, and that was 20 years ago. This would also help to ameliorate an unfortunate accident of history, where the fact that traditional software development and deployment has dealt in separate binaries and source code means there's friction for the user if they want to change how something works on their system. (This is true even if they've taken a hardline stance to ensure everything on their system is libre/open source—dealing with the build tooling on a project-to-project basis just isn't fun or tractable.) This would also neutralize the entire schism between Flatpak vs AppImage vs Snaps vs <whatever>.
- cxr 2y ago
  Some other food for thought: there's an oddity with the way that we approach binary optimization in that we care about it a whole lot, but a program will never be optimized further than whatever optimizations were in place when the binary hit the user's machine prior to its first use (i.e. the optimizations that were put there by the compiler running on the author's machine or the distro build farm. Why should that be the case? Why should the optimization phase stop there?
PaulKeeble 2y ago
The analysis I want is an idea of how shared they actually. Some of them are likely used in an awful lot of processes and represent a lot of memory and drive space savings where others don't represent much saving at all.
xg15 2y ago
> The main point is that, yes these packages can be big, but if we are honest, what would a couple of additional megabytes that would include shared object libraries actually do? A couple hundred, not a couple...
nixdev 2y ago
Many distros avoid the problem with something like apt-get install libflac7 libflac8 If you look in Fedora 40 for example, you'll find nodejs, nodejs18, and nodejs22. Gentoo's ebuilds (packages) can often have multiple major versions installed simultaneously. If I really need something, I can unpack another Gentoo userland, or use a container. AppImages, do exist. What seems to be the missing "glue" is putting a ui in front of users to choose what software they want to run. That problem has not yet been solved gracefully. The author says he knows how to use Linux, but observably never graduated to be a particularly advanced user.
- mitjafelicijan 2y ago
  This was not my argument. Maybe I presented it poorly. I agree with you on different versions being available, but that is not always the case. And in those cases you need to do some unsavory things with symlinking. It is not about graduating to being an advanced user. That's not the case at all. I know how to do it. I expect an advanced system to not force me to do it. That is my argument. I don't think this will ever be solved. And that's ok, as well. I think operating systems have been around long enough that this kind of things could have been resolved. And Windows have the same issues. DLL's missing etc. This is not isolated to just Linux. And developers of applications have also a blame to carry here. I have done this as well. edit: not even an advanced system, it's about how we package apps. That's probably a better way of saying it.
udev4096 2y ago
It's just impossible to critize a single entity in the linux world. The amount of choices (as author mentioned) is mindblowing which is why we still have distro dependent package managers (which, let's be honest, are far better than flatpak or snap)
JackSlateur 2y ago
Fedora is a worldwide experiments for new idea, so yes, you try new stuff, for the better and the worse.
Timber-6539 2y ago
All the fixes he's proposing to add to Appimages were solved by Flatpaks and Snaps. Of course he dismissed both options while giving flimsy non-concrete reasons. Reads like a boomer rant from the greybeard who is resistant to adopting new technologies while complaining about how things were easier back in the day.
sebazzz 2y ago
> Shared dependencies were a mistake! There, I said it! I understand that disk space was limited back then and this was a legitimate constraint. Now it is not disk space, but for instance security that is a major theme. It is so nice to update the shared OpenSSL library and after that just being safe for every application linked to it. However, it is indeed annoying that some distros (looking at you Arch) don't ship older versions of some shared libraries, like libLLVM. And then you indeed run into "shared library not found" issues.
edgarwarren9 2y ago
[dead]

> Shared dependencies were a mistake! Couldn't agree more.

Fedora is a "move fast maybe sometimes break things" distro, e.g., early adoption of Btrfs as the default, Wayland etc. So yeah, these things sometimes happen.

shams93 2y ago

That's Fedora, its a bleeding edge experimental distro when it comes to the desktop at least. Ubuntu has become really popular because it is stable and reliable. My friends who use linux to perform live electronic music all use ubuntu studio and have been for over 15 years now.

shams93 2y ago
However these days its much easier to run a linux desktop on a system that comes with it, some of these laptops have driver issues where they can work but then can run into things like thermal and display issues due to closed code with very complex non-standard low level drivers.
yesco 2y ago
While Ubuntu is a great distro to get things up and running, a lot of their decision making around snap has begun to make me hesitant to recommend it to people. While there is the political/open source angle in regards to how they are handling the servers for snap, my main issue is primarily the stability. Randomly I'll install something with apt and it will not give me an apt package, it will give me a non-standard snap package that becomes difficult to troubleshoot. In the case of firefox, it basically makes it less stable than a nightly build considering how often it crashes, and subtly breaks screen sharing in weird non-obvious ways. This experience has me guessing that Canonical probably cares more about server Ubuntu now than it does about desktop Ubuntu, which is a real shame. While there are workarounds, I specifically endorsed Ubuntu in the first place to many people because these kinds of workarounds used to not be necessary. It's a real bummer honestly, not sure what else to recommend in this category either.

andrewstuart 2y ago

If “gnu” gets headline billing for providing some user land tools then really “systemd/Linux” should be the current operating system title because systemd pervades the distros mentioned in this article. In many ways systemd IS the operating system outside the kernel.

johnea 2y ago
And in fact systemd/linux is what I consider the biggest digression in linux over the last decade. It pushes for a single upstream for all of userland. With IBM being that single upstream. After decades, I'll leave archlinux in my next migration because of this.
- sho_hn 2y ago
  Neither of the systemd lead maintainers works for IBM (or the same company).
- ChocolateGod 2y ago
  > It pushes for a single upstream for all of userland. With IBM being that single upstream. I hate to break it to you but what do you think the GNU Project is?
- pessimizer 2y ago
  It's astounding how easily people slipped from defending Red Hat owning so much of Linux with their giant labyrinthine subsystems to literally defending IBM ownership. When Google or Facebook buy IBM, they'll be calling everyone purists for even mentioning it.
nixdev 2y ago
Yeah.. it's rather unfortunate. I am grateful for https://chimera-linux.org/ https://chimera-linux.org/ and https://wiki.gentoo.org/wiki/OpenRC https://wiki.gentoo.org/wiki/OpenRC

enriquto 2y ago

The world needs a static linux distribution more than ever.

mcflubbins 2y ago
Oasis is one: https://github.com/oasislinux/oasis https://github.com/oasislinux/oasis
ChocolateGod 2y ago
I can't think of how much worse Heartbleed would of been if everything was statically compiled.

anotherhue 2y ago

Since I switched to nixos all these articles read like people fiddling with struct-packing and optimising their application memory layout. The compiler does it well enough now that we don't have to, so it is with nix and your application filesystem.

jeltz 2y ago
The C compiler does not optimize struct packing at all. Some languages like Rust allows optimizing struct layouts but even for Rust struct layout can matter if you care about cache locality and vector operations.
__MatrixMan__ 2y ago
I had a similar feeling during the recent crowdstrike incident. Hearing about how people couldn't operate their lathe or whatever because of an update, my initial reaction was: > Just boot yesterday's config and get on with your life But then, that's one of those NixOS things that we take for granted.
- sshine 2y ago
  Not just NixOS. Ubuntu with ZFS creates a snapshot of the system on every `apt install` command. But yeah, it’s pretty great to know that if your system fails, just `git restore --staged` and redeploy.
thot_experiment 2y ago
Using shared libraries is optimizing for a very different set of constraints than nixos, which iirc keeps like 90 versions of the same thing around just so everyone can have the one they want. There are still people who are space constrained. (I haven't touched nix in years so maybe i'm off base on this) > The compiler does it well enough now that we don't have to You know I see people say this and then I see some code with some nested loops running 2x as fast as code written with list comprehensions and I remember that it's actually. "The compiler does it well enough now that we don't have to as long as you understand the way the compiler works at a low enough level that you don't use patterns that will trip it up and even then you should still be benchmarking your perf because black magic doesn't always work the way you think it works" Struct packing too can still lead to speedups/space gains if you were previously badly aligned, which is absolutely something that can happen if you leave everything on auto.

ChocolateGod 2y ago

> I am all in for AppImages or something like that. I don't care if these images are 10x bigger. Disk space now is plenty, and they solve the issue with "libFlac.8.so is missing They don't solve the dependency problem, they solve a distribution problem (in a bad for security way), what the AppImage provides is up to the author and once you go out of the "Debian/Ubuntu" sphere, you run into problems with distributions such as Arch and Fedora whom provide newer packages or do things slightly differently. You can have them fail to run if you're missing Qt, or your Qt version does not match the version it was compiled against, same GTK, Mesa, Curl etc. The moment there's an ABI incompatibility with the host system (not that uncommon), it breaks down. Meanwhile, a Flatpak produced today should run in 20 years time as long as the kernel doesn't break user-space. They don't run on my current distribution choice of NixOS. Meanwhile Flatpaks do.

AshamedCaptain 2y ago
I really doubt a X11 Flatpak from today will run in Fedora from 10 years time, much less 20 years time. They will break XWayland (in the name of "security") much before that. They will break D-Bus much before that. In addition, the kernel breaks ABI all the time; sometimes this is partially workarounded thanks to dynamic linking (e.g. OSS and solutions like aoss). Other times not so much. I feel that everytime someone introduces a "future proof" solution for 20 years they should make the effort to run 20 year old binaries on their Linux system of today and extrapolate from it.
- o11c 2y ago
  As someone who actually has run at-least-15-year-old binaries (though admittedly not x11 ones for my use case), I can strongly state the following advice: * do not use static linking for libc, and probably not for other libraries either C-level ABI is not the only interface between parts of a program. There are also other things like e.g. well-known filepaths, and the format of those can change. A statically-linked program has no way to work across a break, whereas a dynamically-linked one (many important libraries have not broken SOVERSION in all that time) will know how to deal with the actual modern system layout. During my tests, all the statically-linked programs I tried from that era crashed immediately. All the dynamically-linked ones worked with no trouble.

cherryteastain 2y ago

AppImage does not always solve these dependency issues. I've had AppImages refuse to run because of e.g. missing Qt libraries (at least on Debian + Gnome). Flatpak and Snap are much better solutions for this problem. As for the Nvidia issues, especially the "system refuses to boot" kind, that's on Nvidia.

amlib 2y ago
As soon as nvidia was mentioned in the article a chill went down my spine reminding me of my treacherous experience trying to use ubuntu with the nvidia drivers back in 2007. Every second reboot the drivers would break and I would wind up having to reinstall it trough a VT. Re-installing the system multiple times didn't matter, following multiple different guides didn't matter, following nvidias own instructions to the teeth on a fresh system... didn't matter. Those drivers on Archilinux would also constantly break, but at least it was as a result of the system updating and not just rebooting. It took many years but I've been nvidia free for 6 years now and my system couldn't be more stable. I haven't seen Fedora break in the last 2 years I've been using it, aside from a beta release upgrade I was curious to test that went wrong. I really think it's silly to put all the blame on shared libraries when there is a 99% chance it's the nvidia drivers fucking up again.

anon291 2y ago

The main issue is mutability, not shared objects. Shared objects are a great memory optimization for little cost. The dependency graph is trivially tracked by sophisticated build systems and execution environments like NixOS. We live in 2024. Computers should be able to track executable dependencies and keep around common shared object libraries. This is a solved technical problem.

tremon 2y ago
Immutabililty actually destroys the security benefits that shared objects bring, because with every patch the location of the library changes. So you're back to the exact same situation as without dynamic linking: every dependency will need to be recompiled anyway against the new library location. And that means that even though you may have a shared object that's already patched, every other package on your system that's not yet been recompiled is still vulnerable.
- saagarjha 2y ago
  Applications rarely link against versioned shared libraries. It is rare that a security patch would require every application to have its list of dependent libraries edited.
  - whytevuhuni 2y ago
    And yet, even a compatible change that doesn't break the ABI, will cause NixOS to rebuild all packages that depend on that library. That's because while tracking dependencies is a solved problem, tracking whether each dependency correctly follows semver (especially in C land), and which packages and which "minor" patches break or don't break ABI, is not a solved problem.
    - saagarjha 2y ago
      This sounds NixOS exercising an abundance of caution rather than actually needing to do this.
    - 2y ago

dannyobrien 2y ago

I wonder what the author thinks of Nix/Guix-type distributions? Seems like that's something that gets the best of both worlds, with a minimum (but not non-zero) amount of futzing around.

mitjafelicijan 2y ago
I like Nix and have been using it as a nix-shell for about 2 years and been loving it. Maybe I should just go full in and install it as my OS.

odo1242 2y ago

Something worth noting with shared dependencies is that yes, they save on disk space, but they also save on memory. A 200MB non-shared dependency will take up 600MB across three apps, but a 200MB shared dependency can be loaded on it's own and save 400 megabytes. (Most operating systems manage this at the physical page level, by mapping multiple instances of a shared library to the same physical memory pages.) 400 megabytes of memory usage is probably worth more than 400 megabytes of storage. It may not be a make-or break thing on it's own, but it's one of the reasons Linux can run on lower-end devices.

whatshisface 2y ago
Isn't 200MB a little large for a dependency? The Linux kernel is ~30MB.
- odo1242 2y ago
  It's around the size of OpenCV, to be specific. I do see your argument though.
packetlost 2y ago
When you statically compile an application, you only store text (code) of functions you actually use, generally, so unless you're using all 400Mb of code you're not going to have a 400Mb+ binary. I don't think I've ever seen a dependency that was 400Mb of compiled code if you stripped debug information and weren't embedding graphical assets, so I'm not sure how relevant this is in the first place. 400Mb of opcodes is... a lot.
- vvanders 2y ago
  Yes, this is lost in most discussions when it comes to DSOs. Not only do you have the complexity of versioning and vending but also you can't optimize with LTO and other techniques(which can make a significant difference in final binary size). If you've got 10-15+ consumers of a shared library or want to do plugins/hot-code reloading and have a solid versioning story by all means vend a DSO. If you don't however I would strongly recommend trying to keep all dependencies static and letting LTO/LTCG do its thing.

mfuzzey 2y ago

I haven't seen such problems on Debian or Ubuntu guess it's par for the course with a bleeding edge distro. The author seems to be focusing on the disk space advantage and claiming it's not enough to justify the downsides today. I can understand that but I don't think disk space savings are the main advantage of shared dependencies, rather it's centralized security updates. If every package bundles libfoo what happens there's a security vulnerability in libfoo?

cbmuser 2y ago
> If every package bundles libfoo what happens there's a security vulnerability in libfoo? That’s actually the key point that many people in this discussion seem to miss.
- pmontra 2y ago
  What happens is that libfoo gets fixed, possibly by the maintainers of the distro, and all the apps using it are good to go again. With multiple versions bundled to multiple apps, a good number of those apps will never be updated, at least not in a timely manner, and the computer will be left vulnerable.
- sunshowers 2y ago
  Then you get an alert that your libfoo has a vulnerability (GitHub does a pretty good job here!) and you roll out a new version with a patched libfoo.
  - kelnos 2y ago
    As a user, I don't want to assume that every single maintainer of every single app that uses (a statically linked) libfoo is keeping up to date with security issues in their dependencies and has the time and ability to promptly update their software. But I feel pretty safe believing that the debian libfoo package maintainer is on top of things and will quickly release an update to libfoo.so that all apps running on my system will be able to take advantage of.

jeltz 2y ago

Seems the author should just stop using a experimental bleeding edge distro like Fedora and go back to Debian Stable for example.

mitjafelicijan 2y ago
Author of this little hit piece against shared libraries here. You are correct. I went to Debian stable :)

senzilla 2y ago

The abysmal state of GNU/Linux is exactly why I moved to OpenBSD many years back. It's small, simple and very stable. The BSDs are definitely not for everyone, and they come with their own set of tradeoffs. However, it is safe to say that all BSDs are better today than 10 years ago. Small and steady improvements over time.

Arnavion 2y ago

Distributions optimize for software in their repos. Software in their repos is compiled against libraries in their repos, so dynamic linking has no downsides and has the upside of reducing disk usage and runtime memory usage (sharing pages). Your problem with "libFlac.8.so is missing" happens with using software not from the distro repos. Feel free to statically link it, or run it via AppImage or Flatpak or Podman or whatever you want that provides the environment it *was* compiled for. Whether the rest of the distro is dynamically linked or not makes no difference to your ability to run this software, so there's no reason to make the rest of the distro worse. I personally do care about disk usage and memory usage. I also care about using software from distro repos vs Flatpak etc wherever possible, because software in the distro repos is maintained by someone whose values align with me and not the upstream software author. Eg the firefox package from distro repos enables me to load my own extensions without Mozilla's gatekeeping, the Audacity package from distro repos did not have telemetry enabled that Audacity devs added to their own builds, etc.

anotherhue 2y ago
If you're in an adversarial relationship with the OEM software developer there's not a whole lot the distro maintainers can do, probably time to find a fork/alternative. (Forks exist for both your examples). I say this as a casual maintainer of several apps and I'm loathe to manually patch versus upstream any fix.
- Arnavion 2y ago
  I'm not going to switch to a firefox fork over one line in the configure script invocation. Forks have their own problems with maintenance and security. It's not useful to boil it down to one "adversarial relationship" boolean.
cbmuser 2y ago
The main argument for using shared libraries isn’t memory or disk usage, but simply security. If you have a thousand packages linking statically against zlib, you will have to update a thousand packages in case of a vulnerability. With a shared zlib, you will have to update only one package.

cogman10 2y ago

Perhaps this is a hard/impossible problem to solve, but I feel like the issue isn't so much the shared libraries, it's the fact that you need different versions of a shared library on a system for it to function. As a result, the interface for communicating that "I have version 1, 2, 3" has basically just been linking against filenames. But here's the part that feels wasteful that I wish could be solved. From version 1.0 to 2.0, probably 90% of most libraries are completely unchanged. Yet still we duplicate just to solve the problem. What if instead of having a .so per version, we packaged together a computable shared object and had the compiler/linking system incorporate versions when making a link? From there, we could turn the requests for versions be something like "Hey, I need 1.2.3" and the linking system say "1.2.3 consists of these chunks from the shared repository". That could be manifest and cached by the OS. For example, imagine fooLib has functions foo, bar, baz in version 1.2.3 and foo, bar, baz, blat. in 1.4.3. You could have a small hash of each of the functions in foo and store off the hash of those functions in a key value store for foo. From there you could materialize the runtime of foo 1.2.3 when requested by a library. New versions would essentially be the process of sending down the new function chunks and there would be no overriding of versions. But, it would also give OS maintainers a route to say "Actually, anything that requests version 1.2.3 will get 1.2.3.1-patched because of a CVE". Or you could even hotpatch in the same function on all versions in the case of CVE having a more targeted patching system. I've often wondered about if we could do a really granular dependency graph like this. Mainly because I like the idea of only shipping out the smaller changes and not 1gb of stuff because of what might break.

einpoklum 2y ago

> I am all in for AppImages or something like that WTF? On the contrary! > And Snaps and Flatpaks tried to solve some of these things, Made things worse. > I don't care if these images are 10x bigger. ... the size is just part of the problem. The duplication is another part. A system depending on a 100K different versions of libraries/utils instead of, oh, say, 5K. And there's the memory usage, as others mentioned. Also, there really isn't more trouble locating shared libraries today than 10 years ago; if anything, the opposite is true. Not to mention how there is even more searchable "crowd support" resources today than back then, for when you actually do have such issues. So... > How come GNU/Linux is worse than it was 10 years ago? I think it's actually better overall: * Less gotchas during installation * Better apps for users' basic needs (e.g. LibreOffice) * Less chance of newer hardware not being supported on Linux (it still happens though) but if you asked me what is worse, then: 1. systemd. 2. Further deterioration of the GNOME UI. Although TBH a lot of that sucked 10 years ago as well (e.g. the file picker) 3. Containerization instead of developers/distributors having their act together but certainly not what the author is trying to push. (shrug)

ChocolateGod 2y ago
> * Less chance of newer hardware not being supported on Linux (it still happens though) This is one area I think Linux is really bad on compared to Windows. AMD makes a new graphics card, it pushes out a driver update for Windows and it's all golden. On Linux? They have to spend months getting it into the kernel release cycle, then wait on distributions to test that update, trickle it down to users and if you're on some kind of LTS distribution you might as well not bother.
- trelane 2y ago
  It's not like they only start developing the driver when the card is released. In either case, they work with the OS vendor for months or years prior to develop the driver. One often sees this in e.g. Intel drivers coming out in the Linux kernel well before the hardware is available to the consumer. You're not entirely wrong, either, though; it's more of a concern with LTS support. Though this is reduced somewhat by most things not actually needing custom drivers by using existing standards, e.g. HID, and/or by userspace drivers. And, of course, you don't have it at all if you only buy hardware with Linux pre-installed and supported by the vendor. You know, like you do with Windows and Mac.

AshamedCaptain 2y ago

If anything, I'd argue that the "abysmal state of GNU/Linux" is because programs now tend to bundle their own dependencies, and not the opposite.

sebastos 2y ago
Grrr - I strongly, viscerally disagree! All of these new dependency bundling technologies were explicitly created to get out from under the abysmal state of packaging - from Docker (in some ways) and on to snap, flat pack, appimage, etc. This state of affairs was explained in no uncertain terms and widely repeated in the various manifestos associated with those projects. The same verbiage is probably still there if you go look. It seems crazy to act as if this recent memory is obscured by the mists of time, leaving us free to speculate on the direction of causality. We all lived this, and that’s not how it happened! Besides, in your telling, thousands of people and multiple separate organizations poured blood sweat and tears into these various bundling technologies for no good reason. Why’d they do that? I can’t help but suspect your answer is something like “it all worked fine, people just got lazy. Just simply work with the distro maintainer to get your package accepted and then … etc etc etc”. What do people have to do to communicate with the Linux people that this method of distribution is sucky and slow and excruciating? They’ve built gigantic standalone ecosystems to avoid doing it this way, yet the Linux people are still smugly telling themselves that people are just too stupid and lazy to do things The Right Way.
- zrm 2y ago
  > thousands of people and multiple separate organizations poured blood sweat and tears into these various bundling technologies for no good reason. Why’d they do that? Because stability and rapid change are incompatible, and they wanted rapid change. Which turns into a maintenance nightmare because now every app is using a different, incompatible version of the same library and somebody has to backport bug fixes and security updates to each individual version used by each individual package. And since that's a ton of work nobody wants to do, it usually doesn't get done and things packaged that way end up full of old bugs and security vulnerabilities.

fullspectrumdev 2y ago

It strikes me that Linux seems to have basically reinvented DLL Hell.

bachmeier 2y ago
Not really. This has always been possible, and by definition, it has to be possible. If you use a stable distro and stick with your distro's repositories it's not a problem. If you want to install stuff outside the repos and you aren't willing to compile it yourself, it's absolutely going to be a problem.

Dwedit 2y ago

How about the part where Shared Objects take a performance penalty due to being position-independent code?

kelnos 2y ago
But they also can reduce memory pressure and cache misses, so maybe that evens out.
- Dwedit 2y ago
  I know that on Windows, DLL files get optimized a lot. If a DLL file can be loaded without any relocation, then it becomes a memory mapped-file rather than an additional copy of the program. All the system DLLs have different pre-defined base addresses, so they won't conflict with each other. If relocation is required, then the DLL becomes a private copy in the process's address space rather than a memory-mapped file.

BeetleB 2y ago

Been running Gentoo for over 20 years. It's as (un)stable now as it was then. It definitely has not regressed in the last N years. I don't see this as a GNU/Linux problem, but a distro problem. Regarding shared libraries: What do you do when a commonly used library has a security vulnerability? Force every single package that depends on it to be recompiled? Who's going to do that work? If I maintain a package and one of its dependencies is updated, I only need to check that the update is backward compatible and move on. You've now put a huge amount of work on my plate with static compilation. Finally: What does shared libraries have to do with GNU/Linux? I don't think it's a fundamental part of either. If I make a distro tomorrow that is all statically compiled, no one will come after me and tell me not to refer to it as GNU/Linux. This is an orthogonal concern.

DemocracyFTW2 2y ago

> the issue with "libFlac.8.so is missing" and I have version 12 installed I believe this is one of the core issues here, and it is nicely illustrated by comparing what e.g. one Isaac Schlueter (isaacs of npm fame) thinks about dependencies and the critique to this offered by Rich Hickey (of Closure fame). Basically what Isaac insists on is that Semantic Versioning can Save Us from dependency hell if we just apply it diligently. The advancement that npm offers in this regard is that different transitive dependencies that refer to different versions of the same module can co-exist in the dependency tree, which is great. But sometimes, just sometimes folks, you need to have two versions of the same dependency for the same module, and this has taken a lot of effort to get into the system, because of the stubborn insistence that somehow `foo@4.1` and `foo@4.3` should be the 'same only different', and that really it makes no sense to use both `foo@3` and `foo@4` from the same piece of code, because they're just two versions of the 'same'. Rich Hickey[1] cuts through this and asserts that, no, if there's a single bit of difference between foo version A and foo version B, then they're—different. In fact, both pieces of software can behave in arbitrarily different ways. In the real world, they most of the time don't, it's true, but also in the real world, the part of knowledge that I can be really sure of is that if foo version A is not bit-identical to foo version B, then those are different pieces of software, potentially (and likely) with different behaviors. Where those differences lay, and whether they will impact my particular use of that software remains largely a matter of conjecture. Which brings me back to the OP's remark about libFlac.8.so conflicting with libFlac.12.so. I think they shouldn't conflict. I think we have to ween us off the somewhat magical thinking that we just need an agreement on what is a breaking change and what is a 'patch' and we can go on pretending that we can share libraries system-wide on a 'first-name basis' as it were, i.e. disregarding their version numbers. I feel I do not understand Linux deeply enough but my suspicion has been for years now that we don't have to abolish shared libraries altogether if only we would stop to see anything in libFlac.8.so that ties it particularly closely to libFlac.12.so. Well there is, probably, a lot of commonalities between the two, but in principle there need not be any, and therefore the two libraries should be treated like any two wholly independent pieces of software. [1] https://youtu.be/oyLBGkS5ICk?list=PLZdCLR02grLrEwKaZv-5QbUzK0zGKOOcr https://youtu.be/oyLBGkS5ICk?list=PLZdCLR02grLrEwKaZv-5QbUzK...

tannhaeuser 2y ago

> Sure, we now have PipeWire and Wayland. We enjoy many modern advances and yet, the practical use for me is worse than it was 10 years ago. That's what has made me leave Linux for Mac OS, and I'm talking about things like the touchpad (libinput) causing physical pain and crashing every couple minutes while the "desktop" wants to appeal to a hypothetical casual tablet user even Microsoft left long behind in the Windows 8.1 era (!). Mind, Mac OS is far from perfect and also regressing (hello window focus management, SIP, refactored-into-uselessness expose, etc, etc) but Mac OS has at least a wealth of new desktop apps created in this millenium to make up for it, unlike the Linux desktop struggling to keep the same old apps running as it's on a refactoring spree to fix self-inflicted problems (like glibc, ld.so) and then still not attracting new developers. I wish I could say, like the author, that containers are the solution, but the canonical example of browser updates also is a case of unwarranted and rampant complexity piling up without the slightest actual benefit for the user as the web is dying.

desumeku 2y ago
> while the "desktop" wants to appeal to a hypothetical casual tablet user even Microsoft left long behind in the Windows 8.1 era This sounds like a GNOME issue, not a Linux one.
imiric 2y ago
I agree to an extent, but Linux is actually very usable if you stick to common quality hardware, and a collection of carefully curated robust and simple software. I realize this is impractical for most people, but having a limited ecosystem is what essentially allows Apple to deliver the exceptional user experience they're known for. The alternative of supporting an insane amount of hardware, and making it work with every combination of software, both legacy and cutting-edge, is much, much harder to achieve. It's a miracle of engineering that Linux works as well as it does, while also being developed in a globally distributed way with no central company driving the effort. Microsoft can also pull this off arguably better, but with a completely different development and business model, and all the resources in the world, so it's hardly comparable. The sad part is that there is really no alternative to Linux if you want full control over your devices, while also having a decent user experience. Windows and macOS are walled gardens, and on the opposite spectrum BSDs and other niche OSs are nowhere near as usable. So the best we can do is pick a good Linux distro, something we're thankfully spoiled for choice, and customize it to our needs, which unfortunately does take a lot of time and effort. I still prefer this over the alternatives, though.

ramon156 2y ago

> This is why I am a massive proponent of AppImages I joined Linux late-game, and only recently discovered that AppImages were in some cases much nicer to work with. The thing that I was missing though was.. a package manager. If there was any distro that would build their package manager around AppImages, then I would gladly use it.

idle_zealot 2y ago
What would that even mean? A package manager is for tracking and installing dependencies, and putting things in the right place in the filesystem. AppImages bundle their dependencies and don't expect to unpack into a filesystem, you just put them in an /apps directory. Do you just mean that you want a repository of AppImages to search? Otherwise your "package manager" is 'curl $APPIMAGE_URL > ~/apps/$APP_NAME' and 'rm ~/apps/$APP_NAME'.
3eb7988a1663 2y ago
I have no appreciation for the differences between AppImage and Flatpak, but Flatpak does at least have a package manager which will pull in newer versions for you.

deleted 2y ago

[deleted]

zrm 2y ago

The old reason for shared libraries was to share memory/cache and not waste disk space. That's not gone, but maybe it's less important than it used to be. The modern reason is maintenance. If 100 apps are using libfoo, in practice nobody is going to maintain a hundred separate versions of libfoo. That means your choices are a) have hundreds of broken versions nobody is maintaining spread all over, or b) maintain a small number of major releases forked at the point where compatibility breaks, so that every version of 1.x.x is compatible with the latest version of 1.x.x and every version of 2.x.x is compatible with the latest version of 2.x.x, and somebody is maintaining a recent version of each series, so you can include it as a shared library that everything else links against. But then you need libraries to limit compatibility-breaking changes to once or twice a decade.

JackSlateur 2y ago
The maintenance reason is not really serious: you can maintain one version of the library and still do only static binaries: when you need to upgrade the library, you recompile it, and relink every binaries that uses it. The whole process is slower that doing dynamic linking, but still quite fast. It does require tooling, though.
- zrm 2y ago
  If you're only maintaining one version of the library that everything uses then what do you get from static linking? The reason people want static linking is to be able to use all different versions of the library, which is what causes the maintenance problem.

neilv 2y ago

> Just a normal update that I do many times per week. [...] At this point, using GNU/Linux is more like a second job, and I was so stoked when this was not a case anymore in the past. This is why I feel like the last 10 years were a regression disguised as progress. But the author already knows the solution... > My best memories were always with Debian. Just pure Debian always proved to be the most stable system. I never had issue or system breaking after an update. I can't say the same for Fedora. You've always had the power... tap your heels together three times, and just install Debian Stable.

kelnos 2y ago
Hell, these days I switch from Debian stable to testing around 6 months after each stable release, and I still have fewer issues than I've had with most other distros in the past.

kelnos 2y ago

I feel like these sorts of articles come up every so often, but still don't buy it. While I agree that disk usage is no longer a driver for shared libraries, memory usage still is, to some extent. If I have 50 processes using the same libaray (and I do), that shared library's readonly data sections get loaded into RAM exactly once. That's a good thing. But even if that problem wasn't an issue, security is still a big one for me. When my distro releases a new version of a library package to fix a security issue, every single package that uses it gets the security fix, without its each maintainer having to rebuild each package against the fixed version. (Sure, some distros manage this more centrally and won't have to wait for individual maintainers, but not all are like that.) I don't have to wonder what app has been fixed and what hasn't been. I don't have to make sure every single AppImage/Flatpak/Snap on my system that depends on that library (which I may not even know) gets updated, and possibly disable or uninstall those that haven't been, until they have. I like shared libraries, even with the problems they sometimes (rarely!) cause.

zajio1am 2y ago

Main argument for shared libraries is not space reduction, but uniformity. I do not want in my OS ten different versions of GTK, Freetype, Guile or Lua, each with its own idiosyncrasies or bugs.

kelnos 2y ago

> How come GNU/Linux is worse than it was 10 years ago? This hasn't been my experience at all, as someone who's been using it for more than 20 years now. Today, for the most part I don't have to tinker with anything, or think about the inner workings of my distro. Even just a decade ago that wasn't true.

NotPractical 2y ago

> Some interesting talks and videos [...] GNU is Bloated! by Luke Smith Strange reference because that video isn't relevant to the topic at all. It's about the difference between GNU coreutils command line options and other standards such as BSD and POSIX (the title is mostly a joke). In fact Luke Smith is vehemently against the idea of AppImages/Flatpaks/Snaps and believe they go against the spirit of GNU/Linux [1]. [1] https://www.youtube.com/watch?v=JPXLpLwEQ_E https://www.youtube.com/watch?v=JPXLpLwEQ_E

mitjafelicijan 2y ago
That's a fair point.

hi-v-rocknroll 2y ago

This is a "Unabomber"-style prescription to the problem. The problem isn't shared libraries and the solution isn't static linking everything because that's wasteful for repetitive binary code duplicated N times consuming disk and RAM pointlessly. The problem is solved by management and cooperative sharing of shared libraries that don't rely on a fixed, singleton location or only allowing a single configuration of a shared library, but allow side-by-side installations of multiple version series and multiple configurations. Nix mostly solves these problems, but still has teething problems of getting things to work right especially for non-code shared file locations and dlopen program plugins. I think Nix is over-engineered and learning-curve user-hostile but is generally a more correct approach. There is/was a similar project from what was Opscode called Habitat that did something similar. Before that, we used Stow and symlink forests.

wmf 2y ago
allow side-by-side installations of multiple version series and multiple configurations So now every app requires a different library version and you've achieved all the disadvantages of static linking combined with all the disadvantages of dynamic linking.
- hi-v-rocknroll 2y ago
  No, you're being unreasonable because that's not the goal at all. The goal is to minimize variations while still allowing the possibility of variations that traditional distros like dnf/RPM Fedora/RHEL disallow without jumping through hoops such as renaming/prefixing or alternate toolsets like scl.

nektro 2y ago

sounds like OP would love nixos

pnathan 2y ago

I mean I don't disagree. But this is a bazaar problem and a rebundling problem. I have used Debanoids for decades and they just work. It's very nice. Gentol works very nice too. I usually whack systemD and enjoy. I do want to get a Fedora system going but eh. Just work is nice.

cxr 2y ago

> It would be an interesting exercise to make a prototype distribution that does not rely on shared objects, but has everything packed in AppImages. Frankly, I don't think people are ambitious enough—whether it be the author of this post or those posting here in this thread. We're at a good enough place with modern hardware—for personal/business computers, at least—that we should perhaps not even be thinking about object files at all. All software and all distros should focus on shipping software as source code; JIT everything at run time, but in such a way that JIT results aren't ephemeral—they get re-used, so by the second time (or nth time) it's the same as if all your utilities and system components had been AOT compiled. Neither the system operator, administrators, nor package maintainers should care any more about the object file format and the linking model than they care about... I dunno, the on-disk format of their browser cache for Web resources. (Quick, quick: do you know how your browser stores its cache items? Probably not, since it's not something anybody but browser developers think about.) Fabrice Bellard already demonstrated with TCCBOOT the viability of applying this approach to the Linux kernel with acceptable results, and that was 20 years ago. This would also help to ameliorate an unfortunate accident of history, where the fact that traditional software development and deployment has dealt in separate binaries and source code means there's friction for the user if they want to change how something works on their system. (This is true even if they've taken a hardline stance to ensure everything on their system is libre/open source—dealing with the build tooling on a project-to-project basis just isn't fun or tractable.) This would also neutralize the entire schism between Flatpak vs AppImage vs Snaps vs <whatever>.

cxr 2y ago
Some other food for thought: there's an oddity with the way that we approach binary optimization in that we care about it a whole lot, but a program will never be optimized further than whatever optimizations were in place when the binary hit the user's machine prior to its first use (i.e. the optimizations that were put there by the compiler running on the author's machine or the distro build farm. Why should that be the case? Why should the optimization phase stop there?

PaulKeeble 2y ago

The analysis I want is an idea of how shared they actually. Some of them are likely used in an awful lot of processes and represent a lot of memory and drive space savings where others don't represent much saving at all.

xg15 2y ago

> The main point is that, yes these packages can be big, but if we are honest, what would a couple of additional megabytes that would include shared object libraries actually do? A couple hundred, not a couple...

nixdev 2y ago

Many distros avoid the problem with something like apt-get install libflac7 libflac8 If you look in Fedora 40 for example, you'll find nodejs, nodejs18, and nodejs22. Gentoo's ebuilds (packages) can often have multiple major versions installed simultaneously. If I really need something, I can unpack another Gentoo userland, or use a container. AppImages, do exist. What seems to be the missing "glue" is putting a ui in front of users to choose what software they want to run. That problem has not yet been solved gracefully. The author says he knows how to use Linux, but observably never graduated to be a particularly advanced user.

mitjafelicijan 2y ago
This was not my argument. Maybe I presented it poorly. I agree with you on different versions being available, but that is not always the case. And in those cases you need to do some unsavory things with symlinking. It is not about graduating to being an advanced user. That's not the case at all. I know how to do it. I expect an advanced system to not force me to do it. That is my argument. I don't think this will ever be solved. And that's ok, as well. I think operating systems have been around long enough that this kind of things could have been resolved. And Windows have the same issues. DLL's missing etc. This is not isolated to just Linux. And developers of applications have also a blame to carry here. I have done this as well. edit: not even an advanced system, it's about how we package apps. That's probably a better way of saying it.

udev4096 2y ago

It's just impossible to critize a single entity in the linux world. The amount of choices (as author mentioned) is mindblowing which is why we still have distro dependent package managers (which, let's be honest, are far better than flatpak or snap)

JackSlateur 2y ago

Fedora is a worldwide experiments for new idea, so yes, you try new stuff, for the better and the worse.

Timber-6539 2y ago

All the fixes he's proposing to add to Appimages were solved by Flatpaks and Snaps. Of course he dismissed both options while giving flimsy non-concrete reasons. Reads like a boomer rant from the greybeard who is resistant to adopting new technologies while complaining about how things were easier back in the day.

sebazzz 2y ago

> Shared dependencies were a mistake! There, I said it! I understand that disk space was limited back then and this was a legitimate constraint. Now it is not disk space, but for instance security that is a major theme. It is so nice to update the shared OpenSSL library and after that just being safe for every application linked to it. However, it is indeed annoying that some distros (looking at you Arch) don't ship older versions of some shared libraries, like libLLVM. And then you indeed run into "shared library not found" issues.

edgarwarren9 2y ago

[dead]