Windowsでは、特に古いバージョンでは、プログラムが構成ファイルと非定数データをC:\Program Filesディレクトリに格納するのが一般的でした。これは、プログラムが通常インストールされ、シングルユーザー、ネットワーク、ファイル権限のないDOSの下で実行された方法に由来します。
セキュリティの観点から、これは悪い考えです。実行可能コードが存在する場所は、変更可能なデータから分離する必要があります。そうすれば、適切なファイル権限を適用して、許可されていないユーザーによるインストール済みバイナリの変更を防ぐのが簡単になります。同様に、メインの実行可能ファイルとは別に更新できるライブラリディレクトリも、別のディレクトリにある必要があります。
VistaとUACの煩わしさの出現により、この伝統はついに深刻な牽引力を失い始めています。
UNIXとLinuxは、以前からマルチユーザーシステムであり、インストールされたバイナリをroot以外のユーザーが変更できないようにする必要があったため、実行可能ディレクトリを他のディレクトリから分離する傾向がありました。これも理由で/usrあり、場合/sbinによっては個別のパーティションです。特にセキュリティを意識した管理者は、これらのパーティションを読み取り専用でマウントし、インストール/アンインストールが必要になったときに読み取り/書き込みで再マウントできます。
パッケージは通常、パッケージマネージャーからインストールされます。aptitude(Debianと派生ディストリビューション)、yum(Redhatと派生ディストリビューション)、pacman(どのディストリビューションかを忘れて...)など、さまざまなパッケージマネージャーがあります。
パッケージマネージャーを使用すると、洗練された(無料の)「アプリストア」のように、リポジトリの参照、ソフトウェアのダウンロード、インストール、クエリ、および削除を行うことができます。依存関係が確実に処理され、現在インストールされているものを追跡する責任があります。
通常、パッケージマネージャーは、リポジトリの外で手動でダウンロードしたパッケージに対しても同じ操作を許可します。自分で作成またはコンパイルしたソフトウェアから独自のツールを作成する場合も、ツールを利用できます。
パッケージ自体は実行可能ファイルではないので、信頼できる実行可能ファイルを実行する必要はありません。この実行可能ファイルは、何をしているのか本当にわかりません。(Windowsのは最終的に配布することでアップデートして周りに来ている.msu「の代わりにSを.exeS」 -しかし.msiさんは...しばらくの周りされています)
rpm、を使用rpm -q --whatprovidesして特定のファイルのパッケージ名rpm -q -aを見つけ、パッケージがインストールしたファイルを見つけることができます。