On the other side, link time optimization on static libraries allows deletion of unused functions and more aggressive inlining, so you might get that performance back and more.
The whole debate is just stupid. If it inconveniences even one fewer user, then static linking is the way to go, because of the sheer number of drawbacks that shared libraries bring. Nobody cares how big the executable is. If you do, well... the best time to stop caring was 10 years ago, and the second best time is now.
Also there is value in being able to fix a library without having to recompile everything.
Source? I know when stuff on my distribution gets recompiled because then I have to download and unpack it, so I notice.
I can assure you that it isn't as you say.
> with FreeBSD
Despite the monorepo thing, I assure you that most FreeBSD users do use software coming from other places as well.
Number of times I have benefited from this process: 0 (AFAIK)
Number of times this process has hosed previously-working applications and components: too many to count
On Windows, this "feature" was called "DLL Hell," and was generally considered a bad thing. Nothing has fundamentally changed since it was a common practice for every installer to have its way with c:\windows, IMHO. (Admittedly shared MSVC runtimes aren't as big a problem as the Winsock-provider-du-jour was, but still... there is simply no point.)
Every day on my distribution, when I have to download 5kb of library instead of 3GB of everything recompiled…
The functional package management/build system design instantiated by Guix and Nix show 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.
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
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/
The problem isn’t size. The problem is that with static linking it gets significantly more difficult to patch security vulnerabilities, because with dynamic linking, the vuln is gone once the underlying library is updated, however this wouldn’t happen with static linking.
That said, if the library changes the API or functionality at all, dynamic linking is going to break the game, and that's not good either. So gamedevs are going to opt for static linking and call it a day rather than deal with support requests.
In contrast, on (for example) Debian, I know that the Debian Security Team is looking after the libraries and that gives me a lot of peace of mind. Instead, I'd be wondering if every single third-party apt repository package owner is doing a professional job. At least if they're shipping binaries that are dynamically linked to Debian packages, I can have confidence that those library issues are being handled. (XML parser update, anybody?)
Many programming models (e.g. monomorphization as done in C++ and Rust) are fundamentally incompatible with dynamic linking. The tooling needs to handle those cases anyway.
Typical games I have experience with were in the 5-20Mb range for executables, with tens of GB for assets. Most titles I looked at the performance of were terrible at scheduling I/O, often leaving 80% of their available disk bandwidth unused.
Wasn’t the reason to separate binaries and libraries in the first place to conserve disk space? They are then clearly versioned to signal that you can’t expect just any version of the library to work with the program you wrote.
The trade-off in using more disk to contain “an application” to “a binary” seems fine to me, if you’re not sacrificing anything else.
The only drawback I can think of is that it makes very minor patches, like security fixes, to the library impossible, which is a nice thing to have I guess, but on the other hand you’re now giving the library maintainer the capability to crash your application, and since that would presumably go through some kind of review and rebuild of the application in the first place to avoid crashes against the new library code, why does it matter if the lib is a part of the actual binary or not?
Is it really down to nothing but bandwidth and disk usage, or am I missing something here? Because if it is, and “blob binaries” becomes the norm, I’m sure you could still figure out partial patches somehow to conserve bandwidth and IO, while still keeping the binary essentially a built monolith.
Maybe one argument is that abandoned programs can still be “patched” in a way because a library it depends on fixes an issue that library was responsible for, but doesn’t that seem pretty risky to begin with to run software that is no longer being patched?
Indeed what constitutes “software” just seems to be multiple pieces in one case, and one piece in the other, no?
The biggest case against “vendoring”, which in my mind is similar to “huge” binaries, that I can think of at least is that it gives developers a false sense of security to not have to think about keeping libraries up to date: but aren’t they already equally able to be sloppy about this when the libs are separate?