A nice picture of (dependency) hell(disfunksioneel.blogspot.com)
disfunksioneel.blogspot.com
A nice picture of (dependency) hell
http://disfunksioneel.blogspot.com/2011/04/linux-software-dependencies.html
6 comments
Exactly. This is code reuse done properly, not "dependency hell".
The graph was partially motivated by the experience of compiling a few open source projects in windows. In Gentoo it's not "dependency hell".
Why didn't you call it something non-controversial like "A visualisation of open-source software dependencies" instead of "A nice picture of (dependency) hell", then?
[deleted](1)
It is a dependency hell, ready to fire at the moment one of the packages changes its interface (API, behaviour, file layout, ...) recursively breaking a fraction of its dependents. Then you end up with multiple versions of the same package, versioned libraries, private copies of libraries and tools, and so on.
Reuse works great on a small scale, but otherwise requires a lot of discipline both from the provider (who must refrain from interface changes, or have support for multiple versions from day one), and the consumer (who should be very considerate on which packages and features he uses).
Reuse works great on a small scale, but otherwise requires a lot of discipline both from the provider (who must refrain from interface changes, or have support for multiple versions from day one), and the consumer (who should be very considerate on which packages and features he uses).
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.
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.
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.
That's the reverse of the classic description.
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/
[2] http://upx.sourceforge.net/
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/
[2] http://upx.sourceforge.net/
What happens when someone finds a buffer overflow in that library? In Linux land only one file needs to be updated.
But the inverse is also true. New bugs are automatically distributed to every consumer of the library.
.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
[1] http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx
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.
You might want to try to do some automatic force-based layouting instead for the most dependent-on packages would be easier to see.
I am doing something like that. Look at the zoomed in graph, there you will see the more connected packages are further away from the rim.
Maybe I can give more connected packages a larger angle to occupy?
Maybe I can give more connected packages a larger angle to occupy?
Is there a single package at the center of this chart that requires every single other package to be installed (either directly or via sub-dependencies)? If not, what does the most complex version of that chart look like?
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...
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...
Having explicit dependences on shared libraries in packages was taken straight from playbook of some Department of Redundancy Department. For any dynamically linked ELF binnary, the loader (/lib/ld.so or similar) notifies which libraries are missing upon execution. It doesn't take much to locate relevant library packages... Resolution at runtime could be mostly automated; say a dialog asking ``Install 5 packages (15MB in total) now? [Yes] [No]''. Probably same goes for modules of Python, Perl etc.
I recall Vim being marked as requiring Perl, Python and a half dozen other heavyweights (in PLD distro) simply because it had some optional support for those. Attempting to recover half-upgraded, half-broken system over slow connnection really sucked.
I recall Vim being marked as requiring Perl, Python and a half dozen other heavyweights (in PLD distro) simply because it had some optional support for those. Attempting to recover half-upgraded, half-broken system over slow connnection really sucked.
It doesn't take much to locate relevant library packages... Resolution at runtime could be mostly automated; say a dialog asking ``Install 5 packages (15MB in total) now? [Yes] [No]''.
You're joking, right? When I set up a server, I want to set it up and be done with it.
You're joking, right? When I set up a server, I want to set it up and be done with it.
This could be interesting, but there is too much noise and not enough signal. All I can see is a large multicoloured circle. Why not try to process it a bit more so that this could teach us something?
I agree. The graph on the site is already processed a bit, but not enough.
Can you make any suggestions as to how I can make it better?
Can you make any suggestions as to how I can make it better?
Would it be better if there wasn't the reuse? Or if the system was less functional?