Вышел NixOS 14.04

/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/

Ну, допустим, нарушили они FHS. Не они первые, не они последние. Но почему именно таким образом?

Теперь есть возможность запускать NixOS в NixOS.

Yo dawg, I heard you like to run NixOS…

они не осилили симлинки :)

Почему бы не использовать /nix/store/firefox-2.0.0.1/ вместо этого месива?

Почему бы не использовать /nix/store/firefox-2.0.0.1/ вместо этого месива?

емнип, там еще флаги компиляции хешуются

А без системд можно
?

для того же, для чего и хеши в git, очевидно. чтобы можно было откатить сборку или конфигурацию

По хешу они пакеты находят. Т.е. хеш, это информация для Nix.

Честно говоря я новость запилил в надежде, что кто-нибудь уже пробовал и расскажет общественности об этом не стандарном дистрибе.

Как насчет совместимости с вендовым софтом?

Почему бы не использовать /nix/store/firefox-2.0.0.1/ вместо этого месива?

Идея nix - в воспроизводимости билдов (явно сохранять всё сборочное окружение).
nix патчат пакеты, чтобы в них было побольше абсолютных путей.
Начиная с toolchain.

Результирующее месиво классно грепается на предмет runtime зависимостей
(прямо по бинарнику) и не ломает другие пакеты даже после
пересборки этого же firefox-2.0.0.1 с новым окружением (новой GTK+, например).

Ваша схерма не позволит иметь 2 варианта одной версии firefox, собранной в разных окружениях (например, gcc-4.8 и gcc-4.9).

Я не знаю, что они делают, когда выходит libpng с закрытой уязвимостью
или новая версия glibc.

Я не знаю, что они делают, когда выходит libpng с закрытой уязвимостью

или новая версия glibc.

Обновляют все пакеты, содержащие libpng... Или просто забивают. Такое лучше спрашивать у разработчиков напрямую.

FHS они в целом не нарушали. В стандартных путях делаются симлинки.

Лучше бы сам поставил на виртуалку и попробовал, а потом нам рассказал. Делов-то.

Результирующее месиво классно грепается на предмет runtime зависимостей (прямо по бинарнику) и не ломает другие пакеты даже после пересборки этого же firefox-2.0.0.1 с новым окружением (новой GTK+, например).
Ваша схерма не позволит иметь 2 варианта одной версии firefox, собранной в разных окружениях (например, gcc-4.8 и gcc-4.9).

Ну а почему нельзя было сделать:

/nix/store/firefox-2.0.0.1/r8vvq9kq18pz08v249h8my6r9vs7s0n3/...

Добавилась еще одна скомпилированная по-другому версия, тогда становится:

/nix/store/firefox-2.0.0.1/r8vvq9kq18pz08v249h8my6r9vs7s0n3/...
/nix/store/firefox-2.0.0.1/ids2jqrevs76suk3fahsk8gsaui72bjs/...

Ведь такая организация разумнее чем

/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/

Невелика разница.

Не факт. Твой вариант подразумевает два ключа - пакет-версия и хеш. А их вариант обходится одним ключом.

Причем человеку туда и смотреть не надо. Для него делаются симлинки.

Не факт. Твой вариант подразумевает два ключа - пакет-версия и хеш. А их вариант обходится одним ключом.

Но ведь нельзя в одном ключе смешивать два разных понятия. Список пакетов-отдельно, хеш-отдельно. Вообще, по-хорошему, должно быть что-то типа такого (не два а три вложения):

/nix/store/firefox/2.0.0.1/r8vvq9kq18pz08v249h8my6r9vs7s0n3/...
/nix/store/firefox/2.0.0.1/ids2jqrevs76suk3fahsk8gsaui72bjs/...

Но ведь нельзя в одном ключе смешивать два разных понятия.

Это одно понятие - список пакетов. Просто хеш дополнили понятным человеку отпечатком. Для удобства, не более.

LD_PRELOAD в текущем профиле

Вы можете попробывать Nix на любой системе.

curl -L http://github.io/nix-install.sh | bash
. ~/.nix-profile/etc/profile.d/nix.sh

Я использую Nix для создания окружений для разработки, вот например если кинуть такое вот в корень проекта:

let
  pkgs = import <nixpkgs> {};
  stdenv = pkgs.useGoldLinker pkgs.clangStdenv;
in with builtins; stdenv.mkDerivation {
  name = "myproj";
  src = ./.

  buildInputs = [
    pkgs.re2
    pkgs.libyamlcpp
  ];
}

и затем «nix-shell myproj.nix», то будет созданно окружение в котором дефолтный компилятор clang с линкером gold и в системных путях уже лежат RE2 и Yaml-CPP, при этом вся эта фиеста происходит в /nix-store и системное окружение никак не затрагивается (т..е эффекты не видны за пределами nix-shell и nix-build).

Очень удобно, учитывая что ставится оно в 2 команды очень рекоммендую попробывать

типа такого (не два а три вложения):

/nix/store/firefox/2.0.0.1/r8vvq9kq18pz08v249h8my6r9vs7s0n3/...
/nix/store/firefox/2.0.0.1/ids2jqrevs76suk3fahsk8gsaui72bjs/...

ну замени '/' на '-', поменяй хэш и версю местами и получишь то, что есть сейчас. Суть то не меняется :)

Не надо виртуалку. Nix можно на любой системе попробывать, это пакетный менеджер, ставиться независимо и живет в уголке в /nix-store. Смотри мой коммент выше

Клево вообще. Такой уголок стабильности на арчике, который не будет бесконечно обновляться.

/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/

А что они будут делать, когда я захочу поставить 4097-й пакет?

Это что за фс? Даже в ext3 было 32K.

а если хэш и инфо о пакете в /var/lib/nix/$pkg.manifest или в /nix/store/firefox-?.??/.manifest, а то и вообще в SQLite

Чего?

попробывать
попробЫвать

Убивать за такое нужно.

Как насчет совместимости с вендовым софтом?

Bro, совместимость 147%.

Прочитал как MacOS

curl | bash

Очень удобно, учитывая что ставится оно в 2 команды очень рекоммендую попробывать

Убивать. За такие сообщения просто хочется убивать.

Раз параноишь, скачай да проверь вимом :)

"http://git.io/nix-install.sh", не знаю почему на github.io исправил

также добавило много плюшек

наркоманский слэнг.

Так чем это лучше RHEL и Software Collections, вы говорите?

Ваша схерма не позволит иметь 2 варианта одной версии firefox, собранной в разных окружениях (например, gcc-4.8 и gcc-4.9).

Почему не позволит? Делается нужное число коллекций — /opt/rh/mydomain_firefox-2.0.0.1-gcc44, /opt/rh/mydomain_firefox-2.0.0.1-gcc47, /opt/rh/mydomain_firefix-2.0.0.1-gcc48. А как в сабже конфиг-то отредактировать, у нужной версии программы? Я же не робот, чтобы хэши различать.

чисто функциональном пакетном менеджере Nix

Как-то по-гопнически звучит...

для того же, для чего и хеши в git, очевидно. чтобы можно было откатить сборку или конфигурацию

Yum downgrade и историю транзакций вроде никто не отменял. И без всякого хэшеирования путей.

/nix/store/* это implementation detail, руками туда лазить и уж тем более ничего править не надо. Да там лежат бинарники, но оттуда они симлинкятся на привычные пути, таким образом установка пакета это просто смена симлинка (и обратно). Точнее там двухуровневая струкура: множество профилей и симлинк на текущий.

В Nix можно собрать множество вариантов любой программы и иметь их в системе все разом. Утрированно: собрать mplayer c VAAPI и без и запустить их одновременно :)

Да там лежат бинарники, но оттуда они симлинкятся на привычные пути, таким образом установка пакета это просто смена симлинка (и обратно).

Что такое "привычные пути"? Это что-ли на манер как alternatives, на каждый файл в /nix/store/hash-smth-ver генерить симлинки в / и переключать их по мере надобности? **Если так**, тогда это беспомощное говно, равно как и alternatives. Во-первых, потому что дорого, если файлов много, во-вторых потому что негибко, так как отсутствует возможность подключать пакеты для выбранных пользователей или выбранных процессов, а не для всей системы. Как следствие, из п.2, требует рутовых прав для переключения.

/nix/store/* это implementation detail, руками туда лазить и уж тем более ничего править не надо.

Что это значит? Мой вопрос был --- как редактировать конфиги софта. Если симлинки в корне перещёлкнуты в нужную /nix/store/hash-smth-ver, то понятно. А если нет, и более того, --- их перещёлкивать _до редактирования_ нельзя? Как разыскать нужный файл, учитывая, тот рекламный факт, что по дизайну системы, в /nix/store может параллельно сидеть астрономическое число клонов, отличающихся только хешами?

В Nix можно собрать множество вариантов любой программы и иметь их в системе все разом.

Это я вижу. Поэтому и вопрос изначальный был --- чем это лучше SCL в RHEL.

Утрированно: собрать mplayer c VAAPI и без и запустить их одновременно :)

Утрированно, да. Потому что если я правильно понял твои обьяснения про симлинки и профили, у тебя _нет_ способа запускать разные версии одновременно. У тебя есть _только_ способ переключать симлинки. Запустил первый, перещёлкнул симлинки, запустил второй. Если повезёт, то первый не обломится, не найдя случайно нужных линков.

Проще дать ссылку на доку по профилям: http://nixos.org/nix/manual/#sec-profiles это похоже на алтернативы,но гораздо более гибко и проблем с индивидуальным набором пакетов для каждого пользователя нет как раз никаких.

Что это значит? Мой вопрос был --- как редактировать конфиги софта

мой ответ - конфиги софта не лежат в /nix/store так что редактировать их можно как в любой другой системе. Это касается Nix пакетного менеджера.

В NixOS пошли дальше и используют Nix и для управления конфигами. Вот тут пример https://github.com/chaoflow/nixos-configurations конфигов. Система строится на том, что мейнтейнеры пакетов предоставляют функции для их конфигурирования, а пользователь их вызывает у себя в конфиге, таким образом настраивается вся система целиком, от списка пакетов, до настроек сглаживания. В итоге получается нечто вроде встроенного в систему Puppet, только гораздо более приятный в использовании. Подробнее можешь почитать тут: https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansible-arent-good-enou...

Это я вижу. Поэтому и вопрос изначальный был --- чем это лучше SCL в RHEL.

Я выше привел пример nix выражения для сборки проекта. Это ВСЁ что нужно, чтобы иметь гарантированный байт к байту результат сборки на любой системе. Если добавть nixpkgs, как git submodule в проект, то и через 10 лет твой проект будет собираться точно так же, как и сегодня. Главное преимущество растет от туда, что функция сборки пакета это непосредственно часть функционального языка Nix.

Утрированно, да. Потому что если я правильно понял твои обьяснения про симлинки и профили, у тебя _нет_ способа запускать разные версии одновременно. У тебя есть _только_ способ переключать симлинки. Запустил первый, перещёлкнул симлинки, запустил второй. Если повезёт, то первый не обломится, не найдя случайно нужных линков.

Нет, руками симлинки никто искать не заставляет. Просто устанавливая два mplayer указываешь разные профили и можешь их запускать по известным путям: ~/myprofile1/bin/mplayer ~/myprofiles2/bin/mplayer

Почитал, господи, какой комбайн. Действительно, это совсем не alternatives и даже не SCL. Это что-то совсем иного уровня, это как systemd в мире пакетных менеджеров, от программистов и для программистов, им с этим будет хорошо. Получается, что навскидку он одновременно выполняет функции (как минимум, полный масштаб мне неизвестен):

* rpm (база данных по файлам, формат архива)
* rpmbuild (билд по рецепту)
* mock (песочницы для rpmbuild)
* SCL (SxS-развёртывание, переключение активных версий)
* yum (дистрибуция, решатель зависимостей, транзакции)

То есть не то, чтобы я обязательно сходу был против комбайна, определённые пункты из этого списка так и отнюдь не подарок, но то, что я его капитально недооценил --- это факт.

Если сравнивать с другими решениями, то можно подумать, что это комбайн, но когда работаешь с этим, то видишь только язык Nix, который по своей сути очень простой, а все остальное воспринимаешь как должное, как бесплатные фичи и нет ощущения монструозности и костности.

Я начал использовать Nix для создании окружений для разработки, для меня это очень ценно, что любой участник команды, может сделать «git clone proj; cd proj; ./dev-shell» и он гарантированно получит полностью настроенное окружение, независимо от того, какая у него система. Все готово и надо сделать deploy? nix-copy-closure соберет все зависимости в тарбол, который просто отправляется на сервер. Т.е. их даже не надо документировать, это просто очередная бесплатная фича, что можно сказать «собери мне все, что необходимо для запуска /bin/my-daemon».

В NixOS пошли дальше и используют Nix и для управления конфигами.

Вот отсюда и до конца напрочь непонятно. Можно на примере? Вот опакетил я для этой системы fontconfig последний. Его файлы пошли в /nix/store/hash-fontconfig-ver. Допустим, в окружение тестового пользователя необходимые переменные засорсены (PATH, LD_LIBRARY_PATH, и т.д., много их), так что библиотека готова к использованию. Пользовательские пресеты в ней принципе делаются только модификацией XML-файлов в $PREFIX/etc/fonts/conf.d, что в нашем случае даёт /nix/store/hash-fontconfig-ver/etc/fonts/conf.d. Она по другому не умеет. Редактирование файлов в /nix/ более нелегитимно, ну пускай --- но как мне здесь предлагается предоставить "функции для конфигурирования"? Непонятно напрочь. Писать на том самом функциональном языке транслятор никсового конфига из /etc в XML в глубине /nix/? Или патчить апстрим? Мне больше заняться нечем?

Ну давай разберем fontconfig.

Пакеты собираются так, чтобы искать конфиги не в $prefix/etc/, а в /etc. Смотри configureFlags тут:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/fontc...

Это никс выражение собирает библиотеку, оно не управляет конфигами. Для управления конфигами, в NixOS есть отдельный файл:

https://github.com/NixOS/nixos/blob/master/modules/config/fonts/fontconfig.nix

Который описывает, как информация из пользовательского конфига будет использоваться для генерации конфигов для fontconfig. Можно это считать аналогом debconf.

Пример пользовательского конфига:

  environment.fonts = {
    enableFontConfig = true;
    extraFonts = [
       pkgs.dejavu_fonts
    ];
  };

(extraFonts попадат в config.fonts через отсюда https://github.com/NixOS/nixos/blob/master/modules/config/fonts/fonts.nix)

Я выше привел пример nix выражения для сборки проекта. Это ВСЁ что нужно, чтобы иметь гарантированный байт к байту результат сборки на любой системе. Если добавть nixpkgs, как git submodule в проект, то и через 10 лет твой проект будет собираться точно так же, как и сегодня. Главное преимущество растет от туда, что функция сборки пакета это непосредственно часть функционального языка Nix.

Тыкни, я что-то не найду. Вижу только этот пост, но там просто сетап окружения, а не _сборка проекта_. Сетап-то понятно, что тривиально выглядит. Для SCL он тоже будет не сложнее чем

scl enable localdomain_mm localdomain_graphics localdomain_idevice-support './configure'

. /opt/rh/localdomain_mm/enable
. /opt/rh/localdomain_graphics/enable
. /opt/rh/localdomain_idevice-support/enable

export PATH=/opt/rh/localdomain_idevice-support/root/usr/bin:/opt/rh/localdomain_idevice-support/root/usr/sbin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/opt/rh/localdomain_idevice-support/root/usr/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
export CPATH=/opt/rh/localdomain_idevice-support/root/usr/include${CPATH:+:${CPATH}}
export LIBRARY_PATH=/opt/rh/localdomain_idevice-support/root/usr/lib${LIBRARY_PATH:+:${LIBRARY_PATH}}
export PKG_CONFIG_PATH=/opt/rh/localdomain_idevice-support/root/usr/lib/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}
export MANPATH=/opt/rh/localdomain_idevice-support/root/usr/share/man:${MANPATH}

Вот и весь рокет саенс. А воспроизводимый билд на готовой инфраструктуре, когда всё что надо куда надо закоммичено тоже нетяжело выглядит --- mock --rebuild *.src.rpm, так что непонятно, в чём здесь состоит преимущество.