LINUX.ORG.RU

Вышел NixOS 14.04

 ,


4

6

Несмотря на характерные цифры в версии, этот дистрибутив не имеет ничего общего с *buntu семейством.

Данный дистрибутив основан на «чисто функциональном пакетном менеджере Nix». По словам создателей эта фраза означает, что обновление одного пакета никак не приведет к поломке других, и что всегда можно откатиться на предыдущую версию.

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

/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/

Что нового в 14.04:

  • Добавленна базовая поддержка контейнеров. Теперь есть возможность запускать NixOS в NixOS.
  • Появилась возможность устанавливать NixOS на оборудование с UEFI.
  • Пакетный менеджер Nix обновили до версии 1.7, что также добавило много плюшек
  • Содержимое файлов passwd, shadow, group теперь полностью перезаписывается из конфигурации NixOS при запуске команды nixos-rebuild. Поддержка команд useradd/usermod и им подобным убрана в пользу идеологически более правильных (очень много букв!) для NixOS методов.
  • Подняли версию Systemd до 212.
  • Подняли версии базовых пакетов: Glibc 2.19, GCC 4.8, Linux 3.12.
  • Ну и другой софт обновили.

>>> Подробности

★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)

/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/

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

t184256 ★★★★★
()

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

Yo dawg, I heard you like to run NixOS…

Gotf ★★★
()
Ответ на: комментарий от CYB3R

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

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

MyTrooName ★★★★★
()
Ответ на: комментарий от CYB3R

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

chg ★★★★★
()

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

zloelamo ★★★★
() автор топика
Ответ на: комментарий от CYB3R

Почему бы не использовать /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.

sf ★★★
()
Ответ на: комментарий от sf

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

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

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от t184256

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

AVL2 ★★★★★
()
Ответ на: комментарий от sf

Результирующее месиво классно грепается на предмет 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/
Xintrea ★★★★★
()
Ответ на: комментарий от Xintrea

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

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

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

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

Xintrea ★★★★★
()
Ответ на: комментарий от Xintrea

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

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

AVL2 ★★★★★
()

Вы можете попробывать 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 команды очень рекоммендую попробывать

redbaron ★★
()
Последнее исправление: redbaron (всего исправлений: 1)
Ответ на: комментарий от Xintrea

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

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

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

redbaron ★★
()
Ответ на: комментарий от Sociopsih

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

redbaron ★★
()
Ответ на: комментарий от redbaron

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

Sociopsih ★☆
()

/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/

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

Aceler ★★★★★
()
Ответ на: комментарий от redbaron

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

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

andreyu ★★★★★
()
Ответ на: комментарий от Lavos

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

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

anonymous
()
Ответ на: комментарий от redbaron

curl | bash

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

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

derlafff ★★★★★
()

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

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

splinter ★★★★★
()

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

d_a ★★★★★
()
Ответ на: комментарий от sf

Ваша схерма не позволит иметь 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. А как в сабже конфиг-то отредактировать, у нужной версии программы? Я же не робот, чтобы хэши различать.

d_a ★★★★★
()
Последнее исправление: d_a (всего исправлений: 1)

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

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

Zhbert ★★★★★
()
Ответ на: комментарий от chg

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

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

d_a ★★★★★
()
Ответ на: комментарий от d_a

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

redbaron ★★
()
Ответ на: комментарий от d_a

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

redbaron ★★
()
Ответ на: комментарий от redbaron

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

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

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

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

d_a ★★★★★
()
Ответ на: комментарий от redbaron

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

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

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

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

d_a ★★★★★
()
Ответ на: комментарий от d_a

Проще дать ссылку на доку по профилям: 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...

redbaron ★★
()
Ответ на: комментарий от d_a

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

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

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

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

redbaron ★★
()
Ответ на: комментарий от redbaron

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

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

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

d_a ★★★★★
()
Ответ на: комментарий от d_a

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

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

redbaron ★★
()
Ответ на: комментарий от redbaron

В 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/? Или патчить апстрим? Мне больше заняться нечем?

d_a ★★★★★
()
Ответ на: комментарий от d_a

Ну давай разберем 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)

redbaron ★★
()
Ответ на: комментарий от redbaron

Я выше привел пример 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
в .bash_profile, если для настройки рабочей машины. Последний файл 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, так что непонятно, в чём здесь состоит преимущество.

d_a ★★★★★
()
Последнее исправление: d_a (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.