> DLL Hell was well understood in the mid-90s. Also, there are some additional facets of DLL Hell which happened in the Windows of the mid-90s which are not as

> DLL Hell was well understood in the mid-90s. Also, there are some additional facets of DLL Hell which happened in the Windows of the mid-90s which are not as relevant to Linux. What made DLL Hell so bad there was that installing any random program could replace globally shared libraries, sometimes even with an older version. That is, installing a game could make an unrelated productivity app stop working, because the game helpfully installed newer (or older!) versions of the shared libraries it needed, into the same globally shared directory in which nearly all DLLs lived. It got so bad (even DLLs which came with the operating system were being overwritten) that Microsoft IIRC initially introduced a system which detected when this happened, and replaced the DLLs again with a clean copy it had stashed somewhere else (and later, made these files more directly protected). That's before considering the disaster that is in-process COM servers; presenting a standard "open file" dialog, or doing some printing, is enough to make Windows load arbitrary DLLs into your process (shell extensions and/or printer drivers), and these often don't have the highest code quality. And then there are some things which inject arbitrary DLLs into every process... Compared to that, the dynamic linking issues in the Linux world are much more bearable. You don't see arbitrary programs overwriting the global copy of something like libgtk or openssl or zlib or libc, the only arbitrary dynamic libraries being loaded into a process are things like the NSS ones (usually from a small well behaved set) or plugins from the graphics libraries (also usually from a small well behaved set), and the only dynamic library being injected into every process is the vDSO from the kernel.