|
|
Log in / Subscribe / Register

Shared libraries

Shared libraries

Posted Nov 25, 2025 0:49 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: Shared libraries by carlosrodfern
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.

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.


to post comments

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds