В чем смысл nix/nixos?

Я так и не понял нафиг оно вообще нужно? Объясните тупому.

Зачем? Если ты тупой, тебе ничего не поможет.

Пока оно выглядит как ещё один вариант управления конфигурацией систем, как ansible или его аналоги.

Так и есть, только вокруг этого инструмента построена вся система, а не наоборот.

Но, ведь это, мягко говоря не так. Версии-то не фиксируются никак.

Фиксируются.

Ещё можно зафиксировать ревизию nix-pkgs, но этим ты тупо фиксируешь всё вообще, а не конкретные пакеты, которые тебе важны.

Ты можешь использовать несколько разных версий nixpkgs в одном конфиге.

Фиксируются.

Костылями. Prove me wrong, так сказать. Приведи пример, когда я могу спокойно зафиксировать версию libastral=1.2.3.

Фиксируются.

Костылями. Prove me wrong, так сказать. Приведи пример, когда я могу спокойно зафиксировать версию libastral=1.2.3.

Не костылями, а кодом на Nix.

libastral.overrideAttrs (old: { version = "1.2.3"; sha256 = "хэш"; })

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

Т.е. то, что работает сейчас, не факт что заработает через какое-то время

Такое может попасть в стабильный канал (релиз)? Мне нравится, что можно протестировать что либо, буквально изменив одну строку в конфиге. Например, поменять плазму на lxqt, затем обратно.

поменять плазму на lxqt, затем обратно

Что при этом происходит с пользовательскими конфигами?

А при этот Плазма и lxqt будут установлены паралельно? Или одно поставится, а другое удалится? Как бы, поставить паралельно можно в любом дистре, задав пакетному мэнеджеру нужный метапакет. Те настройки, что наваляют оба три ДЕв хомяке не удалятся? В чём плюс? Не пойму.

Параллельно, думаю, тоже можно. Поставить метапакет можно в любом, да, а удалить также легко? Удалить одно de и установить другое de одной строкой - это плюс.

В чем смысл nix/nixos?

Для задротства. Для всего остального есть арч.

Смотря, где лежат. Я home manager’ом не пользуюсь, через него обычно обслуживают конфиги в хомяке. А так без него nix в home не лазит.

Это если ментейнер добавил поддержку версий в соответствующий nix пакет, а если нет? Оно не обязательно, емнип.

Но, ведь это, мягко говоря не так. Версии-то не фиксируются никак.

Такое жирное 4.2, что спорить лень.

Смысла нет. Все тлен.

Мне система показалась слишком сложной и не для домашнего хомяка, далекого от IT (это я). Когда через полгода вернулся на традиционный линукс, это было, как-будто выбрался из душного темного подземелья на свежий воздух. Такая, физическая, ясность и легкость.

Хотя, да, декларативный конфиг, это удобно.
Но его преимущества неочевидны, в какой-то момент у тебя и так необходимая конфигурация, через месяц или два изыскания нужного софта прекращаются и все настроено. Это если начинать с нуля, а если сохранены конфиги, то через неделю, после их адаптации под новое железо (например было 1366х768 и вдруг приобрел 2560х1600). Переустановка тоже не частое дело.

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

В общем nixos предназначена для тех, кому необходимо быстро переключаться между несколькими состояниями системы.

В теории, да. Но вот хочу я пересесть, допустим, с ветвистой Плазмы на ЛХКути, но софт оставить, преимущественно, кдешный. По куда резать будем одной командой? :)

Это такая гента для ленивых

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

Это если ментейнер добавил поддержку версий в соответствующий nix пакет, а если нет? Оно не обязательно, емнип.

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

Фиксируются.

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

Конечно соберется. Только ты не разобрался пока как писать такой конфиг. (впрочем с flake это будет из коробки).

Единственный минус - у nixos не хранятся исходники на его инфраструктуре. Поэтому если апстрим у себя грохнет версию годовой давности в гите, то привет. Пакет не соберется.

Проще говоря, тебе в конфиге надо указать конкретный хеш конкретной версии nixpkgs. А не просто «текущий» nixpkgs. Тогда все собираться будет ровно тех версий, каких оно в запиненной тобой версии nixpkgs.

Это если по старинке.

Если по новинке, через flake, то там вообще само пинится, как при работе с npm у nodejs. Как у ноды, ты же знаешь? Вот так и тут будет - автоматически в файле фиксируется версия того что ставишь, далее будет ставиться именно она, с точностью до коммита в гите.

Ну и вот тебе как разрабу пример, зачем оно.

Допустим у тебя на гитхабе проект на C++, как всегда, с кучей зависимостей.

У меня - произвольный линукс черти пойми с какими версиями всего. Или даже NixOS.

Если ты используешь nix flake, то как я соберу твой проект у себя? Как-то так, за точность не ручаюсь, но суть такая

git clone
cd cocucka-pr
nix build

Всё! Nix сам поставит все зависимости, причем ровно, точно тех версий как у тебя. На любую систему у меня, будь то NixOS любой версии, арч или что угодно. Соберет проект гарантированно, и он будет работать гарантированно. Потому что полностью воспроизводится сборочное и рантайм окружение.

А без Nix? Ты же представляешь как я буду руками наворачивать все зависимости и молиться чтобы оно собралось на моих версиях всего?

Не нравится nix, используй GNU guix

Фуфло ваш гуикс

Чёйта? Я вот планирую когда нибудь перейти на него с никоса. Ради православной схемки, конечно.

Вот, Джим пришёл и всё объяснил. А остальные только рожи кривят…

Ну кмк спецязык nix лучше для этих задач.

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

Пока оно выглядит как ещё один вариант управления конфигурацией систем, как ansible или его аналоги.

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

Это просто молодые не знают, что такое puppet и chef.

Пока оно выглядит как ещё один вариант управления конфигурацией систем, как ansible или его аналоги.

Мне оно больше напоминает terraform, только применённый ко всему, а не только для узких задач. Ansible и chef слишком императивны, их настройки получаются нифига не воспроизводимы, если не развернуть кучу инфраструктуры тестирования во всяких молекулах.

Вас сожрут адепты никсоси. Вы покусились на святую корову. Бегите.

З.Ы. В дебианахъ и прочих традиционных линуксах предыдущие версии пакетов тоже не хранят,

http://snapshot.debian.org/

но там и не рекламируют воспроизводимость как фишку,

Смотря, что понимать под воспроизводимостью.

https://wiki.debian.org/ReproducibleBuilds

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

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

https://www.aptly.info/

Вас сожрут адепты никсоси. Вы покусились на святую корову. Бегите.

А в GUIX хоть что-то из обозначенных выше проблем NixOS решено лучше?

Не нравится nix, используй GNU guix

Какие преимущества?

Единственный минус - у nixos не хранятся исходники на его инфраструктуре. Поэтому если апстрим у себя грохнет версию годовой давности в гите, то привет. Пакет не соберется.

Есть ли какая-то автоматика для архивирования сорцов с гита, упомянутых в репозитории Nix для сборки каких-либо пакетов?

Т.е. чтобы парой строчек заархивировать вообще все нужное для полной пересборки в любой момент времени хоть через 10-20 лет при необходимости?

если все исходники будут ещё доступны по старым адресам

Как это гарантировать хотя бы локальными копиями (не по старым адресам)? Есть какие-то тулзы?

Например, поменять плазму на lxqt, затем обратно.

Переключить DE в DM уже не подходит?

Никсосочка — это лучшее, что случалось с ИТ.

Никогда не собирать мусор? Скачать откуда-то ещё и добавить их в /nix/store вручную, если вдруг? Расслабиться, и подправить адрес, если на это напорешься?

А я откуда могу знать?

В целом в треде всё уже объяснили, но хочу добавить: вообще состояние твоей системы состоит из её описания + состояния репозитория. Это вообще факт жизни, от которого не уйти. NixOS решил пойти по относительно простому пути и отказаться от версий пакетов, есть только версия репозитория. Взамен тебе дана возможность относительно легко обратиться к конкретной ревизии репозитория.

Как-то «сложна»! Хотя отслеживать, что появилось при запуске софтины иногда хочется, а то потом долго вычищать иногда.

как ansible

Ансиблом всё контролить конечно красиво и эстетично, но поменялись названия пакетов (а они меняются) - плейбук идёт в унитаз. Всё в переменные выносить и их править - проще с нуля написать.

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

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

На практике получился еще один менеджер пакетов с репозиторием из отстающих версий, всратыми (абсолютно нетинтуитивными) командами и скриптами отделенными от пакетов (на манер brew, aur или pkg в бсд) только на своём супер языке похожим на повер-шел от Майкрософт.

NixOS решил пойти по относительно простому пути и отказаться от версий пакетов, есть только версия репозитория.

Когда у тебя репозиторий состоит из скриптов установки то как еще то можно пойти?

В Gentoo тоже репозиторий из скриптов установки, но там есть версии пакетов (и нет версии репозитория).

Отлично, пойду накачу.

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

Смысл в совершенной композиции системы, позволяющей собрать и запускать любую прогу с определенными зависимостями, собранными именно так, как ей надо (версии, окружение сборки и пр.), и при этом чтоб пакеты, сборочные выражения которых оказались идентичными уже установленным, не дублировались. Без костылей вроде дедупликации. Без уродливого, неудобного и ненадежного разделения на «базовую систему и приложения». Бонусом идет возможность наглядно видеть, из чего состоит система и что от чего зависит.

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

Версии-то не фиксируются никак.

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

Сейчас эту проблему «решают» делая несколько вариантов с версией в имени. Например: python39, python310 и т.д.

У дефолтного python в любом конкретном срезе никсос тоже есть определенная версия. Последняя, которую протестировали ментейнеры на момент мержа в релиз бранч. А эти attribute names с версиями прямо в них самих - для другого софта, входящего в состав никсос, которому нужна именно 3.10, хотя последняя 3.11, например. Зачастую используют одно и то же обобщенное никс выражение. Если в никсос нет софта, которому нужна старая версия ХХХ - то для нее не будут делать attribute name. Если юзеру надо - он может сделать сам (в общем случае намного проще, чем с пакетным менеджером в обычном дистре).

Т.е. то, что работает сейчас, не факт что заработает через какое-то время.

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

Конфиг может перестать работать с новым срезом никсос (вернее, новый срез никсос со старым конфигом), т. е. попытка обновиться (сбилдить новую версию системы) будет фейлиться. Но благодаря самой концепции неудачная попытка обновиться не навредит уже запущенной системе, а при исправлении проблемы не надо будет возиться с коллизиями нового и старого.

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

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

Получается, что ты ничего не понял.