Bez względu na to, która organizacja zostanie wybrana, niektóre rzeczy będą łatwiejsze, a niektóre trudniejsze.
Organizuje pliki według typów, sposób Unix (język bin, man, lib/python, ...), sprawia, że jest łatwiejszy w obsłudze plików. Jeśli chcesz uruchomić polecenie, wiesz, gdzie je znaleźć, bez względu na to, który pakiet je udostępnia. Jeśli chcesz przeszukać dokumentację, wszystko jest w jednym miejscu. Jeśli jakiś program udostępnia moduł podświetlania składni Vima, funkcję uzupełniania zsh lub powiązania Pythona, odpowiedni plik będzie w miejscu, w którym vim / zsh / python może go znaleźć.
Unix organizuje również pliki według wzorców użytkowania. Wchodzą pliki konfiguracyjne, wchodzą /etcpliki, które nie zmieniają się podczas normalnej pracy /usr, i pliki, które zmieniają się automatycznie, wchodzą /var. Dane użytkownika idą w dół /home. Jest to bardzo przydatne do zarządzania konfiguracją (zarządzaj zawartością /etci listą zainstalowanych pakietów). Przydatne jest również zdefiniowanie strategii tworzenia kopii zapasowych: to, co jest /etci /homejest niezwykle ważne, a to, co jest, /usrmożna łatwo pobrać ponownie.
Głównym kosztem sposobu uniksowego jest to, że instalacja oprogramowania jest rozłożona na wiele katalogów. Jednak nowoczesne systemy unix i tak mają menedżerów pakietów; zarządzanie plikami w wielu katalogach nie jest zdecydowanie najbardziej złożoną czynnością (śledzenie zależności jest bardzo przydatne i trudniejsze).
Porównaj to z Windows. System Windows zaczął się bez zarządzania pakietami, a każda aplikacja gdzieś utworzyła własny katalog. Wszystkie pliki zwykle znajdowałyby się w tym katalogu: programy, dane statyczne, dane użytkownika… Z wyjątkiem bibliotek, które programy wpadałyby do wspólnego katalogu systemowego bez względu na konflikty („DLL hell”). Z czasem system Windows stał się wieloma użytkownikami, co wymagało oddzielenia katalogów użytkowników od katalogów systemowych. System Windows utworzył również centralne miejsce dla plików konfiguracyjnych (Unix /etc) i niektórych danych systemowych (Unix)/var), rejestr. Jest to raczej artefakt historyczny, głównie ze względu na brak zarządzania pakietami i wczesną historię systemu pojedynczego użytkownika. Podejście do systemu Windows ma wiele ograniczeń: nie pozwala na łatwą interakcję pakietów oprogramowania. Na przykład większość zainstalowanego oprogramowania nie kończy się na domyślnej ścieżce wyszukiwania poleceń, więc źle współpracuje z dowolną formą skryptów. Instalatorzy zazwyczaj zapewniają ikonę menu jako specjalny przypadek - upuszczany w osobnym katalogu systemowym (à la Unix!).
Ograniczeniem podejścia uniksowego jest to, że nie pozwala on łatwo na współistnienie wielu wersji pakietu, co jest szczególnie problematyczne podczas aktualizacji pakietu. Sposobem na uzyskanie najlepszego z obu światów byłoby rozpakowanie każdego pakietu we własnym katalogu ( /optstrukturze) i utworzenie lasów dowiązań symbolicznych z katalogów pakietów do /usrstruktury. To właśnie robi oprogramowanie takie jak stow .
Podsumowując, podejście uniksowe ułatwia korzystanie z plików, zarządzanie plikami i zezwalanie pakietom na interakcję; wymaga oprogramowania do zarządzania pakietami, ale i tak jest to pożądane. Podejście do systemu Windows ułatwia ręczne zarządzanie pakietami, ale musi skręcić w kierunku modelu uniksowego, aby uzyskać przydatną funkcjonalność.