Do shared libraries still make sense?

Software
1

I had been hacking for several days on a small application that provides smart card support for my bank’s ATM card. The bank provided a version for Windows, Mac, and (surprise) Linux. The Windows app just worked on Win11 although it had been written some time ago and only mentioned Windows 7. The Linux app was built on Ubuntu 18.04 and of course was completely broken on Ubuntu 24.04 due to missing/obsolete packages, etc. With a little hacking and backporting a couple of missing libraries I managed to get the app working on Linux, but then ran into a problem at the bank after successfully logging in with my ATM card. So guess I’m stuck with Win11 if I need to pay bills online using my ATM card (that’s the way things work in Taiwan).

I watched a rant by Linus Torvalds on YouTube from about 3 years ago where he was complaining about the sorry state of desktop Linux. So many of the problems I run into when maintaining my systems come down to version-itis issues with libraries that I’m wondering why do we even need this stuff anymore? 40 years ago in the early years of the PC revolution memory was scarce and storage expensive, so it made a lot of sense back then to be able to share resources among applications in order to minimize an app’s storage footprint in a given system. But today why do we need to bother with shared libraries? I mean, when was the last time we had to deal with overlays? Shared libraries really still make sense only for development, but once an app is finished statically compile the bugger and ship it and it will run on any distro regardless of version and survive many an upgrade until the kernel breaks something. But kernel breaking it down the road is unlikely it seems, at least as long as Linus is around. His #1 rule for kernel developers, and it has NO exceptions, is: you don’t break userland.

We measure disk space in Terabytes and memory in Gigabytes these days, who cares how much disk space an app takes up? It’s nothing compared to the amount of storage we have available. Even my itty bitty Jetson dev board has 1TB of SSD on it. And especially for embedded systems running Linux it seems that statically compiling applications makes a lot of sense. The fewer files to configure in a system or have to OTA from time to time the better.

2

We have discussed this quite a few times and the fact that new language runtimes like go, rust and zig, etc. offer static linking as tier 1 method of building apps, we will see more and more apps using static linking in future. I think dynamic linking does promote resource usage, so it has that advantage and glibc is quite good at supporting apps for long long time much like the kernel in this case. However, the problem arises with other libraries, which may not have as mich rigor put behind backward compatibility and thats where most of the problem would arise.

I wonder what would be the disk footprint of a system consisting of just static binaries vs. current systems and what would be the memory consumption at runtime on normal use. I could not find any data on this so far.

One area where the shared model is better at is patching security issues or other serious bug fixes. You build the library and push it to the distro and all its users are technically patched. In a system with static binaries, almost all apps need to be rebuild and updated.

We have been doing VMs and then containers to do app isolation, with a static app ecosystem that will be redundant, which is cool since another layer will not be required and will simplify the system.

so it comes with some pluses and minuses, as is the care always.

2 Likes
3

Deploying statically linked Go apps with an embedded runtime to embedded Linux systems has been a game changer. I can upgrade to any version of Go and simply keep building and deploying app updates with no changes to the underlying system. It is amazing.

4

I think, it will make sense to have a base system rethink and carefully choose what one wants. If systemd binaries are statically linkable e.g. that might be all a good start. I agree, if one app is all you care then current go static linking or rust static linking or perhaps zig even, might be a good way to go. I am thinking more of whole system consisting of just static binaries :slight_smile:

2 Likes