Debian / Gnu LinuxなどのLinuxにアプリケーションをインストールすると、アプリケーションのファイルがファイルシステムのさまざまなディレクトリにコピーされます。
一部のスクリプトは/ usr / share .. / usr / localにあり、その他のファイルは/ var .. / log .. etc /などにあります。
私にとっては問題ありません。ファイルシステムについて何かを学び、ほとんどのディレクトリは特定の目的でファイルを保持するためにそこにあるからです。これは、Unixの理念である「1つのことをうまく実行する」に非常によく適合します。
しかし、私の質問は、そのようなディレクトリ構造の利点は何ですか？それとも単に、昔のUNIXの遺産なのか。（たとえば、アプリケーションのすべてのファイルが1つの特定の「フォルダ」にある1つのウィンドウの使用と比較して）
回答:
私にとって最も簡単に考えられる利点は、類似のファイルが同じディレクトリツリーに存在することです。構成ファイルはにあり/etc、ログファイルおよび/またはランタイムトレースファイルはにあり/var/log、実行可能/usr/binファイルはにあり、PIDファイルのようなランタイム情報はにあり/var/runます。NTP構成ファイルの内容を知りたいですか？ディレクトリをに変更し/etcてくださいls ntp*。従来のファイルシステムウイルスが感染しないように、プログラムに実行可能ファイルを監視させたいですか？すべてのものを監視する必要が/usr/binあり/usr/local/binます。
私が考えることができる2番目の利点は、Unixスタイルの編成がデータと実行可能ファイルの分離を促進することです。実行可能ファイルは、テンプレートが置かれている場所から（/usr/shareおそらく）離れており、データが置かれている場所から離れているディレクトリにあります。その分離が、Unix / Linux / * BSDがWindowsや古いPre-OSX Macが持っていたよりもファイルシステムウイルスに対する耐性が高い理由である可能性があります。
/bin、/etcから、/。
どの組織を選択したとしても、いくつかのことは簡単になり、いくつかのことはより困難になります。
種類、Unixの方法でファイルを整理（へbin、man、lib/python、...）、それが簡単にファイルを使用できるようになります。コマンドを実行する場合は、どのパッケージがコマンドを提供しているかに関係なく、コマンドの場所を知っています。ドキュメントを検索したい場合は、すべて1か所にあります。一部のプログラムがVim構文強調表示モジュール、zsh補完関数、またはPythonバインディングを提供している場合、関連ファイルはvim / zsh / pythonが見つけられる場所にあります。
Unixはまた、使用パターンによってファイルを編成します。構成ファイルが入り/etc、通常の操作で変更されない/usrファイルが入り、自動的に変更されるファイルが入ります/var。ユーザーデータは以下になり/homeます。これは、構成管理（/etcインストールされているパッケージの一覧とインストールされているパッケージの一覧の管理）に非常に役立ちます。また、バックアップ戦略を定義することも役立ちます。何が含まれ/etcてい/homeて非常に重要であるのに対し、何が含まれているか/usrは簡単に再ダウンロードできます。
Unixの方法の主なコストは、ソフトウェアのインストールが多くのディレクトリに分散していることです。しかし、現代のUNIXシステムにはとにかくパッケージマネージャがあります。多くのディレクトリでファイルを管理することは、それらが行う最も複雑なことではありません（依存関係の追跡は非常に便利で困難です）。
Windowsとは対照的です。Windowsはパッケージ管理なしで開始し、各アプリケーションは独自のディレクトリをどこかに作成しました。すべてのファイルは通常、そのディレクトリ内にあります。プログラム、静的データ、ユーザーデータなどです。ただし、ライブラリが競合を考慮せずに共通のシステムディレクトリにドロップする場合があります（「DLL hell」）。時間の経過とともに、Windowsはマルチユーザーになり、ユーザーディレクトリをシステムディレクトリから分離する必要がありました。Windowsは、構成ファイル（Unixの/etc）といくつかのシステムデータ（Unixの/var）、レジストリ。これは、主にパッケージ管理の欠如とシングルユーザーシステムとしての初期の歴史による、より歴史的な成果物です。Windowsのアプローチには多くの制限があります。ソフトウェアパッケージが簡単に相互作用することはできません。たとえば、インストールされているほとんどのソフトウェアは、デフォルトのコマンド検索パスに到達しないため、あらゆる形式のスクリプトと適切に相互作用しません。インストーラーは通常、特別なケースとしてメニューアイコンを提供します—別のシステムディレクトリにドロップされます（Unix！）。
Unixアプローチの制限は、パッケージの複数のバージョンの共存を簡単に許可しないことです。これは、パッケージのアップグレード中に特に問題になります。両方の世界を最大限に活用する方法は、各パッケージを独自のディレクトリ（/opt構造）に解凍し、パッケージディレクトリから/usr構造へのシンボリックリンクのフォレストを作成することです。これは、ストウのようなソフトウェアが行うことです。
要約すると、Unixアプローチにより、ファイルの使用、ファイルの管理、およびパッケージの相互作用が容易になります。パッケージ管理ソフトウェアが必要ですが、とにかくそれが望ましいです。Windowsのアプローチでは、パッケージを手動で管理するのが簡単になりますが、有用な機能を利用するには、Unixモデルに移行する必要があります。
上記で言及されていない主な利点、および構造の歴史的な理由の1つは、ブートプロセスのさまざまな段階で利用可能な複数のボリューム/ディスクの物理的な分離です。
別の利点は、ディレクトリのデータ用に最適化されたボリューム/ファイルシステムにさまざまなディレクトリをマウントできることです。例えば、tmpfsのために/run、そして/sbin、読み取り専用メディア/ ROMに。
また、ボリュームはローカルまたはリモート、個人用または共有にすることができます。
最後に、UNIX（OS X ）、Linux（ROXデスクトップ）、およびWindows（PortableApps.com）で使用されている代替アプローチ（@fluffyで言及）については、アプリケーションディレクトリを参照してください。.app
このレイアウトには、共有ファイルと構成ファイルがアプリケーション用にどこにあるかを簡単に推測できることを除けば、実際にこのレイアウトに利点はありません。UNIXにはこの種のレイアウトの長い歴史があり、それを壊すことはかなり難しいでしょう。ただし、一部のUNIXディストリビューションではモデルが変更されています。それらはレガシー目的のために古い場所のみを提供し、他のアプリは独自の小さなディレクトリ/パッケージにバンドルされています。Mac OS Xはこれの最も顕著な例であり、同じことを行ういくつかのあいまいなLinuxディストリビューションがあります（そしてAndroidは同様のことを行い、少しだけそれを取り、すべてのアプリケーションを独自のユーザーIDでインストールして起動します）。
ファイルシステムの規則が提供する主なものはそれだけです-規則ですので、人々はファイルを探す場所を（手動でもコードでも）知ることができます。それが他の方法よりも優れているという本当の技術的な理由はありません。