Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

https://tests.reproducible-builds.org/debian/reproducible...

So if you think "use popular libraries" and "don't use some crappy tool nobody has heard of" is "jumping through hoops"… sure… However developers that do things like these probably write low quality software and nobody is worse off for it not being available on distribution repositories. The ego of the author might be a bit bruised but perhaps that can be a learning experience.

Keep in mind that prior to becoming a distribution maintainer, I had my software packaged in Debian by someone else. So I've experienced both sides. Have you?

Because you install, update, manage and load a dependency ONCE, instead of 1928391238912 times, one for each user, in slightly different version each time. This affects security, maintenance, bandwidth (not everyone lives in the western world with unlimited data and symmetric fiber), disk space, and memory (a shared library is loaded in memory ONCE and then just remapped for every process that uses it, and this makes a difference on small devices). And more of course. All these are not really language-specific reasons, and apply just the same everywhere. C wasn't (used) like this at the beginning either, it was coerced into, _despite_ its characteristic as a language, and not because of it, and that's why people who work in this ecosystem don't really buy the excuses made by $newlanguageoftheweek.

> Am I right in thinking that glibc is one of the few places where dynamic linking works as intended?

You are very much not right in thinking that, no. By policy every library in most distros is used in the shared object format, and exceptions are extremely rare (and very much frowned upon).
Not everyone is as good as glibc to maintain a stable ABI (but many are, though), but that just means you have to do what in Debian we call 'ABI transitions'. The difference is that in this ecosystem, on a per-library basis, they are rare, as attention is paid to avoid breaking ABI needlessly. There are a few exceptions (*cough* libxml *cough*) but by and large this works. The effort required is anyway orders of magnitude smaller than "rebuild everything every time every minute of every hour of every day".

That's most definitely not true - some libraries are bad, but most are good on that front, and ABI transitions are relatively easy, with few exceptions especially compared to the grand total of number of libraries shipped.
And of course - in case there's a library that is badly maintained and doesn't bother with keeping ABI stable, that is simply a bad library, and not a candidate for being included in the first place

> But the original reason for dynamic linking is simply that consumers cannot recompile proprietary binaries, and want to receive binaries they can run without a "prepare" step. Good tooling can already rebuild all dependent packages on a version change (e.g. Open Build Service does this), and the other reason that people cared about dynamic linking back in the day is that downloading updates over dial-up was already painfully slow with statically linked packages.

That might surely have been the issue originally, but it's not today. Constantly rebuilding everything all the time costs a lot of compute power (hello, climate change anyone?), and while we in the western countries are blessed with symmetric fiber connections with no data caps, that is most definitely not the case everywhere in the world, and in many many countries metered 2g/3g/4g cellurar connections are the only option. And on top of that, disk space still matters in some cases: when building an initrd, you want that as small as possible even on a modern powerful laptop. And you want to save memory and latency by loading the DSO _once_ instead of every time for every program, which matters a lot of low-end/embedded devices.

And that is the point I keep making again and again here -- Go & Rust's tooling for tracking/vendoring/pinning dependencies is quite powerful.. but is utterly useless unless you have the complete source code to _everything_. A single non-public component renders the whole thing unbuildable, even if you have the source to everything else.

This effectively means that you are forever at the mercy of your vendor to provide _any_ sort of updates.

I really don't think this is true. The original reason for creating dynamic linking is to save memory and disk space. RAM and storage was scarce and expensive.

this seems to call for data. even if a library author doesn't bother to learn the common semantics/practices of ABI stability themselves, they're likely to be pointed out as soon as packaging efforts start, or users begin deploying binaries expecting such stability. adding entirely new functionality is not generally abi breakage, if that's not obvious.