Shared libraries [LWN.net]

Shared libraries

Posted Nov 24, 2025 23:39 UTC (Mon) by carlosrodfern (subscriber, #166486)
In reply to: Shared libraries by Cyberax
Parent article: APT Rust requirement raises questions

I'm actually pointing out the *problems* of doing all the things statically linked, not advocating for it.

The fact that statically linked programs are a good solution in containers doesn't mean that it can be extrapolated to an Linux distro. A slightly change in the nature of a problem, or in the size of the problem, can justifies a very different solution. It is a typical mistake that people make as they get excited about one technology or approach and want to apply it to all the things that like like a nail. Statically linked programs written in golang or Rust for containers make a lot of sense since the pros are weighty and the cons are not that significant in the context of that use case, but it is not a good approach for all the programs in Linux distros.

to post comments

Shared libraries

Posted Nov 25, 2025 0:49 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> I'm actually pointing out the *problems* of doing all the things statically linked, not advocating for it.

But it's not really a problem, is it? Binary diffs for patch update can negate the advantages of shared libraries.

> The fact that statically linked programs are a good solution in containers doesn't mean that it can be extrapolated to an Linux distro.

But maybe it can? I actually tried a fully static distro a while ago ( https://github.com/oasislinux/oasis ), and it objectively felt _better_ than regular Debian.

I'm not at all convinced that shared libraries are worth all the hassle.

Shared libraries

Posted Nov 25, 2025 20:27 UTC (Tue) by Whyte (subscriber, #161914) [Link] (1 responses)

Did your test also include KDE or GNOME?

That's the part I don't ever see happening, since the libraries supporting those are huge.

Shared libraries

Posted Nov 26, 2025 2:38 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

No, it used its own display manager. That was pretty snappy but limited.

I think that these days, graphics library problem can be solved by moving the UI into Electron-like shells, with a shared browser layer. And custom native code can be called via IPC. This in theory can provide even more optimizations, like pre-forked initialized shell that can be forked up without waiting for it to load (like the 'zygote' process in Android).

BTW, the browser doesn't have to be Chromium. Servo would be great for this purpose.