The most important experimental distro you've never heard of gets new project lead
- Reference: 1744382287
- News link: https://www.theregister.co.uk/2025/04/11/new_gobolinux_lead_and_version/
- Source link:
Nine years after its last major release, GoboLinux returns, with a new release, [1]version 017 , and a new project maintainer. Until now, Gobo was under the stewardship of founder [2]Hisham Muhammad , a Brazilian developer whose most famous project is probably the popular [3]htop process viewer .
Hisham has now stepped down and passed the torch to a new maintainer, [4]Philip "nuc1eon" Pok , who was already maintaining the [5]project wiki .
[6]
Along with this news, there's also a new release: [7]GoboLinux 017.01 .
[8]
GoboLinux 017 comes with the AwesomeWM tiling window manager, but others are on offer – click to enlarge
Although Gobo users haven't seen a release in a while, that does not make it one of the many one-person efforts which only puts out a release or two and then disappears. Gobo has been around since 2003, and there is a small team of people working on it. Back in 2020 there were both [9]alpha and [10]beta releases of version 017 from project co-founder [11]Luca Villa Real . Now, that version is finally here, fixing some bugs, changing some implementation details of its unique packaging system, and updating many of the components – but it's not massively different from before.
GoboLinux is an experimental and extremely radical distro: it is not another contender for a Windows replacement, or a super-lightweight distro, or anything like that. If you're looking for something easy and ready-to-use, look elsewhere – for instance, [12]Linux Lite 7.4 just came out .
[13]
[14]
Gobo is an OS for people interested in totally reconsidering how Unix-like OSes are put together, how software is packaged, installed, updated, and removed. In its early days, Gobo drew some inspiration from the then-new Mac OS X.
MacOS and NeXTstep
A bootable macOS system drive seems to have a very simple directory layout: there are only a handful of visible directories in the root directory. For example, on the "Monterey" machine we're writing on right now, the boot drive contains just four top-level directories: Applications , Library , System and Users . Inside Applications , each program looks like a single file: Automator , Calculator , Calendar , and so on.
This superficial simplicity, though, is thanks to some sleight of hand. In reality, the root directory has most of the standard Unix entries such as bin , dev , etc , opt , sbin , usr , var and so on. It's just that Finder desktop hides them. Open a terminal, type ls -la / , and there they are – although the contents may not be just as Unix veterans expect.
Those pretty icons in /Applications conceal whole directory trees. They have a special file extension, and when the macOS Finder sees a directory called {something}.app , it hides the extension and treats that tree as a monolithic application. Inside, there's a complex directory hierarchy, which bears no resemblance to a conventional Unix-style layout, and has distinct advantages: for instance, it can transparently handle binaries for multiple CPU architectures.
MacOS inherited its directory layout and the .app system from NeXTstep, developed by Steve Jobs's NeXT Computer, which released NeXTstep 1.0 in 1988. It's also shared by the GNUstep project, which is [15]older than Linux itself . NeXT and Sun standardized the system in the [16]OPENSTEP Specification [PDF] in 1994. Today, it's used in macOS and and GNUstep-based desktops such as [17]NEXTSPACE and [18]GSDE .
The Gobo team took the idea of macOS's simple, stripped-out filesystem layout, and extended it to apply it more ruthlessly to the whole OS. Gobo only has a relatively small number of directories, with human-readable, conventionally-capitalized names in English. Inside these are other fairly self-descriptive names, and inside them, directories with version numbers, so you can have multiple different versions of tools installed simultaneously, side-by-side.
Installing a program is simple: just copy one directory. Uninstall by deleting that directory. If you don't remove the directory with the previous version number, the previous version is left intact – so rollback is built in, without fancy filesystems, copy-on-write snapshots or anything.
This totally replaces the traditional Unix-style system, which separates the component files of the OS and its constituent programs, and spreads them out across a complex directory hierarchy with cryptic, abbreviated, all-lower-case names: libraries in /lib and /usr/lib , binaries in /bin and /sbin and /usr/bin and /usr/sbin and /usr/local/bin and so on, config files in /etc , system state in /var , and so on. The reasons for this are complex and historical: the system evolved after repeated ad hoc compromises [19]due to the constrained hardware UNIX was originally built on .
[20]
As that last link explains:
Of course once the split existed, some people made other rules to justify it.
[…]
Standards bureaucracies like the Linux Foundation… happily document and add to this sort of complexity without ever trying to understand why it was there in the first place.
This is the important point. There are people who will happily explain for hours why all this stuff exists. There is a [21]formal standard for the layout, with various explanations, such as the quite short [22]Ubuntu one or the Linux Documentation Project's [23]extremely in-depth one . Even so, it's not really true: it was all invented after the fact, to justify what had just evolved over time. It's done like this because everyone has always done it like this. Worse still, none of it really matters today, when a £5 ($6) USB key can hold a dozen entire distros and the cheapest computers you can buy boot from SSDs holding hundreds of gigs. Now, it's just tradition.
Today, we need elaborate programs to take packaged software, unpack it and distribute all its many components in many different directories across this complex hierarchy. The task is even more difficult because the tools must also track where every component went, so that all of the files can be upgraded with new versions – or so that they can be uninstalled again. Additionally, these tools must keep track of all the complex interdependencies between the many programs and libraries that make up the OS itself, plus any additional applications.
One of the principle differences between all the many Linux distributions is their various implementations of such tools.
Ostensibly modern systems like Flatpak merely take the old Unix layout, encapsulate it inside their own wrappers, and bolt on some extremely complicated tooling to synchronize changes down from a cloud server to your local machine. Snap does the same, but by loop-mounting compressed archive files, which at least makes updating simpler – copy a new file.
[24]
The Gobo developers threw away all that legacy baggage, and replaced it with a simplified, human-readable layout with capitalized English names – not because they were native English speakers, as they aren't, but because it's the world language of the 21st century.
By way of full disclosure: the traditional Unix folder hierarchy is still present. It is needed, because many of its paths are embedded in the source code of many Linux programs. However, Gobo's version is empty apart from lots of symbolic links to where things are really stored, which means existing source code can be recompiled without modification. It's also hidden, by an optional [25]Linux kernel module called Gobohide , which has been part of the kernel for about 20 years.
[26]
The live image boots to a very clean screen, and there's startlingly little in the root directory - click to enlarge
The system is quite mature now, although even 22 years ago, Hisham had to defend his decisions – for instance, in [27]"I am not clueless ," subtitled Myths and misconceptions about the design of GoboLinux .
There are other systems which have tried to do comparable things.
Back in the days of proprietary UNIX, there were several. The US National Institute of Standards and Technology had a system called the NIST Depot , described as a [28]Framework for Sharing Software Installation Across Organizational & UNIX Platform Boundaries [PDF]. Variants included [29]CMU Depot , which [30]used the Andrew distributed filesystem . Not much is left today, but there is a [31]short overview of what it did and [32]how it worked . Another derivative was Depot-Lite , [33]described as A Mechanism for Managing Software .
Another was [34]Xhier from the University of Waterloo, which still offers [35]HOWTOs on it .
Today, there is Nix. This can be used on other OSes, and there is a distro built around it which [36]we looked at in 2022 . Nix also throws out almost the entire Unix directory hierarchy, and replaces it with a software-generated one using hashes to ensure uniqueness. There's an [37]evaluation and comparison of GoboLinux from 2011 which discusses the different goals of the two projects.
[38]GNU Guix is similar but defines packages using the GNU Guile dialect of Scheme, while Nix has its own unique specification language.
In this vulture's humble opinion, these tools go too far and sacrifice too much in pursuit of declarative, reproducible builds, which are theoretical advantages which we suspect simply don't matter to most Linux users – as we [39]explained why in some depth when Nix was forked about a year ago. Nix produces a filesystem that's barely human-readable or navigable, and if the tools to maintain it stopped working, it would be well-night impossible to repair or maintain by hand. It also discards the hierarchical and explorable nature of other filesystem designs.
In contrast, Gobo aims to produce a hierarchy that is more readable and easier to navigate, and it exploits that design to deliver better encapsulation and isolation than traditional Unix or Linux systems, simpler installation and removal, and upgrades and rollback without the need for sophisticated filesystems such as Btrfs or ZFS.
Also, just like Nix, you can use GoboLinux within your home directory on top of another distribution – the teams calls this [40]Rootless GoboLinux .
The changes Gobo makes enrage Unix traditionalists, but it delivers on its claims. In our testing, version 017.01 runs happily under both VirtualBox and QEMU, but we couldn't get it to successfully install a bootloader – but then, bootloader problems are mentioned under Known outstanding issues in the [41]release notes . We're willing to forgive this: it's under new management, and they've got a release out that's been pending since 2020.
The teething troubles don't in any way lessen the lessons that Gobo has to teach. We've seen people say that Nix and Guix render it obsolete, but that is not remotely the case. We hope that the developers of Flatpak, Snap, openSUSE's Snapper, and other experimental packaging tools pay attention to the new version, and spend some time learning how it works.
Get our [42]Tech Resources
[1] https://gobolinux.org/gobolinux017.html
[2] https://hisham.hm/
[3] https://htop.dev/
[4] https://neonsys.org/
[5] https://wiki.gobolinux.org/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z_k8nFOHEtX_xYHVt_bqMwAAAJc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[7] https://gobolinux.org/release_notes_017.01.html
[8] https://regmedia.co.uk/2025/04/09/gobo_017_desktop.jpg
[9] https://github.com/gobolinux/LiveCD/releases/tag/017_alpha
[10] https://github.com/gobolinux/LiveCD/releases/tag/017_beta
[11] https://lucasvr.gobolinux.org/
[12] https://www.linuxliteos.com/forums/showthread.php?tid=9348
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z_k8nFOHEtX_xYHVt_bqMwAAAJc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z_k8nFOHEtX_xYHVt_bqMwAAAJc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[15] http://gnustep.made-it.com/Guides/History.html
[16] https://www.levenez.com/NeXTSTEP/OpenStepSpec.pdf
[17] https://github.com/trunkmaster/nextspace
[18] https://onflapp.github.io/gs-desktop/index.html
[19] https://lists.busybox.net/pipermail/busybox/2010-December/074114.html
[20] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z_k8nFOHEtX_xYHVt_bqMwAAAJc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[21] https://wiki.linuxfoundation.org/lsb/fhs
[22] https://help.ubuntu.com/community/LinuxFilesystemTreeOverview
[23] https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/index.html
[24] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z_k8nFOHEtX_xYHVt_bqMwAAAJc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[25] https://lwn.net/Articles/194376/
[26] https://regmedia.co.uk/2025/04/09/gobo_017_console.png
[27] https://gobolinux.org/doc/articles/clueless.html
[28] https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir4436.pdf
[29] https://directory.fsf.org/wiki/Depot
[30] https://web.archive.org/web/20010515195513/http://andrew2.andrew.cmu.edu/depot/
[31] https://web.archive.org/web/20010426163204/http://andrew2.andrew.cmu.edu/depot/depot-lisaVI-paper.html
[32] https://web.archive.org/web/20010228051759/http://andrew2.andrew.cmu.edu/depot/SoftMgmt.html
[33] https://www.usenix.org/conference/lisa-viii/depot-lite-mechanism-managing-software
[34] https://cs.uwaterloo.ca/twiki/view/CF/XHier
[35] https://cs.uwaterloo.ca/twiki/view/CF/XhierHowtos
[36] https://www.theregister.com/2022/12/13/nixos_2211_raccoon/
[37] https://sandervanderburg.blogspot.com/2011/12/evaluation-and-comparison-of-gobolinux.html
[38] https://guix.gnu.org/
[39] https://www.theregister.com/2024/05/14/nix_forked_but_over_politics/
[40] https://gobolinux.org/?page=rootless
[41] https://gobolinux.org/release_notes_017.01.html
[42] https://whitepapers.theregister.com/
It sounds like there's increased disk usage but that it decreases complexity, since every installed program presumably includes everything it needs to run rather than depending on a patchwork of dependencies. As you say, that means disk usage could get quite high, but storage is at much less of a premium than it once was, and I can envision having a filesystem with built-in deduplication to help manage overall capacity and/or enhancing the versioning capability so that only changes to a given program get deployed.
> What's the penalty in disk usage for providing every application's private copy of, say libc
It is still a relatively conventional Linux OS (compared, say, to the immutable ones) -- it's just got a lot of weird directory paths.
So it has a fairly standard glibc, Xorg, and so on.
I've experimented with a few distros that use a nonstandard libc, such as Alpine and Void, and apps that expect glibc won't work. I don't think packaging your own would help.
So no, not _every_ dependency is in the apps' own trees. A few versions ago there was, for example, a version with KDE and all the KDE apps did not include their own copies of KDE.
And no, it's not statically-linked. I suggested it to Hisham, actually, and he said he was not against the idea but they had too many other things to do.
Most package installations do indeed mean compiling from source. There's a repo with "recipes" and you install apps using a script called "compile" with a recipe, which fetches it and builds it.
Yes, there is a cost in disk space, but not vastly greater than current conventional distros, and less than the immutable ones.
Let's be realistic, though. Even with a full suite of tools and personal data, a distro installation in its entirety still rarely exceeds 250GB, usually more like 40-60GB of storage. So even if you took entire copies of the distro for your versions, you could store a minimum of 8 snapshots on a 2TB SSD...
Love it!
I for one quite like the concept.
The current stuff is way too complex for me - with my poor memory for pure facts, I have a hard time finding things not my own, or knowing how to do stuff that folks like Liam can instantly access. For example, when an update to Apache comes along that changes the config files, I refer to a piece of paper beside my monitor that says "systemctl stop apache2" to stop the server so I can then go undo any config file changes I don't like (I run an absolutely minimum configuration). Similar for the mail server.
Having fewer directories, with meaningful names, could make things a lot easier. Do they also do it for things like the maze of C header files? As a programmer, I curse every time I have to actually find an active definition for something in, say, the "bits" universe. I sort-of understand how the arrangement came to be, but I certainly don't like it.
I first hit UNIX systems on a PDP-11, then SunOS, so I do know the basic structure, but I'm waaay out of date, and always will be.
But.....can you use it for real work????
Say: Email (thunderbird), documents (libreOffice), spreadsheets (libreOffice), RAW pictures (DarkTable), JPG pictures (GIMP, imagemagick), browsing (Chromium), xBASE (harbour) ......and so on......
If "Yes! To all of the above!!"......then I might move off F41/XFCE............otherwise.......why tell me about something I cannot use?
Re: But.....can you use it for real work????
"why tell me about something I cannot use?"
Because it's interesting to explore alternative ways of doing things? Because El Reg is written for an audience comprised of people who are not just you?
What a limited perspective on the world you have.
Pathetic
"The changes Gobo makes enrage Unix traditionalists"
Imagine being so attached to a traditional way of implementing an operating system that someone else experimenting with alternatives enrages you. It's ironic that there's a faction of so-called technologists who are so hidebound, close-minded, and conservative that they can't bear the thought of someone else doing a different thing.
What's the penalty in disk usage for providing every application's private copy of, say libc - which, if I've understood the description, it must do. Or are the applications statically compiled which amounts to much the same thing? And what happens if you need to compile something from source?
I can appreciate the advantages of this (not least ./configures which assume some unnecessarily recent version of a library and barf if they don't find it) but there's a cost to it in extra storage and extra complexity.