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

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).<p>Your problem with &quot;libFlac.8.so is missing&quot; 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&#x27;s no reason to make the rest of the distro worse.<p>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&#x27;s gatekeeping, the Audacity package from distro repos did not have telemetry enabled that Audacity devs added to their own builds, etc.

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&#x27;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.)<p>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&#x27;s own, but it&#x27;s one of the reasons Linux can run on lower-end devices.

&gt; <i>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.</i><p>That&#x27;s what has made me leave Linux for Mac OS, and I&#x27;m talking about things like the touchpad (libinput) causing physical pain and crashing every couple minutes while the &quot;desktop&quot; 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 <i>also</i> 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&#x27;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 <i>also</i> is a case of unwarranted and rampant complexity piling up without the slightest actual benefit for the user as the web is dying.

Been running Gentoo for over 20 years. It&#x27;s as (un)stable now as it was then. It definitely has not regressed in the last N years.<p>I don&#x27;t see this as a GNU&#x2F;Linux problem, but a distro problem.<p>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&#x27;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&#x27;ve now put a huge amount of work on my plate with static compilation.<p>Finally: What does shared libraries have to do with GNU&#x2F;Linux? I don&#x27;t think it&#x27;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&#x2F;Linux. This is an orthogonal concern.

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.

&gt; I am all in for AppImages or something like that. I don&#x27;t care if these images are 10x bigger. Disk space now is plenty, and they solve the issue with &quot;libFlac.8.so is missing<p>They don&#x27;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 &quot;Debian&#x2F;Ubuntu&quot; 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&#x27;re missing Qt, or your Qt version does not match the version it was compiled against, same GTK, Mesa, Curl etc.<p>The moment there&#x27;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&#x27;t break user-space.<p>They don&#x27;t run on my current distribution choice of NixOS. Meanwhile Flatpaks do.

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

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&#x27;t have to, so it is with nix and your application filesystem.

If anything, I&#x27;d argue that the &quot;abysmal state of GNU&#x2F;Linux&quot; is because programs now tend to bundle their own dependencies, and not the opposite.

&gt; <i>Just a normal update that I do many times per week. [...] At this point, using GNU&#x2F;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.</i><p>But the author already knows the solution...<p>&gt; <i>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&#x27;t say the same for Fedora.</i><p>You&#x27;ve always had the power... tap your heels together three times, and just install Debian Stable.

That&#x27;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.

AppImage does not always solve these dependency issues. I&#x27;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.<p>As for the Nvidia issues, especially the &quot;system refuses to boot&quot; kind, that&#x27;s on Nvidia.

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

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

I feel like these sorts of articles come up every so often, but still don&#x27;t buy it.<p>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&#x27;s readonly data sections get loaded into RAM exactly once. That&#x27;s a good thing.<p>But even if that problem wasn&#x27;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&#x27;t have to wait for individual maintainers, but not all are like that.)<p>I don&#x27;t have to wonder what app has been fixed and what hasn&#x27;t been. I don&#x27;t have to make sure every single AppImage&#x2F;Flatpak&#x2F;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&#x27;t been, until they have.<p>I like shared libraries, even with the problems they sometimes (rarely!) cause.

Perhaps this is a hard&#x2F;impossible problem to solve, but I feel like the issue isn&#x27;t so much the shared libraries, it&#x27;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 &quot;I have version 1, 2, 3&quot; has basically just been linking against filenames.<p>But here&#x27;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.<p>What if instead of having a .so per version, we packaged together a computable shared object and had the compiler&#x2F;linking system incorporate versions when making a link? From there, we could turn the requests for versions be something like &quot;Hey, I need 1.2.3&quot; and the linking system say &quot;1.2.3 consists of these chunks from the shared repository&quot;. That could be manifest and cached by the OS.<p>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.<p>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 &quot;Actually, anything that requests version 1.2.3 will get 1.2.3.1-patched because of a CVE&quot;. Or you could even hotpatch in the same function on all versions in the case of CVE having a more targeted patching system.<p>I&#x27;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.

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

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

&gt; Some interesting talks and videos [...] GNU is Bloated! by Luke Smith<p>Strange reference because that video isn&#x27;t relevant to the topic at all. It&#x27;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&#x2F;Flatpaks&#x2F;Snaps and believe they go against the spirit of GNU&#x2F;Linux [1].<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=JPXLpLwEQ_E" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=JPXLpLwEQ_E</a>

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.

This is a &quot;Unabomber&quot;-style prescription to the problem. The problem isn&#x27;t shared libraries and the solution isn&#x27;t static linking everything because that&#x27;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&#x27;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&#x2F;was a similar project from what was Opscode called Habitat that did something similar. Before that, we used Stow and symlink forests.

The old reason for shared libraries was to share memory&#x2F;cache and not waste disk space. That&#x27;s not gone, but maybe it&#x27;s less important than it used to be.<p>The modern reason is <i>maintenance</i>. 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.<p>But then you need libraries to limit compatibility-breaking changes to once or twice a decade.

It&#x27;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&#x27;s be honest, are far better than flatpak or snap)

&gt; Shared dependencies were a mistake! There, I said it! I understand that disk space was limited back then and this was a legitimate constraint.<p>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 <i>safe</i> for every application linked to it.<p>However, it is indeed annoying that some distros (looking at you Arch) don&#x27;t ship older versions of some shared libraries, like libLLVM. And then you indeed run into &quot;shared library not found&quot; issues.

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

&gt; This is why I am a massive proponent of AppImages<p>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.

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&#x27;t represent much saving at all.

&gt; <i>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?</i><p>A couple hundred, not a couple...

&gt; It would be an interesting exercise to make a prototype distribution that does not rely on shared objects, but has everything packed in AppImages.<p>Frankly, I don&#x27;t think people are ambitious enough—whether it be the author of this post or those posting here in this thread.<p>We&#x27;re at a good enough place with modern hardware—for personal&#x2F;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&#x27;t ephemeral—they get re-used, so by the second time (or nth time) it&#x27;s the same <i>as if</i> 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 <i>you</i> know how your browser stores its cache items? Probably not, since it&#x27;s not something anybody but browser developers think about.)<p>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.<p>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&#x27;s friction for the user if they want to change how something works on their system. (This is true even if they&#x27;ve taken a hardline stance to ensure everything on their system is libre&#x2F;open source—dealing with the build tooling on a project-to-project basis just isn&#x27;t fun or tractable.)<p>This would also neutralize the entire schism between Flatpak vs AppImage vs Snaps vs &lt;whatever&gt;.

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

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

&gt; <i>the issue with &quot;libFlac.8.so is missing&quot; and I have version 12 installed</i><p>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).<p>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.<p>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 &#x27;same only different&#x27;, and that really it makes no sense to use both `foo@3` and `foo@4` from the same piece of code, because they&#x27;re just two versions of the &#x27;same&#x27;.<p>Rich Hickey[1] cuts through this and asserts that, no, if there&#x27;s a single bit of difference between foo version A and foo version B, then they&#x27;re—<i>different</i>. In fact, both pieces of software can behave in arbitrarily different ways. In the real world, they most of the time don&#x27;t, it&#x27;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. <i>Where</i> those differences lay, and whether they will impact my particular use of that software remains largely a matter of conjecture.<p>Which brings me back to the OP&#x27;s remark about libFlac.8.so conflicting with libFlac.12.so. I think they shouldn&#x27;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 &#x27;patch&#x27; and we can go on pretending that we can share libraries system-wide on a &#x27;first-name basis&#x27; as it were, i.e. disregarding their version numbers.<p>I feel I do not understand Linux deeply enough but my suspicion has been for years now that we don&#x27;t <i>have</i> 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 <i>any</i>, and therefore the two libraries should be treated like any two wholly independent pieces of software.<p>[1] <a href="https:&#x2F;&#x2F;youtu.be&#x2F;oyLBGkS5ICk?list=PLZdCLR02grLrEwKaZv-5QbUzK0zGKOOcr" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;oyLBGkS5ICk?list=PLZdCLR02grLrEwKaZv-5QbUzK...</a>

Fedora is a &quot;move fast maybe sometimes break things&quot; distro, e.g., early adoption of Btrfs as the default, Wayland etc.<p>So yeah, these things sometimes happen.

The world needs a static linux distribution more than ever.

sounds like OP would love nixos

All the fixes he&#x27;s proposing to add to Appimages were solved by Flatpaks and Snaps. Of course he dismissed both options while giving flimsy non-concrete reasons.<p>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.

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

The abysmal state of GNU&#x2F;Linux is exactly why I moved to OpenBSD many years back. It&#x27;s small, simple and very stable.<p>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.

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

&gt; Shared dependencies were a mistake!<p>Couldn&#x27;t agree more.

If “gnu” gets headline billing for providing some user land tools then really “systemd&#x2F;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.