> Unless we’re talking about embedded systems (and most of the time, not even then I’d guess for portable gaming devices for example), what is the actual drawback of these “huge” binaries?
The functional package management/build system design instantiated by Guix and Nix shows that you can have the best of both worlds when it comes to static and dynamic linking, even without any form of containerization. Guix in particular has a feature called 'grafts' which implements a kind of hot patching for libraries in programs which are nominally dynamically linked but which in fact never search for libraries other than the exact versions they were built with.
So there's no need to choose between the portability of static linking or the efficiency and flexibility of dynamic linking. You can get all of those things together, today, for many thousands of packages.
If you're not familiar with the basic outline of these build systems, the idea is basically this:
- every package gets installed to a unique, quasi-content-addressed location
- each such location has its own FHS-like tree which gets treated as a prefix for that package at build time
- every package gets manually pointed to each of it's dependencies' unique, full paths at build time
this ensures that each package always tries to load the libraries it was built with, and allows multiple versions of libraries to safely exist side-by-side, even when everything is dynamically linked.
To ship a package, you then just ship the whole dependency closure, which gives you the portability that motivates people to distribute static binaries.
Here's some info on Guix grafts, for an idea of how security updates can still be managed in such a system.
The official docs for grafts: https://guix.gnu.org/manual/en/html_node/Security-Updates.ht...
Original blog post/announcement for the feature: https://guix.gnu.org/blog/2016/timely-delivery-of-security-u...
Detailed writeup of further implementation details: https://guix.gnu.org/en/blog/2020/grafts-continued/