Comments 119
Непрерывная интеграция или почему Guix может работать без мейнтейнеров пакетов: благодаря воспроизводимым сборкам и поддержке частичных обновлений, если пакет работает в Guix, то он будет работать «всегда» и не сломается при следующем обновлении какой-то зависимости (точнее, если зависимость ломает пакет, то это тривиально исправляется, чтобы использовать правильную версию библиотеки). Таким образом, работу с пакетами можно перенести на «фермы сборки» (одна на Hydra из проекта Nix, другая на Cuirass). Сравните это с большинством других сообществ GNU/Linux, которым для обновления тысяч пакетов требуются десятки мейнтейнеров. Такой подход не масштабируется: в итоге эти дистрибутивы стагнируют на паре тысяч пакетов. В Guix количество пакетов может спокойно расти, не опасаясь краха. В то же время контрибуторов можно использовать более эффективно.
А как это работает? Ну вот вы берете пакет X, который зависит от пакета A версии 1.0, берете пакет Y, который зависит от пакета A версии 2.0, которая не совместима с версией 1.0.
У вас есть три варианта:
- Обновить код пакета Y для версии 2.0, для этого нужны мейнтейнеры.
- Даунгрейднуть пакет X до версии, которая работала с 1.0, для этого так же нужны мейнтейнеры, что бы перенести фиксы.
- Статическая линковка, которая в рамках десктопных систем недопустима, потому что системе будет весит чертовы террабайты.
Чем Guix лучше? Тем, что может в простых случаях собрать валидный сабсет пакетов? Ну, такое можно в большом количестве систем.
Есть ещё вариант. Динамическая линковка X и Y к нужным версиям. т.е. будет в системы два пакета A версии 1.0 и 2.0, до тех пор пока разрабы X-а не обновят зависимости до 2.0 и можно будет старую версию автоматом почистить.
— если пакет A в версии 1.0 — зависит от пакета K версии 4.3.1 и только так. в K версии 4.4.0 — убрана какая то нужная вещь. При этом две версии K одновременно — запущены быть не могут никак. Потому что это ядро.
— если пакет A в версии 1.0 — имеет удаленно-эксплуатируемую дыру и при этом обновление A — все же сломает частично пакет Y (и без этого — либо никак либо очень долго и сложно). Кто должен принять решение что да — мы частично ломаем функционал пакета Y но спасаем пользователей. Сам пользователь? Сисадмин?
— если пакет А в версии 1.0 имеет какой то функционал который разработчикам пришлось вырезать в версии 2.0 потому что выяснилось что патенты. Как быть тем кто поддерживает репозитории — выносить A в non-free-репозиторий не смотря на то что поправлено? Рисковать что на них наедут с теми же патентами?
— если у нас стоит задача запустить вот это вот — на системе где то что должно быть пакетом K — вот конкретно этой фиксированной версии (для которой даже пакета то не сделали) и изменить это — нельзя. Например...K это ядро а задача стоит — запустить систему под Linux-on-DeX ну или — внутри контейнера той же Virtuozzo (про докер даже не говорю пока).
В Guix в описанном случае в описании пакета X может быть указано явное использование A версии 1.0, и пакет продолжит собираться и работать так же, как и раньше (в том числе со всеми ошибками и проблемами безопасности, присутствовавшими в A 1.0). Теоретически такое возможно и в обычном rpm-based или deb-based дистрибутиве, если мантейнер пакета A вместо простого обновления пакета A с версии 1.0 до 2.0 создаст отдельные пакеты A1 и A2 (и к ним, скорее всего, A1-devel и A2-devel), однако в Guix подобное «размножение» пакетов происходит само собой — при любом изменении в исходных текстах, скриптах сборки или других используемых при сборке пакетах меняется и хеш собираемого пакета, в результате новая сборка помещается в отдельный каталог в /gnu/store, где может существовать одновременно с любым количеством предыдущих сборок того же пакета. В бинарных файлах пакетов X и Y при их сборке прописываются конкретные пути в /gnu/store, указывающие на точную версию их зависимостей, в результате они могут использовать разные версии пакета A, даже если разделяемые библиотеки в этих версиях по каким-то причинам имеют одинаковые soname (в обычных дистрибутивах такое возможно только при различных soname).
Ничего апгрейдить/даунгрейдить не нужно, нужные версии пакетов можно просто указать в зависимостях. Т.е. если пакет был однажды написан — он будет работать, пока исходники не удалят.
Статическая линковка, которая в рамках десктопных систем недопустима, потому что системе будет весит чертовы террабайты.
Это уже произошло в JavaScript и постепенно происходит в десктопе (например, winsxs). Игры вообще испокон веков распространялись вместе со своим рантаймом: vcc redist, DirectX, не говоря уже о middleware.
P.S. Терабайт не имеет ничего общего с землёй.
Есть огромное множество проектов на доморощенных или слишком ограниченных языках:
…
Повторное изобретение колеса, обычно, не самая хорошая идея.
А что нужно использовать вместо SQL, Octave, JSON или LaTeX? Может, стоило вообще остановиться на Fortran, чтоб не изобретать колесо?
самое интересное что они Lisp и Scheme записали в "доморощенные или слишком ограниченные языки" в то время как сами продвигают свой Guile.
Переводчику надо оторвать руки. Оригинал:
Octave, R, PARI/GP, most scientific programs (better ideas: Common Lisp, Racket and other Scheme)
Правильный перевод:
Octave, R, PARI/GP, большинство научных программ (более лучшая альтернатива им: Common Lisp, Racket и другие реализации Scheme)
Совершенно другой смысл.
Главная цель перевода — передать исходную идею. Это и есть критерий правильности. А если я вдруг надумаю переводить в массовом масштабе, то назначу вас моим редактором, видимо у вас куча свободного времени и въедливые глаза.
В любом случае — сообщество (включая меня) готово Вам помочь сделать все красиво и аккуратно )
Масляное масло передает смысл более лучшее?
И «более хорошая» и «более лучшая» - звучит отвратительно, если уж хочется то "Еще лучше использовать бла, бла "
Есть ваше личное мнение, а есть правила русского языка. "Более лучшая" нарушает правила русского языка, "более хорошая" – нет. "Ещё лучше" вообще имеет несколько другой оттенок, и напрямую "более хорошая" не заменяет.
Есть ваше личное мнение, а есть правила русского языка.
Сразу оговорюсь, что я не использую более с превосходной степенью. Но вот с утверждением про правила не согласен. Грамматика не дана нам свыше, она лишь фиксирует то, как люди говорят. Если все будут говорить более лучшая, то и правила поменяются.
Вот хорошая статья на эту тему: https://sysblok.ru/blog/pravilnost-v-jazyke-a-sudi-kto/
Очередной БолгенОС с нескучными пакетами?
Нет. Тут принципиально новый подход к управлению пакетами и системой в целом.
Через настраиваемый слой совместимости, с трансляцией системных вызовов?
Почему бы и нет? Скажем, ZFS во FreeBSD работает через opensolaris.ko
Благородное начинание, гарантированное на умирание (жизнь в своей нише). Причина? Выбор schema как языка. Никто не будет учить новый тьюринг-полный язык, чтобы чуть сделать пакет.
В целом — идея интересная, и вот вам несколько простеньких задачек для решения:
dpkg-divert --local --divert /etc/ansible/ansible.cfg.dist --no-rename /etc/ansible/ansible.cfgupdate-initramfsпри установке нового компонента (например, dm-crypt) для обработки initramfs хука (надо же добавить программу для расшифровки диска на этап до расшифровки диска, ha.ha).update-alternatives(например, editor -> /usr/bin/vim)apt-mark hold libfoobar-3.2-3-nmu3Package: * Pin: origin private.example.com Pin-Priority: 600
Если для каждого из них покажете пример в этой самой schema-driven package management, то тогда я его перестану считать CS-экспериментом.
(Upd: это перевод… мдя, извините за энтузиазм).
Никто не будет учить новый тьюринг-полный язык, чтобы чуть сделать пакет.
repology.org
Most packages: nixpkgs unstable
Ну никто, да-да-да.
Извините, на Scheme не можу, буду на nix.
dpkg-divert --local --divert /etc/ansible/ansible.cfg.dist --no-rename /etc/ansible/ansible.cfg
Просто перетаскивание файлика пакета в другое место — легко через override. Если нужно файлики конфигурации перетаскивать — элементарно в NixOS черезenvironment.etcили в home-manager черезhome.file
update-initramfs при установке нового компонента (например, dm-crypt) для обработки initramfs хука (надо же добавить программу для расшифровки диска на этап до расшифровки диска, ha.ha).
Реализовано в NixOS. Просто выставляете опцию шифрования диска, всё остальное — автоматически.
update-alternatives (например, editor -> /usr/bin/vim)
stdenv.mkDerivation { name = "editor"; buildPhase = '' mkdir -p $out/bin ln -s ${pkgs.vim}/bin/vim $out/bin/editor ''; }
Как пример. Можно сделать через alias, или ещё кучей способов, если мы на NixOS.
apt-mark hold libfoobar-3.2-3-nmu3
nixpkgs pinning для одного пакета. Известная техника. Суть такая:
let nixpkgs_pin = import (builtins.fetchGit {url = "https://github.com/nixos/nixpkgs"; rev="commit-with-needed-package-version";}) {}; pinned_libfoobar = nixpkgs_pin.libfoobar; in pinned_libfoobar;
Package: * Pin: origin private.example.com Pin-Priority: 600
Что это такое?
Package: *
Pin: origin private.example.com
Pin-Priority: 600
Что это такое?
Это /etc/apt/preferences.d/ — приоритеты для реп в apt
Тогда можно провести прямую аналогию с каналами в Nix. Только в nix всегда явно указывается канал, так что проблем с приоритетом каналов нет.
Извините за задержку с ответом.
Итак, у нас декларативный язык, который решает проблему update-alternatives… исполнением mkdir и ln. Это точно, guile, а не bash?
Дальше, я написал простое: apt-mark hold libfoobar-3.2-3-nmu3. Вы написали
let nixpkgs_pin = import (builtins.fetchGit {url = "https://github.com/nixos/nixpkgs"; rev="commit-with-needed-package-version";}) {};
pinned_libfoobar = nixpkgs_pin.libfoobar;
in pinned_libfoobar;Т.е. вы мне, как оператору, предлагаете писать ЭТО? Можно я сразу забракую всю конструкцию за невыразимую антиэстетичность?
Итак, у нас декларативный язык, который решает проблему update-alternatives… исполнением mkdir и ln. Это точно, guile, а не bash?
- Это не guile, это nix
- Если мы не ограничены присутствием другого пакетного менеджера в системе (т.е. мы находимся на nixos/guixsd), у нас есть куча других способов добавить в PATH бинарник с нужным именем, указывающий на другой бинарник. (А мне лично удобнее пользоваться alias'ами, которые у меня декларативно указывают на нужное мне приложение, например e ->
emacsclient) - Не вижу ничего плохого в использовании UNIX-утилит. Те, кто видят в этом плохое, используют guix и пишут установочные скрипты на scheme.
Дальше, я написал простое: apt-mark hold libfoobar-3.2-3-nmu3И через пару апдейтов всё сломалось, а у меня будет работать (условно) всегда, пока github.com онлайн и старая версия libfoobar с зависимостями не удалена из интернетов. Ну и я забыл упомянуть, что pin можно сделать один на всю конфигурацию, и потом писать просто [ pin.libfoobar pin.bash pin.hello ].
Хотите эстетики?
let
nixpkgs_pin = import (
builtins.fetchGit
{
url = "https://github.com/nixos/nixpkgs";
rev = "commit-with-needed-package-version";
}
) {};
pinned_libfoobar = nixpkgs_pin.libfoobar;
in pinned_libfoobar;Это как я бы написал у себя в конфиге.
Теперь к настоящей красоте nix: оверрайдам. Хочу, чтобы compton с анимациями!
compton = old.compton.overrideAttrs (oldAttrs: {
src = builtins.fetchGit {
url = "https://github.com/BlackCapCoder/compton";
ref = "master";
};
});И мне не нужно заботится о процессе сборки compton.
Хочу телеграм с wide-baloons!
tdesktop = old.tdesktop.overrideAttrs (oldAttrs: {
patches =
[
("${builtins.fetchGit
{
url = "https://github.com/msva/mva-overlay";
rev = "7b61558a20a92920c1594d46a68f713e199957ad";
}}/net-im/telegram-desktop/files/patches/1.5.8/conditional/wide-baloons/0001_baloons-follows-text-width-on-adaptive-layout.patch"
)
] ++ oldAttrs.patches;
});Ещё одно преимущество, вытекающее из повторяемости — хорошая "оффлайновость." Нужно поставить пакет на компьютер без интернета?
nix-store --export $(nix-store -qR $(nix-build 'nixpkgs-version-on-offline-pc' -A firefox)) > outout кидаем на флешку, переносим на компьютер без интернета,
nix-store --import < outПолучаем нужную софтину, которая гарантированно работает (ибо все зависимости идут вместе с ней).
В nixpkgs есть древние версии gcc и средств сборки специально для таких случаев. Даже пинить ничего не надо — просто выбираем версию постарше в buildInputs.
Вообще пока что я вижу, что хоть и nixpkgs гибче, но бинарные ПМ типа rpm/deb при условии верного прописывания версий зависимостей в манифестах (это на самом деле очень важно!) работают как-то попроще. Для пользователя.
Предположим, что для сборки cmake-проекта foobar нужен gcc версии 4 и утилиты, которые идут с этим gcc. Пишем
stdenv.mkDerivation {
name = "foobar";
src = ./.; # Сырцы там же, где и default.nix
nativeBuildInputs = [ gcc49 cmake pkgconfig ];
buildInputs = [ libfoo libbar libbaz ]; # Используемые библиотеки
}И получаем именно то, что нам нужно.
Ну, и вообще хочется понять насколько это годная история, поэтому задаю такие вопросы.
Здорово, что есть возможность руками выбрать, но все-таки, как мне кажется, это задача мейнтейнера задавать вот эти вот ключи для правильной сборки.
Именно мейнтейнеры nixpkgs и занимаются выбором правильных ключей сборки и зависимостей так, чтобы пользователь набрал просто nix-env -iA nixos.foobar и получил нужную программу, не задумываясь о ключах сборки и зависимостях. Когда мы пишем пакет сами, вполне логично, что мы должны выполнять работу мейнтейнера.
Выбор schema как языка. Никто не будет учить новый тьюринг-полный язык, чтобы чуть сделать пакет
Lisp/scheme "учится" за полчаса и на всю жизнь. Хотя соглашусь, что тонны скобок могут напрягать.
В использовании DSL и есть идеология Unix. Но как только вам нужно выйти за рамки специального DSL, то начинается ад, начиная с выбора инструмента, на котором вы будете это делать и заканчивая установкой всех необходимых для этого зависимостей. Количество новых проблем начинает расти экспоненциально. Хотите расширить что-то работой другого разработчика, а он принял другие решения, использует другие инструменты, тянет очередные зависимости. В итоге получаем Linux с его зоопарком дистрибутивов, конфликтами зависимостей и отсутствием общеупотребимых инструментов автоматизации. О чем и написано в статье.
Ничто не мешает создать подмножество Lisp/Guile для конфигурационных файлов с урезанным функционалом.
Кроме того, Portage страдает от той же проблемы с отсутствием надлежащей поддержки нескольких версий
Да ладно? А слоты?
Да apt, portage и подобные обросли, но у них нет будущего.
Надеюсь, Guix и Nix вытеснят уже архаичные костыли apt, yum и им подобное.
Скажем, последний mpv требует нового ffmpeg, но обновление ffmpeg ломает большинство других программ. Мы застряли перед дилеммой: либо ломаем некоторые пакеты, либо сохраняем старые версии.
Если авторы mpv не умеют правильно собрать пакет под конкретную версию дистрибутива, или вы пытаетесь воткнуть в систему пакет собранный для другой версии, то вы, очевидно, сами себе ищете приключений.
Да всем(подавляющей части обычных юзеров планеты) плевать на открытость, какие-то там решения по настройке\сборке пакетов и прочее подобное.
А ведь рецепт(вкратце) убийцы винды\осх прост — красивенький и понятный, никаких hrenznaet4tozademon.conf на 100500 строчек ui + запуск пакета адоба + MS Office + всякие автокады в 1 очередь. Остальное и так почти все уже кроссплатформенное или умеет в wine. И никаких заменителей
Я до сих пор искренне не понимаю почему какой-нить дистр на Linux до этого не дошел — все пляшут на одних и тех же граблях и пытаются переизобрести свое колесо
Периодически смотрю, но он, к сожалению, как умирал на средненькой портянке 400x8000, так и умирает.
Получается, что совместимость на уровне форматов есть (docx, odt etc.), но фактически юзеры как раньше страдали, так и страдают раньше.
(просто предположение)
1) Оно верно
2) Whocares
Тут была цитата, правда к другой теме, но все же она идеально подходит и сюда —
стандарт — это то, что используют, а не то, что написано на бумагах, но не поддерживается почти никем…
А отношение про «стандарт — это то, что [только] мы используем» — очень полезное с точки зрения vendor lock-in, но крайне вредное для кооперации B2B, конкуренции в сфере услуг, и с точки зрения антимонопольных законов тоже.
Кстати, это касается даже корп. серверов(если это не веб офк) — например та же почта.
Сколько надо времени(утрированно, но не сильно) настроить всю обвязку почтовика на лине с клиентами на аутглюке с доменной аутентификацией? А маштабировать это все?
А теперь берем, ну например hMail или, даже, Exchange — поменяется только кол-во доступных фишек: далее-далее-далее-%мастер настройки фичи%-ок.
Все. Все уже работает и через 15 мин в продакшене и может поддерживаться джуниор-помошником админа. Профит.
Вот пока в линуксе не будет чегонить подобного(есть конечно зимбра, но при ее аппетитах — шилонамыло) у линукса шансов объективно примерно чуть ниже нуля.
А маштабировать это все?
Как раз на лине масштабируется легко, в отличие от Win. Времени на настройку уходит не сильно больше (в пределах одного порядка, по личному опыту), а вот квалификация требуется сильно повыше. Так что если нужна надёжная система с высокой масштабируемостью — берут линукс и нанимают профессионала, если нужно просто вот сейчас сервачок — то берут сына ген. директора и win.
Если обновление что-то сломает, всегда можно откатить.Объясните мне на пальцах, как это спасёт от
rm -rf /usr /share/...Только в процессе обновления таких команд быть не может.ORLY?
rm -rf /nixВ функциональных менеджерах нет императивного удаления.
Если надо обновить версию драйвера — прописываете его в конфиг и делаете операцию «привести систему в соответствие с конфигом» — и он сам удалит всё что не нужно.
типичное заблуждение касательно любых SCM (ansible, puppet etc.). Они действительно должны так работать, но под капотом все равно императивщина (а как еще назвать инструкции вроде «удали файл такой-то», «перезапусти сервис» и пр.). Даже хуже — некоторые вещи в парадигме «хочу что-то» (т.е. описываем желаемый конфиг) не работают, что и приводит к необходимости написанию своих модулей для SCM и модулей типа «kubernetes operator» для k8s.
ну так не надо левые приложения запускать под рутом. А если такого сорта баг в ядре (т.е. в основе системы, не обязательно kernel), тогда спасут только бэкапы на сервер расположенный в другой пожарной зоне :)
Будет ли это кто-то делать, когда мы тут за bleeding edge и git clone в качестве первого шага установки, указанный мной инцидент прекрасно продемонстрировал.
Не съест. Прав у nix-builder-0 не хватит на удаление этой папки, в "худшем" случае удалится только $out, т.е. сам пакет.
По умолчанию используется sandbox сборка. Этот каталог не будет виден билдеру
Пока что десктопные ОС похожи на какой-то зоопарк который пытаются решить костылями типа докера, хоть и весьма изящными, но костылями.
В nix/guix сборщик очень ограничен в своих действиях. Я могу попытаться собрать даже rm -rf /, но nix-builder-0 просто не имеет прав на что-либо, кроме своей папки в tmp (rwxrwxrwx) и buildInputs (r-xr-xr-x). Т.е. читать он может только свою маленькую директорию и директории входных пакетов, а писать может только в свою директорию.
Но — NixOS, я пробывал, но этот DSL что то с чем то *непереводимая игра слов*. Прикрутить туда тоже VScode заставило меня достать пылившийся бубен.
Guix — ребят, ну зачем эта излишняя фриварщина? Покупать новое железо под ОСь с неизвестными будущем? и кричать я весь такой фриварный… нет зондам. Emacs? — это прям вообще убер фича? Мое мнение — прикрутить отдельную репу проприетарщины, кому надо то поставит, прикрутить туда IDE из каробки помимо Emacs и VIM. Сделать как Manjaro — Community Release с разными DE. И проект взлетит!
Прикрутить туда тоже VScode заставило меня достать пылившийся бубен.
Одна строка в конфиге — это пылящийся бубен? Серьёзно?
Мое мнение — прикрутить отдельную репу проприетарщины, кому надо то поставит, прикрутить туда IDE из каробки помимо Emacs и VIM.
В nixos по-сути так и сделано. Выставляем опцию nixpkgs.config.allowUnfree = true; и ставим несвободные пакеты в своё удовольствие.
Статья написана так, будто guix сам сын автора создавал)
Но решение приведенное в статье выглядит как академические изыскания, а не как реальное решение проблемы. К тому же, я, как и многие другие, скорее готов изучить YAML/JSON/TOML или любой другой человеко-читаемый формат описания манифестов пакетов, чем генерировать код на Scheme, который может все. К тому же, раз код манифестов в GuiX по сути написан на Scheme и обладает бесконечными возможностями расширения, то это очередная Тьюринг-полная машина, в которой можно насоздавать бесконечное количество уязвимостей. Как это все аудировать? Ответа нет.
Для серверов будущее очевидно. Оно в ОС, изменяющихся атомарно (CoreOS Container Linux и клоны). Программы — в контейнерах типа docker («все свое ношу с собой»). Если заглядывать дальше, то вообще переход на serverless (aka lambda).
А по мне джента ничего так — если ставятся пакеты, которые скоро удалятся — emerge undelete xxx в системе после depcleana останется, будет в 2х слотах… про зависимости — а кто мешает в \etc\portage\use написать для проги yyy use python2 для проги zzz python3… правда заморочки с версиями ruby достают надо явно писать use ruby 5.2 <<-4.8 Также — про «одну актуальную версию» — гугль в помощь, как правило лежат нестабильные версии, актуальная и 5-6 предыдущих — никто не запрещает скачать исходники в локальный портаж, было-бы желание можно и 2.26 ядро собрать, с gcc и linux-headers…
Как-то на raspberry pi настраивал сеть, сам я не админ, поэтому многое было в новинку. Дело осложняло то что версий малины за 5 лет накопилось много и часто гайды были устаревшими. По итогу пришлось настраивать сразу 2 компонента из-за того что новый не работал во всех случаях.
Другой случай был с rtx 2080 fe на убунте. Эта видеокарта не работала должным образом из-за отсутствия драйверов, можно было разве что довольствоваться разрешением ~600х600. После установки дев-версий драйверов, разрешение удалось выставить в 1440p, но необходимую частоту — нет. После нескольки часов гугления и работы с разными конфигами удалось все же выставить частоту обновления 165гц. Так же пока что нет сборки хрома с поддержкой 165гц для линукса, только хроминум который не может стабильно выдавать такую частоту и выдает 80fps с просадками до 40.
Что в винде? В винде через 5 минут скачался и установился драйвер, через 1 минуту была выставлена настройка 165гц обновления, хром сразу перешел на нужную частоту.
При корявости винды все заработало за условные 6 минут, в линуксе за 2-3 часа и не полностью.
Есть докер и k8s, наконец, где вообще не так важно, какая там у тебя операционная система под капотом и где пакеты вообще не особо нужны.
Ниша у «полностью программируемой OS» наверняка есть, но тратить месяц на настройку, чтобы потом держать 100 человек на поддержке — очень специфичный use case.
Ехать же надо, а не шашечки. Если для каждой поездки надо месяц готовить машину, в большинстве случаев такое не взлетит.
Nixos/guixsd очень хорош, когда машин больше десяти. Тогда ты пишешь один раз конфиг (да, это может занять пару дней или даже неделю), а потом просто раскатываешь его по всем машинам. Если всё правильно сделать, то изменения настроек можно делать просто редактированием конфига и после этого nixos-rebuild switch --target-host .... Когда машина одна, преимущества тоже есть (атомарность + декларативность + rollbacks + изолированность + повторяемость + легкость оверрайдов a-la gentoo, только эти оверрайды ещё и аддитивны, и т.д.)
не так важно, какая там у тебя операционная система под капотом
nix тоже запускается на всём POSIX-совместимом.
А вообще — относитесь ко мне с подозрением, ведь я уже потратил месяц на написание конфига и теперь ни за что не признаю ошибки :)
но тратить месяц на настройку, чтобы потом держать 100 человек на поддержке — очень специфичный use case.
Около 400. + NixOps. И да, rollback. Месяц, хм, Вы не поверите…
По сравнение с арч в nixos не так оперативно выкатывают обновления на новые версии.
www.gnu.org/philosophy/open-source-misses-the-point.html
Guix — самая продвинутая операционная система