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

В 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— это основные инструменты администратора и обычного пользователя.

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

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

Кроме того, среда UNIX рассматривалась как готовый продукт (для подготовки документации ). Поэтому путь -s ко всем инструментам был исправлен.

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

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

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

Очень типичная установка программного обеспечения GNU заключалась в компиляции и установке с помощью

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

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

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

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

Моя традиционная настройка для этого — это один каталог ~/software/DIR, в который я устанавливаю программы, а затем использую stow внутри 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.

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

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

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

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

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