What is the '3' for?

Я уже очень давно говорю о том, что Boost, при всей своей полезности и прочих достоинствах, черезмерно усложнен. Разобраться в его внутренностях могут, разве что, сами разработчики Boost-а. И вот, выясняется, что и они не всегда это могут: мегавопрос по Boost-у на RSDN ;)

ЧистА функциональный пакетный менеджер

Некоторое время назад увидел на 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.