What do dynamic linking and communism have in common?

OK, the analogy is dumb, but the point stands on its own. Dynamic linking has been around for so long that it's a sort of dogma, never questioned. Of course you do dynamic linking!<p>Just step back and consider all the problems dynamic linking has caused us (DLL hell, package management headaches, C library incompatibilities, various ABI issues) and the sheer complexity of the systems invented to solve those problems (Side-by-Side assemblies; InstallShield, Windows Installer, and umpteen other install frameworks for Windows; LD_LIBRARY_PATH, ldconfig; APT, RPM, and umpteen other Linux package managers).

"It is probably more illuminating to go a little bit further back, to the Middle Ages. One of its characteristics was that "reasoning by analogy" was rampant; another characteristic was almost total intellectual stagnation, and we now see why the two go together. A reason for mentioning this is to point out that, by developing a keen ear for unwarranted analogies, one can detect a lot of medieval thinking today."<p>Edsger W. Dijkstra

Yay for irrelevant analogies! Who cares if they shed any light on the topic whatsoever?! Let’s give red-blooded patriotic Americans something we can all get behind, hatred of the dirty commies!<p>You know what else dynamic linking is up to, Mandrake? Sapping and impurifying all of our precious bodily fluids.

There's a simple counterexample to this argument: operating systems. If it were not possible to create shared code, it would not be possible to write operating systems, which are nothing but shared code. Shared code does demand more careful management and versioning, especially of interfaces, and if you don't do that you are indeed hosed. But if you do then you aren't.

Libraries also open up a gate to exploits. For example the return to libc technique.<p><a href="http://en.wikipedia.org/wiki/Return-to-libc" rel="nofollow">http://en.wikipedia.org/wiki/Return-to-libc</a>

There are clearly downsides to dynamic linking but static linking would fail spectacularly when there is a bug in a common library, like libc. One of two things happens:<p>- Some applications are not updated and retain the bug. Extremely dangerous if it is a security bug.<p>- Suddenly your package manager needs to update almost every single application on your system. All the packages in my Ubuntu system is a total of ~1GB. Now that you statically compiled them prepare for a very long download.<p>The problems presented are largely solved in integrated distributions (like Linux distributions or Apple software). Where this isn't as clear is when external parties are trying to distribute software in a non-coordinated way (most apps in Windows, non-Apple apps in OSX). In those cases static linking probably makes sense but even then I'd say you are better off linking dynamically to fairly standard stuff like libc.

Couldn't you get the space efficiencies without the incompatibility headaches by naming the library like libfoo-SHA1_AS_LONG_HEX_STRING.so in addition to libfoo.so.1.2.3? They're already using symlinks in the lib directories.

Pfft. Dynamic Linking isn't broken, Solaris is. For some reason I don't have nearly the same amount of trouble handling dynamic libraries on Linux or BSD as I do on Solaris. If code depends on bugs, then the code is broken and <i>that</i> is a bug. Packaging your own special version of a library may solve your problems in the short term, but it increases maintenance in the long term. This is the same whether you do it statically or dynamically.

They're both supported/opposed fanatically by ideologues?

zlib security vulnerabilities, anyone? Or gecko, for that matter...

Dynamic linking works just fine. You don't want your every app to carry its bits of glibc inside, same for libx11, same for openssl. And it's definitely more polished than gems or jars or whatever other languages have; maybe only perl/cpan comes close.<p>On other hand, C++, with its writhing ABIs and changing mangling rules is definitely not suited for dynamic linking.<p>They could make their Class.forName() one day, but they were too arrogant and now it would never work okay. The solution is to restrict C++ usage.

Generally when I see article with really, really stupid analogies, I assume the article is not well thought out and probably of poor quality. As a rule of thumb, it gives pretty good results.