Istnieje krótka wersja i długa wersja twojej odpowiedzi ...
Krótka wersja:
Jako swój link już wspomniano, /usrjest to miejsce dla całego systemu , tylko do odczytu plików. Wszystkie zainstalowane oprogramowanie jest tam. To nie powielać żadnych nazwisk /z wyjątkiem /bina /lib, ale początkowo z innym celu: /bin, /libjest tylko dla binariów i bibliotek potrzebny do uruchomienia , a /usr/bin, /usr/libto dla wszystkich innych plików wykonywalnych i bibliotek. (teraz bądź dobrym chłopcem i nie pytaj o /sbinto, w końcu to krótka wersja)
W dzisiejszych czasach rozróżnienie między „wymaganym do rozruchu” a nie zniknęło, ponieważ większość współczesnych dystrybucji, w tym Ubuntu, nie może poprawnie uruchomić się bez kilku plików /usr. I dlatego następuje silny ruch w kierunku łączenia się, /usr/bini /binprawdopodobnie w niedalekiej przyszłości (być może Ubuntu 12.10?) /binBędzie dowiązaniem symbolicznym /usr/bin.
Ale może jesteś zagubiony /usri /usr/local? Ponieważ tak, istnieje (i powinno być) wiele zduplikowanych nazw katalogów. Więcej o tym później ...
Długa wersja:
W latach 70., w Uniksie (tak, Unix, dużo wcześniej niż Linux), dyskietki miały mało miejsca (brak HD, pamiętasz?), Aw pewnym momencie liczba plików binarnych systemu wzrosła do tego stopnia, że nie zmieściłyby się na jednym dysku, a programiści musieli podzielić je na kilka nośników, a tym samym stworzyć dla nich nowe punkty montowania. /binsystem plików był pełny, więc one zainstalowane nowe pliki binarne w ... /usr/bin. I /usrbył w tym czasie ich ... katalogiem użytkowników !
Po tym, jak nastąpił rozłam (prawie zawstydzający i często opowiadany jako żart / wiedza), zaczęli oni tworzyć „sztuczne” uzasadnienia (i kryteria), aby zdecydować, do kogo pójdzie /bini do czego /usr/bin. Nieformalna zasada brzmiała: „niezbędne” rzeczy idą do /bin, „reszta” idzie do /usr/bin. To samo z /lib. Niedługo potem /usrzapełniły się katalogi związane z systemem, zmieszane z katalogami użytkowników. Tak /homenarodziło się, aby zachować wszystkie katalogi użytkownika i zachować /usrczystość tylko dla „rzeczy” systemowych.
To było na długo przed istnieniem FHS. Kiedy został stworzony, obejmował (i sformalizował) obecną tradycję i zachował nazwę /usr, chociaż w tym czasie nie miał już nic wspólnego z „użytkownikiem”. Więc tak, fantazyjne nazwy „ U NIX s ródło r epository” lub „ U NIX s ystem R esources” są wszystkie nazwy gotowe, a to zbyt późno, aby zmienić jego nazwę tak. (ale nie za późno, aby się /binz nim połączyć )
„Ok, a co /usr/sbin?” , ty pytasz. Cholera, miałem nadzieję, że zapomniałeś. Ok ... /usr/sbindotyczy poleceń, które mogą być (lub mają znaczenie tylko wtedy, gdy) wykonywane przez rootużytkownika, takie jak mounti fdisk.
„Ale czy to nie prawie to samo, co /bin?” . Tak, jasne, ale ...
„Zaczekaj, więc dlaczego też istnieje /sbin? To nie ma sensu!” . Cóż, to z powodu… eee… humm…
Spójrz, trójgłowa małpa za tobą!
Ok, mam nadzieję, że byłeś wystarczająco rozproszony. Iść dalej...
(jeśli uważasz, że oszukuję, tak, masz rację. Ale tak samo jest z „oficjalną” odpowiedzią) niezbędnymi poleceniami, które można wykonać tylko przez rootowanie i muszą być dostępne, zanim jeszcze się zamontujesz /”. Prawda jest taka: linia jest rzeczywiście rozmyta i istnieje wiele starszych nazw, które po prostu „utknęły”, a teraz trudno jest się ich pozbyć.
Więcej o sprawie dotyczącej /usrscalenia , z systemddokumentów:
Historyczne uzasadnienie oddzielenia / bin, / sbin i / lib od / usr nie ma już dziś zastosowania. Zostali rozdzieleni, aby wybrać narzędzia na szybszym dysku twardym (który był mały, ponieważ był droższy) i zawierać wszystkie narzędzia niezbędne do zamontowania wolniejszej partycji / usr. Dzisiaj osobna partycja / usr musi już zostać zamontowana przez initramfs podczas wczesnego rozruchu, co uzasadnia oddzielną dyskusję. Ponadto wiele narzędzi w / bin i / sbin w status quo straciło już możliwość uruchamiania bez wstępnie zamontowanego / usr. Nie ma już żadnego uzasadnionego powodu, aby system operacyjny rozłożyć na wiele hierarchii, stracił on swój cel.
I niesamowita lektura /usrRoba Landleya na temat podziału i jego uzasadnienia:
Zrozumienie podziału bin, sbin, usr / bin, usr / sbin split
dzisiaj
Jeśli chodzi o katalogi instalacyjne, najlepszym sposobem na zrozumienie tego jest myślenie w ten sposób:
/usr - wszystkie ogólnosystemowe pliki tylko do odczytu instalowane przez (lub dostarczane) przez system operacyjny
/usr/local- ogólnosystemowe pliki tylko do odczytu instalowane przez lokalnego administratora (zwykle ty). I dlatego większość nazw katalogów /usrjest tutaj zduplikowana.
/opt- okrucieństwo przeznaczone dla ogólnosystemowego, tylko do odczytu i samodzielnego oprogramowania. Oznacza to, że oprogramowanie, które nie dzieli swoje pliki na bin, lib, share, includejak grzeczne oprogramowanie powinno.
~/.local- odpowiednik na użytkownika /usr/local, to znaczy: oprogramowanie instalowane przez (i dla) każdego użytkownika
~/.local/opt - odpowiednik na użytkownika dla /opt
Gdzie więc zainstalować oprogramowanie?
Powyższa lista stanowi już połowę odpowiedzi na twoje pytanie Oracle JDK, przynajmniej daje kilka wskazówek. Lista kontrolna do „Gdzie mam zainstalować oprogramowanie X?” przechodzi przez:
Czy jest to całkowicie samodzielne oprogramowanie z jednym katalogiem, takie jak Eclipse IDE i inne pobrane aplikacje Java, i chcesz, aby było ono dostępne dla wszystkich użytkowników? Następnie zainstaluj/opt
Tak jak powyżej, ale nie obchodzą Cię inni użytkownicy, a ja chcę zainstalować tylko dla tego użytkownika? Następnie zainstaluj~/.local/opt
Jego pliki są podzielone na wiele katalogów, takich jak bini share, podobnie jak tradycyjne oprogramowanie skompilowane i zainstalowane ./configure && make && sudo make install, i czy powinny być dostępne dla wszystkich użytkowników? Następnie zainstaluj/usr/local
Tak jak powyżej, ale tylko dla twojego użytkownika? Następnie zainstaluj~/.local
Oprogramowanie instalowane przez system operacyjny lub za pośrednictwem menedżerów pakietów (takich jak Software Center), a co najważniejsze, które modyfikacje lokalne mogą zostać zastąpione, gdy menedżer aktualizacji uaktualni je do nowej wersji ? To idzie do/usr
Uwagi:
To wyjaśnia, dlaczego jest domyślny prefiks instalacji skompilowanego oprogramowania /usr/locali dlaczego należy go zmienić na ./configure --prefix=$HOME/.localpodczas instalowania oprogramowania tylko dla własnego użytkownika
Być może zauważyłeś, że wszystkie powyższe katalogi są tylko do odczytu (z wyjątkiem, oczywiście, podczas instalowania / usuwania oprogramowania). Zapisywalne pliki (takie jak pliki konfiguracyjne) zwykle przechodzą do /etc(w przypadku oprogramowania systemowego) i ~/.config(w przypadku ustawień poszczególnych użytkowników). Chociaż korzysta z niego wiele starszych programów (i, niestety, niektóre nowoczesne) ~/.<software-name>, zaśmiecają folder domowy miliardami katalogów i plików.
~/.locali ~/.confignie są częścią specyfikacji FHS. FHS nie zajmuje się folderem domowym użytkownika. Są próbą XDG, kolejnej standardowej organizacji ukierunkowanej na środowiska pulpitu (takie jak Gnome, KDE i Unity), aby spróbować ustalić pewne konwencje dotyczące struktury domu użytkownika. Nie wszystkie programy przestrzegają go (na przykład ~/.local/binnie ma go w ustawieniach domyślnych użytkownika $PATH, a logika powinna to robić ) i żaden użytkownik nie jest zmuszony do jego przestrzegania, ale obaj zyskują wiele korzyści interoperacyjnych, jeśli to zrobią.
Mam nadzieję, że to pomoże trochę wyjaśnić. Nie wahaj się pytać o nic, więc mogę poprawić odpowiedź!
(i mam również nadzieję, że puryści nie zabiją mnie za tak niezwykle nieformalny język i wyjaśnienia. Było to celowe i na pewno ma wiele nieścisłości, ale uważam, że to dobry sposób, aby nowicjusz miał krótki przegląd zrozumienia instalacji katalogi racjonalne)