本月，比尔和我将讨论 Linux 极客之间经典的圣战之一：/opt vs. /usr/local。如果您查看当前的 Linux 文件系统层级标准，您会看到 /opt 和 /usr/local 都被表示在那里。如果您进一步阅读，您会看到它们似乎都有相似的目的：放置不属于标准系统的软件。尽管这两个目录都是为相似的目的而设计的，但它们各自以不同的方式执行该任务。嗯，没有什么比两个非常相似但又存在细微差异的事物更能激起极客之间的辩论了。

比尔： 那么 /opt 有什么问题呢？

凯尔： 当初设置 /opt 时，确实 没有任何问题。 你知道，那是在 tar 是你的包管理器，恐龙还在地球上漫步的时代。

比尔： “当初设置的时候。” 哦，又来了，又一个“比尔比泥土还老”的评论。

凯尔： 我不是说你比泥土还老，我只是说我在你的年鉴照片里见过泥土。 无论如何，在当时，将所有东西打包到一个大目录中并将其转储到 /opt 下是有道理的。 但在过去的二十年中，大多数 Linux 发行版开始使用更复杂的包管理器。

比尔： 嗯哼。 我相当 喜欢 使用 /opt。 能够清楚地区分哪些是由发行版安装的，哪些是管理员事后安装的，这很好。

凯尔： 哇，我完全同意你这句话的一半。

比尔： 嘿，这可是第一次。 而且还印出来了。 呜呼！

凯尔： 确实 很高兴能够清楚地区分哪些是发行版的一部分，哪些是管理员安装的——对我来说，它就在 /usr/local 中。

比尔： 这是我 第一次 听到你，尤其是你，提倡更多打字。

凯尔： 你的系统软件包可以将它们的文件转储到 /usr 中，任何第三方软件包都可以将东西放在 /usr/local 下相同的目录结构中； 然而，因为现在我们不使用 tar，而是使用像 rpm 和 dpkg 这样的程序来安装软件包（以及它们的 yum 和 apt 前端），我们有更复杂的方法来查看安装了什么以及安装在哪里，而不仅仅是 ls 命令。 即使那样，使用 ls，我也可以看到一个特定的二进制文件在 /usr/local/bin 中，因此，一定是第三方软件包的一部分。

比尔： 我可能在这里争论的是语义，但这正是观点/反驳的意义所在。 对我来说，/opt 是“选项”——安装后才有的东西。 /usr/local 意味着它是本地机器的。 对我来说。 你的 “ls” 观点也适用于 /opt，只是路径更短，而且你不能假设每个人都会使用 rpm 和 dpkg。

凯尔： 路径更短，嗯？ 好的，比尔，谢谢你的铺垫。

比尔： 如果你从源代码编译东西，并且不 想 经历制作 .deb 的额外步骤呢？ 最根本的是没有真正的“标准”。 我见过的所有管理员都倾向于有他们自己对此的看法。

凯尔： 一旦你开始使用 /opt，你可以指望你的系统路径呈指数级增长。 使用 /usr/local，我的库路径和我的二进制路径只需要添加一个条目（一个可能已经存在的条目）。

比尔： 指数级？ 只有当你安装了大量的软件时才会这样，伙计。 我更喜欢知道，如果我要构建一个 Java 应用程序服务器，我的 JDK 始终在 /opt/jdk 中（我通常有一个指向实际 JDK 的符号链接，例如 /opt/jdk_sun_1.6.0.17。 这样，JAVA_HOME 始终是 /opt/jdk。 任何其他软件包，例如自定义编译的 apache，都可以放在 /opt/apache 中。

凯尔： 但是如果你将 JDK 安装在 /usr/local 中（并不是说 Sun 会批准），你可以将所有库放在 /usr/local/lib 中，将 Java 二进制文件放在 /usr/local/bin 中，而且 你可以使用你的常规包管理器来查看东西安装在哪里。

比尔： 那只是几个路径。 你假设这些东西是由软件维护者打包的，或者我想经历制作软件包的过程。 很多时候软件没有打包。

凯尔： 当你将软件部署到你的服务器时，这是一个额外的（在我看来，是正确的）步骤，但这是一个确保你可以自动处理依赖关系，可以使用标准工具而不是 tar、cp 和 rm 来添加和删除软件包的步骤。

比尔： 哇，你称 tar 和 cp 为“非标准工具”？

凯尔： 标准 打包 工具。 让我们以你的 apache 示例为例。 如果我想要一个自定义的 apache，我必须编译它，对吧？ 我所要做的就是使用 --prefix 选项将它的安装位置从 /usr 更改为 /usr/local。 在我看来，这比 /opt 方法更容易。

比尔： 能够拿出一个完全正常工作的服务器，然后只是将其目录 rsync 到另一台机器，这相当不错。

凯尔： 再次，我想如果你是一个隐藏的 Solaris 或 Slackware 管理员，tar、cp 和 rm 就是 你的打包工具，但如果你的附加程序在软件包中，你可以只使用标准的包管理器。

比尔： 是的，如果 有它的软件包，或者你想花功夫制作一个。

凯尔： 我认为这场争论最终归结为：在适当的包管理器出现之前安装软件的传统（和古老）方法，与在服务器上部署软件的现代方法。

比尔： 有时打包是合适的。 如果你有足够的时间准备，或者需要大量的验证和控制，那么当然，打包吧。

凯尔： 现代方法是使用包管理器，因此依赖关系很容易管理——添加、删除和更新软件包都得到管理，并且有审计跟踪。 传统方法只是解压或复制文件，并希望它们能工作。 此外，使用传统方法，你会通过共享更少的库并将所有内容捆绑在每个软件包中来占用额外的空间，即使另一个软件包可能使用相同的库。 “正确”完成这项工作的前期工作可以为你节省很多后续工作。 我认为归根结底是比尔对他在 Sun 工作的那些年对 /opt 有一种怀旧之情。

比尔： 嘿，仅仅因为当我看到 /opt/SUNW 类型的路径时感到怀旧并不意味着我没有道理。 在开发系统或沙箱中，拥有一个 /opt 目录，你可以在其中随意放置东西并看看它们是否工作，这非常有意义。 我知道我不会自己花力气打包东西来试用它们。 如果应用程序不起作用，你可以简单地rm删除 /opt/mytestapp 目录，该应用程序就成为历史了。 当你运行大型部署时，打包可能是有意义的（确实 有时我会打包应用程序），但很多时候，将东西扔进 /opt 也很不错。