GoboLinux

Original Article ↗ Hacker News Discussion ↗

GoboLinux revives interest in radically simplifying Unix-like filesystem layouts by installing each program into its own clearly named directory (e.g., `/Programs/App/Version`) and using symlinks for compatibility with traditional paths. Commenters contrast this human-readable approach with the historical, often confusing FHS layout and with more complex systems like Nix, Guix, Flatpak, and containers that prioritize reproducibility or isolation over transparency. Many see GoboLinux as an elegant but niche experiment whose ideas could still inspire more approachable packaging and filesystem models in mainstream systems.

GoboLinux’s core idea

  • Replaces the traditional Unix FHS with a per-application tree: e.g. /Programs/App/Version/…, with central indexes like /System/Index/bin.
  • Legacy paths (/bin, /usr/bin, /usr/sbin, etc.) are symlinks into these indexes, so traditional software still works.
  • Goals: human-readable, self-explanatory layout; easier app installation/removal; reduced “where did this file go?” confusion.

Reactions to the filesystem design

  • Many find it “obviously sane” and more intuitive than the historical Unix layout, which is viewed by some as an accretion of legacy hardware constraints.
  • Others defend FHS: it has coherent (if historical) reasons; calling it a “mess” ignores stability and institutional knowledge; changing it risks “technical debt” of a different kind.
  • A subset dislikes cosmetic aspects: capitalized directories (e.g. /Programs) evoke Windows “Program Files” and feel awkward to type, though case-insensitive shell completion largely mitigates this.

Comparison with macOS, Windows, Android

  • Several note similarities to macOS app bundles and Windows’ Program Files, where apps live in their own directories.
  • Counterpoint: macOS and Windows still scatter config/state (e.g. ~/Library, registry), and uninstall can be messy.
  • Android is cited as a more complete realization: single-file app distribution, strong per-app directories, and sandboxing.

Relation to Nix, Guix, Spack, Flatpak, etc.

  • Some see Gobo as an earlier, simpler answer to problems later tackled by Nix/Guix/Spack and containers.
  • Nix/Guix: use hash-based store paths for strict reproducibility; more technically powerful but much less human-readable, which some argue is a major barrier to adoption.
  • Spack is highlighted as a middle ground: name–version–hash paths plus configurable “views” that can resemble a more semantic tree.
  • Flatpak/Snap: focus on distribution and sandboxing; their complexity and duplication differ from Gobo’s focus on filesystem clarity.

Usability, learnability, and multi-user concerns

  • Proponents argue Gobo reduces cognitive load and makes it easier for non-experts to understand where software lives.
  • Critics worry about multi-user/server implications and loss of familiar conventions, though Gobo keeps isolation by versioned directories and avoids mixing packages.
  • Some want Gobo-like layouts available atop existing distros; Gobo supports a “rootless” mode in a user’s home directory.

Maturity and adoption

  • Project is ~20 years old, with a modest, slow-moving ecosystem; recipes/packages can lag behind mainstream distros.
  • Several express nostalgia and admiration that it persists, but acknowledge they default to Debian/Ubuntu/etc. for breadth and convenience of packaging.