[anyfoo]

> Ah, but you might say, if a shared library is compromised, it's easy to push a fix! But how to you think it got so widely compromised in the first place? Perhaps because it was a widely shared library? Sharing is a double-edged sword.

Not sure I understand. I imagine without dynamic linking/shared libraries, most widely used shared libraries would be widely used statically linked libraries, and so a vulnerability in them would indeed be harder to fix, as you'd need to relink all the binaries using them instead of just the dynamically linked library?

(Also, memory usage seems more concerning to me than disk space. Shared libraries are called "shared" because all their non-mutable pages in memory are shared across processes. To even approximate the same with static libraries, you'd pretty much have to have deduplication of pages in memory. Link-time optimization might then spoil even that plan entirely. Of course on the other hand, dynamic linking precludes LTO for that.)

[twblalock]

You don't re-link binaries. The vendors ship you a new build. Your OS should not have any libraries other than the ones it needs to function by itself.

[anyfoo]

Well, that's the point. The vendor needs to relink, and now you need to wait for an update from the vendor of each individual client of a library. With shared libraries, replacing the shared library is enough.

What I did not understand is how static linking would have precluded the problem in the first place. I don't think that would have made those libraries less widely used.

[twblalock]

> With shared libraries, replacing the shared library is enough.

Yes, but if a shared library update includes a bug, it affects all your programs! That's why it is a double-edged sword: The same mechanism that solves the bugs can also deliver bugs.