История изменений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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