3 ms·

Meanwhile, over in Windows land, I'm trying to remember when I last encountered DLL hell. It's a long time ago now. People simply stopped trying to install DLLs

Meanwhile, over in Windows land, I'm trying to remember when I last encountered DLL hell. It's a long time ago now. People simply stopped trying to install DLLs in the system directories and just ship all their dependencies. With the amount of RAM available now, it doesn't matter if you load 100 different versions of a shared library, you're not gonna notice the difference anyway.

udp 15y ago
In my opinion, that's the very definition of dependency hell - when the system is so badly designed, software is forced to bundle everything and never share it.
- brown9-2 15y ago
  That's the reverse of the classic description.
- bunderbunder 15y ago
  On the contrary, bundling in your dependencies is the very definition of good, user-centric design. Disk space has now become so cheap that there's really no tenable excuse for shipping your software with "some assembly required" and "batteries not included" labels. Which is why pretty much every major platform has quit doing it. The lone holdouts are linux distributions. And even they betray their implicit agreement that it's bad design when they resort to employing ungainly feats of contortionism known as "package management systems" in an effort to duct tape over the problem.
d_r 15y ago
.NET actually made a pretty good effort in addressing this with strong names and assembly signing. Unfortunately, .NET is probably not all that common for mainstream consumer apps (I may be wrong here, please correct me if so.) [1] http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx
el_presidente 15y ago
What happens when someone finds a buffer overflow in that library? In Linux land only one file needs to be updated.
- MatthewPhillips 15y ago
  But the inverse is also true. New bugs are automatically distributed to every consumer of the library.
vog 15y ago
In that case, you can link as well everything statically. That's what one of my open source projects is about. [1] Linking everything statically works usually quite well, except if you use libraries that make some assumptions about being dynamically linked (e.g. GTK+). The benefit is that you have one big EXE file for which you don't even need an installer. Also, it is usually smaller than the previous bunch of DLLs because static linking omits code that won't be called anyway. You can even run an EXE packer [2] on your result, making it even small and easier to deploy. The total memory usage, however, stays the same, of course. The downside is that you need a good build system for that. [1] http://mingw-cross-env.nongnu.org/ http://mingw-cross-env.nongnu.org/ [2] http://upx.sourceforge.net/ http://upx.sourceforge.net/

udp 15y ago

In my opinion, that's the very definition of dependency hell - when the system is so badly designed, software is forced to bundle everything and never share it.

brown9-2 15y ago
That's the reverse of the classic description.
bunderbunder 15y ago
On the contrary, bundling in your dependencies is the very definition of good, user-centric design. Disk space has now become so cheap that there's really no tenable excuse for shipping your software with "some assembly required" and "batteries not included" labels. Which is why pretty much every major platform has quit doing it. The lone holdouts are linux distributions. And even they betray their implicit agreement that it's bad design when they resort to employing ungainly feats of contortionism known as "package management systems" in an effort to duct tape over the problem.

d_r 15y ago

.NET actually made a pretty good effort in addressing this with strong names and assembly signing. Unfortunately, .NET is probably not all that common for mainstream consumer apps (I may be wrong here, please correct me if so.) [1] http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx

el_presidente 15y ago

What happens when someone finds a buffer overflow in that library? In Linux land only one file needs to be updated.

MatthewPhillips 15y ago
But the inverse is also true. New bugs are automatically distributed to every consumer of the library.

vog 15y ago

In that case, you can link as well everything statically. That's what one of my open source projects is about. [1] Linking everything statically works usually quite well, except if you use libraries that make some assumptions about being dynamically linked (e.g. GTK+). The benefit is that you have one big EXE file for which you don't even need an installer. Also, it is usually smaller than the previous bunch of DLLs because static linking omits code that won't be called anyway. You can even run an EXE packer [2] on your result, making it even small and easier to deploy. The total memory usage, however, stays the same, of course. The downside is that you need a good build system for that. [1] http://mingw-cross-env.nongnu.org/ http://mingw-cross-env.nongnu.org/ [2] http://upx.sourceforge.net/ http://upx.sourceforge.net/