GoboLinux is popular for its filesystem hierarchy which breaks away from the traditional Unix Filesystem Hierarchy Standard (FHS). So basically you wouldn't find any /etc or /usr directries under Gobo. In turn, files of a particular program are stored in their own separate directories like /Programs/GCC/2.95.3/lib. This means Gobo's package management system has its advantages since users can now install multiple versions of the same program without conflicts.
To find out more about Gobo and why it does things the way it does, I talk to one of its main developers Lucas Villa Real.
Mayank Sharma: So why did you break away from the traditional FHS? Are there any particular advantages?
Lucas Villa Real: The major aim was to have a simple way of creating and sharing binary packages from programs compiled and installed from their source code. Splitting the filesystem tree into per-program subtrees was the most logical thinking, as packages could be created just by compressing its directory, or removed by deleting that. Another interesting advantage is that more than one version of the same program can be installed in the system at a given time, as each version lives inside its own directory. And this gives us a very unique feature: no database is needed to tell which packages are installed and what files each of them offer; that's just a matter of checking the directory contents inside /Programs.
MS: How do you maintain UNIX compatibility in the background? Doesn't this effect the speed of complex programs like OpenOffice.org?
LVR: 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.
MS: I've read Gobo's filesystem makes installing applications easier. But wouldn't this require application developers to package their apps to conform with Gobo's filesystem?
LVR: Many application developers are already doing that by using autoconf, automake or just by writing well behaved Makefiles. In fact GoboLinux doesn't require anything special from application developers other than the usual care that they should already take regarding portability in their projects.
MS: How does Gobo's "design" let users install multiple versions of the same app? How about uninstallation?
LVR: Every installed program gets its own directory, such as /Programs/GCC/4.2.1. That avoids conflicts with files coming from different versions, as they'll be stored in a different location (eg: /Programs/GCC/4.1.1). For uninstallation, it's just as simple as removing the desired program or version from the /Programs tree. The broken symlinks that'll be left over can be either treated automatically by a daemon such as the GoboLinux Listener or manually by a script shipped with the distribution.
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.
MS: Apart from the filesystem what are the other features that make Gobo unique? What's a rootless Gobo install?
LVR: 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).
Answering the first question, we have, as principle, to try to ship every package as close as possible to the original one, avoiding patches that modify their behavior. This contrasts with many distributions out there, which usually try to merge as many patches as possible to enhance applications (and sometimes breaking them).
Also, the alternative design of Gobo tends to attract a very diverse group of people who like to "think outside the box", such as users of alternative shells and lesser-known programming languages. They usually contribute with many good ideas when we're brainstorming for new features.
MS: What does the immediate future hold for Gobo? Any areas where you could use some help?
LVR: We're doing a series of snapshot releases in the process of stabilizing 014. The best help we can use now is to get people to download those snapshots, give them a try and report any problems they find at http://bugs.gobolinux.org. We're also always open for new contributors to help maintain the "recipes tree" for the Compile tool.
MS: Where do you see Gobo in a couple of years?
LVR: In a couple of years, I expect Gobo to be fully grown from being a small niche distro into a larger community. The main technical foundations have been laid and we already have a small but vibrant community of users. We still have some more work on infrastructure ahead of us but from now on I think the prospects are the best possible.
MS: Thanks for you time Lucas, and best of luck developing Gobo.
You might also be interested in reading: