Каково различие между/, выбирают и/usr/local?
ls -1 | wc -l
...
$ ls --help | grep -- ' -1'
-1 list one file per line
...
$ wc --help | grep -- ' -l'
-l, --lines print the newline counts
PS: Отметьте ls - <номер один> | туалет - <буква L>
В то время как оба разработаны для содержания файлов, не принадлежащих операционной системе, /opt и /usr/local не предназначаются для содержания того же набора файлов.
/usr/local место состоит в том, чтобы установить файлы, созданные администратором, обычно при помощи make команда (например, ./configure; make; make install). Идея состоит в том, чтобы избежать столкновений с файлами, которые являются частью операционной системы, которая была бы или перезаписана или перезаписала бы локальные иначе (например, /usr/bin/foo часть ОС в то время как /usr/local/bin/foo локальная альтернатива).
Все файлы под /usr совместно используемы между экземплярами ОС, хотя это редко делается с Linux. Это - часть, где FHS немного внутренне противоречив, как /usr определяется, чтобы быть только для чтения, но /usr/local/bin потребности быть чтением-записью для локальной установки программного обеспечения для следования. Стандарт файловой системы SVR4, который был основным источником FHS вдохновения, рекомендует избежать /usr/local и используйте /opt/local вместо этого преодолеть эту проблему.
/usr/local наследие от исходного BSD. В то время, исходный код /usr/bin Команды ОС были в /usr/src/bin и /usr/src/usr.bin, в то время как источник локально разработанных команд был в /usr/local/src, и их двоичные файлы в /usr/local/bin. Не было никакого понятия упаковки (снаружи tarballs).
С другой стороны, /opt каталог для установки несвязанных пакетов (т.е. пакетов не часть распределения Операционной системы, но обеспеченный независимым источником), каждый в его собственном подкаталоге. Они уже создаются целые пакеты, обеспеченные независимым дистрибьютором внешнего программного обеспечения. В отличие от этого, /usr/local материал, эти пакеты следуют конвенциям каталога (или по крайней мере они должны). Например, someapp был бы установлен в /opt/someapp, с одним из его команды того, чтобы быть /opt/someapp/bin/foo, его конфигурационный файл был бы в /etc/opt/someapp/foo.conf, и его файлы журнала в /var/opt/someapp/logs/foo.access.
-
1/usr/local, для сам, внутреннее, скомпилированное и сохраняемое программное обеспечение. / выбирают, для несам, внешняя, предварительно упакованная область установки двоичного файла/комплекта приложений. Хм... у нас нет C:\program файлов для всего ;-) – Nikhil Mulley 02.02.2012, 14:49
-
2, "С другой стороны, / выбирают, каталог, где установить несвязанные пакеты", Что 'несвязанные' пакеты означает здесь? – Kevin Wheeler 16.08.2015, 04:54
-
3@KevinWheeler, Который объяснен в следующем предложении. Несвязанный означает пакеты не часть распределения Операционной системы, но обеспеченный независимым источником. – jlliagre 16.08.2015, 04:59
-
4@jlliagre, который документы песней* указывают, "Например, если/usr/каталог смонтирован как доля NFS только для чтения от удаленного хоста, все еще возможно установить пакет или программу в соответствии с/usr/local/каталогом", я не знаю, кто прав, но это, кажется, в противоречии с Вашим требованием об области, где FHS слаб. (*source centos.org/docs/5/html/5.1/Deployment_Guide / …) – Kevin Wheeler 06.12.2015, 13:44
-
5@KevinWheeler Это - точно слабость, к которой я обращаюсь. Установка пакета или программы в удаленном, каталоге только для чтения просто невозможна. Обходное решение должно было бы смонтировать локальную файловую систему на/usr/local, но это больше походит на импровизированное задание, чем что-то, правильно разработанное. двоеточия – jlliagre 06.12.2015, 15:05
Основное различие - это /usr/local для программного обеспечения, не управляемого системным поставщиком программного блока, но все еще после стандартных правил развертывания Unix.
Вот почему Вы имеете /usr/local/bin, /usr/local/sbin /usr/local/include и т.д...
/opt с другой стороны, для программного обеспечения, которое не следует за этим и развертывается монолитным способом. Это обычно включает коммерческое и/или межплатформенное программное обеспечение, которое упаковывается в стиле "Windows".
-
1я не соглашаюсь о Вашей монолитной точке. В стандарте FHS говорится, что пакеты, установленные в/, выбирают, подкаталоги должны иметь свой хост, определенные файлы быть установленными снаружи / выбирают, соответственно под/etc/opt/package для конфигурационных файлов и/var/opt/package для журналов, шпульки и подобный. / выбирают, на самом деле ближе к правилам развертывания Unix, чем/usr/local, которые подвергают все каталогу, который должен быть только для чтения, но не может быть по очевидным причинам. – jlliagre 04.04.2013, 12:03
-
2Несомненно, если я делал выбирать пакет и требуемым для требования соответствия FHS. Иначе стандарт больше, что Вы назвали бы "инструкциями". Просто, потому что NetBeans не использует/etc/opt/netbeans, не собирается мешать мне помещать его в/, выбирают в масштабе всей системы или $HOME/.local/opt для однопользовательского. – jla 14.05.2015, 21:59
-
3@jla я принимаю Ваш последний комментарий, был направлен ко мне, поэтому используйте xxx при ответе кому-то еще что OP или автор ответа. О/etc/opt FHS не говорит, что это - рекомендуемое местоположение (как инструкция), но обязательное местоположение. Вы или разработчик Netbeans свободны нарушить тот стандарт, поскольку нет никаких полномочий для осуществления его, но не говорят выполнению, что это неправильно - способ пойти. Это - просто неудачное недоразумение или преднамеренное нарушение. – jlliagre 22.05.2015, 14:15
-
4@jlliagre Как администратор моей системы, FHS является рядом инструкций. / выбирают, каталог является здравым смыслом, известное место для помещения монолитного / выбирает / <пакет>, или / выбирают / программное обеспечение <provider>. Когда я устанавливаю пакет, который хочет использовать <package|provider>/all/data/required/to/support, он входит, выбирают/, даже если поставщику не удается следовать за каждой деталью последнего FHS. Я мог бы послать электронное письмо или сообщить об ошибке, но я не собираюсь помещать тот монолитный пакет где-то в другом месте для чувства лучше о FHS в моей системе. – jla 27.05.2015, 21:04
-
5@jlliagre я установил партию материала в/, выбирает, и никакой файл не создается в/etc/opt. Должен? – m3nda 26.01.2016, 02:38
Для меня, лично, это - то, что Bill сказал в ссылке @philfr:
В системе разработки или песочнице, имея / выбирают каталог, куда можно просто бросить вещи и видеть, работают ли они, имеет большой смысл. Я знаю, что не собираюсь проходить усилие упаковочных вещей сам для испытания их. Если приложение не удается, Вы можете просто комната,/opt/mytestapp каталог и то приложение являются историей. Упаковка может иметь смысл при выполнении большого развертывания (существуют времена, когда я действительно упаковываю приложения), но много времен, хорошо бросить материал в/, выбирают.
К сожалению, большинство make install сценарии продвигают файлы в /usr/local вместо того, чтобы просто делать символьную ссылку там :-/
-
1Какова была бы точка? Если Вы собираетесь сделать символьную ссылку так или иначе, почему не только помещает исходный файл там во-первых? – Let_Me_Be 18.04.2011, 12:54
-
2Только прокомментировать
make installцелевые файлы продвижения в/usr/local; эта функциональность легко изменяема путем передачи a--prefix=параметр командной строки к./configureсценарий, или если существует нет./configureсценарий, можно передать параметрmakeбудьте нацелены как так:make --prefix=/usr install. – Sean C. 18.04.2011, 14:45 -
3/, выбирают стандартный каталог, включенный в $PATH? Я знаю, что/usr/local. – LawrenceC 18.04.2011, 17:13
-
4@Let_Me_Be, которым преимущество было бы то, что очень легко сохранить более старые версии. Скажем, у меня есть 2 версии 'нечто', расположенного в
/opt/foo-1.1и/opt/foo-1.2. Когда я обновляю,fooсимвольная ссылка в/usr/local/binточки к нечто 1.2. Если по некоторым причинам я должен откатывать, я просто заменяю символьную ссылку той, которая указывает на нечто 1.1 вместо этого. Если 1.2 хорошо после нескольких недель, быстрогоrm -rf /opt/foo-1.1удаляет более старую версию быстро и чисто. – pepoluan 18.04.2011, 17:41 -
5@ultrasawblade не, это не. и никогда не должен быть. в конце концов, согласно FHS, / выбирают, должен быть подразделен на subdirs носящий имени пакета. зубрежка все в ПУТЬ - верный способ к аварии. скорее приложения должны установить себя под/, выбирают, и символьные ссылки их вызванные пользователями программы в/usr/local/bin (или sbin). – pepoluan 18.04.2011, 17:45
Во-первых, я не думаю, что существует строгий ответ; другой adminstrators будет иметь различные мнения, согласно их образованию. Исторически, /usr/local был на первом месте; это была конвенция в Berkley, IIRC. Однажды во время разработки System V, если я не ошибаюсь (это - все давным-давно, и я не сделал заметки), было решение или требование смочь смонтироваться /usr только для чтения, который означал, Вы не могли добавить новое программное обеспечение к нему; это, возможно, было то, почему /opt был изобретен. Как это происходит, было именно так много существующего программного обеспечения, которое действительно писало в /usr то, что та идея, никогда действительно успешно начатая.
Мое персональное предпочтение /opt, с отдельным подкаталогом для каждого продукта; это делает удаление продукта простым случаем rm -fr. Но если все Ваше программное обеспечение установлено через хороший диспетчер пакетов, не имеет значения, и если программное обеспечение, которое Вы устанавливаете, строго не повинуется этим конвенциям и пишет конфигурации и такой где-нибудь под /usr, это не имеет значения также, хотя по противоположным причинам.
-
1" ""все Ваше программное обеспечение установлены через хороший диспетчер пакетов""", это невозможно, если Вы не используете только часто используемое программное обеспечение. – Pacerier 02.11.2017, 00:21
У меня несколько другой взгляд на этот вопрос.
Хотя все в jlliagre ответе верно, для меня практическое применение при развертывании программного обеспечения в кластере сводится к переменным среды по умолчанию и повторное использование библиотек по умолчанию.
Проще говоря - / usr / local и все его дочерние каталоги находятся в соответствующих переменных окружения, таких как PATH и MANPATH и / usr / local / lib {, 64} находятся в файле ldconfig ( /etc/ld.so.conf.d/ ).
/ opt / OTOH не является - что является преимуществом, когда требуется, чтобы несколько версий или конфликтующие пакеты сосуществовали в системе, но требует некоторого управления средой (например, environment-modules ] или коллекций программного обеспечения ), и невыгоден тем, что потенциально может «тратить» пространство памяти на дублирование разделяемых библиотек, поскольку каждая установка в / opt может быть полностью автономной.
Для совместной работы / usr / local предполагается, что, например, двоичные файлы устанавливаются непосредственно в / usr / local / bin (и страницы руководства, соответствующие / usr / local / share / man / ... ), а не в / usr / local / app / {bin, share / man, ...} и т. д.
В общем, мой внутренний ответ...
Пользуясь справедливой долей FreeBSD, начиная с версии 2.2.6, и Red Hat Linux, начиная с версии 9...
/usr/local == Old School Conventions
/opt == New School Conventions
Расположение вещей в файловых системах UNIX/Linux больше связано с соглашениями и традициями, чем с абсолютной логикой.
В остальном я в основном согласен со всеми остальными.:-)
Всегда есть некоторые исключения из правил. В конце концов, вы решаете, что лучше всего подходит для вашей установки (, когда это возможно ).