GoboLinux

By Rebecca Sobol
January 9, 2008

GoboLinux is an alternative distribution that redefines the entire filesystem hierarchy. The distribution joined the LWN Distributions List in late October 2003 at version 007. Now at version 014, the project has made quite a bit of headway. The website has been translated into several major languages, along with much of the documentation.

An early article written by GoboLinux creator Hisham Muhammad explains how the distribution evolved from a custom Linux From Scratch installation, and the motivation for changing the directory structure.

The whole thing started when I had to install programs at the University. As I had no write access to the standard Unix directories, I created my own directories under $HOME the way I saw fit. I upgraded the programs from source constantly, and couldn't use a package manager. My solution was the most obvious one: to place each program in its own directory, such as ~/Programs/AfterStep. Soon the environment variables (PATH, LD_LIBRARY_PATH...) got bigger and bigger, so I created centralized directories for each class of files, containing symbolic links: ~/Libraries, ~/Headers and so on. A natural evolution was to write shell scripts to handle the links, configures and Makefiles.

I downloaded the 014 release and stuck the CD into my ancient Sony Vaio laptop. After booting I was first prompted for my preferred language and keyboard settings and then taken to a console screen with text advising me to "run startx to run the live CD or you can install from here." I ran startx and soon was looking at a familiar KDE desktop. This release features KDE 3.5.8, Glibc 2.5 and Xorg 7.2. From here you'll find a desktop icon for GParted and another to install GoboLinux, so you can easily create a separate partition for GoboLinux before an installation.

I ran it as live CD and brought up a Konsole so I poke about the filesystem hierarchy. The home directory looks much like any other Linux system, but a cd /, followed by ls -al reveals something else entirely. There are only six subdirectories here: Depot, Files, Mount, Programs, System, and Users. Depot proved to be empty, but the other directories have their own subdirectories, which branch further as necessary. For example, I found everything need to compile the linux kernel for a variety of architectures under /Files/Compile/Sources/linux-2.6.23.8/ (the version used by this release). To see all the installed programs just look at /Programs where each package has it's own subdirectory. Different versions of the packages can also be easily installed without conflict, since the directory structure includes the version number, e.g. /Programs/Xorg/7.2/.

The home directory for users is under /Users instead of /home, but it works just the same. As a long time Unix/Linux user I'm used to the old hierarchy, with cryptic names like /etc and /bin. I thought I might have a hard time getting used to GoboLinux. Instead, I found it intuitive and easy to work with. Next time you are looking for something different in a desktop, give GoboLinux a try.

Good ideas, but too far from the mainstream

Posted Jan 10, 2008 11:33 UTC (Thu) by epa (subscriber, #39769) [Link] (3 responses)

Clearly this is a better way to organize the filesystem. Dumping all executables into /bin or
/usr/bin made some sense when V7 Unix or earlier was a small system with a hundred or so
programs. It started to look silly soon afterwards and with today's Linux distributions it's
an absurd way to organize thousands of packages. /usr/include is a little better but still
has lots of .h files splattered at the top level.

We all mock those computer-illiterate Windows users who don't understand the idea of
directories and save every file to the desktop, but our own filesystems are not much better.
Windows's stupid 'My Documents', 'My Computer' and so on make an uncomfortable second
filesystem hierarchy which tries to provide a sensible view of files that are scattered in
bizarre places on the real filesystem. Yet our rpm databases are much the same kind of mess,
putting files all over the place and then needing to track separately which ones belong to
which packages.

The way things currently are, the shell expects all executables to be in PATH and many
programs look for files at fixed locations. Fortunately we have symbolic links.

I think GoboLinux would have more impact on the Linux world if it were written as a variant of
Fedora or Debian where the package manager (rpm or dpkg) is modified to install standard,
vanilla packages into a more organized directory structure and then make symlinks for
compatibility. Then, who knows, one day one of the major distributions might pick up their
work.

Good ideas, but too far from the mainstream

Posted Jan 10, 2008 23:09 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (2 responses)

Now please explain to me what is the advantage of such splitting of the name-space of
executables. Tab-completion does make things manageable.

If that idea were so useful, it would have been implemented in some other distributions,
wouldn't it?

Good ideas, but too far from the mainstream

Posted Jan 13, 2008 1:16 UTC (Sun) by liljencrantz (guest, #28458) [Link] (1 responses)

My old university had something a bit like this. It allowed them to have truly massive amounts
of software installed, and dozens of versions of some packages. Each user could then freely
pick and choose which versions of which packages (or modules, as they called them) to use, or
they could simply use the latest recommended version. It was extremly useful in an environemnt
with tens of thousands of users running software on something like half a dozen different
hardware platforms and half a dozen different operating systems.

I don't really know how useful this would be on a simple desktop system.

Good ideas, but too far from the mainstream

Posted Jan 13, 2008 18:36 UTC (Sun) by nix (subscriber, #2304) [Link]

I wrote a system at an old workplace which worked something like this. At 
login it traversed a dependency tree, built a pair of directories full of 
symlinks to binaries and shared libraries under /tmp, and pointed PATH and 
LD_LIBRARY_PATH through it. (It used shell traps to remove the 
directories, although if I'd had root privs I would probably have used PAM 
instead.)

(You could ask for specific binaries or all binaries from specific 
packages, but almost nobody but me ever did that. Most people just turned 
everything off and on when necessary, *sigh*)

GoboLinux

Posted Jan 10, 2008 17:41 UTC (Thu) by dany (guest, #18902) [Link] (3 responses)

I liked Gobo idea when this project started and still like it today. Its funny, that something
similar is doing Apple. Its MacOSX root filesystem contains dirs like 
/Applications, /Users, /System, /Network, /Library
and applications are actually dirs, containing everything, that app needs to run. Examples:
/Applications/iChat.app/, /Applications/Thunderbird.app/

GoboLinux

Posted Jan 10, 2008 20:03 UTC (Thu) by pphaneuf (guest, #23480) [Link] (2 responses)

That's what it reminded me too, but Mac OS X also has the regular directories (they are hidden in the Finder, but you can see them in a shell).

Applications on Mac OS X also also easier to install without needing a package manager (just drag and drop in the /Applications directory), in most of the cases anyway (drivers and things that are plugins to other software use installers, for example). So the fact that they don't have a good package manager isn't nearly as bad as some people make it to be, since the pain level is reduced (drivers and plugins are a pain, though, but they're not the common case).

Mac OS X also has a different way of starting applications (which the Finder uses), where a directory with a special extension is considered an application (it might have to have certain files inside of it, as well). Many Linux users still start applications through the command line rather than from the menus or file browser, even for GUI applications.

Because of this, the Mac OS X way is much weaker for command line programs (that's more or less why /usr/bin and friends still exist). But that's okay, since their target market does not really care about that.

GoboLinux

Posted Jan 15, 2008 17:39 UTC (Tue) by tjc (guest, #137) [Link] (1 responses)

So the fact that they don't have a good package manager isn't nearly as bad as some people make it to be [snip]

Yes it is. If you accidently delete an application in OS X, you have to reinstall the entire operating system to get it back. Or alternatively, download a shareware utility to extract and reinstall the individual application.

There's really no excuse for this. Apple needs to take some of the developers it has working on trivial things like eye candy and get them working on a half-way decent package manager. What they have now is worse than Slackware.

GoboLinux

Posted Jan 15, 2008 18:46 UTC (Tue) by pphaneuf (guest, #23480) [Link]

If you accidentally delete a normal application in OS X, you have to reinstall just that application. The definition of "normal" here is whether it came in a package or just as the application in a disk image. If it's a package, it's not normal.

Of course, it makes it kind of annoying that most of the applications that come with OS X itself (the iWork trial, Safari, iSync, etc) come from packages. In the case of those "abnormal" applications, true, you have to reinstall the package, which in their case, is the operating system itself (gah!).

The curious thing of note here is that the package manager hurts instead of helping. The applications that don't use the package manager are simple to deal with and don't pose the problem you mention! To follow through on that thinking path, one could simply get rid of the package manager entirely, rather than getting a "better" one.

What I would like is if the applications that came bundled with OS X were simply in a "Bundled Applications" directory on the installation media, where the installer could simply copy them the plain old way, and if you deleted one of them, you'd simply plop back the DVD and drag-and-drop it back into place, done and done.

Where OS X applications really drop the ball compared to sophisticated Linux package managers (by which I mean apt), is with updates. That is also the reason why the bundled applications are from a package (which you can reinstall separately, without reinstalling the entire operating system, I should point out) rather than the way I described.

What I'd really like is for people to think outside the box a little bit. For example, OS X applications being self-contained is a pretty interesting property, making installation and removal trivial (deleting an application is done by, well, deleting the application, that's quite straightforward!). Note that applications can register themselves for certain things, like being able to open certain types of files.

Now, picture that they can register where they came from (their "repository", in a certain way). The Software Update application could then handle updates for all applications that registered a repository, transparently, without introducing a "real package manager" (or, at the very least, the explicit steps of installing or removing a "package"). You'd still have a direct manipulation of the application for installing/removing, and you'd have automated updating.

I don't know about you, but I've never heard or seen such a thing, I think that'd be what some people would call innovation, possibly! Wouldn't it be nice that we came up with it first, instead of Apple?

GoboLinux

Posted Jan 10, 2008 20:57 UTC (Thu) by cdmiller (guest, #2813) [Link] (9 responses)

The base idea is not unlike a common old time practice for organizing software under
/usr/local.  One installs the software in it's own directory under /usr/local/,
/usr/local/apache for example.  Then one creates symbolic links to the executables and needed
libraries, /usr/local/bin/httpd -> /usr/local/apache/bin/httpd.

GoboLinux

Posted Jan 11, 2008 3:09 UTC (Fri) by madscientist (subscriber, #16861) [Link] (5 responses)

There's even software to manage this for you.  See http://www.gnu.org/software/stow/ for
example.

GoboLinux

Posted Jan 12, 2008 1:16 UTC (Sat) by nix (subscriber, #2304) [Link] (2 responses)

I have a substantial pile of patches for this (speedups, optionally 
trading speed against unstow accuracy, that sort of thing) and it seems to 
be unmaintained. I'll probably put them up somewhere soon.

GNU Stow

Posted Jan 12, 2008 17:00 UTC (Sat) by madscientist (subscriber, #16861) [Link] (1 responses)

Have you tried contacting the FSF?  If no one is maintaining it they're probably looking for
volunteers...

GNU Stow

Posted Jan 13, 2008 18:28 UTC (Sun) by nix (subscriber, #2304) [Link]

I may well do that, but I have to switch jobs first, to one whose lawyers 
don't just *sit* on the FSF's legal paperwork and then deny they ever 
received it when contacted.

Bah.

epkg

Posted Jan 14, 2008 1:24 UTC (Mon) by patha (subscriber, #6986) [Link] (1 responses)

I tested GNU Stow many years ago, but found epkg (http://encap.org/epkg/) to be better. I
still find epkg to be an indispensable tool for "local" software.

epkg

Posted Jan 14, 2008 20:32 UTC (Mon) by nix (subscriber, #2304) [Link]

It seems good at first, but it's a classic example of bundling too much 
into one package. Many of its features would better be placed in a build 
system wrapped around encap; e.g. downloading and running autoconf have 
*no* place in a symlink-creator. Transaction logging is also completely 
out of place there.

I have something better (the only feature it's missing is the 
autodownloading and it has *many* features above and beyond encap) and (to 
quote corbet) as soon as I've cleaned it up I'll be releasing it. :)

(However, there'll be a public git repo in a matter of weeks, not years!)

GoboLinux

Posted Jan 12, 2008 11:49 UTC (Sat) by dh (subscriber, #153) [Link] (2 responses)

Hi,

I remember that I did software management like this back in 1995 when I 
was student administrator at the university's computer science institute. 
My colleague Thomas Esser (the guy who did teTeX) even wrote a perl 
script "lntool" which did the links from /usr/local/{bin,lib,etc,...} into 
the specific subdirectories.

I do this even today for software I install additionally to the 
distribution's packages. As this is usually only a small number of 
programs, I do the links by hand today. And unfortunately, since some 
version of the basic tools, softlinked libraries are not found and used 
any more, so for /usr/local/lib, this does not work any more. :-(

Best regards,
Dirk

GoboLinux

Posted Jan 12, 2008 13:05 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

Symlinks to shared libraries are picked up by /sbin/ldconfig just fine 
(and thus used by ld-linux.so.2). Back in the glibc 2.2.x days, they 
weren't, so you had to add heaps of entries to /etc/ld.so.conf instead: 
but this was fixed long ago:

2001-05-07  H.J. Lu  <hjl@gnu.org>

        * elf/ldconfig.c (dir_entry): Add ino and dev.
        (add_single_dir): Compare ino and dev to check if 2 directory
        paths are the same or not.  Free entry->path for duplicates.
        (add_dir): Initialize ino and dev for entry.
        (search_dir): Handle symlink to directory.

2003-07-21  HJ Lu  <hongjiu.lu@intel.com>

        * elf/ldconfig.c (search_dir): Treat symlink as regular file
        if it won't point to itself.

2003-08-25  Jakub Jelinek  <jakub@redhat.com>

        * elf/ldconfig.c (search_dir): Treat symlink as regular file
        if it won't point to itself unless it is .so symlink for the 
linker.

GoboLinux

Posted Jan 14, 2008 21:23 UTC (Mon) by dh (subscriber, #153) [Link]

Hi,

thanks for clarification. Could be that I was wrong about the lib 
problems. Perhaps I remember the switch from a.out to elf or from Irix to 
Linux (which was long before 2001...). I do not install much software this 
way any more as most simply comes with the distributions. And if, I 
usually just make the link in /usr/local/bin by hand.

Best regards,
Dirk

GoboLinux

Root less install

Good ideas, but too far from the mainstream

Good ideas, but too far from the mainstream

Good ideas, but too far from the mainstream

Good ideas, but too far from the mainstream

GoboLinux

GoboLinux

GoboLinux

GoboLinux

GoboLinux

GoboLinux

GoboLinux

GNU Stow

GNU Stow

epkg

epkg

GoboLinux

GoboLinux

GoboLinux