Shared libraries [LWN.net]

Shared libraries

Posted Dec 5, 2025 12:06 UTC (Fri) by ras (subscriber, #33059)
In reply to: Shared libraries by Cyberax
Parent article: APT Rust requirement raises questions

> Why would this be complicated? You just recompile stuff and ship it.

It's complicated because the upstream stuff isn't the same.

Debian Stable has one feature sysadmin of smaller places love: it's stable. If there is some security issue Debian doesn't ship the new upstream with it's new features and depreciations, they ship the same version with a security fix backported. That effectively means you can let unattended upgrades do it's thing in the background for the four year lifetime a Debian of a typical release without too many concerns. (You will get the occasional email about something that might require manual intervention, like a reboot for a kernel upgrade, but it's rare.)

Big shops probably don't see much value in this, as they have teams of programmers releasing new static binaries or docker images every few weeks. But for small shops it's live saver. For example it makes home mail/web/ssh/router server as hobby feasible, because I only have to touch it once every 4 years. If you work in place that has less than 10 people handling IT functions, that way of operating is the norm. I've don't know much about LWN for instance, but I'd bet that's how they manage their infrastructure. It's either that, or god help you, you use micro services and outsource it all to a very well paid provider.

To pull that off Debian uses a small army of security volunteers watching incoming CVE's, and doing the backporting work. I'd kinda amazed it works at all, but it does better than that. In my experience Microsoft's security patches break far more servers than Debian does.

One of the tricks Debian uses to make it is Debian insisting there is only one version of every library in use. Imagine what it would be like if you have 20 versions of glibc, gtk, libm and every other library. The work load of the backporters would explode. Yet when I look in the Cargo.lock of your typical largish Rust program that is exactly what I see. Worse, it's not just a case of different program uses different versions of the same library, it's often different versions of the same library used by one program! Kudo's for Rust for making that work I guess - but that wonderful experience of having "cargo build" just work most of the time looks to me to have laid the foundations for creating a security nightmare.

All that said, I'm not a huge fan of the current package model myself. I'd much prefer an immutable core, rather like MacOS does (but much smaller), and default to complete isolation of the apps running on top of it like Android does. It would be far more secure by default. But it's decades of work away, and in the mean time Rust's monomorphization model doesn't seem to be a good fit for how distro's work today.

to post comments

Shared libraries

Posted Dec 5, 2025 12:48 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> One of the tricks Debian uses to make it is Debian insisting there is only one version of every library in use. Imagine what it would be like if you have 20 versions of glibc, gtk, libm and every other library. The work load of the backporters would explode. Yet when I look in the Cargo.lock of your typical largish Rust program that is exactly what I see. Worse, it's not just a case of different program uses different versions of the same library, it's often different versions of the same library used by one program! Kudo's for Rust for making that work I guess - but that wonderful experience of having "cargo build" just work most of the time looks to me to have laid the foundations for creating a security nightmare.

Can/does Cargo complain when told to use several different versions of the same library?

Given the general "If it compiles it will work" nature of Rust, a warning/error trace telling you "this library is loaded using several different versions pulled in in all these places", surely it would just take a bit of discipline to delete all the older references, a quick QA, and your "typical largish Rust program" would suddenly be rather smaller?

Cheers,
Wol

Shared libraries

Posted Dec 5, 2025 14:04 UTC (Fri) by farnz (subscriber, #17727) [Link]

Cargo itself will let you use multiple different versions of the same library in one program, without errors.

You can, however, use cargo-deny, which will tell you about multiple versions in use.

The issue, however, remains developer time. We all agree that using undermaintained versions of code is bad, but nobody is putting in the time to make sure that we're all on maintained versions. And the only difference in that regard between the C ecosystem and the Rust ecosystem is that in the Rust ecosystem, the use of large numbers of small dependencies means that it's easy to spot, where in the C ecosystem, spotting which parts of a big library (like glib) are undermaintained, and which ones are cared for is hidden behind the fact that glib overall is cared for.

Shared libraries

Posted Dec 5, 2025 13:08 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> All that said, I'm not a huge fan of the current package model myself. I'd much prefer an immutable core, rather like MacOS does (but much smaller), and default to complete isolation of the apps running on top of it like Android does. It would be far more secure by default. But it's decades of work away, and in the mean time Rust's monomorphization model doesn't seem to be a good fit for how distro's work today.

Unfortunately, I don't think that's a good fit with how linux development actually happens. Because everything happens independently, it's hard to do big releases. But yes, I agree with you.

The base OS - linux the kernel, systemd, basic utilities (similar in concept to MS-Dos).
The daemon set - sendmail and friends, MySQL and friends, etc etc
The windowing system - KDE/Plasma, Gnome, whatever
User applications.

And if each part were as self-contained as possible it would make life a whole lot easier. But it would require a "distro BDFL", and I don't think that's going to happen! It would probably take someone like Dell, or Red Hat, and the network effects are against it.

Cheers,
Wol

Shared libraries

Posted Dec 5, 2025 13:42 UTC (Fri) by pizza (subscriber, #46) [Link]

> Unfortunately, I don't think that's a good fit with how linux development actually happens. Because everything happens independently,

This point cannot be emphasized enough.

Shared libraries

Posted Dec 5, 2025 14:11 UTC (Fri) by daroc (editor, #160859) [Link]

As our HTTP headers state, LWN is currently hosted on CentOS Stream. But, as it happens, we've been looking into whether we need to change the site's hosting infrastructure due to some recent outages at our hosting provider. All the important configuration is theoretically kept in an ansible playbook that should allow us to change underlying systems without too much fuss — and if we do, Debian would certainly be a fine choice. But I believe the site has been on CentOS for the last several decades, and keeping to what is known to work also makes sense.

Shared libraries

Posted Dec 6, 2025 17:14 UTC (Sat) by ggreen199 (subscriber, #53396) [Link]

> All that said, I'm not a huge fan of the current package model myself. I'd much prefer an immutable core, rather like > MacOS does (but much smaller), and default to complete isolation of the apps running on top of it like Android does. > It would be far more secure by default. But it's decades of work away, and in the mean time Rust's
> monomorphization model doesn't seem to be a good fit for how distro's work today.

There are the new immutable distributions that work like this. For example, Kinoite, in Fedora, which is what I use now. It has an immutable core, and you use flatpaks or containers for everything else. Still early days, but I've been using it all year with no problems.