Некоторое время назад увидел на www.linux.org.ru анонс NixOs – дистрибутива Linux, который использует новый менеджер пакетов – Nix. На Новогодних каникулах попробовал прочитать про него подробнее. Прочел две статьи: Imposing a Memory Management Discipline on Software Deployment (2004-го года) и Purely Functional System Configuration Management (2007-го года). Статьи, как мне показалось, бестолковые – читаешь их, читаешь, букв много, а сухого остатка -- мизер.
Сама идея, которая, как я понял, лежит в основе Nix, довольно интересная. Смысл в том, чтобы запретить сваливать все подряд в одну кучу. Поэтому, все пакеты размещаются в уникальных подкаталогах специально отведенного хранилища. Имя подкаталога для пакета формируется с использованием значения криптографического хэша, который, в свою очередь, вычисляется над содержимым пакета. Т.е. разные версии одного и того же пакета будут иметь разные хэши, т.к. их содержимое будет хоть чуть-чуть, но различаться. В результате, в хранилище получается что-то типа:
/nix/store
`- 068q49…-ssh-5.0.0/
`- 07837d…-ssh-5.1.0/
`- 8372dh…-svn-1.4.4/
`- 973bs9…-svn-1.4.5/
…
С помощью настройки переменных окружения можно легко создавать профили с разными версиями установленных пакетов. Например, один пользователь хочет иметь ssh-5.0.0 и svn-1.4.5, у него в настройках профиля будет что-то типа:
PATH=$(PATH):/nix/store/068q49…-ssh-5.0.0/bin
PATH=$(PATH):/nix/store/973bs9…-svn-1.4.5/bin
А другой пользователь хочет пользоваться ssh-5.1.0 и svn-1.4.4, для чего его профиль настраивается иначе:
PATH=$(PATH):/nix/store/07837d…-ssh-5.1.0/bin
PATH=$(PATH):/nix/store/8372dh…-svn-1.4.4/bin
Эта идея в NixOs доведена до того, что подобным образом происходит работа и с конфигурационными файлами. Т.е. том, что любое изменение должно приводить к созданию отдельного каталога с уникальным именем, в NixOs возведено в принцип.
А почему, собственно, я заинтересовался пакетным менеджером Nix?
Ну, во-первых, я еще не расстался с мыслью о том, что для распространения C++ библиотек нужно иметь что-то типа RubyGems. Обязательно кросс-платформенное. И ориентированное, в первую очередь, на распространение исходников. Чтобы не приходилось иметь дело с монстрами вроде Boost – по сути, это куча мелких, почти независимых, библиотечек, для использования которых нужно тянуть к себе tar.bz2 почти на тридцать(!) мегабайт. Самые последние собственные идеи на этот счет я чуть более года назад описывал в списке рассылки SObjectizer. А тут интересный подход – добавление криптографического хэша в имя каталога с пакетом. Может быть, когда-нибудь пригодится.
Во-вторых, интересно было осознать, что почти такую же идею о том, что любые новые версии нужно располагать в разных подкаталогах, мы у себя используем уже года четыре. Подробно она описана в разделе 4.5 документации по SObjectizer-овским фреймворкам.
Ну и, в-третьих, читая упомянутые выше статьи об Nix и NixOs, я вспоминал название какой-то статейки, которую видел в специализированном АСУТП-шном журнале в 1998-м или 1999-м году. Там речь шла об объектно-ориентированном(!) контроллере. Модно тогда было ООП (объектно-ориентированное программирование), вот и упоминали его к месту и не к месту. Сейчас становится модно функциональное программирование, вот и притягивают его за уши куда ни попадя. Чисто функциональный пакетный менеджер – это вам не хухры-мухры, это по взрослому J.
4 комментария:
Чем в итоге окончились эксперименты?
Главная, с моей точки зрения, фича это транзакционные накаты/откаты.
@worldmind:
О каких именно экспериментах вопрос?
Подумал что была попытка использовать nix, раз такой положительный отзыв.
Раз экспериментов не было, то и вопроса нет.
@worldmind
Отзыв не положительный, а язвительный :)
Проекты Nix и NixOS вроде как живут все еще.
Отправить комментарий