Каково обоснование для каталога `/ usr`?

Каково обоснование для "системных ресурсов unix", или /usrкаталога, как описано здесь , который дублирует многие имена каталогов в корневом каталоге /?

Моя цель: я в очередной раз устанавливаю Oracle JDK и решил на этот раз просто поставить его, /home/userи я просто немного читаю, чтобы увидеть, является ли это плохой идеей на однопользовательской машине.

Есть короткая версия и длинная версия вашего ответа ...

Укороченная версия:

Как ваша ссылка уже сказала, /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, хотя по логике это должно) , и ни один пользователь не вынужден следовать ему, но оба получают много преимуществ взаимодействия, если они делают.

Надеюсь, это поможет немного прояснить ситуацию. Не стесняйтесь спрашивать что-нибудь, чтобы я мог улучшить ответ!

(и я также надеюсь, что пуристы не убьют меня за такой крайне неформальный язык и объяснения. Это было сделано намеренно, и в нем наверняка есть много неточностей, но я верю, что это хороший способ дать новичку краткое представление об установке справочники обоснования)