Something I see a lot when I go to write software using linux-centric libraries is that they always use shared libraries almost exclusively. This is especially the case when the library is licensed under the LGPL or other licenses that restrict static linking. DLL hell with windows applications is NOT OKAY! It's totally understandable that it actually happens, but it's not ideal at all, and I find it absolutely infuriating for a short list of reasons:

• It pollutes the application root directory on windows because "package management" isn't really a thing
• It discourages attempting to maintain binary compatibility on linux because "anything that's dynamically linked we can recompile anyway"
• Don't get me started with libraries that are cross-compiled from linux to windows, can't normally be built from windows, and somehow fail to distribute compatible architectures of dynamic library (Yes, this actually happens)

I'm not against shared objects; I think they have a lot of great properties. Being able to update a library on its own or use shared objects to implement plugins is great. But there's something really shitty about the current ecosystem with shared libraries on windows, and most linux distributions.

Windows is notorious for having crazy long-term binary compatibility, because OS-side shared library APIs don't (usually) change, or at the very least, applications don't crash because some functionality they used was removed or the ABI changed.

I haven't used a single linux distribution where binary compatibility was maintained for a significant period of time, and applications which wanted binary compatibility had to target "the OS itself". That's "sort of" changing with Steam Runtime as far as games go (good luck getting 99% of games to target anything else), but that doesn't help other applications or ones which need functionality that's not included in any of the Steam Runtime libraries.

I got so mad at the DLL Soup that my GTK application has that I now run it through a launcher application that monkeypatches PATH so that it will load the GTK DLLs from a bin directory inside the application's root directory. Out of sight, out of mind. A better OS would try to do this automatically, or go further and track versioned libraries instead of one per name (Debian tries to do something like this, right? But it doesn't go far enough...).

This is a shortcoming with modern OSs for sure, and it's something that they'll need to address sooner or later. Microsoft has tried really hard to keep DirectX helper libraries as compatible as possible (that's why you have 400 versions installed right now, if you game on windows at all). At the very least, people shouldn't be looking at how shared libraries are handled across most OSs right now as any kind of good thing, and always strive to do better.