В чем обоснование «системных ресурсов unix» или /usr , как описано здесь , что дублирует многие имен каталогов в корневом каталоге / ?
Моя цель: я инсталлирую Oracle JDK уже в этот раз и решил на этот раз просто поставить его под /home/user , и я просто немного читаю, чтобы понять, плохо ли это на одной пользовательской машине ,
Есть короткая версия и длинная версия вашего ответа ...
Краткая версия:
Как уже говорилось в вашей ссылке, /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 пользователя, а по логике оно должно) , и никто не вынужден следовать ему, но оба получают много если они это сделают.
Надеюсь, это поможет немного прояснить ситуацию. Не стесняйтесь спрашивать что-нибудь, чтобы я мог улучшить ответ!
(и я также надеюсь, что пуристы не убьют меня за такой крайне неформальный язык и объяснение. Это было намеренно, и у него наверняка много неточностей, но я считаю, что это хороший способ сделать новичок имеет краткий обзор понимания обоснований каталогов установки)