
GoboLinux: A distro that redefines the entire filesystem hierarchy - joshumax
https://gobolinux.org/
======
ropeladder
Coming from Windows a year or so ago, the Linux filesystem has been probably
_the_ most confusing thing about the switch (I've read about the logic behind
/var and /bin and /usr several times but it was not intuitive to me and didn't
stick). I generally have no idea where my config files are stored and can
barely find where programs keep their data. And then I download some software
that doesn't install itself and I have to figure out where to put it... The
fact that this is all only sorta-kinda standardized between distributions, and
that you often have separate config files for the system, for the user, and
for the session doesn't help either.

It's not clear that GoboLinux entirely solves this issue but at first glance
it looks like it's trying and the /Programs organization is pretty intuitive.

What's not appealing at all though is using a distro that doesn't have custom
packages for all the software I'm using (aka is not Ubuntu or RedHat based).
I'm not at all comfortable building from source--when I've tried it I've
rarely been successful--and the prospect of further winnowing down my choices
(from not just Linux-compatible software to software that however many
GoboLinux users have uploaded to their Recipes directory) is, well, pretty
intimidating.

~~~
thegeomaster
On your last point about installing software: I've used Ubuntu and Fedora, and
finally settled on Arch ~4 years ago. Interestingly, although Arch has a
reputation of being a "DIY" distribution (in the sense that it targets power
users), I've had way more trouble installing software on Ubuntu and Fedora
than on Arch.

Arch has what is called the Arch User Repository (AUR). It's a repository of
recipes for building all kinds of software, and it's submitted and maintained
by the users, not maintainers of the distro itself. Whenever there's a package
missing in the official repositories, I almost always find it in the AUR. AUR
has no binary builds---instead, you download files and scripts needed to build
the software from source. You then run the _makepkg_ utility, and you get a
package you can install. (There are also helper programs which automate this
whole process for you.) The result is that the package manager tracks the
files properly, and you can keep track of which version you have, can remove
the software cleanly, and update it whenever you like.

Today, when I'm at a Ubuntu box, it's a pain in the ass to install some less-
known software. I can download the sources and then try to build, and I
usually succeed, but not before I've figured out the right flags, prefixes,
build-time and run-time dependencies, etc. I also get questions pertaining to
this from my friends that have recently switched to Linux, and I don't really
have a solution to offer. Yes, there are PPAs, but more often than not, PPAs
are outdated and are binary-only, meaning you can't really review how the
binary packages came about.

AUR really solves the problem nicely. I'd like to see such a concept in
another, more beginner-friendly distribution, that I can then recommend to
people around me who are considering making the switch.

~~~
cr0sh
I tried arch a couple of years ago (in a VM), and while I liked it and the
reasoning behind it, I had certain misgivings that led me away from it being
considered for any future use.

The main one being that whole AUR thing: What happens if there isn't a recipe
in there? For example - you want to install something which only has a binary,
no source, and can't be (legally) redistributed; what then?

Well - to "install" the software, you basically have to go thru all of the
steps to build your own recipe, noting down what you do manually, and
eventually getting to the point where you have a script (or whatever) to
install the software. Then, you undo all of your manual work, and run your
arch package to do the real install. Tada - you now have a working package for
that piece of software, and have spent potentially hours to get to that point.

As a bonus, you can't redistribute that recipe, because it is based around a
binary blob that was purchased and you don't have the rights to redistribute
it.

At least, that's how I interpreted it. I honestly don't recall what piece of
software I wanted to use, but I think it may have been EagleCAD - which has a
Linux port, but is binary only. I think it only has RPM and DEB packages, so
to get it on arch, you'd have to build your own package.

It wasn't so much the fact that you had to do this, just that it wasn't an
easy and straightforward process (from what I recall), and if you only need to
do it once or twice, it would be pretty arduous. Maybe by now (haven't looked)
they have some kind of package conversion tool, which would be a great
addition.

------
Majora320
Looks somewhat interesting. Essentially, it just switches the primary index
from "type of file" (e.g. binary, config file etc.) to "program this belongs
to". That has some advantages, as humans are more likely to want to search by
program. I do have some issues with the distro's execution of this idea,
though - the path names are far too verbose, and I'd rather not have to use
the shift key twice in every path. I'd take '/etc/foo.conf' over
'/Programs/Foo/Config/Foo.conf' any day.

~~~
greenhouse_gas
How does this compare to nixos/guix?

~~~
xelxebar
AFAIK, gobo "just" redefines the directory hierarchy along with a small kernel
patch that lets you see an equivalent standard hierarchy. It has none of of
the architecture for build reproducibility that nixos and guix boast.

------
nthcolumn
Okay so correct me if I am wrong: the original root structure is still there
just hidden with this Gobohide thing. (I do not like this - turn off
immediately).

You download tarballs into Programs and unpack and configure make install
there, it 'just works'TM somehow, (I like this - sort of). I think 'Couldn't
you create a script which creates a load of symlinks (for any distro), put it
in a folder on your desktop?'

Okay,.. help me here - what problem are we trying to solve again? I like the
nice view of the applications we have, but just thinking quite often packages
have their own symlinks for like lib.so.2-->lib.so.3 will this have symlinks
to symlinks to... so now thinking is it really worth the effort for a nice
view of the applications? What else do I get?

~~~
ufo
That thing about the bunch of symlinks actually reflects how Gobolinux was
first created :). Onde of the devs didnt havê root access in their university
lab computer so they came up with this alternate organization that let them
install everything they needed inside a directory in their home folder. He
grew fond of that folder organization and later on grouped up with some
friends to find out what would happen if they made a custom distro where
everything used the alternate organization.

As for what benefit this brings... One big one is that it makes it very easy
to mix together programs installed via the package manager and programs you
compiled from source by hand. There is no need for an alternate /use/local
hierarchy. Similarly it it better at handling those situations where you might
want to install multiple versions of some software. It can create different
versions of that virtual root filesystem but with symlinks that point to
different versions in each one. The end result is similar to what you would
get with chroot and other "container" tech but in a quite elegant way.

~~~
cr0sh
There's also the fact - if I understand it correctly - that the filesystem in
Gobo -is- the "package database"; if it is in the filesystem, it's installed
and can be looked up easily by the system. Or browsed manually. It's also
friendly to manual installs; once you install things manually, it's now a part
of the package database!

That's the one thing I hate about package managers - if you need to install
from source, the manager has no clue about it; in fact, you can have multiple
versions installed - a new version "from source" and an old version from a
real package via the manager! It's also possible for the manager to uninstall
stuff it knows about - along with part of the stuff of the new version,
depending on various things.

I ran into that earlier when I had to upgrade and munge my Ubuntu system to
get TensorFlow to work properly with Python 3 and some other stuff and crap I
forget about; long story short, I can no longer perform an upgrade to my
system (I'm on 14.04 too!) - the tool b0rks hard when I try, and I honestly
don't recall enough to return my system back to working status (I also had to
install a major upgrade to gcc - which necessitated upgrades to other things,
new manual symlinks, hours of swearing).

This was all needed for the Udacity Self-Driving Car Engineer Nanodegree
because of their system requirements for code and such (had I been running
16.04, it would have been easier - most likely - but that was also fraught
with potential issues, which is why I didn't pursue it). Looking back on
things, I probably shoulda used a container or VM, or built a new machine, but
I was pressed for time. I was assured in the beginning, before the class
started, that what I had would work - like many things in the course, this
wasn't true (I'm not saying they lied or misrepresented stuff - my cohort was
only the second cohort from November, and so I am a part of the "guinea pig"
crowd as they debug the new course - paying beta tester, if you will).

A system like Gobo might have been useful for this...

------
todd8
Many readers of HN won't need this explanation of the Unix/Linux/MacOS
filesystem hierarchy, but for those that find it confusing here is a very
brief summary. See Wikipedia for a more in depth discussion [1].

When Unix was invented, the concept of hierarchical filesystems wasn't new,
notably Multics had a hierarchical filesystem, but there were conflicting
visions. At the time, most other operating systems divided the filesystems
between a number of top-level containers containing files, but no nested
containers. IBM's contemporary time-sharing system, VM/370, supplied users
with a set of top-level "virtual" drives each containing any number of files.
There were no recursively nested directories.

The designers of Unix wanted a simple Operating System suitable for software
development so they tended to implement an idea and then use it as much as
practical in the OS design. Rather than have top-level containers like drives
that contain folders that contain files, Unix just had directories and files
(both implemented with the same on device structures called inodes). This
combination of simple ideas fully generalized can be seen throughout Unix:
multiple pathnames can point (link) to the same inode providing a form of
aliasing for filenames, the api for files is generalized to include access to
(possibly raw) devices so devices show up in the filesystem hierarchy, etc.

[/]

The top level directory has the name /, unlike other systems all filesystem
pathnames start at this single point.

[/etc]

System configuration is found here. Most of these files are simple text files
that may be edited by system administrators. In the past administrators might
directly edit /etc/passwd to remove a user. Now, things are more complex, but
there is still a backwards compatible /etc/passwd file (containing encrypted
passwords, etc.).

[/bin and /sbin]

Unix, from the beginning was, like it's inspiration Multics, a multi-user
system. Reconfiguring the system, for example to add a printer or drive,
normally required running in single user mode at a privileged level. For this
reason the programs needed by administrators running single user were
segregated and placed in /bin. The rest of the system could be left offline,
useful when working on the rest of the system.

As Unix grew, more and more utilities were added to /bin until it made sense
to segregate it into those utilities needed when even a normal user might find
themselves in single user mode vs a system administrator doing something
dangerous. The super-user type programs now go in /sbin while the essential,
but far less dangerous utilities go in /bin. Ordinary file copy is /bin/cp
while the reboot command is /sbin/reboot. Some of the division look arbitrary
to me, like /sbin/ping instead of /bin/ping, but there is probably logic
behind it.

[/usr and /var]

Once booted up normally in multi-user mode, /usr contains system read-only
content (for example, programs and libraries) and /var contains system content
that is variable (like log files).

The /usr directory is large and subsequently divided into a number of second
level directories.

[/usr/bin]

This is where the rest of the Unix "binaries" (i.e. programs) reside. So while
ls (the list directory command) is /bin/ls the c compiler resides in /usr/bin
and is /usr/bin/gcc.

[/usr/sbin]

Like the division between /bin and /sbin more administrative commands not
necessary for single user mode (see /sbin) are placed in /usr/sbin. For
example, the command /usr/sbin/setquota used to set disk quotas on users is in
/usr/sbin and not in /usr/bin.

[/usr/lib]

This is where Unix supplied software development libraries go.

[/usr/include]

This is where Unix supplied (predominantly C and C++) include files are
placed.

[/usr/share]

System documentation, the man pages, and spelling dictionaries are examples of
the files found in /usr/share. They are read-only files used by the system
under normal (multi-user) operation.

By now /usr/share is full of further subdivisions since many programs and
systems need a place to put their read-only information. For example there is
a /usr/share/cups for the Common Unix Printing System to store information
about printers, etc.

[/usr/local]

System administrators may add additional local data and programs to their
system. It make sense that these would be segregated from the rest of the
files under /usr that come with Unix. The contents of /usr/local are local to
the machine and are further subdivided into programs in /usr/local/bin and
read-only data for these programs in /usr/local/share.

[/usr/X11...]

Once, one of the biggest subsystems in Unix was it's support for the graphical
user interface known as the X window system. There were development libraries
and include files, commands, man pages, and other executables. Rather than
swamping the neat file hierarchy with these new files they were placed under a
single subdirectory of /usr. You will probably not need to look at this very
often.

[/home]

Users home directories are placed here; mine is /home/todd. Often /home is on
a different physical partition so that it can be unmounted and a new version
of the operating system can be installed without touching /home.

[/tmp]

Temporary files, for example that don't need to be backed up, are placed here.

[/mnt]

I've mentioned mounting and unmounting. Unix systems support a number of
different filesystem formats, and devices can contain multiple filesystems
(for example on distinct partitions). These filesystem become accessible once
they are mounted into the hierarchy. Users need to temporarily (and now
automatically) mount USB drives somewhere so that their files can be accessed
via a pathname. In the past, users would just pick a directory to mount over.
Now, it's traditional for temporary mounts to be placed in /mnt.

[/dev]

In Unix, low level access to devices is done through device drivers that
support a number of file interfaces. Because they appear as special files they
can be found under this directory. This is a convenience for programs because
it makes naming and access to devices very similar to naming for ordinary
files.

[Finding out more information about Unix and its hierarchy]

The Unix manual pages are a great resource. Originally, the manual was a
physical book (I've still got a couple) divided into sections. Section 1 were
the commands one might type on the command line. Now it is much easier to
simply use the man command to access the exact same content. Use a terminal
and enter "man ls", for example, to get all the information on the ls command
to list directory contents. (You will be surprised at the number of options.)

When you aren't sure of the command's name try the command "apropos" followed
by a word you'd like to find the man page for. Passwords are an important
subject so "apropos password" on my system lists 47 different manual pages for
information on passwords. I see one listed as "passwd(1)". The (1) means it's
section one so its about a command named "passwd", the command for changing
your password.

Here are the sections:

(1) Commands

(2) System calls

(3) Library functions

(4) Special files like device files

(5) File formats

(6) Recreations like games

(7) Misc info

(8) System admin and daemons

If I was looking for the format of the password file I would enter the section
number 5 as the first argument to the man command: "man 5 passwd". This would
show me the documentation for the password file, /etc/passwd.

Filesystem hierarchy manual page: "man 7 hier" or, since it is in only one
section: "man hier". To find the name, "hier", of this man page one could have
used the command "apropos filesystem".

I hope this helps; it's probably too long.

[1]
[https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard](https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)

------
gbrown_
A lot of people talking about FHS here, let us not forget history.

[http://lists.busybox.net/pipermail/busybox/2010-December/074...](http://lists.busybox.net/pipermail/busybox/2010-December/074114.html)

~~~
JdeBP
For more on which see
[https://news.ycombinator.com/item?id=11647304](https://news.ycombinator.com/item?id=11647304),
[https://news.ycombinator.com/item?id=3519952](https://news.ycombinator.com/item?id=3519952)
and
[https://news.ycombinator.com/item?id=9554134](https://news.ycombinator.com/item?id=9554134)
.

------
gcoda
Version control of installed packages would be awesome. I am still on Arch coz
I am lazy. It would be perfect if it worked like nixpkg or guix but simpler

~~~
Filligree
Nix is much easier than it used to be, _assuming_ you go all-in. Specifically,
NixOS is; nix-without-NixOS has weird corners.

If you haven't tried it in the last year or two, then you might want to give
it another try. Keep to some simple rules:

\- Look for 'enable' toggles for particular software (for configuration.nix),
rather than adding just the package. If it exists, use it; it wraps any extra
configuration that's needed.

\- Don't use nix-env. If you want a package installed temporarily, use nix-
shell. Your system is probably single-user anyway, right? This way you can put
configuration.nix in git.

\- If you must use unpackaged software, then install and use steam-run.
Despite the name, it's really just an Ubuntu-esque chroot. (...which
duplicates the Steam runtime environment, yeah.)

Forcing people to build package recipes for everything they want to use is
helpful, but not actually required. :)

~~~
DiThi
I came here to ask how GoboLinux compares to NixOS, because NixOS sounds like
the perfect distro to me, and your comment pushed me to actually try it,
thanks.

~~~
infinisil
If you have any trouble/questions, drop in on #nixos in Freenode

------
koehr
So they take the MacOS file structure to Linux? Sounds horrible to me. I
always loved the structure of the Unix file system. It's simple and rather
efficient. You wonder if a specific binary is installed? Look in /bin. You
wonder if where to configure something? Look in /etc. You want to write a
program that gives you a list of all binaries installed (like a shell)? Use
the path variable that contains a few paths and check their contents. In
gobolinux this variable is either huge or they use yet another mechanism. It
clearly will not get better though.

The file structure should be efficient for the computer and can be abstract
for the user as they want a icon on their desktop and not much more.

~~~
xenadu02
You think /bin, /sbin, /usr/bin, /usr/local/bin, /usr/local/sbin (and so on)
is simple and efficient?

You do know it’s a hack because the original Unix computer was running out of
space and they hadn’t invented Union mounts yet... right?

~~~
SwellJoe
I think "/usr/bin" is simple and efficient, and Fedora/CentOS have converged
on that a couple of years ago (/bin is a symlink to /usr/bin on those
distros). /sbin is the same (linked to /usr/sbin).

I find macOS paths atrocious (too long, too inconsistent, and derived
completely outside of UNIX traditions and norms) and I certainly wouldn't want
them on my Linux system.

Discussion of the usr move on Fedora:
[https://fedoraproject.org/wiki/Features/UsrMove](https://fedoraproject.org/wiki/Features/UsrMove)

Folks can progress without throwing away decades of tradition and tribal
knowledge.

~~~
throwaway91111
I'm not sure I follow you; naming is an area where "UNIX traditions and norms"
is clearly an example NOT to follow.

~~~
SwellJoe
Why not?

------
bobsgame
This is exactly what I have wanted for many years. This helps make Linux
understandable and accessible to new computer users. Fantastic work, and thank
you!

------
arghwhat
That's cool and all, but oh dear god WHY did you have to capitalize things?!
BLASPHEMY.

~~~
ufo
Capitalizing the directory names is a way to guarantee that they will not
conflict with the directories in the legacy file system hierarchy.

~~~
arghwhat
I find that to be quite a weak argument. Avoid conflicting with known standard
structures such as "bin" ans "etc" if necessary (which it isn't—you could
theoretically run all applications in a filesystem namespace mimicking their
expected structure), but that should be the only concern. Non-standard
structures might clash anyway (capitalized folders in root does unfortunately
occur).

~~~
ufo
The known standard does change though. For example, since Gobolinux came out
in 2003 the FSH added /run and /sys...

------
stuaxo
This is incredibly sane.

What a nice logical system, I've been a Linux user for about 15 years but
would definitely prefer this.

------
carlhjerpe
I've always wondered why things wasn't set up like this from the beginning,
much less pain for humans!

~~~
chme
Because computers where originally designed to work within the given
limitations.

In current time, where we have more computing power and storage than we know
what to do with it, we can allow computers to be inefficient for the sake of
becoming easier to use.

------
onikolas
So place your programs in a directory structure that makes sense and use
symlinks to maintain compatibility. Simple and elegant.

But... how do I go about actually installing those programs? Web search and
then git-clone / manual download? How are dependencies resolved? Admittedly I
haven't read the documentation, just the overview.

On a related note, I feel like Arch struck a nice balance with pacman and AUR.

~~~
digi_owl
There are two sets of programs/scripts (much of the gobo tools are actually
shell scripts, with a few binaries or python scripts for higher performance).
Scripts and Compile.

[https://github.com/gobolinux/Scripts/tree/master/bin](https://github.com/gobolinux/Scripts/tree/master/bin)

[https://github.com/gobolinux/Compile/tree/master/bin](https://github.com/gobolinux/Compile/tree/master/bin)

A package in Gobolinux is basically a tar-ball of the versioned dir in
/Programs.

So if a precompiled version is available in the Gobo repo (sadly fairly
limited as there is not really any resources for a compile farm available),
InstallPackage will fetch the latest from there, unpack it, and run
SymlinkProgram to have /System/Index updated.

Inside each package or recipe there is a Resources directory, inside there are
a few files that describe the program or recipe, and a list of dependencies.
these are parsed before compile or install, and additional updates/installs
suggested.

Compile is the recipe equivalent of InstallPackage. It will parse a recipe,
check dependencies, and download the source from the included url. The
compilation and install will then take place in a union mount overlaying
/System/Index, redirecting writes to the target dir in /Programs. After that
completes successfully, SymlinkProgram will again be run to update
/System/Index.

If you want to make a new recipe, there is MakeRecipe. You give it a name, a
version number and a url (though it can attempt to guess the first two from
the tar-ball name if left blank), and it downloads the tar-ball, unpacks it,
and sets up a basic recipe of the content is one of the tools it has built in
support for. Mostly a recipe is a set of steps to make things compile, things
like switches to pass to configure.

If you simply want to a newer version of an existing recipe, there is
NewVersion. All you may need to feed it is the new version number, though it
may need a url as well if the one from previous recipes are no longer valid.

------
lproven
I've occasionally played with Gobo for years now. I am delighted to see it
coming back to life of late.

One thing I've always thought would be ideal would be if either or both of the
2 Linux desktops that natively implement the idea of application-directories
were top support Gobo app-dirs.

Those 2 are GNUstep:

[http://www.gnustep.org/](http://www.gnustep.org/)

... and the ROX Desktop:

[http://rox.sourceforge.net/desktop/](http://rox.sourceforge.net/desktop/)

GNUstep implements NeXTstep/macOS style app dirs: a top-level Appname.app
folder with an OS X-like structure inside it.

ROX Desktop implements Acorn RISC OS-style app dirs, called

!Appname

... and containing a different but comparable layout.

------
traverseda
It's currently pretty annoying to set up gobolinux in "home-dir" mode. I
tried, and the documentation failed to link to the correct scripts, and after
searching the scripts out, I got a "permission denied" error when I tried to
download them, and a request for a user/password combo that wasn't documented
anywhere.

What I wanted to do was create an "append only" "everything is installed"
operating system on top of ipfs. Gobo, with it's ability to have multiple
versions of each component in the same tree, seemed perfect for that. The idea
being that you just run an executable right out of the ipfs mount.

~~~
digi_owl
Best i understand, the "home-dir" mode, or Rootless, was depreciated because
it needed a major rework to be compatible wit their switch to the /usr like
/System/Index.

------
rufius
Gobo is a cool district - one of my favorites. I used it for a while in
college with good success. Back then I recall the process for packaging being
a little rough.

I should give it another go to see how it has evolved.

~~~
digi_owl
The change from /System/Links to /System/Index was done in part because of the
issues with packaging.

While Links used a gobo unique set of directory names to house the symlinks,
Index basically acts like /usr/local.

meaning that these days a compile is done pretty much as if one would do
./configure --prefix=/usr/local. But the install stage is captured by a union
mount and the files transferred to their designated location in /Programs.

Sadly this change makes it that much harder to run Gobolinux in Rootless form
out of a home dir or similar.

------
davemp
Kind of interesting, but honestly I'd like to see a much more drastic
departure from UNIX roots. If you want to clean things up, go all in. I
wouldn't hire a cleaning service to clean 1/5th of my house (especially if
they left some clutter in that 1/5th because they thought I might miss it).

A small change like this is cool but pacman/aur leaves almost nothing to be
desired for dealing with my programs. I do like the idea, but I would need to
see a compelling philosophy for the __whole__ system.

------
pvdebbe
Have to say -- it's looking real good otherwise. Cool scifi fonts and colors,
awesome by default. Apparently it also skips systemd and pulseaudio -- a big
plus, a big plus indeed.

------
jbb67
I like this a lot. This seems to be how it should be. However, not sure I'd
use it. I guess I'll try it out in a VM and see how it goes :)

------
digi_owl
A little something to note, with the latest release there is a tool, Alien,
that integrate language specific package managers with the Gobolinux directory
tree.

Meaning that downloads from cpan or similar will be placed in a sub-directory
of /Programs and managed just like any other Gobolinux package.

Right now perl, python, ruby, and lua are supported (afaik).

------
arca_vorago
I live the gobo fs, but I don't lie the rest of the distro that much. I've
often though a bigger distro like manjaro could use the fs and show the world
how good it is.

I've been sysadmining for a long time, and even I get lost in the old dir
structure sometimes, I've just gotten good at the find command.

------
pm
Copyright 2002-2017... must've been going for quite a while now.

~~~
Semaphor
Indeed, 2003 was the first stable release:
[https://gobolinux.org/releases.html](https://gobolinux.org/releases.html)

------
steinuil
I was interested in Gobo a few years ago, but I was a bit turned off by
learning that it achieves this mostly by using a lot of symlinks.

~~~
vkazanov
...and? What's wrong with simlinks?

~~~
digi_owl
Likely parroting the age old claim that symlinks are inefficient.

~~~
steinuil
No, I just think it's a messy way to address the problem.

------
jbverschoor
It's funny how more and more macos designs are being copied over. First
systemd, now this.

~~~
noisem4ker
GoboLinux was first released in 2003.

~~~
TickleSteve
...and the NextStep/OSX layout is from '88.

------
blablabla123
They are basically doing what GNU Stow does for everything. I enjoy the
isolation but a normal package manager is in my experience more comfortable.

