A tradeoff that few consider is that dynamic linking can lessen the motivation of library developers to reduce code bloat and complex dependency trees. Archite

A tradeoff that few consider is that dynamic linking can lessen the motivation of library developers to reduce code bloat and complex dependency trees. Architecting an operating system and its packages as a psychological forcing function to improve software development is not a worthwhile tradeoff for the efficiency, security, or reliability of a system. Who cares about 20 megs here or there if there is only one shared library instance? Who cares about bringing in a tree of 50 dependencies for this console program if the user probably has them installed already? And thus we end up with the modern Linux desktop, where nearly everything depends on a gigabyte or more of dependencies. I find it amusing that someone is arguing for static linking as a way to make it obvious how bloated programs are, since usually the counter-argument to dynamic linking from many is "who cares about disk space!". There are plenty of programs that are distributed essentially statically-linked today, that still have 50 dependencies or more -- there is no data that I am aware of to support the idea that dynamic vs. static linking would encourage developers to reduce their dependencies. Whereas with static linking, you can directly see the effect that any library you use has on the binary size. This encourages library and application devs alike to be more judicious with their dependencies. This is a dubious argument at best; you can still easily see the size of your program today even if it's dynamically linked simply by looking at top, or by using the appropriate developer tools. I can empathize with the frustrations that some feel in dealing with some operating systems and applications, but it is not due to a technological issue -- it is due to cultural and process issues present not only in the development of the software they rely on but in the distributions that provide the software themselves. "papering over" those issues by static linking only makes the problem worse -- not better. This a cultural and process issue that cannot be addressed solely through technological means. Also, I want to be clear that I am not linking against static linking completely; I'm arguing for dynamic linking (or more generally, shared objects) for those dependencies shared between a sufficient number of components that have sufficiently stable interfaces to share them. By all means, if there is a component with a sufficiently unstable interface, then by definition, it is not appropriate for sharing between components, and at that point whether you statically or dynamically-link the dependency is moot, since you can have private dynamically-linked dependencies just as easily statically-linking them into binaries.