21–25 of 25 posts
When dependencies are shown on the rim of the circle, most of the area is used by the circle. You might want to try to do some automatic force-based layouting instead for the most dependent-on packages would be easier to see.
Maybe I can give more connected packages a larger angle to occupy?
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.
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.
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.
What happens when someone finds a buffer overflow in that library? In Linux land only one file needs to be updated.
My assumption is that this is multiple dependency networks being displayed but that the networks are not all interdependent - eg: dev/ruby does not require dev/perl or vice versa.
It's an interesting exercise, but it needs justification to define it as representing "dependency hell" and not just a visualization of a complex system.
Also, to be read in a Crocodile Dundee voice, that's not a dependency, this is a dependency: http://thedailywtf.com/Articles/Enterprise-Dependency-The-Ne...
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.
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.
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.