В чем преимущество того, как Linux организует файлы установленных программ? [закрыто]


10

В Windows системный диск C:имеет каталог program_files, в котором каждая программа имеет свой собственный каталог.

В линуксе под /usr/и /usr/local/есть /bin, /etc, /share, /src, и т. Д.

Таким образом, в Windows все файлы каждой программы сгруппированы в одном каталоге, в то время как в Linux файлы одного типа из всех программ находятся.

Я чувствую, что способ, которым Windows организует установленные программы, более логичен, чем способ Linux, и поэтому с установленными программами проще управлять вручную.

В чем преимущество того, как Linux организует файлы установленных программ? Спасибо.

У меня есть этот вопрос, когда возникает проблема Как организовать установленные программы в $ HOME для оболочки, чтобы искать их при запуске? где я пытаюсь упорядочить свои программы в $HOMEсоответствии с Windows, но у меня есть некоторые проблемы с указанием путей поиска программ.


9
@RandallStewart ваше « непредсказуемое и рассеянное » - это наше рациональное размещение и отсутствие дублирования библиотек DLL.
RonJohn

1
Это исторически основано - главным образом для того, чтобы иметь возможность монтировать несколько разделов диска, при этом имея возможность загружать только необходимые элементы. Похожая ситуация была, когда в BIOS компьютера могли видеть только первую часть очень больших жестких дисков, поэтому в этой первой части был помещен отдельный раздел, содержащий все необходимое для загрузки. Обычно называется "/ boot". Сегодня потребность в песочницах и ненадежных приложениях привела к переосмыслению этого - см., Например, снимки Ubuntu.
Торбьерн Равн Андерсен

9
Позвольте мне первым указать, что Windows в настоящее время не помещает все файлы каждой программы в каталог smae. В дополнение к «Программным файлам» и «Программным файлам (x86)» существуют каталоги «Users \ <username> \ Appdata», среди которых «Local», «LocalLow» и «Roaming». Кроме того, Windows не всегда использовала папку «Program Files» для программ и не использовала ее последовательно в своей истории. * nix гораздо более последовательн в обработке файлов с течением времени.
YLearn

5
@JAB, согласился и понял это. Я указывал на то, что утверждение ОП, а именно: «Таким образом, в Windows все файлы каждой программы сгруппированы в одном каталоге» просто не соответствует действительности. Я также не стал обсуждать реестр Windows, который также можно рассматривать как хранящий конфигурацию и другие данные о программах Windows, который не является частью каталога «Program Files».
YLearn

2
Linux организует файлы установленных программ? С тех пор как?
Хоббс

Ответы:


17

В Linux разные локации, как правило, в хорошем состоянии отражают некоторую логику. Например.:

  • /bin содержит самые основные инструменты (программы)
  • /sbin содержит самые основные программы администратора

Обе они содержат элементарные команды, используемые при загрузке и устранении фундаментальных неисправностей. И здесь вы видите первое отличие. Некоторые программы не предназначены для использования обычными пользователями.

Тогда взгляни /usr/bin. Здесь вы должны найти больший выбор команд (программ), обычно более 1000 из них. Они являются стандартными инструментами, но не так важен , как в /binи /sbin.

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

Взгляни на мой PATH,

$ echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games

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

  • /home/tomas/bin мой личный каталог в моей домашней папке для моих личных исполняемых файлов.
  • /usr/local/bin Я объясню отдельно ниже.
  • /usr/bin описано выше.
  • /bin также описано выше.
  • /usr/local/gamesявляется комбинацией /usr/local(будет объяснено ниже) и игр
  • /usr/gamesэто игры. Не следует смешивать с исполняемыми файлами утилит, они имеют свои отдельные местоположения.

Сейчас к /usr/local/bin. Это несколько скользко, и здесь уже объяснялось: что такое / usr / local / bin? , Чтобы понять это, вам нужно знать, что папка /usrможет использоваться многими компьютерами и монтироваться из сетевого расположения. Команды там не нужны при загрузке, как отмечалось ранее, в отличие от команд /bin, поэтому расположение может быть смонтировано на более поздних этапах процесса загрузки. Он также может быть установлен только для чтения. /usr/local/binс другой стороны, предназначен для локально установленных программ и должен быть доступен для записи. Таким образом , в то время как многие сетевые машины могут совместно использовать общий /usrкаталог, каждый из них будет иметь свои собственные /usr/localустановки внутри общего /usr.

Наконец, взгляните на PATHмоего пользователя root:

# echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

Он содержит эти:

  • /usr/local/sbin, который содержит команды администратора типа /usr/local
  • /usr/local/bin, которые являются теми же, которые может использовать обычный пользователь. Опять же, их тип может быть описан как /usr/local.
  • /usr/sbin являются несущественными утилитами администрирования.
  • /usr/bin являются несущественными административными и обычными пользовательскими утилитами.
  • /sbin являются необходимыми инструментами администратора.
  • /bin являются необходимыми инструментами администратора и обычного пользователя.

Спасибо. Мне очень интересно, как вы организуете программы для установки /home/tomasz/bin/, см. Unix.stackexchange.com/questions/431793/…
Tim

Насколько я понимаю, в то время как разделение /binи /usr/binдействительно нужно было избегать проблем с сетевыми /usrкаталогами, разделение /usrи /usr/localпредназначено для разграничения между файлами ( /usr), поставляемыми поставщиком, и файлами, установленными вручную на самой машине ( /usr/local) и не имеющими ничего общего с проблемы с подключением к сети. Это точно?
Кейджи

4
@Keiji, продавец-противы-местное управление является наиболее распространенным (и обычным) использованием для этого различия сегодня, но если вы посмотрите на традиционных установках UNIX, /usr-OFF-а-сети ( по сравнению с /usr/localтого, ну, местный ) не неслыханным из.
Чарльз Даффи

Это все такая плохая идея в 2018 году
Амара

7

В настоящее время я думаю, что это историческое наследие от классического UNIX.

В первых версиях UNIX программы были не такими большими, как в наши дни. Программы часто состоят из одного исполняемого файла, который использует системные библиотеки. Итак, никто не задумывался о программах, которые будут состоять из пары собственных библиотек. Основной библиотекой была библиотека C, и каждая программа знала об этом месте.

Также среда UNIX считалась готовым продуктом (для подготовки документации). Поэтому пути к всем инструментам были исправлены.

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


6
Есть неотразимые преимущества, которые остаются полезными сегодня. Хранение двоичных файлов /usr/bin, статических файлов данных /usr/shareи файлов, которые могут быть изменены, /varили /usr/varозначает, что меры безопасности могут быть использованы для обеспечения того, чтобы ничего не выполнялось shareили varне выполнялось (используя noexecфлаги для их монтирования); что ничто снаружи не varможет быть изменено (в системе, использующей dm_verityили аналогичные меры для создания подписанных носителей только для чтения); и т.д.
Чарльз Даффи

3

То, что вы видите в современной Unix-подобной системе, не совсем традиционно.

Обычно, было бы довольно минимально /и /usrиерархии с только системными утилитами, и программы затем устанавливаются отдельно в подкаталог /usr/local, а затем становятся доступными путем создания символических ссылок.

Очень типичной настройкой для программного обеспечения GNU было скомпилировать и установить с

./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1

Утилита хранения GNU создает символические ссылки, чтобы сделать программное обеспечение доступным по стандартному пути, без необходимости добавлять какие-либо каталоги в переменную PATH (как это делает Windows, и там накапливается cruft).

Однако в современных дистрибутивах Linux все поставляется в виде готовых пакетов, поэтому программы стали частью «системы». Поскольку менеджер пакетов заботится об установке, нет необходимости в символических ссылках, а разделение программ не имеет никакой полезной цели (но замедлит запуск программы, так как придется сканировать много небольших каталогов).

Если вы хотите установить программное обеспечение в свой домашний каталог, я предлагаю вам также использовать для этого GNU-хранилище - это позволит вам хранить ваши программы отдельно, что разумно, если вы не используете менеджер пакетов.

Моя традиционная установка для этого - это один каталог, в ~/software/DIRкоторый я устанавливаю программы, затем использую внутреннюю панель DIRдля создания ~/software/binи ~/software/shareт. Д. Это означает, что мне нужно только добавить ~/software/binпеременную PATH, чтобы получить все мое установленное программное обеспечение.

Использование:

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

установить, если программа соответствует соглашениям GNU.


2

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

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

Unix-системы, с другой стороны, с 90-х годов, как правило, каждая имели единый принятый менеджер пакетов и группу, предоставляющую большое количество обычно используемого программного обеспечения через этот менеджер пакетов. (Официальные менеджеры пакетов для различных Unices включают yumи aptдля систем Linux, pkgsrcдля NetBSD и portsдля FreeBSD. Часто коммерческие системы Unix также заканчиваются неофициальным, но широко распространенным менеджером пакетов, таким как brewдля MacOS.)

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

Тем не менее, в Unix существует давняя традиция установки «отдельного каталога на приложение», обычно под /optкаталогом.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.