Re: [dev] [question] gobo linux filesystem hierarchy

From: Anselm R Garbe <>
Date: Tue, 4 Jul 2017 23:17:22 +0200

Hi Kajetan,

On 4 July 2017 at 14:23, Kajetan Jasztal <> wrote:
> What do you think can be the downsides of filesystem hierarchy of
> Gobo Linux[0]? STALI[1] was attempting to modify default hierarchy
> after all. I personaly think it's clear, evident (only problem I have
> is hiding symlinks in /) and elegant. It's in a way compatible with
> Unixes by symlinking. I guess it's not that good after all, but
> I can't see what can be the problem here.

The main difference between gobo and stali is, that gobo introduced a
rather complex solution to a non-issue, whereas the stali fs layout is
a simple solution to an actual issue.

The installation of program assets into common directories (shared
with other programs) is not an issue at all. Gobos solution is very
similar to the misguided approach found in macOS (and probably its
ancestor NeXT) with the containers. After all, a total
non-issue in a world, where either proper package management or
Makefile uninstall targets would allow to remove the assets of a
particular program or package. Apart from this, the Gobo approach goes
into a pretty retarded direction with the introduction of
Index-directories for executables and libraries crowded by a softlink

In contrast a real issue with the Linux FHS is, that it offers far too
many options for common directories, by allowing /bin /sbin /usr/bin
/usr/sbin /usr/local/bin /opt/bin etc. to name just a few typical
ones. The FHS is totally over-engineered and hence a real issue.
Deciding which prefix to use for a program or looking up some config
file with so many options to pick from sucks. Hence stali solved this
mess by declaring a hand full of softlinks to force the established
FHS thinking into a very simplified layout, where you can easily
determine where executables are to be found or where runtime stuff
will be placed.

I hope this shed some light into the motives of stali's rather unusual
fs layout.

Received on Tue Jul 04 2017 - 23:17:22 CEST

This archive was generated by hypermail 2.3.0 : Tue Jul 04 2017 - 23:24:41 CEST