GoboLinux 017The GoboLinux project develops a distribution with an unusual goal: reorganizing the operating system's filesystem. The project introduces itself as follows:
GoboLinux is an alternative Linux distribution which redefines the entire filesystem hierarchy. In GoboLinux you don't need a package database because the filesystem is the database: each program resides in its own directory.
In other words, instead of a package manager placing executable files in /usr/bin, libraries in /usr/lib, and other resources in /usr/share, a program's files are all stored in one tree, such as /Programs/Firefox or /Programs/LibreOffice. This way the user, and package utilities, can remove software by deleting a single directory rather than keeping track of where individual files have been installed.
GoboLinux uses the the Awesome window manager, which provides a lightweight graphical interface. Version 017 of Gobo removes Python2 in favour of Python3, and also removes GTK2 for GTK3 on the ISO. Audio management is now handled by PulseAudio.
Gobo makes available one edition of the distribution for 64-bit (x86_64) computers. The download is 1.9GB in size. Booting from this media brings up a series of text-based menus. These menus ask us to select one of six languages from a list, then select our keyboard's layout. With these questions answered we are presented with a text console where we are automatically logged into the root account. A message appears above the command line prompt which lets us know we can run "startx" to open a graphical user interface. The text also explains how to launch the system installer from either the command line or from the Awesome window manager.
Opening the Awesome environment places a panel at the top of the screen. We can find an application menu in the upper-left corner and the system tray in the upper-right. The wallpaper is mostly black with abstract designs drawn on it. The background appears to be dynamically drawn rather than a fixed image. The volume icon is interesting in that clicking on it changes the colour of the icon (toggling between green and red) and this appears to mute audio.
The application menu in the live environment contains very few entries. Most of these manage or adjust the Awesome session. I feel it worth noting that to customize Awesome we need to edit a text file, there isn't any point-and-click settings panel. There is a menu entry to open the Awesome manual. Trying to access the manual caused a window to open for a second, then immediately crash without showing the requested documentation or an error.
There are also some utilities such as the GParted partition manager and a terminal. I will talk about the included software more later, but almost everything included in the menu is intended to either manage Awesome or get the system ready to install Gobo on the hard drive.
The Gobo installer, when launched from Awesome, is a graphical desktop application. The installer does not have a method for managing partitions and if the installer cannot find a suitable partition for the operating system, the installer will ask us to launch a tool such as GParted or cfdisk to set up a new partition for it.
Assuming the installer finds a suitable partition it will ask which partition it should use for the root filesystem and if the partition should be formatted. Gobo appears only support the ext4 filesystem. We are given the option of creating a swap file. I skipped this step as I have a dedicated swap partition, but the installer does not provide an option for using the existing swap space. This meant I started my trial without swap space, but had the option of manually adding it later. The installer also does not appear to support keeping users' home directories on a separate partition.
The installer next lists all the packages that will be installed. We can uncheck boxes to exclude items we do not want. The list is quite long and it probably is not practical to go through it item-by-item. Most packages have a brief description next to them to help us figure out what we want, but a few do not. I opted to simply install all the packages which is the default behaviour.
The installer next walks us through installing the boot loader (and choosing where it should be placed), confirming our keyboard layout, the boot theme, and our clock's settings. Then we make up a root password and create one (or more) additional user accounts. I like being able to make multiple user accounts up front. The installer then showed me detailed progress reports as it copied files to my hard drive and reported it had successfully finished a short time later.
Gobo boots to a text console where we can sign into our account. The default approach with Gobo is to use the command line. While this will not be appealing to many people, it is light on resources. Users can access a graphical desktop by typing "startx" from the command line.
The console environment uses the zsh shell by default and includes the usual UNIX-style command line utilities. The man program is included but there are no manual pages, making it hard to get local help with the command line.
Once we launch the Awesome window manager we have access to a small collection of desktop software. Programs such as the Firefox browser, Audacity media player, and vim editor are on hand. Some system tools like GParted and the Htop process monitor are included too. While zsh is the default shell, others are available. The bash shell is included by default and other shells are in the project's software repository. The sudo utility is provided to help users perform administrative tasks. In the background we find Gobo uses the SysV init software and version 5.6.10 of the Linux kernel.
GoboLinux 017 -- Running the Firefox web browser (full image size: 634kB, resolution: 1366x768 pixels)
When Gobo is running just a text console it is pleasantly light on resources. The CPU pretty much sits idle and the system consumes 50MB of RAM. Even when logged into Awesome, the distribution uses a mere 150MB of memory and very little of the CPU. A full install takes about 6GB of disk space, which seems like a lot considering how few desktop tools are included. However, I believe much of the space is consumed by build tools as Gobo builds new software from source code. (More on installing software in a minute.)
I started running Gobo in a VirtualBox environment and, for the most part, the distribution ran well. It was a little slow to boot, but after that ran quickly. Sound, networking, and the desktop environment all worked. My one serious issue was I could not get the Awesome interface to resize. It was stuck at a low resolution and would not resize dynamically with the virtual machine's window. Awesome also does not appear to have a built-in tool to adjust the screen resolution which hampered my use of Gobo in the virtual environment.
Things went better when I switched over to running Gobo on my laptop. Audio and wireless networking functioned smoothly. The desktop used my full screen resolution. The distribution was still a little slow to boot, but ran well after that - with one exception which I am about to share.
The distribution uses a tool called Compile to download source code, build it and install it into a directory tree. Compile uses supplied build instructions, called recipes to figure out how to download and build software. According to the documentation, we can typically use "sudo Compile <package name>" to install new software. Building new packages from source code makes the process very slow as each package and its dependencies needs to be built from scratch. Unfortunately there does not appear to be a search feature built into Compile and I had to browse recipes on-line to find out what software was available.
Compile appears to clone an on-line repository of recipes like a ports tree on other distros. It took a long time just trying to get a copy of the repository. There was no sign of progress, even when Compile was run in verbose mode.
After trying six times and never getting a copy of the repository, despite having an active (and fast) Internet connection, I found Compile would always hang on cloning the Git repository. No data was being downloaded after the initial Git files were created. Even after several minutes, no new data was added to my repository tree. This doesn't doesn't appear to be an issue with Compile specifically as using the git command line tool would also hang trying to get the Recipes repository, and always stopped after downloading 112kB of the 474MB repository.
I tried downloading the git repository from another computer on the same network and the Recipes repository downloaded without any problems in a minute, so the issue was not the GitHub server or the local network.
Next I tried manually copying the recipes from my other computer to the Gobo system. With the recipes repository manually installed Compile no longer tried to download it. However, Compile would still hang when instructed to install software and it still showed no messages when run in verbose mode. In addition, there was no activity on the disk or network. The process monitor showed no activity from Compile. I tried installing multiple packages, all with the same result - nothing would happen and no error message was given.
On a related issue, when exploring large directories or sub-directories, my shell used a lot of disk activity just doing simple things like using cd or running pwd. This only happened in directories with many entries like /Programs or /Data/Compile/Recipes. When exploring directories with few entries the shell was immediately responsive and used almost no resources. I found this issue only happened when running the default zsh shell. Switching to bash removed the lock-up in large directories.
I had hoped running Compile again from bash would provide a solution to my package management problem, but it did not. Trying to run Compile, or git, on data that included a lot of files, caused the shell to hang.
Gobo's claim to fame isn't software management exactly, it is filesystem organization. Traditional Linux filesystems contain directories such as etc, usr, and home. Gobo names directories differently and the root filesystem contains directories called Data, Mount, Programs, System, and Users. This is nice in that it is more obvious what directories contain which resources.
Technically, the directories usr, etc, and so on still exist on a Gobo system. These legacy entries are simply hidden from the user. We can still cd into them, but do not see them in directory listings. Typically, the contents of these locations are symbolic links to Gobo's custom locations, though not always. For example, the /etc/passwd file, containing user account information still exists. However, the /etc/zshrc file is a symbolic link to /Programs/Scripts/Settings/zshrc. This hiding of traditional locations means the filesystem looks cleaner and is organized in a way which makes the contents of directories clearer to newcomers.
The irony here, to my mind, is only advanced Linux users are likely to ever use Gobo because it requires a more technical knowledge and experience to run. However, the people who will benefit from the reorganization of directories into clearly named modules are almost exclusively Linux newcomers.
Renaming directories is not the only strength Gobo offers. Modularly stored programs can be useful. It means we can easily see what programs are installed, which versions are available, and deleting programs is as easy as deleting their directory. In theory this makes the filesystem itself our package database. This is, to my mind, a neat idea.
However, I see a few issues with this approach. One, on the practical side, is I could not get the Compile tool to actually download and install any software. However, let's assume this is a rare quirk on my end and usually Compile works perfectly. Then we still have three main issues, as I see things.
First, Compile builds packages from source code and this is very slow. Most users do not want to wait around for a few hours while their web browser updates just so their underlying filesystem can be organized more modularly. I'm not saying the modular approach isn't appealing, just that the cost (compiling everything from scratch) is expensive. If Gobo had pre-built packages this would no longer be an issue.
Second, most modern package managers (such as DNF, APT, and pacman) do a good enough job that users are probably just as well off with them as with a modular filesystem that acts as a package database. These tools make running searches, removing old packages, and checking dependencies relatively painless and accomplish about the same result as Gobo's layout. There is an argument to be made that package managers add complexity to the system and removing them in favour of a new filesystem layout is better (more in line with the KISS philosophy). And I would agree with that idea, in theory, but I'm not sure Gobo's approach is practically better because....
Third, modern Linux distribution deal with tens of thousands of software packages. Gobo's modular approach (the filesystem is the package database) makes sense in small scale environments. But I'm not so sure it works practically on a system with 50,000 packages. There is no way I'm going to hunt down individual packages manually, modularly organized or not, on a modern distribution. The directory is too large. At best, I will use a command line string like "find /Programs -type d | grep -i falkon" to see if the Falkon browser is installed. At the end of the day, is that any better or worse than "dpkg -l | grep -i falkon" on a Debian-based system? Is "find /Data/Compile/Recipes -type d | grep -i supertux" really better than running "apt search supertux" from the user's perspective? I can see technical arguments for both sides, but ultimately, as a user, I want the tool that makes my life easier and my system faster to use.
All in all, I think what Gobo is doing is interesting. If nothing else it is an appealing experiment that provides an alternative approach and something to think about. Plus it makes the filesystem look cleaner and less arcane for newcomers. In my case, I found it was not a practical tool (at least when it came to package management), but I do like that the Gobo developers are thinking outside the box and offering a way to overhaul package management and the filesystem hierarchy.
* * * * *
Hardware used in this review
My physical test equipment for this review was a de-branded HP laptop with the followingspecifications:
Processor: Intel i3 2.5GHz CPU
Display: Intel integrated video
Storage: Western Digital 700GB hard drive
Memory: 6GB of RAM
Wired network device: Realtek RTL8101E/RTL8102E PCI Express Fast