“I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications.” – John Carmack
<rant>
I don't like to be a parrot for the Plan9 people [1] (they've been winning their own fights for a while now), but they've assembled a better set of citations than I could in the time I'm willing to devote to an HN comment.
Dynamic linking is fine, in very specific, very limited cases. Python extensions. Maybe you want to do a carve-out for like, some small hardened core of an SSL implementation or a browser because you've got actual hot-deploy in your (massive) installation/infrastructure.
As a basically mandatory default it's a chemical fire next to an elementary school. It started gaining serious traction as a horrific hack to get a not-remotely-finished X Windows to run on Sun boxes in like, +/- 1990. It wasn't long before the FSF had figured out that they could bio-weaponize it against interoperability. The `glibc` docs are laughing in their beer while they explain why static linking on "GNU" systems is impossible, and also makes you a criminal. They don't even pretend to make a cogent argument (they said the quiet part loud on the mailing lists). It's to kill other `libc` and `libc++` (fuck you small-but-vocal anti-interoperability FSF people!). Don't want LLVM to finish you off? Start interoperating better. There are a lot of us who think "Free Software" has to mean that I can use it in legal ways that you philosophically disagree with, and if it happens to be better than your Win32-style lock-in? Well that's just groovy.
Dynamic linking by (mandatory) default: Just Say No.
Myths:
- People want it: Docker. QED.
- Secure: Dynamic linking is the source of tons of security vulnerabilities. More generally, the best way to not trust your system is to not be able to audit the literal code you're running without jumping through insane, sometimes practically impossible hoops. If you want "father knows best" security, you need self-patch like Chromium and shit do now. And if you're willing to trade performance for security by the gross, flat pack or something.
- Performant: Dynamic linking forces address patch-ups, indirect calls, and defeats many optimizations. It thrashes TLB. It slows startup of even simple programs.
- Necessary: Text pages are shared. I don't care if you've got 9, 90, or 90k processes using `printf`: it's going to be in the same text page unless something else went badly, badly wrong.
Good primary sources are the `glibc` documentation, especially the FAQ [1], and the `musl` docs, especially the "differences from glibc" section [2] and the FAQ [3], which is basically a long list of ways that `glibc`/`gnulib` developers have leaned into ever-more-broken/nonstandard behavior. If you dig through the GNU mailing lists (which is where I draw the line for an HN comments), you'll find megabytes of admission that this is in an effort to make "GNU/Linux" (or as I've taken to calling it, GNU "plus" Linux, Linux being merely the kernel...), to quote Fassbender as Steve Jobs: "Closed system! Completely incompatible with anything!"
But the short story is that both NSS (DNS lookup), and `iconv` (locale handling) don't work without `glibc`-specific dynamic linking shit. Ostensibly this is because of things like merely being able to read decades-obsolete multibyte character encodings, and not able to write them, is a bridge too far to support at all, let alone as a default. They've also got a bridge they'd like to sell you (see mailing lists).
It's just 90s Microsoft vendor lock-in: "embrace, extend, extinguish" we used to call it. Stallman was a hero for getting the free software movement rolling in the 80s. But in this business, you either die a hero or live long enough to become the villain, and Bill Gates himself would be proud.
I understand why, technically speaking, glibc doesn't support static linking (and I also think that it's bad design). What I don't understand is how this makes it "incompatible with anything". The glibc-specific APIs, sure, they do - to the extent the apps actually use them (which, judging by the intersection of e.g. Debian and FreeBSD package repos, is not exactly common). But how does denying the ability to link statically promote this goal?
Your last point is a bit off. Text pages are shared iff they come from the same file. So your point works if the 90k processes are the same program. Else: shared libs...
Yeah I was typing too fast in ranty mode, thanks for calling it. I did a much more detailed answer that gets it (mostly) right replying to another commenter: https://news.ycombinator.com/item?id=32461766
<rant>
I don't like to be a parrot for the Plan9 people [1] (they've been winning their own fights for a while now), but they've assembled a better set of citations than I could in the time I'm willing to devote to an HN comment.
Dynamic linking is fine, in very specific, very limited cases. Python extensions. Maybe you want to do a carve-out for like, some small hardened core of an SSL implementation or a browser because you've got actual hot-deploy in your (massive) installation/infrastructure.
As a basically mandatory default it's a chemical fire next to an elementary school. It started gaining serious traction as a horrific hack to get a not-remotely-finished X Windows to run on Sun boxes in like, +/- 1990. It wasn't long before the FSF had figured out that they could bio-weaponize it against interoperability. The `glibc` docs are laughing in their beer while they explain why static linking on "GNU" systems is impossible, and also makes you a criminal. They don't even pretend to make a cogent argument (they said the quiet part loud on the mailing lists). It's to kill other `libc` and `libc++` (fuck you small-but-vocal anti-interoperability FSF people!). Don't want LLVM to finish you off? Start interoperating better. There are a lot of us who think "Free Software" has to mean that I can use it in legal ways that you philosophically disagree with, and if it happens to be better than your Win32-style lock-in? Well that's just groovy.
Dynamic linking by (mandatory) default: Just Say No.
Myths:
- People want it: Docker. QED.
- Secure: Dynamic linking is the source of tons of security vulnerabilities. More generally, the best way to not trust your system is to not be able to audit the literal code you're running without jumping through insane, sometimes practically impossible hoops. If you want "father knows best" security, you need self-patch like Chromium and shit do now. And if you're willing to trade performance for security by the gross, flat pack or something.
- Performant: Dynamic linking forces address patch-ups, indirect calls, and defeats many optimizations. It thrashes TLB. It slows startup of even simple programs.
- Necessary: Text pages are shared. I don't care if you've got 9, 90, or 90k processes using `printf`: it's going to be in the same text page unless something else went badly, badly wrong.
</rant>
[1] http://harmful.cat-v.org/software/dynamic-linking/