W systemie Windows, szczególnie w starszych wersjach, programy do przechowywania plików konfiguracyjnych i nietrwałych danych często znajdowały się w ich C:\Program Fileskatalogu. Wynika to ze sposobu, w jaki programy były zwykle instalowane i uruchamiane w systemie DOS dla jednego użytkownika, nie podłączonego do sieci i bez uprawnień dostępu do plików.
Z punktu widzenia bezpieczeństwa jest to zły pomysł. Miejsca, w których funkcjonuje kod wykonywalny, powinny być oddzielone od modyfikowalnych danych. W ten sposób łatwiej jest zastosować odpowiednie uprawnienia do plików, aby zapobiec modyfikacji zainstalowanych plików binarnych przez nieautoryzowanych użytkowników. Podobnie katalogi bibliotek, które mogą być aktualizowane osobno od głównych plików wykonywalnych, również powinny znajdować się w osobnym katalogu.
Wraz z pojawieniem się irytujących systemów Vista i UAC ta tradycja w końcu zaczyna poważnie tracić przyczepność.
UNIX i Linux, będąc znacznie wcześniejszym systemem dla wielu użytkowników, miały tendencję do oddzielania katalogów wykonywalnych od innych katalogów znacznie wcześniej, ponieważ konieczne było uniemożliwienie użytkownikom innym niż root modyfikowania zainstalowanych plików binarnych. Jest to również powód, /usra nawet /sbinczasem oddzielne partycje - szczególnie świadomy bezpieczeństwa administrator może montować te partycje tylko do odczytu i ponownie montować je w trybie odczytu / zapisu, gdy trzeba zainstalować / odinstalować.
Pakiety są zwykle instalowane z menedżera pakietów. Istnieją różne menedżery pakietów, takie jak aptitude(Debian i dystrybucje pochodne), yum(Redhat i dystrybucje pochodne), pacman(zapomnij, która to dystrybucja to ...) i inne.
Menedżer pakietów pozwala przeglądać repozytoria, pobierać, instalować, wyszukiwać i usuwać oprogramowanie, podobnie jak wyrafinowany (i bezpłatny) „sklep z aplikacjami”. Przyjmuje odpowiedzialność za dbanie o zależności i śledzenie tego, co jest obecnie zainstalowane.
Zwykle menedżer pakietów zezwala również na te same operacje na pakiecie, który pobrałeś ręcznie poza repozytoriami. Narzędzia są również dostępne, jeśli chcesz tworzyć własne na podstawie oprogramowania, które sam stworzyłeś lub skompilowałeś.
Ponieważ sam pakiet NIE jest plikiem wykonywalnym, nie musisz uruchamiać niezaufanego pliku wykonywalnego, którego tak naprawdę nie wiesz, co on robi. (Windows wreszcie pojawia się z aktualizacjami, dystrybuując .msuzamiast zamiast .exe- ale .msijuż od jakiegoś czasu ...)
rpm, możesz użyć,rpm -q --whatprovidesaby znaleźć nazwę pakietu dla określonego pliku, a następnierpm -q -adowiedzieć się, jakie pliki zainstalował pakiet.