Если я устанавливаю приложение в Linux, например Debian / Gnu Linux, файлы приложений копируются во многие разные каталоги в файловой системе.
Некоторые сценарии помещаются в / usr / share .. / usr / local, некоторые другие файлы - в / var .. / log .. etc / и так далее.
Для меня это нормально, потому что я кое-что узнал о файловой системе, и большинство каталогов предназначены для хранения файлов с определенной целью. Это очень хорошо вписывается в философию Unix «делай одно и делай это хорошо»
Но мой вопрос в том, каковы преимущества такой структуры каталогов? Или это просто наследие старых дней Unix. (например, по сравнению с использованием одного окна, где все файлы для приложения находятся в одной определенной «папке»)
linux
filesystems
directory
directory-structure
Ян Кестер
источник
источник
/bin,/etcот/.Независимо от того, какая организация выбрана, некоторые вещи будут легче, а некоторые сложнее.
Организация файлов по типам, пути Unix (Into
bin,man,lib/python, ...), делает его легче использовать файлы. Если вы хотите запустить команду, вы знаете, где ее найти, независимо от того, какой пакет ее предоставляет. Если вы хотите искать документацию, все это в одном месте. Если какая-то программа предоставляет модуль подсветки синтаксиса Vim, функцию завершения zsh или привязки Python, соответствующий файл будет находиться там, где vim / zsh / python сможет его найти.Unix также организует файлы по шаблонам использования. Вводятся файлы конфигурации, файлы
/etc, которые не меняются при нормальной работе/usr, и файлы, которые изменяются автоматически/var. Пользовательские данные идут под/home. Это очень полезно для управления конфигурацией (управляйте тем, что входит в/etcплюс список установленных пакетов). Также полезно определить стратегии резервного копирования: что входит/etcи/homeчто критически важно, тогда как то, что входит,/usrможет быть легко загружено снова.Основная стоимость способа Unix заключается в том, что установка части программного обеспечения распространяется по многим каталогам. Однако современные Unix-системы в любом случае имеют менеджеры пакетов; Управление файлами во многих каталогах - далеко не самая сложная вещь, которую они делают (отслеживание зависимостей очень полезно и сложнее).
Сравните это с Windows. Windows начиналась без управления пакетами, и каждое приложение где-то создавало свой собственный каталог. Все файлы обычно находятся внутри этого каталога: программы, статические данные, пользовательские данные… За исключением иногда библиотек, программы которых попадают в общий системный каталог без учета конфликтов («ад DLL»). Со временем Windows стала многопользовательской, что потребовало отделения пользовательских каталогов от системных каталогов. Windows также создала центральное место для файлов конфигурации (Unix
/etc) и некоторых системных данных (Unix's)./var), реестр. Это скорее исторический артефакт, во многом из-за отсутствия управления пакетами и ранней истории однопользовательской системы. Подход Windows имеет много ограничений: он не позволяет программным пакетам взаимодействовать легко. Например, большинство установленных программ не попадают на путь поиска команд по умолчанию, поэтому они плохо взаимодействуют с любой формой сценариев. Установщики, как правило, предоставляют значок меню в качестве особого случая, который помещается в отдельный системный каталог (как Unix!).Ограничение подхода Unix состоит в том, что он не позволяет легко сосуществовать нескольким версиям пакета, что особенно проблематично во время обновления пакета. Чтобы получить лучшее из обоих миров, можно распаковать каждый пакет в его собственный каталог (
/optструктуру) и создать леса символических ссылок из каталогов пакетов в/usrструктуру. Это то, что делает программное обеспечение, как Stow .Таким образом, подход Unix упрощает использование файлов, управление файлами и позволяет пакетам взаимодействовать; это требует программного обеспечения для управления пакетами, но это все равно желательно. Подход Windows облегчает управление пакетами вручную, но для получения полезной функциональности необходимо повернуть в сторону модели Unix.
источник
Основное преимущество, не упомянутое выше, и одна из исторических причин структуры - это физическое разделение на нескольких томах / дисках, доступных на разных этапах процесса загрузки.
Другое преимущество заключается в том, что различные каталоги можно монтировать на томах / файловых системах, которые оптимизированы для данных каталога. Например,
tmpfsдля/run; и только/sbinдля чтения / ROM.Также тома могут быть локальными или удаленными, личными или общими.
Наконец, посмотрите каталог приложений для альтернативного подхода (упомянутого @fluffy), используемого в UNIX (OS X
.app), Linux ( ROX Desktop ) и Windows ( PortableApps.com ).источник
В этом макете нет никаких преимуществ, кроме того, что легко угадать, где находятся общие файлы и файлы конфигурации для приложения. UNIX имеет долгое наследие такого рода компоновки, и сломать его было бы довольно сложно. Однако некоторые дистрибутивы UNIX изменили свою модель - они предоставляют только старые местоположения для устаревших целей, а другие приложения упакованы в его собственный небольшой каталог / пакет. Mac OS X является наиболее ярким примером этого, и есть несколько непонятных дистрибутивов Linux, которые делают то же самое (и Android делает нечто подобное, только делает это немного дальше, а также устанавливает и запускает каждое приложение под своим собственным идентификатором пользователя). ).
Главное, что обеспечивает соглашение о файловой системе, - это соглашение, чтобы люди знали, где искать файлы (будь то вручную или в коде). Нет никакой реальной технической причины, чтобы он был одним путем над другим.
источник