NixOS

NixOS
Разработчик	Элко Долстра[вд], Питер Саймонс[вд][4] и Томас Тюгель[вд]
Семейство ОС	Unix-подобные ОС
Основана на	Nix package manager[5], ядро Linux и systemd
Исходный код	открытый
Первый выпуск	в 2003 году
Последняя версия	24.11[1] (31 ноября 2024; 16 месяцев назад (2024-11-31))
Менеджеры пакетов	Nix package manager
Поддерживаемые платформы	полностью поддерживаемые: x86-64, AArch64;[2] ограниченная поддержка (необходима сборка из исходного кода): i686[3]
Тип ядра	монолитное (Linux)
Лицензия	лицензия MIT[5]
Состояние	в разработке
Репозиторий исходного кода	github.com/NixOS/nixpkgs
Веб-сайт	nixos.org (англ.)
Медиафайлы на Викискладе

NixOS — дистрибутив Linux, созданный поверх менеджера пакетов Nix. Он использует декларативную конфигурацию, контейнеризацию всех программ с хэшированием, и инкрементное сшивание их в состояния (поколения). Это гарантирует однозначность и предсказуемость состояния системы и обновлений в любой точке, и возможность возврата к любому предыдущему состоянию средствами ОС^[6]. Предлагаются два основных подхода к обновлениям: с использованием текущего стабильного выпуска или с подключением канала Unstable для постоянного получения свежих пакетов, как это происходит у дистрибутивов с плавающим выпуском.

Проект NixOS начинался как исследовательский проект, но сейчас разрабатывает операционные системы^[7].

NixOS разрабатывается под сферу DevOps, и имеет инструменты, посвященные задачам развёртывания^[8][9].

Проект начался в 2003 году как исследовательский проект голландца^[6] Элко Долстра (Eelco Dolstra) в Утрехтском университете под руководством Элко Виссера, известного учёного-информатика. Докторская диссертация Долстры 2006 года «Чисто функциональная модель развёртывания программного обеспечения» описывает декларативный и функциональный подход к развёртыванию программного обеспечения и излагает проектирование менеджера пакетов Nix^[10][11].

Первый прототип NixOS был создан Армином Хемелем в 2006 году в рамках его магистерской диссертации «NixOS: Операционная система на основе Nix», в которой исследовалось применение Nix и его принципов в дистрибутивах Linux. Хемель продемонстрировал применение управления пакетами, системных служб, управления ядром и других принципов, определяющих NixOS^[12][13]. В декабре 2009 у проекта появился свой логотип в виде снежинки, созданный Саймоном Франкау, в котором обыгрывается значение слова nix на латыни («снег»)^[14]. После продолжения разработки NixOS в 2013 году был выпущен первый стабильный релиз дистрибутива версии 13.10^[15].

В 2015 году был создан фонд NixOS, чтобы помочь проектам, поддерживающим чисто функциональную модель развёртывания, такую как NixOS^[16].

Начиная с 2021 года NixOS выпускается в виде стабильных версий дважды в год, в конце мая и ноября^[17][18]. До выхода первого стабильного релиза в 2013 году версии крупных релизов нумеровались по семантическому принципу, вплоть до версии 0.2^[19], стабильные релизы начали нумероваться по дате выхода и называться в честь каких-либо животных.

В NixOS вся операционная система — ядро, приложения, системные пакеты, файлы конфигурации и т. д. — создаётся менеджером пакетов Nix из описания на функциональном языке сборки. Это означает, что создание новой конфигурации не может перезаписывать предыдущие конфигурации^[20].

Система NixOS настраивается путем написания спецификации функций, которые пользователь хочет на своей машине, в глобальном файле конфигурации. Например, вот минимальная конфигурация машины, на которой запущен демон SSH^[21]:

{
  boot.loader.grub.device = "/dev/sda";
  fileSystems."/".device = "/dev/sda1";
  services.sshd.enable = true;
}

После изменения файла конфигурации система может быть обновлена с помощью nixos-rebuild switch.

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

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

NixOS имеет транзакционный подход к управлению конфигурацией, вносящий изменения в конфигурацию, такие как атомарные обновления. Это означает, что если переход на новую конфигурацию прерван — скажем, сбой питания на полпути — система все равно будет в согласованном состоянии: она загрузится либо в старой, либо в новой конфигурации. В других системах система может оказаться в несогласованном состоянии и может даже не загружаться^[22]. То же самое относится к текущему состоянию системы. Фактически любое обновление - это самодостаточная, новая система. Присутствуют инструменты проверки состояния, а обращение к компонентам через хэш-суммы создает встроенную дедупликацию.

Если после обновления системы новая конфигурация нежелательна, её можно откатить с помощью специальной команды nixos-rebuild switch --rollback.

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

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

Язык сборки Nix, используемый NixOS, указывает, как создавать пакеты из исходного кода. Для предотвращения сборки наиболее часто используемых пакетов, повсеместно используется автоматический сборщик (Hydra) и пул с готовыми бинарными пакетами. Менеджер пакетов автоматически загружает предварительно созданные двоичные файлы с кэш-сервера, когда они доступны. Это даёт гибкость и прозрачность базирующейся на исходном коде модели управления пакетами с эффективностью двоичной модели^[23].

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

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

NixOS основан на диспетчере пакетов Nix, который хранит все пакеты отдельно друг от друга в хранилище пакетов.

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

Следствием этого является то, что NixOS не соответствует стандарту иерархии файловой системы (но может его создать для конкретного пакета). Единственными исключениями являются symlink /bin/sh для версии bash в менеджере пакетов Nix (например: /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/) и, в то время как у NixOS есть каталог /etc для хранения файлов конфигурации всей системы, большинство файлов в этом каталоге являются символическими ссылками на сгенерированные файлы в /nix/store, такие как /nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config. Отказ от использования глобальных каталогов, таких как /bin, позволяет существовать нескольким версиям пакета.

Джеси Смит написал обзор NixOS 15.09 для DistroWatch Weekly^[24]:

DistroWatch Weekly также имеет обзор NixOS 17.03, написанный Эваном Сандерсом^[25]. По состоянию на 2023 год NixOS прекрасно подходит в качестве настольной операционной системы общего назначения, в том числе игровой, и содержит как большой выбор рабочих окружений, игр, а также steam, proton, lutris; избавляя владельца от необходимости следить за частными изменениями и полностью убирая риски поломать систему при обновлении.

• Константин Владимирович Черемнов. Функциональный менеджер пакетов Nix: Часть 1.Базовое использование  (рус.) (недоступная ссылка — история). IBM DeveloperWorks (1 апреля 2010). Дата обращения: 9 января 2016.
  • К. В. Черемнов. Функциональный менеджер пакетов Nix: Часть 2. Специализированный язык  (рус.) (недоступная ссылка — история). DeveloperWorks (6 апреля 2010). Дата обращения: 9 января 2016.
  • К. В. Черемнов. Функциональный менеджер пакетов Nix: Часть 3. Описание сборки пакета  (рус.) (недоступная ссылка — история). DeveloperWorks (8 апреля 2010). Дата обращения: 9 января 2016.
  • К. В. Черемнов. Функциональный менеджер пакетов Nix: Часть 4. Дистрибутив NixOS  (рус.) (недоступная ссылка — история). DeveloperWorks (23 сентября 2010). Дата обращения: 9 января 2016.
• Oliver Frommel. NixOS and the case for declarative configuration // Linux Magazine. — 2014. — № 163.
• Eelco Dolstra. Purely Functional Configuration Management with Nix and NixOS . InfoQ (8 июня 2014). Дата обращения: 9 января 2016.
• Ричард Смедли. LXFHotPicks. Nixos // LinuxFormat. — 2014. — Август (№ 8 (186)). — С. 102.
• Анатолий Ализар. NixOS: дистрибутив с декларативной конфигурацией . «Хакер» (20 мая 2013). Дата обращения: 9 января 2016.

• nixos.org — официальный сайт NixOS
• Domen Kožar, перевод: Денис Шевченко. Nix: идея . ruhaskell.org. Дата обращения: 9 января 2016. (оригинал: Why Puppet/Chef/Ansible aren't good enough (and we can do better) . Domen Kožar (11 марта 2014). Дата обращения: 9 января 2016.)