Sometimes, distinguishing one of the several hundred available Linux distributions from another seems impossible. That, however, is not the problem with GoboLinux. Admittedly, its main claim to uniqueness is its radical reorganization of the Linux file hierarchy may seldom be seen by casual users, but as a challenge to the accepted standards, it is definitely worth a closer look.

This reorganization is not the only innovation in GoboLinux. Its call for a reconsideration of a single, all-powerful user, like Solaris’ use of roles, would improve basic security. Similarly, its renaming of /home as /Users and /usrs as /Programs seems a sensible clarification — although one or two name changes, such as using “gobo” for “root” seems pointless, an in-joke that should have been resisted. Such improvements prove that GoboLinux is more than an arbitrary system of changes, or the implementation of personal idiosyncrancies. In fact, many of its changes amount to a modernization of the traditional Linux file hierarchy that takes into account the much larger system resources of today compared to those of the era in which the file hierarchy began.

Still, some of these changes could be made as simply as adding a few symlinks. The reorganization is the innovation that is by far the most far-reaching.

What GoboLinux calls “the legacy tree” first became a standard in 1994, although its origins are a couple of decades older if you count the directory hierarchies of other forms of Linux. Over the years, the standard has been updated, with /floppy disappearing and /media being added, and a few minor variations exist, such as the merger of the top level /lib and /bin directories being merged with the similarly named sub-directories of /usr, but, on the whole, the structure has remained roughly consistent, with some twenty directories below root, and another twenty sub-directories, mostly in /usr and /var.

By contrast, GoboLinux reduces the top level directories to /Programs, /Users, /System, /Data, and /Mount. Under /Programs, each version of each application has its own sub-directory. This sub-directory has all the files associated with the application, including its man pages; Vim users might see a resemblance to Pathogen and its descendants, which reorganize Vim plugins similarly. Core operating system resources, such as binaries and the kernel, are positioned in /System, while the resources of /var are in /Data. Because some applications are not set up for GoboLinux, extensive symlinks are used to preserve compatibility with the legacy tree. In addition, all files are indexed to minimize the need to sort through thousands of files.

Is Change Needed?
Each of GoboLinux’s innovations deserves to be examined separately, but that would be another article or three. Here, my main question is whether such a massive restructuring is worth the effort to create and maintain, especially when most of Linux uses the legacy standard.

The question is not easy to answer. If nothing else, long-term use of GoboLinux would be needed to overcome the novelty of the new or the prejudice for the familiar.

In GoboLinux’s favor is the fact that its directory tree is comprehensible at a glance. Its simplification, renaming, and use of full words are all improvements over the legacy tree. You only have to notice the number of commands like grep and scripts like Debian’s dpkg-reconfigure that are designed to prevent direct contact with the file hierachy to realize how complex the legacy tree has become. In the same way, environments can be described as a way both to automate and to give direction to normal operations.

Yet the fact that GoboLinux itself uses indexing suggests that the problem lies less in the directory hierarchy used and more in the sheer size of modern file systems. No matter what directory tree is use, complexity is probably inescapable. From that perspective, only so much simplification is possible without sacrificing accuracy.

If that is true, then GoboLinux may do administrators no favor in its rearrangement. True, the traditional File Hierarchy System continues to use abbreviations that are no longer necessary, and its distinctions make for an unnecessarily difficult learning curve. Yet for those who take the time and effort to learn it, the legacy tree’s distinctions are at least as useful as a simplified general structure.

For example, as you may know, while /bin  holds general binaries, /sbin is supposed to hold binaries useful for system administration. Similarly, /etc should contain configuration files, but no binaries, and /usr non-system files.

Yet such arrangements are not arbitrary, as GoboLinux documents sometimes seem to imply — instead, they are the parts of an organizational system based on function, rather than on files like GoboLinux. I am not sure which is most efficient, but I do know that in searching for information, especially in reading man pages, the traditional functional organization sometimes leads me to other useful information in a way that GoboLinux’s do not.

If the distinctions in the legacy tree sometimes get murky, especially in the difference between top level directories and similarly named sub-directories in /usr, that does not change the fact that much of the knowledge of the legacy tree is transferable to other distributions — in fact to other Unix-like systems — while GoboLinux’s structure is not.

Hisham H. Muhammad, GoboLinux’s founder, makes a virtue of this fact. Far from similarity being a virtue, he argues:

But the actual reason why we don’t want to change the standard is because we believe there should be no standard. I know this statement may sound even bolder than talking about changing a standard, but the reason I say that is because we believe it is the duty of each application to allow itself to be installed anywhere and to accept that other applications it needs to work with may be installed anywhere (more on this in the next section). Now, if there was a standard stating this, I’d even sign a petition to support it. In fact, there is: the GNU release standards, when they recommend the usage of GNU Autotools, supporting the -prefix family of switches, and probing for the location of applications with the configure script, do just that. But when a proposed standard like the FHS gives me an arbitrary list of binaries that should be, for unexplained reasons, in a separate directory, I laugh at that.

Yet, while standardization can be restrictive, it can also be useful. Learning GoboLinux might be compared to learning only LibreOffice, learning the standard File System Hierarchy to learning about word processors and their features in general. If you learn about word processors, you can quickly learn a new one when the need arrives. However, if you learn only LibreOffice, learning another word processor requires starting almost from scratch, all the time troubled by the fact that features have other names and menus list other features.

If that is true for a word processor, how much more is it likely to be true about entire operating systems? An idiosyncratic operating system may be convenient for those who use it regularly, but it does not allow users to transfer their knowledge to any other operating system.

Questioning Authority
My experiences with GoboLinux over several weeks leave me with few definite conclusions. However, in a sense, that hardly matters.

GoboLinux does not release user figures, but I suspect its user base is comparatively small. But for me, the value of the distribution is not that it is an innovation that would be sensible for everyone to accept. Instead, I value GoboLinux because its attempts to do things differently have me examining and questioning the way things are. It raises issues the Filesystem Hierarchy Standard might do well to consider in order to stay relevant — and that is a function much more valuable than how I organize my daily computing.

 

[sharedaddy]