if ($answer_counter == 1): ?>
endif; ?>
Есть короткая версия и длинная версия вашего ответа ...
Краткая версия:
Как уже говорилось в вашей ссылке, /usr
- это место для общесистемных , файлов только для чтения . Итак, все ваше установленное программное обеспечение идет туда. Он не дублирует имена /
, кроме /bin
и /lib
, но изначально с другой целью: /bin, /lib
- только для двоичных файлов и библиотек , необходимых для загрузки , в то время как /usr/bin, /usr/lib
для всех остальных исполняемых файлов и библиотек. (теперь будьте хорошим мальчиком и не спрашивайте о /sbin
, это короткая версия)
В настоящее время различие между «необходимым для загрузки» уменьшилось, поскольку большинство современных дистрибутивов, включая Ubuntu, не могут правильно загрузиться без нескольких файлов из /usr
. И поэтому существует сильное движение к объединению /usr/bin
и /bin
, поэтому, вероятно, в ближайшем будущем (возможно, Ubuntu 12.10?)% Co_de% будет символической ссылкой на /bin
.
Но может быть, вы путаете /usr/bin
и /usr
? Потому что да, существует (и должно быть) lot дублированных имен каталогов. Подробнее об этом позже ...
Длинная версия:
В 70-х годах, в Unix (да, Unix, путь до Linux), у флоппи было мало места (нет HD, помните?), и в данной точке системные двоичные файлы выросли слишком много по количеству и размеру до точки они не подходили бы ни одному диску, и разработчикам приходилось разделить их на нескольких носителях и тем самым создать для них новые точки монтирования. Файловая система /usr/local
была заполнена, поэтому они установили новые двоичные файлы в ... /bin
. И /usr/bin
были в то время их ... пользовательским каталогом!
После того, как произошло (почти смущающее и часто упоминаемое как шутка / знания), они начали создавать «искусственные» обоснования (и критерии), чтобы решить, что будет идти в /usr
и что будет идти в /bin
. Неофициальное правило состояло в следующем: «существенный» материал перешел на /usr/bin
, «остальное» - на /bin
. То же самое с /usr/bin
. Незадолго до того, как /lib
переполнилось системными дисками, смешанными с пользователями. Таким образом, /usr
родилось, чтобы сохранить все связанные с пользователем dirs и сохранить /home
clean только для системного «материала».
Это было задолго до того, как существует FHS. Когда он был создан, он принял (и формализовал) текущую традицию и сохранил имя /usr
, хотя в то время он уже не имел никакого отношения к «пользователю». Итак, да, причудливые имена « U NIX s наш r epository" или " U NIX s ystem r esources "- это все созданные имена, и слишком поздно переименовывать его. (но не слишком поздно, чтобы слить /usr
к нему)
«Хорошо, как насчет /bin
?» , спросите вы. Черт, я надеялся, что ты забыл. Ok ... /usr/sbin
- это команды, которые могут быть (или только значимы) когда-либо выполняются пользователем /usr/sbin
, например root
и mount
. Р>
«Но это не так, как fdisk
?» . Да, конечно, но ...
«Подождите, тогда почему есть /bin
тоже? Не имеет смысла!» . Ну, это из-за ... err .. humm ..
Посмотрите, обезьяна с тремя головами за вами!
Хорошо, надеюсь, вы достаточно отвлеклись. Двигаемся дальше ...
(если вы думаете, что я обманываю, да, вы правы. Но так же «официальный» ответ «основные команды, которые могут выполняться только root, и должны быть доступны до того, как вы установите mount co_de % "). Правда заключается в том, что линия действительно размыта, и существует много устаревших имен, которые просто «застревают», и теперь довольно сложно избавиться.
Подробнее о примере для /sbin
merge , из /
docs: р>
Историческое обоснование для / bin, / sbin и / lib отдельно от / usr больше не применяется сегодня. Они были разделены на выбранные инструменты на более быстром жестком диске (который был небольшим, потому что он был дороже) и содержал все инструменты, необходимые для монтирования более медленного раздела / usr. Сегодня отдельный раздел / usr уже должен быть установлен initramfs во время ранней загрузки, тем самым делая оправдание для расщепления. Кроме того, многие инструменты в / bin и / sbin в статус-кво уже потеряли возможность запуска без предварительно установленного / usr. Нет никакой веской причины, чтобы операционная система распространялась по нескольким иерархиям, она потеряла свою цель.
И потрясающее чтение о рассогласовании /usr
и его обосновании Робом Ландли:
Понимание bin, sbin, usr / bin, usr / sbin split
В настоящее время
В настоящее время, касаясь установочных каталогов, ваш лучший способ понять - подумать так:
-
systemd
- все общесистемные, доступные только для чтения файлы, установленные (или предоставляемые) ОС
-
/usr
- общесистемные, доступные только для чтения файлы, установленные локальным администратором (обычно, вы). И вот почему большинство имен каталогов из /usr
дублируются здесь.
-
/usr/local
- зверство, предназначенное для системного, только для чтения и автономного программного обеспечения . То есть, программное обеспечение, которое не разбивает файлы на /usr
, /opt
, bin
, lib
, например, на хорошо выполненное программное обеспечение.
-
share
- сопоставление между пользователями include
, то есть: программное обеспечение, установленное (и для) каждого пользователя
-
~/.local
- сопоставление для каждого пользователя /usr/local
Итак, где установить программное обеспечение?
Приведенный выше список уже является половиной ответа на ваш вопрос Oracle JDK, по крайней мере, он дает несколько подсказок. Контрольный список «Где я должен установить программное обеспечение X?» :
-
Является ли это полностью автономным программным обеспечением с одним каталогом, например Eclipse IDE и другими загруженными java-приложениями, и вы хотите, чтобы он был доступен для всех пользователей? Затем установите в ~/.local/opt
-
То же, что и выше, но вас не интересуют другие пользователи, и я хочу установить для своего пользователя в покое? Затем установите в /opt
-
Его файлы разделены на несколько серверов, например /opt
и ~/.local/opt
, как традиционное программное обеспечение, скомпилированное и установленное с bin
, и должны быть доступны для всех пользователей? Затем установите в share
-
То же, что и выше, но только для вашего пользователя? Затем установите в ./configure && make && sudo make install
-
Программное обеспечение, установленное ОС или менеджерами пакетов (например, Software Center) и, что наиболее важно, , которое может быть перезаписано любой локальной модификацией, когда менеджер обновлений обновит его до новой версии ? Он переходит в /usr/local
Примечания:
-
Это объясняет, почему префикс установки по умолчанию для скомпилированного программного обеспечения - ~/.local
, и почему вы должны изменить его на /usr
при установке программного обеспечения только для собственного пользователя
-
Возможно, вы заметили, что все указанные выше каталоги только для чтения (за исключением, конечно, при установке / удалении программного обеспечения). Зарегистрированные файлы (например, файлы конфигурации) обычно идут в /usr/local
(для общесистемного программного обеспечения) и ./configure --prefix=$HOME/.local
(для пользовательских настроек). Хотя многие устаревшие программы (и, к сожалению, некоторые современные) используют /etc
, загромождают вашу домашнюю папку миллиардами файлов и файлов.
-
~/.config
и ~/.<software-name>
не входят в спецификацию FHS. FHS не занимается домашней папкой пользователя. Это попытка XDG, еще одной стандартной организации, ориентированной на среду рабочего стола (например, Gnome, KDE и Unity), чтобы попытаться установить некоторые соглашения о структуре дома пользователя. Не все программное обеспечение придерживается его (например, ~/.local
не имеет значения по умолчанию ~/.config
пользователя, а по логике оно должно) , и никто не вынужден следовать ему, но оба получают много если они это сделают.
Надеюсь, это поможет немного прояснить ситуацию. Не стесняйтесь спрашивать что-нибудь, чтобы я мог улучшить ответ!
(и я также надеюсь, что пуристы не убьют меня за такой крайне неформальный язык и объяснение. Это было намеренно, и у него наверняка много неточностей, но я считаю, что это хороший способ сделать новичок имеет краткий обзор понимания обоснований каталогов установки)