根据文件系统层次结构标准，/opt用于“附加应用程序软件包的安装”。 /usr/local是“供系统管理员在本地安装软件时使用”。这些用例看起来非常相似。发行版中未包含的软件通常默认配置为安装，或者/usr/local没有/opt特定的韵律或理由来选择安装。
我是否缺少一些差异，或者两者都做同样的事情，但由于历史原因而存在？
答案1
虽然两者都被设计为包含不属于操作系统的文件，/opt并且/usr/local不打算包含同一组文件。
/usr/local是安装由管理员构建的文件的位置，通常使用命令make（例如./configure; make; make install）。这个想法是为了避免与属于操作系统的文件发生冲突，否则这些文件将被覆盖或覆盖本地文件（例如，/usr/bin/foo是操作系统的一部分，而是/usr/local/bin/foo本地替代文件）。
下面的所有文件/usr都可以在操作系统实例之间共享，尽管 Linux 上很少这样做。这是FHS有点自相矛盾的部分，因为它/usr被定义为只读，但/usr/local/bin需要读写才能成功本地安装软件。 SVR4 文件系统标准是 FHS 的主要灵感来源，建议避免/usr/local并使用/opt/local它来克服这个问题。
/usr/local是原始 BSD 的遗产。当时，/usr/bin操作系统命令的源代码在/usr/src/bin和/usr/src/usr.bin，而本地开发的命令的源代码在/usr/local/src，其二进制文件在/usr/local/bin。没有打包的概念（在 tarball 之外）。
另一方面，/opt是用于安装非捆绑软件包（即不属于操作系统发行版的软件包，而是由独立源提供的软件包）的目录，每个软件包都位于其自己的子目录中。它们已经由独立的第三方软件分销商提供了完整的软件包。与其他东西不同/usr/local，这些包遵循目录约定（或者至少应该遵循）。例如，someapp将安装在 中/opt/someapp，其命令之一为/opt/someapp/bin/foo，其配置文件将在 中/etc/opt/someapp/foo.conf，其日志文件将在 中/var/opt/someapp/logs/foo.access。
答案2
基本区别在于，/usr/local软件不受系统打包程序管理，但仍遵循标准的 UNIX 部署规则。
这就是为什么你有/usr/local/bin，/usr/local/sbin /usr/local/include等等......
/opt另一方面是不遵循这一点并以整体方式部署的软件。这通常包括以“Windows”风格打包的商业和/或跨平台软件。
答案3
它们确实非常相似，使用其中之一更多的是见仁见智的问题。 Linux 杂志对这个确切的主题进行了观点/对位讨论这里。
答案4
我对这个问题的看法略有不同。
虽然一切都在伊利亚格雷的回答是正确的，对我来说，在集群中部署软件时的实际应用可以归结为默认环境变量和库的默认重用。
简而言之 -/usr/local它的所有子目录都在适当的环境变量中，例如PATH和MANPATH，并且/usr/local/lib{,64}在 ldconfig 的 ( /etc/ld.so.conf.d/) 中。
/opt/OTOH 不是——当需要多个版本或冲突的包在系统中共存时，这既有优势，但需要某种环境管理（例如，环境模块或者软件集合），缺点是它可能会通过复制共享库来“浪费”存储空间，因为每个安装/opt都可以完全独立。
对于工作的共享性质/usr/local，假设例如二进制文件直接安装到/usr/local/bin（以及适当的手册页/usr/local/share/man/...）而不是/usr/local/app/{bin,share/man,...}等。