Hi Kajetan, On 4 July 2017 at 14:23, Kajetan Jasztal <kajetanjasz...@gmail.com> 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 Crap.app 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 mess. 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. BR, Anselm
