GoboLinux, a distribution which redefines the entire filesystem hierarchy.

[Pedro]

-{ Quote: "GoboLinux is an alternative Linux distribution which redefines the entire filesystem hierarchy.
In GoboLinux you don't need a package manager because the filesystem is the package manager: each program resides in its own directory, such as /Programs/Xorg/7.2/ and /Programs/KDE-Libs/3.5.8." }-
http://www.gobolinux.org/

Learn more... (http://www.gobolinux.org/?page=at_a_glance)

NetBSD interviews GoboLinux developer on Package Management and Build System (http://www.netbsd.org/gallery/pkgsrc-interviews.html#gobo-linux)

I mentioned to Mrkvonic in another thread, kind of kidding, but the thing is, i'm finding it most interesting.
It could to take a bit of my attention from Debian. I still love Debian, i've messed with it doing a few horrible things (do NOT mix stable with testing! ;D ) and it still ticks. I'll be a fan for a long time.

But this whole new approach makes sense to this noob - me.
Am i missing something? Alphalutra, Mrk, Iceni, GlobalForce, nickr, wilbertnl, all you guys i forgot to name! :P

Announcing the 014.01-beta1 (its my birthday!!) LiveCD (http://lists.gobolinux.org/pipermail/gobolinux-users/2008-March/007388.html)

I hope you see the thread..

[Pedro]

Scrolling down the NetBSD interviews, one reads about "The Zero Install system", wow, maybe i should scroll up too. Lots of ideas boiling!

[Franklin]

Worked ok off the live cd so I tried to install into a 20 gig drive twice and after reboot it comes up looking for a mac address.:thumbd:

[Mrkvonic]

Hello,

I'll have to check it out of course.

As to redefining the fs hierarchy, I actually like it the way it is. The hierarchy has been developed for approx. 30 years. That's not something that will change in a manner of hours...

And since the compatibility backwards to Linux is retained, seems to me there's be a whole lot of symbolic links all over the place...

Mrk

[NGRhodes]

Seems a bit odd, in that they have a nice neat structure, but then need loads of links to make it all work, cant understand how that is better/easier than using a package manager.

Would be interesting to see how I would actually check for upgrades of the distro, do their tools have to scan every folder (and build a list of current files) then check against server (why is this better than using a traditional package manager ?) dependency handling, if I upgrade GTK, how does the system get the apps that depend on it to use.

And then all those links, gonna have to have some robust scripts to manage them and prevent the system blowing up (I've seen a red hat server stuck in sym link hell before).

Will be worth having a play with the livecd at some point though.

[Pedro]

Mrk, i understand what you're saying, and apparently so does the developer.
It doesn't seem that it will have symlinks scattered, it looks organized. I mean, a symlink will be in the /System/Links tree, pointing to the legacy tree. It can't be that bad ;D
-{ Quote: "MS: So why haven't other distros taken to Gobo's filesystem? Is it difficult to implement from the distro developer's point of view?

LVR: It's difficult, because they would have to make many important changes to their package management scripts and to many existing distro-specific applications, such as boot scripts configuration, for example." }-
http://www.packtpub.com/article/GoboLinux-An-Interview-with-Lucas-Villa

There are other questions that arise for me, like consequences for security, since it is another structure. He refers to a rootless install for instance:
-{ Quote: " A Rootless GoboLinux is a set of scripts that makes it possible for anyone running an UNIX-like operating system to run GoboLinux tools inside their own home directory. That makes it possible for users in eg: Mac OS X to run Compile and get the program installed in a GoboLinux-like structure. And that doesn't require special admin privileges, as everything is installed inside the directory specified by the user (usually their home dir, or another where he/she has write access to)." }-

-{ Quote: "Seems a bit odd, in that they have a nice neat structure, but then need loads of links to make it all work, cant understand how that is better/easier than using a package manager.

Would be interesting to see how I would actually check for upgrades of the distro, do their tools have to scan every folder (and build a list of current files) then check against server (why is this better than using a traditional package manager ?) dependency handling, if I upgrade GTK, how does the system get the apps that depend on it to use.

And then all those links, gonna have to have some robust scripts to manage them and prevent the system blowing up (I've seen a red hat server stuck in sym link hell before)." }-
Do note that it's not to make it work, but to be compatible with the "legacy tree". Or so i think.
-{ Quote: "Every time a new application is installed in GoboLinux, its contents are linked inside a global /System/Links tree. This tree presents subdirs such as Executables, Libraries, Headers and Shared, among others. So, having a centralized point where programs' contents can be reached makes it possible to achieve UNIX compatibility by presenting symlinks that point the desired legacy entry to the /System/Links corresponding one. And this comes with a great advantage: by having entries such as /bin, /sbin, /usr/bin and /usr/sbin pointing to /System/Links/Executables, the applications will always find what they're looking for—given that the file exists.

This extra level of indirection introduced by the symlinks require one more step when opening or getting information on files, but that's a really cheap and fast procedure, especially when compared to the entire file manipulation operations. And anyways that already happens in traditional systems when an application tries to open a shared library, which is usually presented as a symlink to the real shared object.

It's interesting to note that although we have those compatibility symlinks they're all hidden from the end user by default, thanks to a kernel extension written by us." }-
I thought this was useful info too:
-{ Quote: "Which are the unique features and advantages of the GoboLinux package management system?

With all this modularity, we don't need to keep in sync with a database to remind the user about which programs and versions are installed. All installed and compiled packages can be listed with ls /Programs, their versions with ls /Programs/Foo, and their contents with find /Programs/Foo/Version.

Dependency handling is also kept simple: a text file describes which programs and libraries a package depends on, and the check for these requirements is again made by looking at the /Programs hierarchy.

Being so clear and simple by design makes it a very powerful scheme to manage systems of different scales, as it's always possible to rollback the system to a previous state after a bad software upgrade and to have a consistent view of the system with no aid of special tools.

The /System/Links has an important rule, too. Since all legacy links point to their related categories inside that directory (ie: /bin, /sbin, /usr/bin and so on all point to /System/Links/Executables, /lib, /usr/lib point to /System/Links/Libraries), system indices can be centralized: $PATH is set to /System/Links/Executables, and ld.so.conf contains a single /System/Links/Libraries entry.

And with this, Gobo can be even more compatible than some more standard-looking distributions, as all standard paths work for all files, while other distros may struggle with incompatibilities such as scripts breaking with they refer to /usr/bin/foo when the file is actually in /usr/local/bin/foo.

Another property of the link-based indexing is that any references to non-existing files automatically become broken links, and therefore inactive. This makes it easy to spot and fix problems and, most importantly, ensures that the the index is always in sync with the actual functional state of the system. No more problems of having the package manager complain that libXYZ is not installed even though you can see that it *is* there." }-


-{ Quote: "
Will be worth having a play with the livecd at some point though." }-
I agree :)