GoboLinux

原文 ↗ Hacker News 讨论 ↗

GoboLinux 通过将每个程序安装到自己明确命名的目录中（例如 `/Programs/App/Version`），并用符号链接兼容传统路径，重新点燃了人们对极简化类 Unix 文件系统布局的兴趣。评论者将这种人类可读的方法与历史上常令人困惑的 FHS 布局，以及更复杂、优先考虑可复现性或隔离而非透明度的 Nix、Guix、Flatpak 和容器系统进行了对比。许多人认为 GoboLinux 是一个优雅但小众的实验，不过它的想法仍可能为主流系统中更易用的软件包和文件系统模型提供灵感。

GoboLinux 的核心理念

  • 用按应用程序划分的树结构取代传统的 Unix FHS：例如 /Programs/App/Version/…，并配有诸如 /System/Index/bin 之类的中央索引。
  • 旧路径（/bin、/usr/bin、/usr/sbin 等）通过符号链接指向这些索引，因此传统软件仍然可以正常工作。
  • 目标：更符合人类阅读、更加自解释的布局；更容易安装/移除应用；减少“这个文件到底去哪了？”的困惑。

对文件系统设计的反应

  • 许多人觉得它“显然很合理”，也比历史上的 Unix 布局更直观；在一些人看来，后者只是旧硬件约束不断累积的产物。
  • 也有人为 FHS 辩护：它有连贯的（尽管是历史形成的）理由；把它称作“乱七八糟”忽视了稳定性和制度性知识；改变它会带来另一种“技术债务”。
  • 还有一部分人不喜欢其外观上的细节：首字母大写的目录（例如 /Programs）让人联想到 Windows 的“Program Files”，而且输入起来感觉别扭，不过大小写不敏感的 shell 补全在很大程度上缓解了这一点。

与 macOS、Windows、Android 的比较

  • 有几位提到它与 macOS 的应用捆绑包和 Windows 的 Program Files 很相似，因为应用都位于各自的目录中。
  • 反驳则是：macOS 和 Windows 仍然会把配置/状态分散到各处（例如 ~/Library、注册表），而且卸载过程可能很混乱。
  • Android 被认为是更完整的实现：单文件应用分发、强按应用分目录，以及沙盒化。

与 Nix、Guix、Spack、Flatpak 等的关系

  • 一些人认为 Gobo 是后来由 Nix/Guix/Spack 和容器所处理问题的更早、更简单的答案。
  • Nix/Guix：使用基于哈希的存储路径以实现严格可复现性；技术上更强大，但可读性差得多，而这被一些人认为是普及的重大障碍。
  • Spack 被强调为一个折中方案：采用名称–版本–哈希路径，并通过可配置的“views”来呈现更像语义化树结构的视图。
  • Flatpak/Snap：重点在分发和沙盒化；它们的复杂性和重复性与 Gobo 关注文件系统清晰度的方向不同。

可用性、可学习性以及多用户问题

  • 支持者认为 Gobo 降低了认知负担，也让非专家更容易理解软件放在哪里。
  • 批评者担心多用户/服务器场景以及对熟悉约定的破坏，不过 Gobo 通过按版本分目录来保持隔离，并避免混合软件包。
  • 有些人希望在现有发行版之上也能使用类似 Gobo 的布局；Gobo 支持在用户家目录中使用“无 root”模式。

成熟度与采用情况

  • 这个项目已有约 20 年历史，生态规模不大、推进缓慢；recipes/软件包可能落后于主流发行版。
  • 有几位表达了怀旧和敬佩，认为它能够持续存在很难得，但也承认自己在软件包的覆盖面和便利性上还是默认使用 Debian/Ubuntu 等。