Interestingly both started roughly around the same time (though i only started hearing about Nix in the last few years).

Note though that Gobolinux is largely constructed from shell scripts.

Also, since this comparison was made Gobolinux replace /System/Links with /system/Index. The latter is more like the classic FHS, and came about because of various issues during software compiles (iirc).

Oh, one potentially interesting tidbit about Gobolinux history is that it apparently started out as one guy's way to manage compiles stored in his user directory on a university server. Sadly since the move to /System/Index the tool for bootstrapping such an environment, Rootless, has been nonfunctional.

I did not know about Gobo either. Why isn't everyone using it yet? Directories as packages, multi-versioning made easy... Use it now!

The "how can this possibly work" section shows the problem: System libraries are links to app directories. Basically, you end up bundling the same libs over and over again in your applications. Just imagine having several identical copies of gtk, qt, webkit, etc.

Not quite. As long as multiple programs use the same lib version, you only install it once just as with RPM or DEB.

but if another program needs a older or newer version you can install that version in parallel without it disturbing the rest.

If you can't distribute individual directories/packages as stand-alone apps this entire exercise seems pointless, it just becomes a fancy filesystem hierarchy.

Wait, neither debian nor ubuntu distribute packages as stand alone app. They distribute it without their libs and add a layer of dependency management (I did not look into Gobo's but I guess it is similar though apparently more permissive)

And I don't see either what prevents one to distribute an application as standalone by stuffing all the libs needed in the application directory.

That's my point, you don't gain anything except a different directory structure. And if you stuff everything into one directory, size.

Ah ok, now i get it. You are stuck thinking devops and containers...

Dunno. Maybe because it is largely made out of shell scripts and symlinks, and not laden with buzzwords?

Maybe because it's not ambitious enough?

Nix (and NixOS) does most of the same things, and then some, achieving more of the potential benefits. If you're going to break compatibility anyway, you might as well do it in a big way.

A 2x improvement isn't enough to be worth the cost. 10x might be.

They don't break the compatibility. The old hierarchy is still there.

I think one of the problems is that is a source-based distribution, which is a pretty niche thing nowadays.

I am more wondering about the filesystem organization than the distribution itself.