あなたの答えの短いバージョンと長いバージョンがあります...
短縮版：
あなたのリンクは、すでに述べたように、/usrのための場所であるシステム全体、読み取り専用ファイル。したがって、インストールされているすべてのソフトウェアがそこに行きます。/except /binとの名前は重複しません/libが、元々、目的/bin, /libが異なります：起動に必要なバイナリとライブラリ専用で/usr/bin, /usr/lib、他のすべての実行可能ファイルとライブラリ用です。（今は良い子になり、質問しないでください/sbin、これは結局ショートバージョンです）
現在、Ubuntuを含む最新のディストリビューションのほとんどは、からのいくつかのファイルなしでは適切に起動できないため、「起動に必要」と「起動に必要」の区別は小さくなりました/usr。そして、それは、合併に向けた強い動きがある理由です/usr/binし、/bin近い将来にそうおそらく、（おそらくUbuntuの12.10は？）/binへのシンボリックリンクになります/usr/bin。
しかし、多分あなたは混乱している/usrと/usr/local？はい、なぜなら、多くの重複したディレクトリ名があります（そうあるべきです）。詳細は後で...
ロングバージョン：
70年代に戻って、Unix（はい、Unix、Linuxより前の方法）では、フロッピーのスペースはほとんどなく（HDなし、覚えていますか？）、ある時点でシステムバイナリの数とサイズが大きくなりすぎて、単一のディスクに適合し、開発者はそれらを複数のメディアに分割し、それらの新しいマウントポイントを作成する必要がありました。/binファイルシステムがいっぱいだったため、新しいバイナリを...にインストールしました/usr/bin。そして/usr、その時、彼らは... ユーザーディレクトリでした！
（ほとんど恥ずかしくて、しばしば冗談/伝承と言われる）分裂が起こった後、彼らは「人工的な」正当化（および基準）を作成し始め/bin、何に行くのか、何に行くのかを決定し始めました/usr/bin。非公式のルールは、「必須」のものはに /bin、「残り」のものはになり/usr/binます。と同じ/lib。/usrユーザー関連のディレクトリと混ざり合ったシステム関連のディレクトリで混雑するようになるのは、間もなくでした。このよう/homeにして生まれたのは、すべてのユーザー関連のディレクトリを保持し/usr、システムの「もの」だけをきれいにすることです。
これは、FHSが存在するずっと前のことです。それが作成されたとき、それは現在の伝統を受け入れ（そして公式化）、その名前を保持しました/usrが、その時点ではすでに「ユーザー」とは何の関係もありませんでした。そうです、ファンシー名「U NIX S ourceのRの epository」または「U NIX S ystemのRの esourcesは」すべて作らアップ名であり、そしてそれはとにかくそれを名前を変更するには遅すぎるのです。（しかし、手遅れになることはありません/bin）
「わかりました、どう/usr/sbinですか？」、 あなたが尋ねる。くそー、私はあなたが忘れていたことを望んでいた。Ok ... /usr/sbinは、rootユーザーが実行できる（または意味がある場合にのみ）コマンドで、mountandのようなものfdiskです。
「しかし、それはほとんど同じではありません/binか？」。はい、確かですが、...
「待って、それでなぜそれ/sbinもあるのか？意味をなさない！」。まあ、それは... err .. humm ..
見て、あなたの後ろの三頭の猿！
さて、うまくいけば、あなたは十分気を取られました。次へ...
（私が不正行為をしていると思うなら、はい、あなたは正しいです。しかし、「公式」の答えもそうです/。真実は次のとおりです。実際、線はぼやけており、「スタック」しているレガシー名がたくさんありますが、今では取り除くのは非常に困難です。
詳細について事例/usrマージから、systemdドキュメント：
/ usrとは別の/ bin、/ sbin、および/ libの歴史的な正当化は、今日ではもう適用されません。それらは分割されて、より高速なハードディスク（より高価なため小さい）でツールを選択し、より低速な/ usrパーティションをマウントするために必要なすべてのツールを含めるようにしました。現在、初期ブート時にinitramfsによって別の/ usrパーティションがすでにマウントされている必要があります。これにより、分割された論争を正当化することができます。さらに、現状の/ binおよび/ sbinにある多くのツールは、事前にマウントされた/ usrなしで実行する機能をすでに失いました。オペレーティングシステムを複数の階層に分散させる正当な理由はなくなり、その目的は失われました。
そして、/usrロブ・ランドリーによる分裂とその理論的根拠についての驚くべき読書：
bin、sbin、usr / bin、usr / sbin splitの理解
今日は
現在、インストールディレクトリに関して、理解するための最良の方法は次のように考えることです。
/usr -OSによってインストールされた（またはOSによって提供された）すべてのシステム全体の読み取り専用ファイル
/usr/local-ローカル管理者（通常はユーザー）によってインストールされたシステム全体の読み取り専用ファイル。そして、それがほとんどのディレクトリ名/usrがここで複製される理由です。
/opt-システム全体の読み取り専用の自己完結型ソフトウェアを対象とした残虐行為。それは上の自分のファイルを分割しないソフトウェアですbin、lib、share、includeソフトウェアがすべき行儀のように。
~/.local-のユーザーごとの対応/usr/local、つまり：各ユーザーによって（および各ユーザーに）インストールされるソフトウェア
~/.local/opt -ユーザーごとの対応 /opt
それでは、ソフトウェアをどこにインストールしますか？
上記のリストは、Oracle JDKの質問に対する回答の半分に過ぎません。少なくともいくつかの手がかりが得られます。「ソフトウェアXのインストール先」のチェックリスト 行く：
Eclipse IDEや他のダウンロードされたJavaアプリのような完全に自己完結型の単一ディレクトリソフトウェアであり、すべてのユーザーが利用できるようにしたいですか？次にインストールする/opt
上記と同じですが、他のユーザーのことは気にせず、ユーザーだけのためにインストールしたいですか？次にインストールする~/.local/opt
そのファイルは、などで複数のディレクトリに分割され、でコンパイルおよびインストールされた従来のソフトウェアのようbinにshare、./configure && make && sudo make installすべてのユーザーが利用できるはずですか？次にインストールする/usr/local
上記と同じですが、ユーザー専用ですか？次にインストールする~/.local
ソフトウェアは、最も重要なのは、OSによってインストール、または（ソフトウェアセンターのような）パッケージマネージャを経由して、および任意のローカル変更は新しいバージョンへのアップデートマネージャのアップグレードにそれを上書きされる可能性がありますか？に行きます/usr
ノート：
これは/usr/local、コンパイルされたソフトウェアのデフォルトのインストールプレフィックスがである理由と./configure --prefix=$HOME/.local、自分のユーザーのみにソフトウェアをインストールする場合に変更する必要がある理由を説明しています
上記のすべてのディレクトリが読み取り専用であることにお気づきかもしれません（もちろん、ソフトウェアをインストール/削除する場合を除く）。書き込み可能なファイル（構成ファイルなど）は、通常/etc（システム全体のソフトウェアの場合）および~/.config（ユーザーごとの設定の場合）に移動します。多くのレガシソフトウェア（および、残念ながら最新のものもあります）はを使用し~/.<software-name>ますが、ホームフォルダーを何十億ものディレクトリやファイルで乱雑にします。
~/.localそして、~/.configFHS仕様の一部ではありません。FHSはユーザーのホームフォルダーを扱いません。これらは、デスクトップ環境（Gnome、KDE、Unityなど）を対象とした別の標準組織であるXDGが、ユーザーの家の構造に関する規則を設定しようとする試みです。すべてのソフトウェアがそれに準拠しているわけではありません（たとえば、~/.local/binユーザーのデフォルトではありませんが、$PATH論理的にはそうである必要があります）。また、従うことを強制されるユーザーはいません。
これが少し物事を明確にするのに役立つことを願っています。何でもお気軽にお問い合わせください。答えを改善できます。
（そして、私は純粋主義者がそのような非常に非公式の言語と説明のために私を殺さないことを願っています。それは意図的であり、確かに多くの不正確さを持っていますがディレクトリの根拠）