В чем обоснование каталога `/ usr`?

В чем обоснование «системных ресурсов unix» или каталога /usr , как описано здесь , что дублирует многие имена каталогов в корневом каталоге / ?

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

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

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

Как уже говорилось в вашей ссылке, /usr – это место для общесистемных файлов только для чтения . Итак, все ваше установленное программное обеспечение идет туда. Он не дублирует имена / except /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 s ource r epository» или « U NIX s ystem r esources» – это все созданные имена, и слишком поздно переименовывать их. (но не слишком поздно, чтобы объединить /bin )

«Хорошо, что насчет /usr/sbin , ты спрашиваешь. Черт, я надеялся, что ты забыл. Ok … /usr/sbin – это команды, которые могут быть (или имеют смысл только тогда), которые выполняются пользователем root , например mount и fdisk .

«Но разве это не так, как /bin , Да, конечно, но …

«Подождите, тогда почему есть /sbin тоже? Не имеет никакого смысла!» , Ну, это из-за … err .. humm ..

Послушай, трехглавая обезьяна!

Хорошо, надеюсь, вы достаточно отвлеклись. Двигаемся дальше …

(если вы думаете, что я обманываю, да, вы правы. Но так же «официальный» ответ «основные команды, которые могут выполняться только 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~/.local пользователь /usr/local , то есть: программное обеспечение, установленное (и для) каждого пользователя

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

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

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