すべてのbinおよびsbinフォルダーで明確にしましょう（ファイルシステム階層標準から）：

• /bin システムレベルのバイナリ用
• /sbin 主にブートローダーとシステム管理者のための他のシステムレベルのバイナリ用です
• /usr/bin 必須ではないバイナリ用
• /usr/sbin-これは混乱の始まりです-システム管理者にとって不可欠なツールではありませんか？どういう意味ですか？実験用？
• /usr/local/bin -このフォルダについての言葉はありません
• /usr/local/sbin-ローカルにインストールされたシステム管理プログラム。再び？どう/usr/sbin？

質問は次のとおりです。なぜ多くのディレクトリがあるのか/usr/sbin、/usr/local/sbinそしての意味は何/usr/local/binですか？

多くのプログラムはアーカイブを通じて配布されており、ソースコードからビルドする必要があります。通常はmakefileがあるため、非常に簡単です。このプロセスでは、特定のプログラム用に特定のフォルダーを作成せずに、usr / local / lib、usr / local / bin ... usr / local / whateverにファイルを作成します。

なぜそうですか？

プログラムを削除する必要がある場合、プログラムの作成者がそれを処理しなかった場合、すべてのファイルを手動で削除する必要があるため、これは正しくないと思います。

1.ディレクトリ構造

これは、Filesystem Hierarchy Standard （2.3 PDF）で説明されています。

/ bin /シングルユーザーモードで使用できる必要がある必須コマンドバイナリ。
            すべてのユーザー、たとえば、cat、ls、cp

/ sbin /必須のシステムバイナリ、たとえば、init、ip、mount。

/ usr / bin /必須ではないコマンドバイナリ（シングルユーザーモードでは不要）。 
            すべてのユーザー向け

/ usr / sbin /必須ではないシステムバイナリ。たとえば、さまざまなネットワークサービスのデーモン。

/ usr / local /このホストに固有のローカルデータの3次階層。 
            通常、さらにサブディレクトリがあります。たとえば、bin /、lib /、share /

2.インストール

可能な限りパッケージマネージャーを使用します（たとえば、yumまたはapt-get）。これは非常に多くのアプリケーションで可能ですが、いくつかのケースではリポジトリを追加する必要があります。私の2番目の選択肢は、RPMなどの低レベルのパッケージであり、ソースからのコンパイルが最後の手段になります（ただし、これを好む人もいます）

一部のパッケージマネージャーはRPMからインストールできます（例yum install oddity.rpm）

ソースからコンパイルする場合、システムインストーラーが実行内容を認識できるように独自のパッケージを作成することは、おそらく大きなステップではありません。

その後、あなたの問題は例えば yum remove packagename

別の方法は、実施されたすべてのsysadminアクティビティに関する適切なドキュメントを保持することです（とにかくジャーナルをテキストファイルに保持します）

すべての* / sbinディレクトリにあるものは、システム管理者のみに役立つ傾向があります。あなたが普通のユーザーなら、あなたのPATHからそれらを遠ざけることができます。

単一のディスク上に単一のUNIXマシンがある場合、異なるディレクトリはあまり意味がありませんが、大きなシステムと異なるパーティションがある場合はより意味があります。これらの習慣の多くは、システムが少し異なっていた80年代と90年代に作られたことを思い出してください。

/sbin非常に小さい傾向があります。これらは、本当に疲れているときに必要なユーティリティです。/ rootと/ libを使用して、これを最小限のルートパーティションに配置します。/ sbin内のものはすべて静的にリンクされていました。これは、/ usrパーティションがホース接続されている場合、動的にリンクされたアプリは役に立たないためです。fsckはここにあり、静的にリンクされています。/ usrに依存している場合、明らかに/ usr /をfsckすることはできません。もちろん、ルートパーティションがホースで固定されている場合は、非常に手間がかかります。これがこのような小さなパーティションである理由です-ここで非常に少ないブロックを使用することにより、不良ディスクブロックの確率を下げます。

/usr/sbinバイナリは、少なくともシングルユーザーモードに移行してすべてのボリュームをマウントできる一般的なsysadminツールです。動的にリンクすることが許可されています。

/ sbin（まあ、/ partitionの/ sbin）と/ usrの個別のパーティションは、バックアップが時間とテープの両方で非常に高価であることを覚えているときにもより意味があります。それらが別々のパーティションにある場合、それらを別々にスケジュールできます。

/usr/localネットワークファイルシステムにすることができます。そのため、多くのマシンで共有できるローカルで作成されたsysadminツールは、/ usr / local / sbinに移動することがあります。明らかに、ネットワーク修正ユーティリティはそこに行くことができません。

繰り返しになりますが、複数のボリュームを持つ管理対象マシンのネットワーク環境の大きなマシンでは、単一のルートパーティションに1台のLinuxマシンを使用するよりも、多くのことが意味をなします。

スーパーユーザーでの2番目の質問は、ここで別の質問にしてください。最初とは無関係です。

はい、あちこちにファイルがあるのは面倒です。それが多くのパッケージングソリューションがある理由です。RedHatは、あらゆる場所で使用されるRPMを作成しました。Solarisにはパッケージ形式がありました。HP / UXにはそれらがあり、aptや他の多くのパッケージ形式があります。必要に応じて適切な場所（/ usr / bin、/ usr / lib）に保管しますが、簡単に追加および削除できます。

ソースについては、以前は/ usr / localのサブディレクトリに構成およびインストールできるツールがあり、/ usr / local / binへのシンボリックリンクを処理していました。パッケージツールが広く普及しているため、これはあまり必要ではなく、名前を忘れました。

一部の人々は、/ opt / packagenameにインストールして、すべてをそこにまとめておきたいと考えています。良い点：すべてが1つのディレクトリにあり、アンインストールがrm -rf /opt/packagename。これのマイナス面は、全員のPATHに/ opt / packagename / binを追加する必要があることと、人々が通常/ optを別のパーティションに配置せず、ルートパーティションをいっぱいにすることです。

（Debian GNU Linuxの経験から）ディレクトリの意味に関する私の見解は次のとおりです。

最初の区別：sスーパーユーザー向け

s前binのディレクトリには、通常、管理者にのみ有用なツールが含まれていることを示しています。たとえばifconfig、このカテゴリにも属しているためifconfig、通常のユーザーとして呼び出して（IPアドレス/ネットワーク接続を取得したかどうかを確認する）、この区別は見かけほど難しくありません。

2番目の区別：local「ローカルデータ」用

実際には、ここで最も重要な違いは、OSパッケージマネージャー（APTなど）がパッケージを通常の/usr構造にインストールし、/usr/local影響を受けないことです。これにより、ローカルにコンパイルされたパッケージまたはシステム管理者から提供された社内スクリプト/usr/localを、適切にパッケージ化されたファイルに干渉しない場所に配置できます。

/usr/local通常の/usr構造の既存のファイルをオーバーライドするかどうかは議論の余地があります。PATHで/ usr / local / binを/ usr / binの前に置くのは危険ですか？を参照してください。これに関するいくつかの詳細について。

3番目の区別：トップレベル/binと/sbinディレクトリ。

Debianには、実際にはいわゆるUsrMergeがあります。そこの違いにするために使用/binし、/sbinそれ以前のブートプロセスで使用可能であった（と思う/usrRAIDなど、ネットワークデバイスまたは別のパーティション上にある）が、いくつかのLinuxシステムがなくても起動nowdays /usr私はトップとの違いを検討する理由ではありますレベルと/usrディレクトリは、主にLinuxの歴史的な関心事です。

最後に：「散乱」ファイルのメリットと問題。

これに対する「1つの真実」の答えは本当にありません。Linuxの分散ファイルシステムの利点は次のとおりです。

• すべてのバイナリはいくつかのディレクトリにあります。つまり、シェルからすべてのプログラムを呼び出すことができます。対象の%PATH%プログラムを追加するために常に環境変数を編集する必要があるWindowsを比較してください。Windowsで非常に長いパス環境を見てきました。

• すべてのライブラリは中央の場所にあります。つまり、複数のアプリケーションで使用する場合、2回インストールする必要はありません。

• Linuxはほとんどのシステムファイルがパッケージマネージャーによって追跡されるように設計されているため、ユーザーの観点からファイルの概要を保持する必要はありません。

• FHSの標準化により、ドキュメントも中心的な場所に置かれman、infoなどのシステムやサポートREADMEファイルが期待どおりに機能するようになります。

• 固定された場所にインストールされているプログラムに依存する方が簡単です。誰も#!/bin/sh -eがスクリプトの最初に書いたり、似たようなものを書いたりしますが、それはうまくいきます。シェルが別のディレクトリに移動するシステムを考えてみましょう。どのような名前になるかをどのように知るのでしょうか？興味がある場合は、WindowsにPerlまたはLaTeXをインストールするさまざまな方法を調べて、これがどれほど複雑になるかを確認してください...

私がこれまでに発見した欠点は次のとおりです。

• 通常、「Windows用のポータブルアプリケーション」の意味で、アプリケーションを「ポータブルに」実行するのは困難です。Linuxでは、プログラムを別のコンピューターにコピーするだけでは簡単ではありません...パッケージ（ルート権限が必要）を持っLD_LIBRARY_PATHているか、アプリケーションが必要なライブラリの異なる検索パスを指すように対処する必要があります。

• 同じプログラムの複数のバージョンをインストールすることを明示的にサポートする必要がありますが、「プログラムごとに1つのディレクトリ」があるシステムでは、これは問題の少ない場合が多いです。

• パッケージマネージャーを使用せずにファイルを管理すると、エラーが発生しやすくなります（既に説明したとおり）。

2番目の質問に答えるには、
通常、プログラムはいわゆるパッケージマネージャーで配布されます。通常、パッケージマネージャーは、バイナリパッケージ（特定のプラットフォーム用にコンパイルされたソフトウェア）を取得し、ディレクトリに放り込みます（ソースコードをダウンロードし、マシンでコンパイルしてインストールする人がいます）。したがって、パッケージマネージャーは、特定の「プログラム」（パッケージ）に属するファイルの場所を認識し、パッケージを削除するときに、パッケージマネージャーがすべてをクリーンアップします。
独自にソースコードをコンパイルする場合でも

make

そしてそれをインストールします

make install

あなたは通常できる

make uninstall

ファイルシステムからファイルを削除します。