The DynDN.eS Blog

About DynDN.eS, eQmail, Gentoo & some other network stuff

User Tools

Site Tools

The Resurrection of Gobo Linux

It was surprising me really to see a new release of Gobo Linux in 2015 after 8 years. And with Gobo Linux 016 (released December 2016) it looks like the development will continue further on. I used it for a while back in the days around 2007, later on I applied gobohide over a Gentoo system to be able to create my own file system hierarchy. And this is the core difference of Gobo Linux - the file hierarchy. Gobo gets rid of the FHS, at least visual.

As I have some concerns too, in general I like new and good ideas. Getting rid of FHS is one of the points about I think it should be done (BTW, there are more). For sure there are more or less valid arguments pro and con for every thing, so for Gobo Linux as well. IMHO the developers made and make a very good job. Though I saw Gobo Linux as a technical preview back in 2007 I would enjoy to see continued progress in the future. Less as big distribution but as project, do-ability analysis. With the ability to use - most of the - Linux/Unix software there are all kinds of options given.

Technique: gobohide

Gobo Linux is based on gobohide. It has 2 parts: a kernel patch and a userland tool. The patch itself adds code to the kernel which prevents programs like  ls  to show folders in  / . There is a kernel config option to switch the functionality on or off. The userland tool  gobohide  is used to configure which folders will be hidden. The folders still exists and includes content, so typing e.g.  /bin/sh  still works. Usually  gobohide  will be started at boot time. However, as of now the kernel HAVE TO be patched (for sure, this is done in the kernel of the distro already).

A bit aside, but as the kernel have to be patched anyway, why not going further with changing the location of (some) kernel system folders? Independent of the effort and impacts I missed any thoughts about it.


Maybe the header of this paragraph isn't accurate as the following are some of my thoughts and miss-likes. And yes, I did read I am not clueless1). Even though it is an older article it is still an important one to understand the initiators thoughts behind Gobo Linux.

There are some minor miss-likes which I don't want to mention, except (without referring about possible problems) the usage of upper letters (folders). This isn't user friendly at the command line. It is inconsistent in itself too (e.g. “/System/Index/share”). But there is one important point to me (freely cited):

Gobo Linux doesn't require a package manager, the file system (hierarchy) is the package manager.

Sounds good? Hmmm - but doesn't they move from one extreme position into the opposite one only? Is their solution really better or does it replace simply an existing problem by a new one? I would answer the last 2 questions with yes. It is not the place to discuss or analyze package management here and now. But does it make sense to install every program (e.g. single binary) inside a separate folder(structure)? With subfolders and a lot of additional links? Or is it may be a better way to combine traditional and new ideas? I don't have an answer at the moment, but I tend to compromises in most cases. (package management)


Except for educational reasons I don't see any reason to go on with Gobo Linux. As distribution it will stay like a mayfly at distrowatch. There are a some people who will use it for quite a while. But I question that Gobo Linux has the potential to get a big user base. Better take the good new ideas and and try to improve the UNIX' philosophy. Sorry.

There are some points I want to mention because I have a different view about it against the founders.

  • renaming “root” to something else isn't an invention by Gobo Linux, a number of Unix/Linux administrators did this long before
  • the  /usr/bin  and  /usr/lib[*]  folders exists because of small hard disks at time of initial development of UNIX
  • using  gobohide  with other distributions is a decision of the (advanced) user who did it, no matter of any reason

Again - these are my thoughts and sometimes they depend on my preferences. I didn't research any technical do-ability yet. And didn't think about the amount of effort(s) yet. Perhaps there are some points at the to do list of the developers, but I haven't seen (found) a road-map yet.