Today, to get a game to work on an older system.

Several times last week when I needed to use an old proprietary program that used several outdated libraries.

Every single time I want to run a program (usually a game) that has a runtime dependency on pulseaudio[1]. (apulse[2] usually works to translate the libpulse ABI back to ALSA).

One time I had to write my own version of a library that specifically emulated the ABI used by an important program from an outside vendor. Obviously this didn't "just work"; it required a couple weeks of work to write the new version. The point isn't that future versions of a library will magically "just work". With a dynamically linked dependency replacement is at least possible. If the program in question was statically linked, nothing could be changed.

The question isn't about which method is less work or easier to maintain. The question that matters in the long run is if you want the basic ability to modify program's dependencies in the future to fix an important problem?

[1] As of a few years ago, the stupid design decisions in pulseaudio make it make it highly incompatible with my needs. Just having it installed makes runtime linking issues even worse. It also add insane amounts of latency (>5ms is bad. >50ms is insane) by design.

[2] https://github.com/i-rinat/apulse

I'm not in the pro-shlib camp (it's what brought us the whole Docker->k8s fiasco in the first place), but it might be worth noting that the LGPL requires shared libs ie requires you as an end user be able to swap LGPL libs by newer versions, alternate implementations, or your own.

Also, there are legitimate use cases for shlibs-as-plugins, such as ODBC.

I agree with the core of your comment, but I would note that containerization has other advantages over simple static binaries. In particular, sandboxing even at the network layer. Also, containers often bundle mutiple programs together to ensure compatibility, not just libraries, which is a step that is almost never discussed. Applications often depend on system utilities whose API is even more poorly defined/maintained than system libraries, so bundling your own ls or shell may be a safer option.

Even further, k8s really has nothing to do with this, it is a tool for submitting workloads to a group of a computers through a single API, and it critically depends on containerization for network and storage isolation. K8s would have looked more or less identical to how it does today even if shared libraries had never existed (though probably the exact format of OCI container images could have been much simpler).

> it might be worth noting that the LGPL requires shared libs

nope, not at all. https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...

But it says

> If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Heads up to gnu.org: site won't load via https in FF due to HSTS policy (broken certificate chain?).

It happens almost every day when I update my rolling release distribution.

You'd not need to do that if all (or all besides libc maybe) were statically linked though.

So that's actually an argument for statically linking, as doing such every day is just a PITA and not really an option for those who need to actually get work done during spending paid time on such a system.

I successfully upgraded the OpenSSL-DLLs used by a no longer maintained Windows program when some servers started refusing connections (presumably due to outdated SSL/TLS versions and/or encryption schemes used by the old DLLs). After upgrading to a recent version of OpenSSL, everything worked fine again.

Last time I ran apt upgrade?

All the time.