What you think about Gobolinux's FS layout?

Question

GoboLinux is a modular Linux distribution: it organizes the programs in your system in a new, logical way. Instead of having parts of a program thrown at /usr/bin, other parts at /etc and yet more parts thrown at /usr/share/something/or/another, each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way.
http://www.gobolinux.org/
They also seem to have a clear direction, or philosophy, like Arch does:
http://gobo.kundor.org/wiki/The_GoboLinux_way
Gobolinux's FS layout have some advantages, like:
* Easy package management, no need to handle and track multiple files scatered in the system
* Easy coexistence of multiple versions of the same package
* Easy to rollback, just change symlinks
* Easy for third-party application distribution, just make a bundle with all it needs
In fact, this layout is much close to what OS X does. There's an obvious con, and is the fact that some packages might duplicate files, thus increasing disk usage. On the other hand, it would be a much more friendly Linux system for shipping applications, as it's easier to ship a bundle that installs itself correctly with all it needs. I think the current UNIX historical FS layout is holding back a lot of inovation Linux could have on the desktop for making easier for developers target and ship binaries for the plataform.
No more various distro teams duplicating effort to put source tarballs together. You see we have a lot of distros, but they are actually doing small variations and incrementations of the same thing: building and packaging stuff from source, and taking care for one not break the other. The result is, if the package doesn't come from your distro, you're on high risk of breaking your system. This holds back 3rd parties from targeting the plataform, as they can't control the package building and distribution themselves.
As I said, OS X already does a similar package concept to that, and see how much good aplications they're bringing from both big companies and independent developers. And, despite the core being an open kernel and GNU userland, all the relevant stack (core libraries, UI) is closed source! I'm asking myself, why Linux, for free and with a ton of open-source core and libraries, without any vendor lock-in, is NOT kicking ass in this aspect? The only fault I see in Linux is a lack of cohesive package distrbution. Gobolinux approach seems a step to fix this.
So... I want your opinions, not much about Gobolinux itself, but about their approach. Maybe would we ever see an Arch spin-off using this approach, or another approach with similar results - effectively, package compartmentation in the FS layout level? Using this layout could alleviate a bit the burden of forced upgrade that a rolling release brings.
And for those who didn't know Gobolinux, give it a try.
I hope this post can give a glimpse of new ideas and solutions for some of the incredible talented people here. I think the Linux landspace is too immersed in inertia and old traditions that don't cope with today needs, Arch was a refreshing oasis of innovation I found in that landscape.
Last edited by freakcode (2008-09-30 22:39:47)

Answer 1

jcasper wrote:
freakcode wrote:But this is scheme is less applicable for executables, and more for dynamic libraries, as binaries link to names like "lib-1.0.so.0.9.1", so those can be distinct symlinked.
Wouldn't you then need to link all your executables to specifically numbered library .so's?  Most executables, by default, are linked to /usr/lib/libfoo.so.1 where libfoo.so.1 is a symlink to libfoo.so.1.5.2 or whatever (where most libfoo.so.1.* are more or less backward compatible, so most executables linked to libfoo.so.1 will be just fine with the upgrade).   I don't see how this would work if package A needs libfoo 1.4.3 and package B needs libfoo 1.5.2 but both are linked to libfoo.so.1.   So you would need executable X linked to libfoo.so.1.4.3 and executable Y linked to libfoo.so.1.5.2.  And then when you upgrade the library, you need to re-link every package that links to it to take advantage of the new lib (throwing away the whole point of linking to libfoo.so.1 by default).
Yes, my example wasn't clear. Executables X and Y are linked against lib-A.so, which in turn is a symlink to a minor version like lib-A.so.aa. When this lib gets updated, and breaks compatiblity, the maintainers bump the major version number so it turns into lib-B.so. Executable X can be readily updated to work with the new lib-so.B, while executable Y can still work because both lib-A.so and lib-B.so can coexist in the system. In this case, I don't need to wait both X and Y being updated to the new library to install one of them. Minor versions (lib-A.so.aa, lib-A.so.ab, ...) don't affect most builds, as they normally link to a major release (lib-A.so, that is a symlink to the most recent minor version) that guarantee to maintain compatiblity.
For instance, this happened with libstdc++ too, but is an exception because both branches (5 & 6) coexisted for some time.
But don't take my word on it, see how Gobolinux actually manages that http://www.gobolinux.org/index.php?page=k5 (What is it all about?)
jcasper wrote:So I must be missing something, as I don't see how this new directory layout would improve the modularity of the distro packages.  The cleanliness of the filesystem is arguable improved, but I agree with earlier posts that a good package manager like we have in Arch is just as effective.  In Arch I can instantly see what package a file belongs to, see every file installed by a package, and easily add and remove packages.   So in terms of stuff I can do easily, what do separate directories for each get me?
(Just to make it clear, I'm not directly comparing with what is existent in Arch, neither saying that what we have today doesn't work, which also happens to be the case with all the other 300 distros. The fact one thing works, doesn't mean it is the only neither the best possible solution. From there comes the interest to discuss Gobolinux's approach)
The point is, if the layout is clean and sandboxed, you don't need a package manager. A package manager is an abstraction to a database relating what files belongs to what packages, that tries to ultimately solve a fundamental flaw of using the traditional Unix hierarchy, where files from one package are scattered on the filesystem, and then you have no simple means to track them anymore. That's hardly KISS. In Gobolinux's approach, you can track files to their packages by simply inspecting symlinks.
/System/Links/Libraries] ls -l | cut -b 49-
libgtk-1.2.so.0 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
libgtk-1.2.so.0.9.1 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
libgtk.a -> /Programs/GTK+/1.2.10/lib/libgtk.a
libgtk.la -> /Programs/GTK+/1.2.10/lib/libgtk.la
libgtk.so -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
libgtk-x11-2.0.la -> /Programs/GTK+/2.6.7/lib/libgtk-x11-2.0.la
libgtk-x11-2.0.so -> /Programs/GTK+/2.6.7/lib/libgtk-x11-2.0.so.0.600.7
libgtk-x11-2.0.so.0 -> /Programs/GTK+/2.6.7/lib/libgtk-x11-2.0.so.0.600.7
On a side note now, having /bin and /usr/bin, /usr and /usr/local,... all that made sense once, with a different hardware, with a different purpose. Does it make sense today, on a modern desktop system? There's enough room and flexibility to rethink and improve those ideas further *without* actually breaking compatiblity, as Gobolinux and OS X already achieved. The only reason most Linux systems until today stick to old standards is because Linux systems were originally intended as cheap Unix replacements. Funny enough is that OS X, which doesn't follow the Unix hierarchy standard so close, is regarded as fully Unix compatible and marketed using the Unix trademark - whereas Linux isn't.
Last edited by freakcode (2008-10-01 20:16:09)