4 ms·

Makes me remember of the late Gobolinux. Sad it never catched on : https://gobolinux.org/ https://gobolinux.org/

zlg_codes 3y ago
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!
- arghwhat 3y ago
  Yeah, using a kernel module to pretend you have a certain file structure gives off a bad smell... Playing with alternative structures is fine though.
  - zlg_codes 3y ago
    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.
  - lproven 3y ago
    Does it, though? 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. The history: https://tookmund.com/2022/03/rob-pike-shortcuts https://tookmund.com/2022/03/rob-pike-shortcuts 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.
reegnz 3y ago
Reminds me of how homebrew on MacOS used to work, it softlinked into the /usr/local prefix. Nowadays homebrew on arm processors puts everything into /opt/homebrew instead by default...
chungy 3y ago
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...).
- ylyn 3y ago
  Definitely not elegant. https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-wrapper/cc-wrapper.sh https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp... I rather have a kernel-level filesystem remapper.
  - soraminazuki 3y ago
    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.

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!

arghwhat 3y ago
Yeah, using a kernel module to pretend you have a certain file structure gives off a bad smell... Playing with alternative structures is fine though.
- zlg_codes 3y ago
  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.
- lproven 3y ago
  Does it, though? 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. The history: https://tookmund.com/2022/03/rob-pike-shortcuts https://tookmund.com/2022/03/rob-pike-shortcuts 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.

reegnz 3y ago

Reminds me of how homebrew on MacOS used to work, it softlinked into the /usr/local prefix. Nowadays homebrew on arm processors puts everything into /opt/homebrew instead by default...

chungy 3y ago

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...).

ylyn 3y ago
Definitely not elegant. https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-wrapper/cc-wrapper.sh https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp... I rather have a kernel-level filesystem remapper.
- soraminazuki 3y ago
  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.