Unixファイルシステム構造の利点は何ですか
Debian/Gnu LinuxなどのLinuxにアプリケーションをインストールすると、アプリケーションのファイルがファイルシステムのさまざまなディレクトリにコピーされます。
一部のスクリプトは/ usr/share../ usr/localに移動します他のいくつかのファイルを/ var../ log..etc /などです。
私にとってこれは大丈夫です。ファイルシステムについて何かを学び、ほとんどのディレクトリは特定の目的のためにファイルを保持するためにそこにあります。これは、Unixの哲学「1つのことを行い、それをうまく行う」に非常によく適合します
しかし、私の質問はそのようなディレクトリ構造の利点は何ですか？または、それは単に古いUNIXの遺産です。 （たとえば、アプリケーションのすべてのファイルが1つの特定の「フォルダー」にある1つのWindowsの使用と比較して）
私にとって最も考えやすい利点は、同様のファイルが同じディレクトリツリーに存在することです。構成ファイルは/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が持っていたよりもファイルシステムウイルスに対する耐性が高い理由かもしれません。
どの組織を選んだとしても、それはいくつかのことをより簡単にし、いくつかのことをより困難にするでしょう。
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構造へのシンボリックリンクのフォレストを作成することです。これは stow のようなソフトウェアが行うことです。
要約すると、Unixアプローチにより、ファイルの使用、ファイルの管理、およびパッケージの相互作用が容易になります。パッケージ管理ソフトウェアが必要ですが、とにかくそれが望ましいです。 Windowsのアプローチでは、パッケージを手動で管理するのが簡単になりますが、有用な機能を利用するには、Unixモデルに移行する必要があります。
上記に記載されていない主な利点、および構造の歴史的な理由の1つは、ブートプロセスのさまざまな段階で利用可能な複数のボリューム/ディスクでの物理的な分離です。
別の利点は、ディレクトリのデータ用に最適化されたボリューム/ファイルシステムにさまざまなディレクトリをマウントできることです。たとえば、tmpfs for /run;および/sbin読み取り専用メディア/ ROM。
また、ボリュームはローカルまたはリモート、個人用または共有にすることができます。
最後に、UNIXで使用される代替アプローチ（@fluffyで言及）については、 アプリケーションディレクトリ を参照してください（OS X .app）、Linux（ ROXデスクトップ ）およびWindows（ PortableApps.com ）。
このレイアウトには、アプリケーションの共有ファイルと構成ファイルの場所を簡単に推測できることを除いて、実際には何の利点もありません。 UNIXにはこの種のレイアウトの長い伝統があり、それを壊すことはかなり難しいでしょう。ただし、一部のUNIXディストリビューションではモデルが変更されています。それらはレガシー目的のために古い場所のみを提供し、他のアプリは独自の小さなディレクトリ/パッケージにバンドルされています。 Mac OS Xはこれの最も顕著な例であり、同じことを行ういくつかのあいまいなLinuxディストリビューションがあります（そしてAndroidは似たようなことをしますが、少し先に進んでインストールして起動します独自のユーザーIDのすべてのアプリケーションも）。
ファイルシステムの規則が提供する主なものは、まさにそれです。つまり、ファイルを探す場所を人々が知っているようにするためです（手動またはコードで）。それが別の方法を超えているという本当の技術的な理由はありません。