我的理解是自定义/非发行版软件应该安装在/opt. 然而，在 Django 部署教程 [ 1 ] 中，我发现了一个安装 Django Web 应用程序的建议，/srv该应用程序被描述为包含由系统提供的特定于站点的数据。

非发行版 Web 应用程序应该安装在/opt或中吗/srv？

在FHS下，系统软件包（例如 RPM）将库安装到/usr/lib（或/usr/lib64）。同样，使用旧的“”例程编译的库configure;make;make install（不属于系统发行版的一部分）默认安装到/usr/local/lib（或/usr/local/lib64）。

一般来说，要求用户更改 LD_LIBRARY_PATH 或ld.so.conf他们安装的应用程序被认为是不好的形式。参见示例：

http://web.archive.org/web/20060719201954/http://www.visi.com/~barr/ldpath.html

但是，这条规则不应该/usr/local/lib是一个例外吗？

如果是这种情况，为什么许多/大多数发行版默认情况下不包含/usr/local/lib在库搜索路径中？到目前为止，似乎只有 ArchLinux 认为这是一个错误，请参阅http://bugs.archlinux.org/task/20059?project=1&opened=2263 以及相关的http://bbs.archlinux.org/viewtopic.php?id =99807

/usr/local/lib对于需要将库包含/usr/local/lib在其 RPATH 中的应用程序来说，还是期望操作系统已经具有该设置更正确？我不喜欢在 RPATH 中使用任何不基于 $ORIGIN 的东西。

这不是一个迂腐的问题，因为它对系统稳定性以及软件的打包方式有影响。

我最近一直在摸索文件系统层次结构标准，并且在很多场合，当谈论目录时/usr/local，我遇到了术语“本地安装的包”。有人可以解释一下在这种情况下“本地”的确切含义吗？

这个systemd wiki 页面关于 /usr 合并，在神话 #6 下，指出它/bin传统/usr/bin上是 System V UNIX 上的符号链接。

这样做的动机是什么？为了向后兼容，这是有道理的，但我不明白为什么在早期会这样。（或者，我误解了吗？早期的 UNIX 版本是否区分/bin和/usr/bin，而 System V 通过合并它们改变了这一点？）

如果我从源代码安装，是否需要保留解压后的 tarball 目录？所以如果我下载 git tarball。然后我做：

tar -xvzf git.tar.gz

这将创建一个git.x.x. 目录，cd然后运行./configure等。一旦我完成了这个过程，git或者安装了任何东西，我是否需要保留原始git.x.x提取的目录，或者它只是用于编译程序？

我对所有用于程序的目录和文件夹感到有些困惑。

该文件系统层次标准说往哪里放东西在UNIX分布。

FHS 是用于/设计用于 GNU/Linux 之外的，还是主要限于 GNU/Linux？

/opt/Linux 中的目录用于安装附加软件包。

/opt/<package>/bin目录和/opt/<package>/X/bin目录有什么区别？将二进制文件放在这些目录中有什么区别？

您能否也请指点我一些文档，其中解释了安装在/opt/目录中的新软件包/应用程序的目录结构应该是什么？

Linux FHS（文件系统层次结构标准）是指以下形式的目录：

/lib<qual>

它对此类目录的描述如下：

在支持多种需要单独库的二进制格式的系统上，/lib 目录可能有一种或多种变体。

同样，它指的是目录：

/usr/lib<qual>

并将它们描述为：

对于备用二进制格式，/usr/lib 执行与 /usr/lib 相同的角色，但不需要符号链接 /usr/lib/sendmail 和 /usr/lib/X11。

FHS维基百科文章为这些目录提供了以下替代描述：

/lib<qual>

替代格式基本库。此类目录是可选的，但如果存在，则有一些要求。

/usr/lib<qual>

备用格式库，例如 64 位计算机上的 32 位库的 /usr/lib32（可选）。

我假设该字符串<qual>是某种东西的助记符。是吗？如果是的话，它代表什么？

我想了解 Linux 文件层次结构以及操作系统如何在更深层次上工作。有没有电子书或网页可以学习？

在 Linux FHS 中，它表示所有第三方软件包都应该使用/opt. 不过我没看到有人用/opt。另外，无论如何/opt也不在$PATH，所以我认为操作系统无意让我们使用/opt. 那么为什么还要费心去创造/opt既然没有人会使用它，那么

你们可能认为这是重复的，但显然不是。我知道差异和线索，但我只是不知道为什么没有人使用它。

编辑：过时我并不是说不好/不必要（我同意/proc一团糟）。模块化是一件好事，我喜欢它。我的意思是：系统的信息，保存在（在/sys）其他地方可以找到。

我真的找不到太多关于/sys和 的信息/proc。除了这两个内容都不属于文件系统层次结构标准的一部分（因为它们看起来/正在构建的方式取决于内核版本）

/ SYS并不甚至有它自己的man页面。/proc 有它自己的手册页，哦，天哪，它有很多解释，但我仍然有一些文件夹和文件（例如/acpiand consoles），其中没有提到。 /sys很新吧？在它存在之前，所有提供的信息/sys都是/proc正确的一部分？

题：

现在还是这样吗？是否可以在一种或另一种形式中/sys找到所有信息/proc表？那会使文档/sys过时，因为它只是具有用户友好设计的扩展，对吗？或者是否有任何系统信息/sys不以其他形式存在/proc？

如果是这种情况，/sys向linux业余爱好者解释的地方在哪里？

Linux 文件系统层次结构充满了未使用的文件夹，这些文件夹仅因历史原因而存在。

是否仅使用实际使用的目录安装任何发行版？