/ optと/ usr / localの違いは何ですか？
Filesystem Hierarchy Standard によると、/optは、「アドオンアプリケーションソフトウェアパッケージのインストール」用です。 /usr/localは「ソフトウェアをローカルにインストールするときにシステム管理者が使用するため」です。これらの使用例はかなり似ています。ディストリビューションに含まれていないソフトウェアは、通常、デフォルトでどちらかにインストールするように構成されています/usr/localまたは/opt特定の韻や彼らが選んだ理由はありません。
私が見逃している違いはありますか、または両方とも同じことをしますが、歴史的な理由で存在しますか？
どちらもオペレーティングシステムに属していないファイルを含むように設計されていますが、_/opt_と_/usr/local_は同じファイルセットを含むことを意図していません。
_/usr/local_は、通常makeコマンドを使用して管理者が作成したファイルをインストールする場所です（例：_./configure; make; make install_）。アイデアは、オペレーティングシステムの一部であるファイルとの衝突を回避することです。これは、上書きされるか、ローカルのファイルを上書きします（たとえば、_/usr/bin/foo_はOSの一部であり、_/usr/local/bin/foo_はローカルの代替です） ）。
_/usr_の下のすべてのファイルはOSインスタンス間で共有できますが、これはLinuxではほとんど行われません。 _/usr_は読み取り専用として定義されていますが、ソフトウェアのローカルインストールを成功させるには_/usr/local/bin_を読み取り/書き込みにする必要があるため、これはFHSがわずかに自己矛盾している部分です。 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_。パッケージ化の概念はありませんでした（tarballの外側）。
一方、_/opt_は、バンドルされていないパッケージ（つまり、オペレーティングシステムディストリビューションの一部ではないが、独立したソースによって提供されるパッケージ）をインストールするためのディレクトリで、それぞれが独自のサブディレクトリにあります。これらは、独立したサードパーティのソフトウェアディストリビューターによって提供されるパッケージ全体が既にビルドされています。 _/usr/local_のものとは異なり、これらのパッケージはディレクトリ規則に従います（または少なくともそれらに従う必要があります）。たとえば、someappは_/opt/someapp_にインストールされ、そのコマンドの1つは_/opt/someapp/bin/foo_であり、その構成ファイルは_/etc/opt/someapp/foo.conf_にあり、そのログファイルは_/var/opt/someapp/logs/foo.access_。
基本的な違いは、/usr/localは、システムパッケージャで管理されていないソフトウェア用ですが、標準のUNIX展開ルールに従っています。
だからこそ/usr/local/bin、/usr/local/sbin/usr/local/includeなど...
/opt一方、これは従わず、モノリシックな方法で展開されるソフトウェア用です。これには通常、「Windows」スタイルでパッケージ化された商用ソフトウェアやクロスプラットフォームソフトウェアが含まれます。
それらは確かに非常に似ており、どちらか一方を使用することは、より意見の問題です。 Linuxジャーナルは、この正確なトピックについてこのポイント/カウンターポイントディスカッション here を行いました。
私にとって、個人的には、@ philfrのリンクでビルが言ったことです：
開発システムまたはサンドボックスでは、/ optディレクトリを使用して、物事を投げて、それらが機能するかどうかを確認することができます。自分で物事をパッケージ化して試してみるつもりはありません。アプリが機能しない場合は、/ opt/mytestappディレクトリをrmするだけで、そのアプリケーションは履歴になります。大規模なデプロイを実行している場合はパッケージ化が理にかなっている場合があります（アプリをパッケージ化する場合があります）が、多くの場合、/ optにあるものをトスするのはいいことです。
残念ながら、ほとんどのmake installスクリプトは、ファイルに/usr/localにシンボリックリンクを作成する代わりに、そこにプッシュします：-/
まず、厳密な答えはないと思います。経歴によって、管理者が異なれば意見も異なります。歴史的には、/usr/localが最初に登場しました。それはバークレー、IIRCの大会でした。 System Vの開発中のある時点で、私が間違っていなかった場合（これはずっと前のことであり、私はメモを取らなかった）、マウントすることができるかどうかの決定または要望がありました/usr読み取り専用。つまり、新しいソフトウェアを追加できませんでした。それが/optが発明された理由かもしれません。たまたま、/usrに書き込みを行った既存のソフトウェアが多すぎて、そのアイデアが実際に実現することはありませんでした。
私の個人的な好みは/optで、製品ごとに個別のサブディレクトリがあります。これにより、製品の削除がrm -frの単純なケースになります。ただし、すべてのソフトウェアが適切なパッケージマネージャーを介してインストールされている場合は問題ありません。インストールするソフトウェアがこれらの規則に厳密に従っていない場合、/usrの下に構成などを書き込むと、どちらも重要ですが、反対の理由があります。
私はこの問題について少し異なる見方をしています。
jlliagre 's answer のすべてが正しい一方で、ソフトウェアをクラスタにデプロイするときの実用的なアプリケーションは、デフォルトの環境変数とデフォルトになりますライブラリの再利用。
単に-/usr/localとその子ディレクトリすべてがPATHやMANPATHなどの適切な環境変数にあり、/usr/local/lib{,64}はldconfigの（/etc/ld.so.conf.d/ ）。
/opt/ OTOHはそうではありません—これは、複数のバージョンまたは競合するパッケージをシステムに共存させる必要がある場合に有利ですが、何らかの環境管理が必要です（例： environment-modules または- ソフトウェアコレクション ）。また、/optの各インストールは完全に自己完結型であるため、共有ライブラリを複製することによってストレージスペースを「浪費」する可能性があるという欠点があります。
/usr/localの共有された性質が機能するためには、たとえばバイナリは、/usr/local/binなどではなく、直接/usr/local/share/man/...（およびマニュアルページを適切な/usr/local/app/{bin,share/man,...}に）にインストールします。
要約すると、私の腸の答え...
2.2.6以降のFreeBSDと、バージョン9以降のRed Hat Linuxを公平に使用している...
/usr/local == Old School Conventions
/opt == New School Conventions
UNIX/Linuxファイルシステムでの配置は、絶対的なロジックよりも、慣例と伝統に関係しています。
それ以外の場合、私はほとんどすべての他の人に同意します。 :-)
ルールには常にいくつかの例外があります。 1日の終わりに、セットアップに最適なものを決定します（可能な場合）。