Shared libraries [LWN.net]

Shared libraries

Posted Nov 27, 2025 0:47 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: Shared libraries by bluca
Parent article: APT Rust requirement raises questions

So, correct me if I'm wrong, everything that solves the users' problems with updates is bad? As long as it makes the updates fast, seamless, reliable, and atomic?

BTW, even the _actual_ user-facing versions of Fedora are switching away from RPMs. See: Bazzite.

to post comments

Shared libraries

Posted Nov 27, 2025 1:06 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> So, correct me if I'm wrong, everything that solves the users' problems with updates is bad?

Ladders are really, really useful for climbing to the top of a one or two-floor building.

But for 3-4 floors, portable ladders are no longer an option. Beyond 5.. ladders of any sort are worthless and a completely different solution must be employed.

In case you can't follow this analogy, something that is optimal for one application, or even a couple of applications, rapidly runs into fundamental scaling problems when you try to scale it to dozens or hundreds of applications.

But application writers don't care about bigger picture problems; they only care about *their* application.

Shared libraries

Posted Nov 27, 2025 6:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> But application writers don't care about bigger picture problems; they only care about *their* application.

I agree with your analogy. Except that classical distros are these rickety wooden home-made ladders. And modern Docker or immutable distros are tower cranes.

Shared libraries

Posted Dec 2, 2025 21:06 UTC (Tue) by raven667 (guest, #5198) [Link] (1 responses)

I think it is a good fit for the OS distributor using tools like RPM to manage the internal complexity of their software, then roll that up into an image with deltas for distribution in the way that Bazzite and other rpm-ostree distros are built, same for building Flatpak and Docker runtimes and apps. You need a tool like RPM/deb to track how a complicated runtime gets built.

I've been working with package-based OS since Redhat 4.2 (Colgate IIRC) and can see the limitations in scaling up a full desktop workstation using rpm/dpkg and yum/apt, where update performance is slow (my Fedora MacPro I used to use would take *hours* to update between releases on spinning rust) and the cost of de-duplicating all application libraries is the local admin has to use the packaging tool to manage long dependency chains, and things get complicated if you want to install an app which the OS distributor hasn't packaged themselves.

For someone who just wants to _use_ the computer to do computer things, rather than making OS design and development their hobby, the image-based systems with container-based apps work a lot better and more reliably than the package-based model, at least in my experience. Heck, having a good way to rollback because you aren't trying to mutate the one-and-only live system comes in really handy and makes me sleep better at night that the computer isn't going to immolate itself if something goes wrong.

Shared libraries

Posted Dec 3, 2025 2:50 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Yup. As many people noted, Linux works well for local development. And image-based systems allow that local environment to be used more easily for deployment. Package-based distros are also great for low-level tinkering and experimentation.

Although classic distros might also eventually change a bit. I think something like nix or guix might end up a better solution.