Есть короткая версия и длинная версия вашего ответа ...
Укороченная версия:
Как ваша ссылка уже сказала, /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
стало тесно связано с системными каталогами, смешанными с пользовательскими каталогами. Так /home
родился, чтобы сохранить все пользовательские каталоги и содержать в /usr
чистоте только системные "вещи".
Это было задолго до появления FHS. Когда он был создан, он принял (и формализовал) текущую традицию и сохранил название /usr
, хотя в то время он уже не имел ничего общего с «пользователем». Так что да, причудливые названия « U NIX сек сходный код г epository» или « U NIX сек ystem г ЕСУРСЫ» все выдуманные имена, и это слишком поздно , чтобы переименовать его в любом случае. (но не поздно слиться /bin
с ним)
"Хорошо, а что /usr/sbin
?" , ты спрашиваешь. Черт, я надеялся, что ты забыл. Ok ... /usr/sbin
для команд, которые могут быть (или имеют смысл только) исполняться root
пользователем, например, mount
и fdisk
.
"Но разве это не то же самое, что и /bin
?" , Да, конечно, но ...
«Подождите, тогда почему это /sbin
тоже? Не имеет никакого смысла!» , Ну, это из-за ... эээ ... хм ...
Смотри, трехглавая обезьяна позади тебя!
Хорошо, надеюсь, вы достаточно отвлеклись. Двигаясь дальше ...
(если вы думаете, что я обманываю, да, вы правы. Но таков и «официальный» ответ: «Основные команды, которые могут быть выполнены только пользователем root и должны быть доступны до того, как вы даже смонтируете /
»). Правда в том, что линия действительно размыта, и есть много устаревших имен, которые просто «застряли», и теперь от них довольно сложно избавиться.
Подробнее о деле для /usr
слияния , из systemd
документов:
Историческое обоснование для / bin, / sbin и / lib отдельно от / usr больше не применяется сегодня. Они были разделены, чтобы выбрать инструменты на более быстром жестком диске (который был маленьким, потому что он был более дорогим) и содержать все инструменты, необходимые для монтирования более медленного раздела / usr. Сегодня, отдельный / USR раздел уже должен быть установлен с помощью initramfs в начале загрузки, таким образом, делая основание для того, отщепленной тоо. Кроме того, многие инструменты в / bin и / sbin в статус-кво уже потеряли способность работать без предварительно смонтированного / usr. Больше нет веской причины для распространения операционной системы по нескольким иерархиям, она утратила свое предназначение.
И удивительное чтение /usr
Роба Лэндли о расколе и его обосновании:
Понимание bin, sbin, usr / bin, usr / sbin split
В наше время
В настоящее время, что касается установки каталогов, ваш лучший способ понять это думать так:
/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
Программное обеспечение, установленное операционной системой или через менеджеры пакетов (например, Центр программного обеспечения), и, что наиболее важно, какие локальные изменения могут быть перезаписаны, когда менеджер обновлений обновляет их до новой версии ? Это идет к/usr
Примечания:
Это объясняет, почему префикс установки по умолчанию для скомпилированного программного обеспечения /usr/local
и почему вы должны изменить его на ./configure --prefix=$HOME/.local
установку программного обеспечения только для вашего собственного пользователя
Возможно, вы заметили, что все вышеперечисленные каталоги доступны только для чтения (кроме, конечно, при установке / удалении программного обеспечения). Записываемые файлы (например, файлы конфигурации) обычно идут /etc
(для общесистемного программного обеспечения) и ~/.config
(для пользовательских настроек). Хотя многие устаревшие программы (и, к сожалению, некоторые современные тоже) используют ~/.<software-name>
, загромождают домашнюю папку миллиардами папок и файлов.
~/.local
и ~/.config
не являются частью спецификации FHS. FHS не имеет дело с домашней папкой пользователя. Это попытка XDG, другой стандартной организации, ориентированной на среды рабочего стола (например, Gnome, KDE и Unity), попытаться установить некоторые соглашения, касающиеся структуры дома пользователя. Не все программное обеспечение придерживается его (например, ~/.local/bin
это не по умолчанию пользователя $PATH
, хотя по логике это должно) , и ни один пользователь не вынужден следовать ему, но оба получают много преимуществ взаимодействия, если они делают.
Надеюсь, это поможет немного прояснить ситуацию. Не стесняйтесь спрашивать что-нибудь, чтобы я мог улучшить ответ!
(и я также надеюсь, что пуристы не убьют меня за такой крайне неформальный язык и объяснения. Это было сделано намеренно, и в нем наверняка есть много неточностей, но я верю, что это хороший способ дать новичку краткое представление об установке справочники обоснования)