ファイルシステム階層標準によると、/opt 「アドオンアプリケーションソフトウェアパッケージのインストール」用です。 /usr/local 「ソフトウェアをローカルにインストールするときにシステム管理者が使用するため」です。これらのユースケースは非常に似ているようです。ディストリビューションに含まれていないソフトウェアは、通常、デフォルトで/usr/localのいずれかにインストールするように構成されています。 または/opt 彼らが選んだ特別な韻や理由はありません。
私が見逃している違いはありますか、または両方とも同じことをしますが、歴史的な理由で存在しますか？
承認された回答：
どちらもオペレーティングシステムに属していないファイルを含むように設計されていますが、/opt および/usr/local 同じファイルのセットを含めることを意図したものではありません。
/usr/local 通常はmakeを使用して管理者が作成したファイルをインストールする場所です。 コマンド（例：./configure; make; make install ）。アイデアは、オペレーティングシステムの一部であるファイルとの衝突を回避することです。ファイルは、上書きされるか、ローカルファイルを上書きします（例：/usr/bin/foo /usr/local/bin/fooがOSの一部である間、 ローカルの代替手段です。
/usrの下にあるすべてのファイル Linuxではめったに行われませんが、OSインスタンス間で共有可能です。これは、/usrのように、FHSがわずかに自己矛盾している部分です。 読み取り専用として定義されていますが、/usr/local/bin ソフトウェアのローカルインストールを成功させるには、読み取り/書き込みが必要です。 FHSの主なインスピレーションの源であるSVR4ファイルシステム標準は、/usr/localを避けることを推奨しています。 /opt/localを使用します 代わりに、この問題を克服します。
/usr/local 元のBSDからの遺産です。その時、/usr/binのソースコード OSコマンドは/usr/src/binにありました および/usr/src/usr.bin 、ローカルで開発されたコマンドのソースは/usr/local/srcにありました 、および/usr/local/bin内のそれらのバイナリ 。パッケージングの概念はありませんでした（タールボールの外）。
一方、/opt バンドルされていないパッケージ（つまり、オペレーティングシステムディストリビューションの一部ではないが、独立したソースによって提供されるパッケージ）をインストールするためのディレクトリであり、それぞれが独自のサブディレクトリにあります。それらは、独立したサードパーティのソフトウェアディストリビューターによって提供されたパッケージ全体ですでに構築されています。 /usr/localとは異なり これらのパッケージは、ディレクトリの規則に従います（または少なくともそうする必要があります）。たとえば、someapp /opt/someappにインストールされます 、そのコマンドの1つは/opt/someapp/bin/fooです。 、その構成ファイルは/etc/opt/someapp/foo.confにあります 、および/var/opt/someapp/logs/foo.access内のそのログファイル 。