Jeśli zainstaluję aplikację w systemie Linux, na przykład Debian / Gnu Linux, pliki aplikacji zostaną skopiowane do wielu różnych katalogów w systemie plików.
Niektóre skrypty przechodzą do / usr / share .. / usr / local, a niektóre inne pliki do / var .. / log .. etc / i tak dalej.
Dla mnie jest to w porządku, ponieważ dowiedziałem się czegoś o systemie plików, a większość katalogów zawiera pliki do określonego celu. To pasuje bardzo do filozofii uniksowej: „zrób jedną rzecz i zrób to dobrze”
Ale moje pytanie brzmi: jakie są zalety takiej struktury katalogów? A może jest to po prostu dziedzictwo dawnych dni uniksowych. (np. w porównaniu z jednym oknem, w którym wszystkie pliki aplikacji znajdują się w jednym „folderze”)
linux
filesystems
directory
directory-structure
Jan Koester
źródło
źródło
/bin,/etcz/.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ść.
źródło
Podstawową korzyścią niewymienioną powyżej i jednym z historycznych powodów tej struktury jest fizyczna separacja na wielu woluminach / dyskach dostępnych na różnych etapach procesu rozruchu.
Kolejną zaletą jest to, że różne katalogi mogą być montowane na woluminach / systemach plików zoptymalizowanych pod kątem danych katalogu. Na przykład
tmpfsdla/run; i/sbinna nośniku / ROM tylko do odczytu.Woluminy mogą być także lokalne lub zdalne, osobiste lub współdzielone.
Na koniec zobacz katalog aplikacji dla alternatywnego podejścia (wspomnianego przez @fluffy) używanego w systemach UNIX (OS X
.app), Linux ( ROX Desktop ) i Windows ( PortableApps.com ).źródło
Tak naprawdę nie ma żadnych zalet tego układu, poza tym łatwo zgadnąć, gdzie są udostępnione i pliki konfiguracyjne dla aplikacji. UNIX ma długą spuściznę tego rodzaju układu i złamanie go byłoby dość trudne. Jednak niektóre dystrybucje UNIX zmieniły swój model - podają tylko stare lokalizacje do starszych celów, a inne aplikacje są pakowane we własny mały katalog / pakiet. Mac OS X jest najbardziej znanym przykładem tego. Istnieje kilka niejasnych dystrybucji Linuksa, które robią to samo (a Android robi coś podobnego, tylko idzie nieco dalej i instaluje i uruchamia każdą aplikację pod własnym identyfikatorem użytkownika ).
Najważniejszą rzeczą, jaką zapewnia konwencja systemu plików, jest właśnie taka - konwencja, aby ludzie wiedzieli, gdzie szukać plików (czy to ręcznie, czy w kodzie). Nie ma żadnego rzeczywistego technicznego powodu, aby był jeden na drugim.
źródło