FHS 的替代方案有哪些？

Question 1

首先，预先声明利益冲突：我是一名长期的 GoboLinux 开发人员。

其次，预先声明领域专业知识：我是一名长期的 GoboLinux 开发人员。

当前使用的有几种不同的结构。GoboLinux有一个，以及像这样的工具GNU 斯托,自制等，使用非常相似的东西（主要用于用户程序）。尼克斯操作系统还使用非标准的层次结构来进行程序和生活哲学。这也是一个相当常见的 LFS 实验。

我将描述所有这些，然后根据经验评论其在实践中的效果（“可行性”）。简短的回答是是的，这是可行的，但你必须真正想要它。

GoboLinux

GoboLinux 的结构与您所描述的非常相似。软件安装在/Programs：/Programs/ZSH/5.0.8包含属于 ZSH 5.0.8 的所有文件，位于通常的bin/ lib/... 目录中。系统工具在/System/Links层次结构下创建指向这些文件的符号链接，该层次结构映射到/usr1。该PATH变量仅包含单个统一可执行目录，并且LD_LIBRARY_PATH未使用。多个版本的软件可以同时共存，但bin/zsh一次只会主动链接一个给定名称 ( ) 的文件。您可以通过其他人的完整路径来访问他们。

还存在一组兼容性符号链接，因此/bin并/usr/bin映射到统一的可执行文件目录，等等。这使得软件在运行时的工作更加轻松。内核补丁 GoboHide 允许从文件列表中隐藏这些兼容性符号链接（但仍然可遍历）。

反对另一个答案，你不要需要修改内核代码：GoboHide 纯粹是装饰性的，内核一般不依赖于用户空间路径²。 GoboLinux 确实有一个定制的 init 系统，但这也不是执行此操作所必需的。

口号一直是“文件系统是包管理器”，但系统中也有相当普通的包管理工具。不过，您可以使用cp、rm、和来完成所有操作ln。

如果您想使用GoboLinux，我们非常欢迎。不过，我要指出的是，这是一个小型开发团队，如果以前没有人想要使用您想要的某些软件，您可能会发现它没有打包。好消息是，为系统构建程序通常相当容易（标准“配方”大约三行长）；坏消息是，有时它会非常复杂，我将在下面详细介绍。

刊物

有一些“出版物”。我做了一个演讲linux.conf.au 2010整个系统涵盖了所有内容，可在视频中找到：奥格夫 mp4（也在您本地的 Linux Australia 镜像上）；我也写下了我的笔记变成散文。还有一些较旧的文档，包括著名的“我并非无知”，在GoboLinux 网站，它解决了一些反对意见和问题。我认为现在我们都不太热心了，我怀疑未来的版本将采用/usr作为符号链接的基本位置。

尼克斯操作系统

尼克斯操作系统将每个已安装的程序放入其自己的目录中/nix/store。这些目录的命名类似于/nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/- 有一个加密哈希值，代表导致该程序的整个依赖项和配置集。该目录内包含所有关联的文件，在本地或多或少具有正常位置。

它还允许您同时拥有多个版本，并使用其中的任何一个。 NixOS 有一个与可重复配置相关的完整理念：它本质上从一开始就内置了一个配置管理系统。它依赖于一些环境操作来向用户呈现已安装程序的正确世界。

线性FS

这是相当简单的Linux 从头开始并准确设置您想要的层次结构：只需创建目录并配置所有内容即可安装在正确的位置。我在构建 GoboLinux 实验中已经做过几次，它并不比普通的 LFS 难多少。在这种情况下，您确实需要创建兼容性符号链接；否则它会变得更加困难，但是如果你真的想要的话，仔细使用联合安装可能可以避免这种情况。

我感觉好像有一个LFS提示曾经有过这样的说法，但现在我似乎找不到了。

论可行性

FHS 的特点是它是一个标准，非常常见，并且广泛反映了其编写时的现有用法。大多数用户永远不会使用本质上不遵循该布局的系统。其结果是，许多软件对其具有潜在的依赖关系，但没有人意识到，而且通常是完全无意的。

所有这些脚本都带有#!/bin/bash？如果你没有 Bash 那就不好了。这就是为什么 GoboLinux 具有所有这些兼容性符号链接；这很实用。许多软件在构建时或在非标准布局下运行时无法运行，然后需要修补来纠正，这通常是相当侵入性的。

您的基本 Autoconf 程序通常会在您告诉它的任何地方愉快地安装，并且很容易自动化传递正确的--prefix.其他构建系统并不总是那么好，要么是故意烘焙层次结构，要么是主要作者编写不可移植的配置。 CMake 是后一类的主要罪犯。这意味着，如果您想生活在这个世界上，您必须准备好在其他人的构建系统中预先完成大量繁琐的工作。在编译过程中动态修补生成的文件确实很麻烦。

运行时又是另一回事了。许多程序都会假设自己的文件或其他人的文件相对于他们或绝对在哪里找到。当您开始使用符号链接来呈现一致的视图时，许多程序在处理它们时都会出现错误（或者有时，可以说是对您没有帮助的正确行为）。例如，工具foobar可能期望找到baz它旁边的可执行文件，或者在../sbin.根据它是否读取其符号链接，这些可能是两个不同的位置，而且它们都可能不正确。

一个综合问题是/usr/share目录。当然，它是针对共享文件的，但是当您将每个程序放在自己的前缀中时，它们实际上不再是共享的。这会导致程序无法找到标准图标等。 GoboLinux 以一种相当丑陋的方式处理这个问题：在构建时，$prefix/share是一个指向的符号链接$prefix/Shared，而在构建之后，该链接被指向全局share目录。它现在使用编译时沙箱和文件移动来处理share（以及其他目录），但读取链接的运行时错误仍然可能是一个问题。

多个程序的套件是另一个问题。 GoboLinux 从未让 GNOME 完全正常工作，我也不相信 NixOS 做到了，因为布局的相互依赖关系是如此根深蒂固，以至于很难解决所有问题。

所以，是的，这是可行的，但：

光是让事情正常运转就需要做很多工作。
有些软件可能永远无法工作。
人们会用滑稽的眼神看着你。

所有这些对您来说可能是问题，也可能不是问题。

14.01 版本使用/System/Index，它直接映射到/usr.我怀疑未来的版本可能会放弃链接/索引层次结构并/usr全面使用。

² 它确实需要/bin/sh默认存在。

Answer

首先，预先声明利益冲突：我是一名长期的 GoboLinux 开发人员。

其次，预先声明领域专业知识：我是一名长期的 GoboLinux 开发人员。

当前使用的有几种不同的结构。GoboLinux有一个，以及像这样的工具GNU 斯托,自制等，使用非常相似的东西（主要用于用户程序）。尼克斯操作系统还使用非标准的层次结构来进行程序和生活哲学。这也是一个相当常见的 LFS 实验。

我将描述所有这些，然后根据经验评论其在实践中的效果（“可行性”）。简短的回答是是的，这是可行的，但你必须真正想要它。

GoboLinux

GoboLinux 的结构与您所描述的非常相似。软件安装在/Programs：/Programs/ZSH/5.0.8包含属于 ZSH 5.0.8 的所有文件，位于通常的bin/ lib/... 目录中。系统工具在/System/Links层次结构下创建指向这些文件的符号链接，该层次结构映射到/usr1。该PATH变量仅包含单个统一可执行目录，并且LD_LIBRARY_PATH未使用。多个版本的软件可以同时共存，但bin/zsh一次只会主动链接一个给定名称 ( ) 的文件。您可以通过其他人的完整路径来访问他们。

还存在一组兼容性符号链接，因此/bin并/usr/bin映射到统一的可执行文件目录，等等。这使得软件在运行时的工作更加轻松。内核补丁 GoboHide 允许从文件列表中隐藏这些兼容性符号链接（但仍然可遍历）。

反对另一个答案，你不要需要修改内核代码：GoboHide 纯粹是装饰性的，内核一般不依赖于用户空间路径²。 GoboLinux 确实有一个定制的 init 系统，但这也不是执行此操作所必需的。

口号一直是“文件系统是包管理器”，但系统中也有相当普通的包管理工具。不过，您可以使用cp、rm、和来完成所有操作ln。

如果您想使用GoboLinux，我们非常欢迎。不过，我要指出的是，这是一个小型开发团队，如果以前没有人想要使用您想要的某些软件，您可能会发现它没有打包。好消息是，为系统构建程序通常相当容易（标准“配方”大约三行长）；坏消息是，有时它会非常复杂，我将在下面详细介绍。

刊物

有一些“出版物”。我做了一个演讲linux.conf.au 2010整个系统涵盖了所有内容，可在视频中找到：奥格夫 mp4（也在您本地的 Linux Australia 镜像上）；我也写下了我的笔记变成散文。还有一些较旧的文档，包括著名的“我并非无知”，在GoboLinux 网站，它解决了一些反对意见和问题。我认为现在我们都不太热心了，我怀疑未来的版本将采用/usr作为符号链接的基本位置。

尼克斯操作系统

尼克斯操作系统将每个已安装的程序放入其自己的目录中/nix/store。这些目录的命名类似于/nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/- 有一个加密哈希值，代表导致该程序的整个依赖项和配置集。该目录内包含所有关联的文件，在本地或多或少具有正常位置。

它还允许您同时拥有多个版本，并使用其中的任何一个。 NixOS 有一个与可重复配置相关的完整理念：它本质上从一开始就内置了一个配置管理系统。它依赖于一些环境操作来向用户呈现已安装程序的正确世界。

线性FS

这是相当简单的Linux 从头开始并准确设置您想要的层次结构：只需创建目录并配置所有内容即可安装在正确的位置。我在构建 GoboLinux 实验中已经做过几次，它并不比普通的 LFS 难多少。在这种情况下，您确实需要创建兼容性符号链接；否则它会变得更加困难，但是如果你真的想要的话，仔细使用联合安装可能可以避免这种情况。

我感觉好像有一个LFS提示曾经有过这样的说法，但现在我似乎找不到了。

论可行性

FHS 的特点是它是一个标准，非常常见，并且广泛反映了其编写时的现有用法。大多数用户永远不会使用本质上不遵循该布局的系统。其结果是，许多软件对其具有潜在的依赖关系，但没有人意识到，而且通常是完全无意的。

所有这些脚本都带有#!/bin/bash？如果你没有 Bash 那就不好了。这就是为什么 GoboLinux 具有所有这些兼容性符号链接；这很实用。许多软件在构建时或在非标准布局下运行时无法运行，然后需要修补来纠正，这通常是相当侵入性的。

您的基本 Autoconf 程序通常会在您告诉它的任何地方愉快地安装，并且很容易自动化传递正确的--prefix.其他构建系统并不总是那么好，要么是故意烘焙层次结构，要么是主要作者编写不可移植的配置。 CMake 是后一类的主要罪犯。这意味着，如果您想生活在这个世界上，您必须准备好在其他人的构建系统中预先完成大量繁琐的工作。在编译过程中动态修补生成的文件确实很麻烦。

运行时又是另一回事了。许多程序都会假设自己的文件或其他人的文件相对于他们或绝对在哪里找到。当您开始使用符号链接来呈现一致的视图时，许多程序在处理它们时都会出现错误（或者有时，可以说是对您没有帮助的正确行为）。例如，工具foobar可能期望找到baz它旁边的可执行文件，或者在../sbin.根据它是否读取其符号链接，这些可能是两个不同的位置，而且它们都可能不正确。

一个综合问题是/usr/share目录。当然，它是针对共享文件的，但是当您将每个程序放在自己的前缀中时，它们实际上不再是共享的。这会导致程序无法找到标准图标等。 GoboLinux 以一种相当丑陋的方式处理这个问题：在构建时，$prefix/share是一个指向的符号链接$prefix/Shared，而在构建之后，该链接被指向全局share目录。它现在使用编译时沙箱和文件移动来处理share（以及其他目录），但读取链接的运行时错误仍然可能是一个问题。

多个程序的套件是另一个问题。 GoboLinux 从未让 GNOME 完全正常工作，我也不相信 NixOS 做到了，因为布局的相互依赖关系是如此根深蒂固，以至于很难解决所有问题。

所以，是的，这是可行的，但：

光是让事情正常运转就需要做很多工作。
有些软件可能永远无法工作。
人们会用滑稽的眼神看着你。

所有这些对您来说可能是问题，也可能不是问题。

14.01 版本使用/System/Index，它直接映射到/usr.我怀疑未来的版本可能会放弃链接/索引层次结构并/usr全面使用。

² 它确实需要/bin/sh默认存在。

Question 2

两个都GoboLinux（F.sb 提到过）和GNU图形用户界面是使用每个包的目录结构以及符号链接来指向二进制文件的“当前”版本的发行版。

如果您想要一个稳定的系统，GoboLinux 似乎是更好的选择。 GNU guix 明确表示它还没有做好生产准备。 GoboLinux 已经存在多年了。我自己也从未尝试过。

Answer

两个都GoboLinux（F.sb 提到过）和GNU图形用户界面是使用每个包的目录结构以及符号链接来指向二进制文件的“当前”版本的发行版。

如果您想要一个稳定的系统，GoboLinux 似乎是更好的选择。 GNU guix 明确表示它还没有做好生产准备。 GoboLinux 已经存在多年了。我自己也从未尝试过。

Question 3

如果每个包都有自己的文件系统部分，那么您将需要非常大且笨重的环境变量PATH，LD_LIBRARY_PATH以及类似的变量。

当然，您也可以通过这种方式自行安装软件包，然后使用类似环境模块管理它们是否在您的环境中，这就是我们为我工作的科学软件所做的事情，但我们不会为系统软件这样做。

Answer

如果每个包都有自己的文件系统部分，那么您将需要非常大且笨重的环境变量PATH，LD_LIBRARY_PATH以及类似的变量。

当然，您也可以通过这种方式自行安装软件包，然后使用类似环境模块管理它们是否在您的环境中，这就是我们为我工作的科学软件所做的事情，但我们不会为系统软件这样做。

Question 4

Linux FHS 基于 Sun 和其他 UNIX 公司在 20 世纪 80 年代末做出的决定。

当时一个重要的改变就是放弃/usr/local/并引入/opt//{ bin! lib！man！...}

如果你正在寻找 /usr/bin 今天被用作垃圾场的原因，我相信 GNOME 是最负责任的项目之一。

32 位库与 64 位库发生的情况似乎是由 FHS 引起的。

Solaris 在/lib /usr/bin和中引入了特定于平台的子目录/usr/lib。 Sun 自 1988 年起就强化了这一基本概念。

Answer

Linux FHS 基于 Sun 和其他 UNIX 公司在 20 世纪 80 年代末做出的决定。

当时一个重要的改变就是放弃/usr/local/并引入/opt//{ bin! lib！man！...}

如果你正在寻找 /usr/bin 今天被用作垃圾场的原因，我相信 GNOME 是最负责任的项目之一。

32 位库与 64 位库发生的情况似乎是由 FHS 引起的。

Solaris 在/lib /usr/bin和中引入了特定于平台的子目录/usr/lib。 Sun 自 1988 年起就强化了这一基本概念。

FHS 的替代方案有哪些？

答案1

GoboLinux

刊物

尼克斯操作系统

线性FS

论可行性

答案2

答案3

答案4

相关内容