Є коротка версія та довга версія вашої відповіді ...
Коротка версія:
Як ваша посилання вже сказала, /usrце місце для всієї системи , призначених тільки для читання файлів. Тому все встановлене програмне забезпечення йде туди. Вона не дублює будь-які імена , /крім /binі /lib, але, спочатку, з іншою метою: /bin, /libтільки для виконуваних файлів і бібліотек , необхідних для завантаження , в той час як /usr/bin, /usr/libдля всіх інших виконуваних файлів і бібліотек. (тепер будьте хорошим хлопчиком і не запитуйте про /sbinце, адже це коротка версія)
В даний час відмінність між "необхідним для завантаження" і не зменшилася, оскільки більшість сучасних дистрибутивів, включаючи Ubuntu, не можуть належним чином завантажуватися без декількох файлів з /usr. І тому існує сильний рух до злиття, /usr/binі /bin, можливо, найближчим часом (можливо, Ubuntu 12.10?) /binБуде символьним посиланням на /usr/bin.
Але, можливо, ви плутаєте /usrі /usr/local? Тому що так, існує (і повинно бути) багато дублюваних імен каталогів. Детальніше про це пізніше ...
Довга версія:
Ще в 70-х роках, в Unix (так, Unix, шлях до Linux), на дискетах було мало місця (немає HD, пам’ятаєте?), І в даний момент системні бінарні файли зросли занадто багато в кількості і розмірі, щоб вони не стали помістити один диск, і розробникам довелося розділити їх на кілька носіїв і таким чином створити для них нові точки монтажу. /binФайлова система була повною, тому вони встановили нові виконавчі файли на ... /usr/bin. І /usrбув, на той час, їхнім ... каталогом користувачів !
Після того, як відбувся розкол (майже бентежить і часто говорили як жарт / лора), вони почали створювати "штучні" обґрунтування (та критерії), щоб вирішити, на що піти /binі на що піти /usr/bin. Неофіційне правило було таке: "важливі" речі йдуть /bin, "решта" йде /usr/bin. Те саме з /lib. Невдовзі /usrпереповнилося системою, що стосується системи, змішаною із користувачем-dir. Таким чином /homeнародився, щоб зберегти всі пов'язані з користувачем грязі та зберегти /usrчистоту лише для системних "речей".
Це було задовго до існування FHS. Коли він був створений, він прийняв (і формалізував) сучасну традицію і зберіг назву /usr, хоча на той час вона вже не мала нічого спільного з "користувачем". Так що так, химерні назви « U NIX сек жерело г epository» або « U NIX сек ystem г ЕСУРСИ» все вигадані імена, і це занадто пізно , щоб перейменувати його в будь-якому випадку. (але не пізно для злиття /binз ним)
"Гаразд, про що /usr/sbin?" , Ви запитаєте. Чорт, я сподівався, що ти забув. Ок ... /usr/sbinпризначено для команд, які можуть бути (або мають значення лише тоді, коли) виконуються rootкористувачем, як mountі fdisk.
"Але хіба це майже не так, як /bin?" . Так, звичайно, але ...
"Зачекайте, тоді чому це /sbinтеж є? Не має сенсу!" . Ну, це через ... помилку ... гул ..
Подивіться, 3-голова мавпа позаду вас!
Добре, сподіваємось, ви досить відволіклися. Жити далі...
(якщо ви думаєте, що я обманюю, так, ви маєте рацію. Але так само є "офіційна" відповідь "основних команд, які можуть бути виконані лише корінцями і повинні бути доступні, перш ніж ви навіть змонтуєте /"). Правда полягає в тому, що лінія дійсно розмита, і є маса застарілих імен, які просто "застрягли" і тепер цього досить важко позбутися.
Детальніше про справу про /usrзлиття , від systemddocs:
Історичне виправдання для / bin, / sbin та / lib, окремо від / usr, сьогодні вже не застосовується. Вони були розділені, щоб обрати інструменти на більш швидкому жорсткому диску (який був невеликим, оскільки він був дорожчим) та містити всі інструменти, необхідні для монтажу повільнішого / usr-розділу. Сьогодні окремий розділ / usr вже повинен бути змонтований інітрамфами під час раннього завантаження, таким чином, виправдовуючи роздільний спор. Крім того, багато інструментів в / bin та / sbin в статусі вже втратили можливість працювати без попередньо встановленого / usr. Більше немає поважних причин для того, щоб операційна система поширилася на кілька ієрархій, вона втратила своє призначення.
І дивовижне читання про /usrрозкол та його обгрунтування, Роб Лендлі:
Розуміння bin, sbin, usr / bin, usr / sbin розділено
У наш час
Наразі, що стосується встановлення каталогів, ваш найкращий спосіб зрозуміти - це мислити так:
/usr - всі загальносистемні файли, доступні лише для читання, встановлені (або надані) ОС
/usr/local- загальносистемні файли, доступні лише для читання, встановлені місцевим адміністратором (як правило, ви). І тому тут більшість імен каталогів /usrдублюються.
/opt- злодіяння , призначене для загальносистемного, тільки для читання і автономного програмного забезпечення. Тобто програмне забезпечення , яке не розщеплюється свої файли через bin, lib, share, includeяк добре себе програмне забезпечення має.
~/.local- аналог на кожного користувача /usr/local, тобто програмне забезпечення, встановлене (і для) кожного користувача
~/.local/opt - аналог кожного користувача /opt
То де встановити програмне забезпечення?
Наведений вище перелік є вже половиною відповіді на ваше запитання Oracle JDK, принаймні, він дає декілька підказок. Контрольний список "Де мені встановити програмне забезпечення X?" йде:
Це повністю автономне програмне забезпечення для єдиного каталогу, як Eclipse IDE та інші завантажені програми java, і ви хочете, щоб воно було доступне для всіх користувачів? Потім встановіть/opt
Як і вище, але вас не цікавлять інші користувачі, і я хочу встановити лише для вашого користувача? Потім встановіть~/.local/opt
Її файли розбиті на декілька режимів, як binі share, як традиційне програмне забезпечення, складене та встановлене разом із ним ./configure && make && sudo make install, і чи мають бути доступні всі користувачі? Потім встановіть/usr/local
Те саме, що вище, але лише для вашого користувача? Потім встановіть~/.local
Програмне забезпечення, встановлене ОС, або за допомогою менеджерів пакетів (наприклад, Software Center), і, головне, яку локальну модифікацію можна перезаписати, коли менеджер оновлень оновить її до нової версії ? Це іде до/usr
Примітки:
Це пояснює, чому є префікс встановлення за замовчуванням для скомпільованого програмного забезпечення /usr/localта чому слід змінювати його, ./configure --prefix=$HOME/.localколи встановлюється програмне забезпечення лише для власного користувача
Можливо, ви помітили, що всі наведені вище каталоги є лише для читання (за винятком, звичайно, під час встановлення / видалення програмного забезпечення). Записувані файли (як-от конфігураційні файли) зазвичай переходять у /etc(для загальносистемного програмного забезпечення) та ~/.config(для налаштувань для кожного користувача). Хоча багато застарілих програмних засобів (і, на жаль, деякі сучасні теж) використовують ~/.<software-name>, захаращуючи домашню папку мільярдами брудів та файлів.
~/.localі ~/.configне входять до специфікації FHS. FHS не займається домашньою папкою користувача. Вони є спробою XDG, іншої стандартної організації, орієнтованої на робочі середовища (наприклад, Gnome, KDE та Unity), спробувати встановити деякі умови щодо структури будинку користувача. Не все програмне забезпечення дотримується цього (наприклад, ~/.local/binце не за замовчуванням користувача $PATH, тоді як, за логікою, це повинно) , і жоден користувач не змушений дотримуватися цього, але обидва отримують багато переваг для сумісності, якщо вони є.
Я сподіваюся, що це допоможе трохи прояснити речі. Не соромтеся запитувати що-небудь, щоб я міг покращити відповідь!
(і я також сподіваюся, що пуристи не вб'ють мене за таку надзвичайно неофіційну мову та пояснення. Це було навмисно, і воно, безумовно, має багато неточностей, але я вважаю, що це хороший спосіб зробити новачком короткий огляд розуміння встановлення обгрунтування каталогів)