What's late about it? It's out of date maybe, but as far as I can tell it's still alive. Did I miss an announcement?
I really like this one's approach. These guys created a kernel module to enforce their hierarchy and hide directories, etc. Such an interesting project!
Aren't dot files just pretending to be hidden due to a bug in early Unix?
Unix v1 had a flat filesystem. Unix v2 added subdirectories. As an implementation detail, each directory contained two magic files, `.` for "this directory" and `..` for "the parent directory".
The command to list files was sloppily coded to skip them. If a name started with a dot, it was skipped.
Hey presto! Unix 2 had a way to hide files! It was a bug, but it was useful, so it stayed.
So, Gobo doesn't use `/etc` and `/var` and all that 1970s nonsense, but it keeps them around, empty except for shortcuts, for sloppy code that assumes they are there.
But they are hidden, just like dot files are hidden on every Unix-like OS. Because it looks better, no other reason.
Fair enough, it's a mess mostly due to old conventions, the LSB, etc. I would be more satisfied with a kernel or init system or whatever that can configure where libraries are, temp data, cache, local software, system software, global configuration, etc. Then the primary difference in pathways for Gobo vs, say, Debian would be what paths they configured for Linux's main types of OS data.
It would make playing with alternative hierarchies kinda fun.
I think Nix and Guix have carried on similar concepts to Gobo in a much more elegant fashion (especially by not requiring the kernel to be patched...).
That's the standard build script setting the required compiler flags. Pretty mundane stuff, and nothing "inelegant" about it. It's not something Nix users or packagers need to even care about.
While the code is mundane and might not score any beauty points, it does offer a clear technical advantage. Namely, Nix doesn't require that packagers uniquely choose the installation path for each package. Instead, Nix guarantees that different package definitions result in a different installation path. This is one of the things that make Nix package definitions programmable because packagers don't have to manually resolve path conflicts.
Programmable package definitions mean more automation and customizability.
