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

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

Существует короткая и длинная версия вашего ответа…

История

Короткая версия:

Как уже сказано в вашей ссылке, /usr — это место для системных, только для чтения файлов. Поэтому все программное обеспечение, установленное через пакеты системного репозитория, располагается там. Оно не дублирует никакие имена из /, кроме /bin и /lib, но изначально с другой целью: /bin и /lib предназначены только для двоичных файлов и библиотек, необходимых для загрузки, в то время как /usr/bin и /usr/lib — для всех остальных исполняемых файлов и библиотек. (и пожалуйста, не спрашивайте про /sbin, в конце концов, это же Короткая Версия)

В настоящее время различие между необходимыми и не необходимыми для загрузки сокращается, так как большинство современных дистрибутивов, включая Ubuntu, не могут правильно загрузиться без нескольких файлов из /usr. Вот почему существовало мощное движение к объединению /usr/bin и /bin. Начиная с Ubuntu 19.04 /bin, /lib (и /sbin) — это просто символические ссылки на их аналоги в /usr, и на некоторых системах они могут даже больше не существовать.

Но, может быть, вы путаете /usr и /usr/local? Потому что да, есть (и должно быть) много дублированных имен каталогов. Об этом позже…

Длинная версия:

Еще в 70-х в Unix (да, Unix, задолго до Linux) диски имели небольшой объем (еще не было жестких дисков!), и в определенный момент двоичные файлы системы выросли настолько по числу и размеру, что они не помещались на одном диске, и разработчики должны были распределить их по нескольким носителям и создать новые точки монтирования для них. Файловая система /bin была заполнена, поэтому новые двоичные файлы установили на… /usr/bin. И /usr в то время был их… пользовательским каталогом!

После этого разделения они начали создавать искусственные обоснования и критерии, чтобы решить, что должно идти в /bin, а что в /usr/bin. Неформальное правило было таким: “основные” вещи идут в /bin, “все остальное” идет в /usr/bin. То же самое с /lib. Долго не прошло, как /usr заполнился системными каталогами, смешанными с домашними каталогами реальных пользователей. Таким образом был создан /home, чтобы разместить все пользовательские каталоги и оставить /usr чистым для “системных вещей”.

Это было задолго до того, как появился FHS. Когда он был создан, он поддержал и формализовал эту текущую традицию и сохранил название /usr, хотя к тому времени оно уже не имело ничего общего с “пользователем”. Так что да, красивые имена типа “UNIX Source Repository” или “UNIX System Resources” — это все выдуманные имена, и теперь уже слишком поздно переименовывать. Но, как мы уже видели, не слишком поздно забросить /bin, /lib и /sbin туда. Таким образом, /usr теперь является основным “системным” каталогом.

“Хорошо, что насчет /usr/sbin?”, спросите вы. Черт, я надеялся, что вы забыли. Хорошо… /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

Сегодня

В настоящее время, касательно директорий установки, лучше всего понимать следующим образом:

• /usr – все системные, только для чтения файлы, установленные (или предоставленные) ОС

• /usr/local – системные, только для чтения файлы, установленные местным администратором (обычно вами). И поэтому большинство имен каталогов из /usr дублируется здесь.

• /opt – зверство, предназначенное для системных, только для чтения и самодостаточного программного обеспечения. То есть, программного обеспечения, которое не распределяет свои файлы по bin, lib, share, include, как хорошо себя ведущее программное обеспечение.

• ~/.local – аналог /usr/local для каждого пользователя, то есть ПО, установленное каждым пользователем и для каждого пользователя. Как и /usr, он имеет свои собственные ~/.local/share, ~/.local/bin, ~/.local/lib.

• ~/.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 (для пользовательских настроек). Хотя многие старые программы (и, к сожалению, некоторые современные тоже) все еще используют ~/.<имя_программы>, загромождая вашу домашнюю папку множеством скрытых директорий и файлов.

• ~/.local и ~/.config не являются частью спецификации FHS. FHS не занимается структурой домашней папки пользователя. Они являются попыткой Freedesktop/XDG, другой стандартной организации, нацеленной на Среды Рабочего Стола (такие как Gnome, KDE, и Unity), попытаться установить некоторые конвенции по структуре домашней папки пользователя. Не все программное обеспечение следует этим правилам (например, дистрибутивы только недавно включили ~/.local/bin в значение по умолчанию $PATH пользователя, и только если это существует), и ни один пользователь не обязан следовать им, но оба получают много преимуществ, если следуют.

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

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