如果我在 Linux（例如 Debian/Gnu Linux）中安装应用程序，应用程序的文件将被复制到文件系统中的许多不同目录中。
一些脚本进入/usr/共享../usr/本地一些其他文件到/var../日志..ETC/等等。
对我来说这没关系，因为我了解了一些有关文件系统的知识，并且大多数目录都是为了特定目的而保存文件的。这非常符合 Unix 哲学“做一件事并把它做好”
但我的问题是这样的目录结构有什么优点呢？或者它只是旧 Unix 时代的遗产。 （例如，与单一窗口使用相比，应用程序的所有文件都位于一个特定的“文件夹”中）
答案1
无论选择哪个组织，都会让一些事情变得更容易，让一些事情变得更困难。
按照 Unix 方式按类型组织文件（分为bin, man, lib/python, ...），可以更轻松地使用文件。如果您想运行命令，您知道在哪里可以找到它，无论哪个包提供它。如果您想搜索文档，一切都在一处。如果某个程序提供了 Vim 语法突出显示模块、zsh 完成功能或 Python 绑定，则相关文件将位于 vim/zsh/python 可以找到的位置。
Unix 还按使用模式组织文件。配置文件进入/etc，正常操作中不更改的文件进入/usr，自动更改的文件进入/var。用户数据受到保护/home。这对于配置管理（管理其中的内容/etc以及已安装软件包的列表）非常有用。定义备份策略也很有用：其中的内容/etc至关重要/home，而其中的内容/usr可以轻松地再次下载。
Unix 方式的主要成本是安装一个软件分散在许多目录中。然而，现代 UNIX 系统无论如何都有包管理器；到目前为止，管理许多目录中的文件并不是它们所做的最复杂的事情（跟踪依赖关系非常有用且更困难）。
与 Windows 进行对比。 Windows 开始时没有包管理，每个应用程序在某处创建自己的目录。所有文件通常都在该目录中：程序、静态数据、用户数据……除了有时程序会放入公共系统目录而不考虑冲突的库（“DLL 地狱”）。随着时间的推移，Windows 变得多用户，需要将用户目录与系统目录分开。 Windows 还为配置文件（Unix 的/etc）和一些系统数据（Unix 的/var）创建了一个中心位置，即注册表。这更像是一个历史工件，很大程度上是由于缺乏包管理和作为单用户系统的早期历史。 Windows 方法有很多限制：它不允许软件包轻松交互。例如，大多数已安装的软件不会出现在默认命令搜索路径中，因此它与任何形式的脚本交互都会很差。安装程序通常会提供一个菜单图标作为特例 — 放入单独的系统目录中（类似于 Unix！）。
Unix 方法的一个限制是它不容易允许包的多个版本共存，这在包升级时尤其成问题。获得两全其美的方法是将每个包解压到其自己的目录（结构/opt）中，并创建从包目录到结构的符号链接森林/usr。软件就是这样的存放做。
总之，Unix 方法使得使用文件、管理文件以及允许包交互变得更加容易；它需要包管理软件，但无论如何这是可取的。 Windows 方法使手动管理包变得更容易，但必须转向 Unix 模型才能获得有用的功能。
答案2
在我看来，最容易想到的优点是相似的文件位于同一目录树中。配置文件位于/etc，日志文件和/或运行时跟踪文件位于/var/log，可执行文件位于/usr/bin，运行时信息（如 PID 文件）位于/var/run。您想知道 NTP 配置文件中有什么内容？将目录更改为/etc并执行ls ntp*.您想让某些程序监视可执行文件，以便某些传统文件系统病毒不会感染它们吗？一切都在里面/usr/bin，/usr/local/bin需要观察。
我能想到的第二个优点是，Unix 风格的组织促进了数据和可执行文件的分离。可执行文件所在的目录远离模板所在的位置（/usr/share可能），并且远离数据所在的位置。这种分离可能是 Unix/Linux/*BSD 比 Windows 或旧的 Pre-OSX Mac 对文件系统病毒具有更强抵抗力的原因。
答案3
答案4
除了很容易猜测应用程序的共享文件和配置文件的位置之外，这种布局实际上没有任何优点。 UNIX 长期以来一直保留着这种布局，要打破它是相当困难的。然而，一些 UNIX 发行版已经改变了它们的模型 - 它们只提供旧位置用于遗留目的，而其他应用程序则捆绑到自己的小目录/包中。 Mac OS X 是最突出的例子，还有一些不起眼的 Linux 发行版也做同样的事情（Android 也做了类似的事情，只是更进一步，并且也在自己的用户 ID 下安装和启动每个应用程序） ）。
文件系统约定提供的主要内容就是 - 一个约定，以便人们知道在哪里查找文件（无论是手动还是在代码中）。没有真正的技术原因让它以一种方式优于另一种方式。