A nice picture of (dependency) hell | Hacker News Reader

A nice picture of (dependency) hell

disfunksioneel.blogspot.com

16 pointsESCdc23 comments

I'm not sure what the problem is here. Looks like there's a large, very functional, set of systems that have a lot of reuse.

Would it be better if there wasn't the reuse? Or if the system was less functional?

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?

The obvious answer is that the former would not generate nearly so much interest/clicks/attention.

Sensationalism? If you would like a post with a less controversial name, have a look at "High resolution dependency graph".

Sorry if you felt cheated by the title :)

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).

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.

That's the reverse of the classic description.

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.

.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

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.

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/

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.

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?

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...

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.

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.

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?

Reply on news.ycombinator.com