LINUX.ORG.RU

Nix 2.0

 , , ,


3

8

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

Одной из особенностей данного пакетного менеджера является то, что для описания пакетов в нём используется функциональный язык nix. Набор пакетов nixpkgs, описанный на этом языке, на данный момент содержит более 8 тысяч пакетов применимых для широкого круга задач. Все пакеты с их зависимостями образуют Merkle tree, в котором уникальный хэш каждого пакета зависит от его собственного описания и от хешей всех его зависимостей, также огромное внимание уделяется изоляции сборок друг от друга (используется множество разных механизмов), всё это позволяет окончательно решить проблему так называемого «DLL hell». Nix также является сердцем декларативного дистрибутива Linux под названием NixOS. Nix 2.0 будет использован в следующем релизе NixOS 18.03 Impala.

Нововведения в релизе:

  • Обновлённый интерфейс командной строки на базе единой команды nix должен стать более удобным и однородным (интерфейсы nix-env, nix-build и другие сохранены для обратной совместимости)
    • nix build пришел на замену nix-build
    • nix run служит для запуска программ в окружении заданных пакетов (в чём-то похож на старый nix-shell -p ... --run ...)
    • nix search заменяет nix-env -qa. В отличии от последнего, nix search умеет кэшировать список пакетов для быстрого поиска
    • nix copy позволит копировать пакеты между произвольными хранилищами пакетов, является обобщением nix-copy-closure и nix-push
    • nix verify проверяет, что файлы пакета не были модифицированы
    • nix repl — встроенный REPL для языка nix
    • nix why-depends демонстрирует каким образом один пакет зависит от другого. Помогает мейнтейнерам бороться с «распуханием» дерева зависимостей
  • Улучшения безопасности
    • Nix теперь сохраняет цифровые подписи к пакетам в локальном хранилище. Подписи также копируются автоматически вместе с пакетами при копировании между хранилищами.
    • Цифровые подписи больше не требуются для содержимого с фиксированным хешем
    • Команда nix verify позволяет проверять наличие необходимых цифровых подписей
    • Цифровые подписи теперь по-умолчанию требуются для бинарных сборок (раньше так было только в NixOS)
    • В сборках в песочнице на платформе Linux теперь в качестве временной директории используется /build вместо /tmp
  • Режим чистого выполнения выражений на языке nix в котором не доступны некоторые функции позволяющие получать переменные окружения, скачивать файлы с недетерминированным содержимым.
  • Добавлены несколько фич для поддержки бинарной воспроизводимости (проверки на то, что независимые сборки одного и того же пакета имеют одинаковый результат). Если флаг enforce-determinism установлен в false, то различие в промежуточных сборках (например, зависимостей) приведёт всего лишь к предупреждению, а не к фатальной ошибке. Также параметр diff-hook позволяет задать приложение, такое как diffoscope, которое будет запущено в случае обнаружения несовпадений.
  • Унифицирована внутренняя логика работы с локальными хранилищами пакетов (место, куда пакеты устанавливаются) и удалёнными хранилищами (для передачи бинарных сборок). На данный момент поддерживаются следующие протоколы: http://, https://, file://, s3://, ssh://, ssh-ng://. Добавленная поддержка HTTP/2 позволит немного быстрее работать с бинарными кэшами.
  • Новые встроенные функции языка nix такие как builtins.fetchGit, builtins.fetchMercurial, builtins.path, builtins.split, builtins.partition. Поддержка значений типа float.
  • Избавление от зависимости от Perl. Компоненты зависящие от него либо были переписаны на C++ либо удалены. Биндинги к Perl были вынесены в отдельный пакет.

>>> Полный список изменений



Проверено: jollheef ()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от Deleted

Использует язык общего назначения

Уже который раз слышу это мнению, вот только сомневаюсь, что это решающий фактор. nixlang не такой уж и сложный.

проще их местные ебилды писать

Это из практики или следствие из того, что guile — ЯП обещего назначения? Емнип, там те ещё лиспо-портянки писать надо, в отличие от.

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

Это и есть 14 тыщ. Но repology точнее поскольку правильно обрабатывает всякие дубликаты.

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

В линуксах с so тоже самое.

Это как это ?

Вообще то dll hell это не кривость винды или чего, это кривость сборщика проги(пакета).

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

Уже который раз слышу это мнению, вот только сомневаюсь, что это решающий фактор. nixlang не такой уж и сложный.

Это из практики или следствие из того, что guile — ЯП обещего назначения?

Из практики. Небольшой, но практики.

Емнип, там те ещё лиспо-портянки писать надо, в отличие от.

И там и там в рамках уже готового API портянок не будет, потому что DSL. Но если чуть отходить от стандартного, то за счёт доступа к привычным библиотекам писать на guile выходит значительно проще.

Deleted
()
Ответ на: комментарий от MrKooll

У Guix никаких перспектив. Типичный результат NIH синдрома.

Так Guix — избавление от NIH в виде собственного языка, лiл. Разобрался бы сначала, чем без знаний говорить.

Deleted
()

Оно же как обычно не позволяет ставить over 9000 версий одного и того же приложения, которым требуется over 9000 версий одной и той же библиотеки и переключаться между версиями приложения в одну команду? Менеджер пакетов в GoboLinux умеет, да.

Впрочем, по сравнению с откровенно **дским docker-подходом, тупо делающим из всего гигантский блоб с упакованными зависимостями - подход nix - уже шаг вперёд, хотя и мало кому из поклонников SCRUM'а с Agile'ом он интересен. Разрабам показали, как можно ни в чём не разбираться и просто тупо забивать на особенности тех операционных систем, под которые они пишут - разрабы и рады.

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

Оно же как обычно не позволяет ставить over 9000 версий одного и того же приложения

https://github.com/NixOS/nixpkgs/issues/9682

We keep multiple versions in nixpkgs only when there's a good reason to. Nix is able to handle any number of versions/configurations, but on the other hand it's much more convenient when all (or most) use just a single one. It leads to better sharing of the effort in many respects: simplified maintenance, testing, sharing of the binaries, etc. It's what most distros do. (Only gentoo diverges from the big ones I know, and they pay a price for it.)

anonymous
()

nix why-depends демонстрирует каким образом один пакет зависит от другого. Помогает мейнтейнерам бороться с «распуханием» дерева зависимостей

Чушь какая. Нужно показывать не свойства зависимостей, а то, насколько притаскиваемая зависимость является нестандартной. В том же KDE полно приложений, дерево зависимостей которых выглядит жутковато, но если ты ставишь KDE - тот как бы 99% этих зависимостей сразу оказываются установленными. А вот если ради установки приложения нужно натащить в систему ещё 250Мб библиотек, не нужных практически нигде больше - это уже печаль-беда. Хотя на виртуалках, создаваемых обычно под нужды вообще всего одного приложения то всё в принципе пофигу.

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

Я этот ответ понял, как «да, но на самом деле нет, потому что нам лень»

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

так что они правы - поддерживать это безумие никто не сможет.

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

Проблема масс-ребилдов решается бинарным кэшем. Не нужно на каждой енд-юзер машине заново пересобирать мир, как в генте. Пересборка происходит один раз на сборочном кластере, юзеры получают готовые пакеты из кэша. В эпоху HD-порнухи скачать добавочных 500 мег - семечки. Как бы, очень скромная плата за воспроиозводимость и отсутствие необходимости полагаться на «бинарную совместимость», т. е. честное слово разрабов, что ничо не поломали, «мамой клянёмся».

Алсо, в рамках стабильного релиза версии glibc не меняют - что в дебиане, что в NixOS. А пользователи unstable сами знают, на что идут. Хотя и в unstable масс-ребилды стараются минимизировать: все несрочные изменения, вызывающие пересборку мира, идут в отдельную ветку staging, и она мёржится в unstable где-то раз в месяц. Также, для срочных патчей безопасности есть отдельный механизм, который позволяет заменить пакет на новый, не меняя хэша и не вызывая пересборки.

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

Это не поддержка оффтопика. Как работа программ в вайне не поддержка онтопика. И ни с какими DLL nix от этого не начал бы работать.

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

Больше блобов богу блобов

Двачую этого знатока жизни. Всё так.

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

проблема не в масс-ребилдах, а в параллельных деревьях зависимостей. добавление ещё одной версии glibc порождает новую вселенную и удваивает дерево зависимостей, добавление ещё одной версии утраивает и т.д. это только glibc, а попробуй например добавить musl вместо glibc, а потом несколько версию musl, а потом несколько версий ещё каких-нибудь пакетов, желательно «пониже» в дереве. если они начнут поддерживать по несколько версий пакетов, то комбинаторика очень быстро убьёт возможность просто обработать такое дерево зависимостей.

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

Оно же как обычно не позволяет ставить over 9000 версий одного и того же приложения, которым требуется over 9000 версий одной и той же библиотеки и переключаться между версиями приложения в одну команду?

Из мануала:

To install a specific version of gcc from the active Nix expression:

$ nix-env --install gcc-3.3.2
installing `gcc-3.3.2'
uninstalling `gcc-3.1'
Note the previously installed version is removed, since --preserve-installed was not specified.

Это же то, что ты хотел?

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

Тобою описанная проблема существует в основном в генте, где каждый пакет может зависеть от разных версий зависимостей, в зависимости от установленного набора пакетов, USE-флагов и погоды на Марсе. Протестировать все возможные комбинации из-за комбинаторной сложности нереально.

В Nix все версии зависимостей строго фиксированы, результат сборки строго определён, никакого комбинаторного взрыва, никаких проблем.

добавление ещё одной версии glibc порождает новую вселенную и удваивает дерево зависимостей

Нiт, оно ничего не порождает. Если ты добавишь пакет nixpkgs.glibc2 рядом с nixpkgs.glibc, у тебя просто появится новый пакет nixpkgs.glibc2. Остальные пакеты продолжат собираться с nixpkgs.glibc, потому что у них в зависимостях именно он.

Если ты бампнешь версию nixpkgs.glibc, то придётся пересобрать всё дерево, но никакой параллельной вселенной не будет - просто все пакеты начнут собираться с новой версией.

anonymous
()
Ответ на: Слив засчитан от Camel

Сэешь ещё этих вкусных обрезков ногтей

Как насчёт этого: у Nix есть работающая NixOS, а у Guix нет ничего, кроме скобок.

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

ты не врубаешься. версию надо не просто бампнуть, а бампнуть и оставить старую версию тоже. зависимости надо будет пересобрать под новую версию, старые пакеты под старую версию тоже нужны для того чтобы иметь возможность сделать переключение на старую версию, ага. эти две версии пересобраных пакетов - это и есть две вселенные т.к. от glibc зависит всё. ещё один бамп версии - ещё одна версия пакетов. добавляешь в это уравнение три версии musl - появляются шесть вселенных.

разумеется это невозможно поддерживать, васяны и не поддерживают. они-то знают к чему это ведёт.

а в генту всё ок - просто собрал с нужными опциями и просто поставил.

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

Если хочешь переключиться на старую версию, просто скачиваешь старую версию nixpkgs, в которой старая версия.

а в генту всё ок - просто собрал с нужными опциями и просто поставил.

Мне-то не надо врать, лол. С 2002 года на ней сидел, каждое второе обновление - поход в багзиллу. «ERROR: undefined reference to symbol '__libc_start_main@@GLIBC_2.4», "../libgettextpo/.libs/libgettextpo.so: undefined reference to `po_error'" и т. д. Потому что именно твою комбинацию пакетов, accept keywords и USE-флагов никто не протестировал.

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

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

Зависимости времени сборки можно безболезненно удалить.
Ты еще дофантазирыешь, что в дебиане без gcc-0.1 и binutils-0.1 нельзя работать.

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

а можно ещё из гита сделать менеджер пакетов - откатываешься на старую ревизию и у тебя другая версия glibc. но нет, никс это поддерживать не будет, математика - жестокая сука, мешает жить.

Потому что именно твою комбинацию пакетов, accept keywords и USE-флагов никто не протестировал.

а почему ты говоришь, что никто не протестировал? ты же протестировал.

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

а можно ещё из гита сделать менеджер пакетов - откатываешься на старую ревизию и у тебя другая версия glibc. но нет, никс это поддерживать не будет, математика - жестокая сука, мешает жить.

Кто кого поддерживать не будет? Потрудитесь излагать ваши мысли яснее.

а почему ты говоришь, что никто не протестировал? ты же протестировал.

Оно мне надо? За меня всё тестирует https://hydra.nixos.org/, она железная.

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

а ты точно говоришь о никсе, а не о фильме джей джей абрамса о гентопроблемах?

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

а можно ещё из гита сделать менеджер пакетов - откатываешься на старую ревизию и у тебя другая версия glibc. но нет, никс это поддерживать не будет, математика - жестокая сука, мешает жить.

Разве? Вот тут кто-то вроде такое сделал http://illumium.org/node/125

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

Вообще то dll hell это не кривость винды или чего, это кривость сборщика проги(пакета).

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

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

а почему ты говоришь, что никто не протестировал? ты же протестировал.

Gentoo in a nutshell.
Так и живём.

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

Note the previously installed version is removed, since --preserve-installed was not specified.

Нет, точно нет.

Я хочу принципиального понимания разработчиками того, что в одной системе не и «последовательно», и «параллельно» может использоваться любое количество версий и сборок одного и того же ПО. Это нормально и абсолютно не зазорно. Да, нужно при этом иметь возможность переключать конфигурационные каталоги, но во-первых почти любой софт умеет запускаться с опцией, указывающей расположение конфигов, ну и во-вторых - никто не мешает собирать так, чтобы конфиги каждой версии лежали в своём каталоге. В конце-концов для решения каких-то таких заморочек и нужен мудрёный софт, а не для того, чтобы это была очередная скачивалка/собиралка из git'ов.

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

Нет, точно нет.

Тебе не нравится, что он удаляет предыдущую версию? Ну так это не физическое удаление, а подмена симлинка. Физическое удаление происходит только при nix-collect-garbage -d.

Я хочу принципиального понимания разработчиками того, что в одной системе не и «последовательно», и «параллельно» может использоваться любое количество версий и сборок одного и того же ПО.

Проблематично параллельно использовать разные версии ПО, если у них одинаково называются бинарники. А вообще, можно ставить разные версии софта для разных пользователей, заменять одни версии на другие одной командой, запускать шеллы с заданными пакетами, да хоть руками дёргать нужные бинаринки из /nix/store. Я не знаю задач, которые нельзя было бы решить перечисленными способами.

Это нормально и абсолютно не зазорно.

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

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

Ну сам запускай софт с такой опцией. Лично мне, например, нафиг не надо, чтобы ПМ гадил в мой уютный /home или /etc кучей каталогов с конфигами для разных версий софта.

Esper
()
Ответ на: комментарий от Deleted

То что в Guix решили scheme использовать не делает его чем-то особенным. Scheme для разработчиков и опсов такая-же неведомая херня которую надо дополнительно учить.

Очередной мертворожденный проект GNU сделанный чтоб можно было говорить что у них это тоже есть.

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

То что в Guix решили scheme использовать не делает его чем-то особенным.

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

Очередной мертворожденный проект GNU сделанный чтоб можно было говорить что у них это тоже есть.

Собака лает — караван идет.

Deleted
()
Ответ на: комментарий от DRVTiny

Я думаю многие никсеры не используют nix-env в повседневности потому что установка чего-либо требует наличия некоторого global state, которое мы иметь не хотим. На практике, nix-env нужен чтобы установить текстовый редактор, систему контроля версий, и т.п. В мануале написано, что так можно ставить компилятор, но никто так не делает. Для разработки конкретных проектов удобнее (и часто надёжнее) использовать nix-shell. Он ничего не устанавливает в традиционном смысле слова, только определяет переменные окружения, так чтобы нужный софт работал. Сам софт лежит в nix store и может быть в любом количестве и каких угодно версий, с какими угодно патчами. При помощи nix-shell можно в разных терминалах одновременно иметь разные окружения, нужны только соответствующие nix expressions.

Ещё я слышал про альтернативный подход, где используется nix-env с отдельными профилями, но сам так не делал.

veprbl
() автор топика
Ответ на: ШINDOШS плес от Camel

Нет, спасибо, мне на NixOS. Приятно уже когда вас не дюжины.

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

многие никсеры не используют nix-env

Используют. Так удобнее. Да и разве можно иначе добавить пакет в пользовательское окружение без рута?

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

Дык nix-shell (или новый nix run).

$ nix-shell -p cowsay --run 'cowsay Cyka blyat!'
these paths will be fetched (0.83 MiB download, 4.41 MiB unpacked):
  /nix/store/48kg4c7yabya57901vzqc4csx1lpla86-cowsay-3.03+dfsg1-16
  /nix/store/5hszvi0hczzh25mmsz5rkb9qa758c10p-bash-4.4-p12-dev
  /nix/store/9bkj2zjc8jdzwgwdwb5d890hrhrk9d3g-bash-4.4-p12-dev
  /nix/store/bkx6rzqciq0sdn1z5liard33ffvv1n3s-bash-4.4-p12-doc
  /nix/store/d5ki460cwwydf93f31is95sqpcf334r4-bash-4.4-p12-info
  /nix/store/f1rp3j71id6g6zcmiafrksmw1cgydl9k-bash-4.4-p12-doc
  /nix/store/fskpf2pdlgn4gm2kay7lfbw1cmjil6s3-bash-4.4-p12-man
copying path '/nix/store/bkx6rzqciq0sdn1z5liard33ffvv1n3s-bash-4.4-p12-doc' from 'https://cache.nixos.org'...
copying path '/nix/store/f1rp3j71id6g6zcmiafrksmw1cgydl9k-bash-4.4-p12-doc' from 'https://cache.nixos.org'...
copying path '/nix/store/5hszvi0hczzh25mmsz5rkb9qa758c10p-bash-4.4-p12-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/9bkj2zjc8jdzwgwdwb5d890hrhrk9d3g-bash-4.4-p12-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/d5ki460cwwydf93f31is95sqpcf334r4-bash-4.4-p12-info' from 'https://cache.nixos.org'...
copying path '/nix/store/fskpf2pdlgn4gm2kay7lfbw1cmjil6s3-bash-4.4-p12-man' from 'https://cache.nixos.org'...
copying path '/nix/store/48kg4c7yabya57901vzqc4csx1lpla86-cowsay-3.03+dfsg1-16' from 'https://cache.nixos.org'...
 _____________ 
< Cyka blyat! >
 ------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.