This is certainly very true, and the pessimistic tone of the cat-v article is, to some degree, unwarranted, but it's also worth pointing out the unanticipated p

This is certainly very true, and the pessimistic tone of the cat-v article is, to some degree, unwarranted, but it's also worth pointing out the unanticipated problems real life brought. In practice, this is something that happens less often than we'd want: > It's the last that is still crucial and which causes so many problems. When, say, there's a security problem in Webkit, an updated version of the webkit code can be installed, immediately (well, upon restart) providing that fix to all programs that used Webkit. Otherwise the end user / in house deployer would need to recompile every program that used Webkit (even if they could figure out what those were) and redeploy them all. In fact, many applications either rely on bugs and quirks in the libraries they use, end up forking and packaging them separately for entirely unrelated reasons and so on. OpenOffice, for instance, used to pack its own libc for a long time, and -- more recently -- Google's own policy for Chrome is to fork things madly. And sometimes there's just no choice (e.g. when relying on a bug/quirk in a closed-source library). In all these cases, which are remarkably common, being shared doesn't help. This tends to be especially true for big-ass vendor packages, which pack every single library they can. You're still dependent on their goodwill for updates, just as you'd be if they had statically linked their stuff. Your package manager will gladly update libfoo from 1.9 to 1.9.1, which solves a million security bugs and one, and that will help exactly not at all, because there are probably two or three programs on your computer that pack libfoo 0.9 on their own. Ironically enough, this seems to be the direction in which (some of) the Linux desktop is moving, with containerized applications and so on.