Alexander Kuklev (akuklev) wrote,
Alexander Kuklev
akuklev

О структуре системных каталогов


Структура системных каталогов быть разумной, удобной и, главное, вечной. То есть, избегать конфликтов имён и сохранять обратную совместимость. Структуры каталогов Unix, MacOS X и Windows этим условиям не отвечают.

В каждой из этих операционных систем есть каталог для программ. Программы при записи туда используют какие им заблагорассудится имена. Бывают конфликты. Что делать, чтобы их не происходило, придумали авторы Джавы. Дело в том, что в мире уже существует хорошо зарекомендовавшая себя система постоянных глобальных уникальных имён, и эта система — DNS интернета. Посему в качестве внутренних названий программ следует использовать их домашние домены + номер версии. В качестве разделителя мне лично больше всего нравится ничего не нравится, но двоеточие с пивом потянет. Получаются каталоги типа /app/sendmail.org:8.14.3.

— А как же вызывать этот самый Сендмейл, — спросит внимательный читатель, — неужели по полному названию с номером версии?

Разумеется, нет. Для этого должны быть краткие названия, ссылающиеся на конкретные программы. Сейчас для этого программы просто пишут ссылки на себя с короткими названиями в каталог /bin и его аналоги. Разумеется, возникают и конфликты, и нарушение обратной совместимости. Вчера скрипт, использующий sendmail (/usr/sbin/sendmail) работал, сегодня не работает.

Чтобы этого не было, нужно, чтобы краткие названия програм тоже были стандартизированы и каждый скрипт указывал, с какой версией стандарта он хочет работать. Вместо стандартного начала скрипта
#!/bin/sh
надо просто использовать
#!/app/dash.org:2009

Соответственно, ведать раздачей стандартных кратких названий (= команд) должны будут создатели шеллов или открытые комитеты, которым они передадут эту почётную обязанность. Разумеется, никто не должен мешать пользователям самим добавлять/перегружать краткие названия, например при помощи запихивания соответствующих симлинков к себе в ~/.cfg/unix.org:2008/aliases/, однако скрипты и любые другие программы должны жить в выбранных ими пространствах имён и таких штучек не замечать.

Вообще же системных каталогов для програм должно быть четыре:
(~)/app/something.com:1.0
    — неизменная часть программы; личные программы в ~, общие в /
(~)/.var/something.com’1.0
    — рабочий каталог программы; личные программы в ~, общие в /
(~)/.reg/something.com’1.0
    — реестр программы, если она в таковом нуждается; ~ и / мерждатся.
(~)/.conf/something.com’1.0
    — конфигурационные файлы программы, если она конфигурируется; ~ и / мерждатся, причём личная конфигурация имеет приоритет.

Важно понимать разницу между конфигурацией и реестром. Конфигурация нужна, если поведение программы по умолчанию поддаётся настройке. Реестр нужен, если программа поддерживает какие-то расширения. При инсталляции расширения должны как-то сообщить материнской программе о своём существовании — для этого и нужен реестр, где они при установке регистрируются.

Конфигурация — это для редактирования пользователем, она не предназначена для автоматических изменений какого либо рода. Реестр — наоборот не должен изменяться пользователем*. Он изменяется лишь при установке и удалении программ. Устанавливаясь, программа может добавлять себя в реестры каких-либо других программ (в некоторых случаях для этого требуется сертификат, подписанный ключом программы-реципиента). При удалении, соответствующие записи убираются.

Несложно понять, что в нашей структуре каталогов иного места, где бы расширения могли заявить о себе, нет.
(~)/app — константа, неизменная часть программы, запускаемые файлы и ресурсы. Это фактически подписанный jar c программой в неизменном виде. Изменения этого каталога заблокированы, и исключением является только его полное удаление при деинсталляции.
(~)/.var содержит persistent state и может быть изменён только самой программой (права на изменения только у неё).
(~)/.conf не подхоит идеологически, кроме того он тоже открыт для изменения только для самой программы и пользователя (case ~)/администратора (case /) напрямую (или через посредничество GUI configuration frontend).

* Это всё-таки не совсем так. Например, регистрация некого каталога как веб-страницы должна осуществляться при помощи реестра. Чтобы зарегистрировать каталог ~/www/ как сайт, отвечающий по хостнейму имярек.com, нужно сделать на него симлинк ~/reg/httpd-такой-то:1.0/sites/имярек.com. Конфигурация сайта — это именно конфигурация сайта, а не сервера. Она должна быть целиком размещена в самом каталоге сайта, в аналоге .htaccess, и надёжно отделена от конфигурации сервера, чтобы изменяя её нельзя было положить сервер или повлиять на другие сайты. Аналогичным образом каталог с svn-репозиторием надлежит класть в домашний каталог соответствующего пользователя или группы разработчиков, и регистрировать в реестре svn-сервиса.

Особняком стоит часть конфигурации и реестра, относящиеся ко всей системе в целом. Выше я уже упоминал их в примере ~/.conf/unix.org:2008/aliases. Структура этой части должна определяться, например, POSIX-комитетом. Например где-то должен храниться список программ, имеющих интерфейсную совместимость с другими более старыми программами. Я бы назвал такое место /.reg/unix.org:2008/alt. Если Postfix:2.6.2 полностью совместим с Sendmail:8.14.3, при установке он должен поставить симлинк на себя (или имеет специальный скрипт-транслятор, эмулирующий совместимость) в /.reg/unix.org:2008/alt/sendmail.org:8.14.3. Программы должны создавать и заносить в реестр не только интерфейсы совместимости с аналогами и своей предыдущей версией, но и с их предыдущими версиями и аналогами вверх по дереву совместимости.

А вот выбор, какую именно реализацию такой-то программы использовать по умолчанию, если есть несколько альтернатив, должен как раз таки находиться в ~/.conf/unix.org:2008/alt/. Аналогичным образом, программы способные просматривать/редактировать документы определённых типов регистрируются в реестре соответствующей desktop environment, однако какая из них вызывается по умолчанию, определяется в конфигурации соответствующей desktop environment.

Каталог конфигурации должен быть не настоящим каталогом, а скорее аналогом env, т.е. изменения конфигурации должно быть возможно внутри текущего шелла без записи на жесткий диск, в каком случае эти изменения будут действены только для программ, запущенных из данного шелла, и их наследников. Такая возможность предусмотрена (и работает!) в Plan9. В идеале, и каталог конфигурации, и каталог реестра должен быть суммой патчей, а пакетная система чисто-функциональной в духе Nix (http://nixos.org/about.html), в результате чего деинсталляция программы будет сводиться к простому удалению её из /app, а установка не сможет привести к деструктивным последствиям. (В ходе установки любой программы происходит ровно три вещи: (I) cкачиваются и устанавливаются недостающие пререквизиты, (II) сам пакет разархивируется в app/, (III) запускается скрипт-конфигуратор, формирующий var-каталог программы и патчи конфигурации и реестра. Все эти процессы обратимы.)

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

Такую структуру каталогов я, кстати, впервые описал в 2006 году (Даша-туча, возможно, даже помнит), но при этом сказать, что я её “придумал”, я не могу, потому что она в известном смысле неизбежна. Необходимость именно такой (по модулю названий и прочих частностей) структуры системных каталогов, похоже, вытекает из конечного и вполне обозримого набора постулатов.
Subscribe

  • О программировании, из комментов у vit_r

    orleans: У ФП есть обьективные преимущества в плане исполнения на многопроцессорных системах и организации юнит тестов. Все то что можно…

  • Effect typing in short

    There are many different classes of functions out there. There are pure functions and there are functions with diverse side effects. Some can perform…

  • Towards Scala 3

    I'd like to share some ideas on features that might be included into next major Scala releases. Some of them might come in question already for Scala…

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 11 comments

  • О программировании, из комментов у vit_r

    orleans: У ФП есть обьективные преимущества в плане исполнения на многопроцессорных системах и организации юнит тестов. Все то что можно…

  • Effect typing in short

    There are many different classes of functions out there. There are pure functions and there are functions with diverse side effects. Some can perform…

  • Towards Scala 3

    I'd like to share some ideas on features that might be included into next major Scala releases. Some of them might come in question already for Scala…