Хабр·Russia·Tuesday, September 15, 2026 at 01:25 PM

Простая декларативная установка NixOS, часть 3.5(теория) — Пакеты Nix и Nix Flakes, что это такое и с чем это едят?

Translate

AlexandrBelkov19 минут назад

Эта статья является прямым продолжением этой статьи, посвящённой декларативной разметке диска через disko.

Что мы будем делать сегодня?

Мы с вами разберёмся, что такое флейки, что они из себя представляют, а вместе с этим разберёмся с тем, как Nix устанавливает и хранит пакеты.

Это ЧИСТО ТЕОРЕТИЧЕСКАЯ статья, а не практическая. Иными словами - мы не будем сегодня писать никаких конфигураций или команд. Наша задача на данный момент - разобраться, что такое флейки и какую проблему они решают, прежде чем перейти к непосредственной работе с ними.

Что мы узнаем?

Что такое флейки, зачем они нужны и чем отличаются от стандартного nix-channels
Как работает установка и хранение пакетов в NixOs

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

1. Откуда берутся пакеты в Nix?

В Nix пакеты берутся из официального Git-репозитория Nixpkgs, который является одним из самых больших и активно обновляемых репозиториев(честно говоря, самого ПО там не так много, как в том же AUR, большая часть - это добавки к тем или иным пакетам или их другие вариации).

Если говорить упрощенно, путь пакета от исходного кода разработчика до вашего компьютера выглядит так:

Всё начинается с репозитория Nixpkgs(лежит на GitHub)
Nixpkgs - это огромный репозиторий на GitHub, где лежат тысячи текстовых файлов с расширением .nix. Важно учесть, что:
1. В этих файлах нет готовых программ.
2. Там написаны "РЕЦЕПТЫ"(их называют деривациями или derivations). В таком рецепте строго зафиксировано: откуда скачать исходный код программы(например, с гитхаба автора), какие зависимости ей нужны для сборки и какие команды выполнить(например, make и make install).
Официальная сборка через Hydra
Поскольку собирать каждую программу из исходников на компьютере пользователя - это долго и ресурсоемко, у проекта Nix есть собственная CI/CD система автоматической сборки, которая называется Рydra.
1. Hydra постоянно следит за изменениями в репозитории Nixpkgs на GitHub.
2. Как только в Nixpkgs обновляется рецепт какой-то программы, Hydra берет этот рецепт и автоматически собирает программу на мощных серверах.
3. Процесс сборки происходит в абсолютной изоляции. На выходе получается готовый бинарник (скомпилированная программа).
Кэш готовых пакетов(Binary Cache)
После того как Hydra успешно собрала программу, готовый бинарный файл отправляется в официальное облачное хранилище - бинарный кэш (по умолчанию это адрес cache.nixos.org).
Каждому собранному пакету присваивается уникальный хэш(длинная строка из букв и цифр), который зависит от всего: версии исходного кода, флагов компилятора и версий всех зависимостей.
Если уже есть готовый собранный результат, Nix просто скачивает скомпилированный бинарник из официального кэша cache.nixos.org. Это происходит в большинстве случаев.
НО если готового бинарника в кэше нет(или вы изменили флаги компиляции в настройках), Nix автоматически скачает исходный код автора программы и скомпилирует его прямо на вашем компьютере строго по инструкции из Nixpkgs.

Альтернативные источники

Помимо официального Nixpkgs, благодаря архитектуре Nix(особенно флейкам), вы можете брать пакеты откуда угодно(или даже делать их сами):

Cторонние репозитории от сообщества (например, NUR - Nix User Repository, аналог AUR в Arch Linux).
Напрямую от разработчиков: сегодня многие разработчики(особо крупных программ) добавляют файл flake.nix прямо в корень своих проектов. Вы можете установить такую программу одной командой напрямую с их GitHub, даже если её еще нет в официальном репозитории Nix. Или установить её навсегда, добавив парочку(буквально) небольших строчек кода, но об этом в другом блоке.

Развёртывание и хранение пакета

Процесс установки и развёртывания пакетов в NixOs кардинально отличается от других дистрибутивов. Вместо распаковки файлов по всей системе(/usr, /etc и прочие) NixOs использует более упорядоченный процесс.

И прежде чем мы приступим, давайте разберёмся с тем, как NixOs вообще хранит у себя пакеты.

NixOS хранит все свои пакеты и системные компоненты В ОДНОМ специальном месте - директории /nix/store. Само хранение пакетов работает на следующих принципах:

Анатомия пути пакета в /nix/store
В NixOS нет привычного разделения программ по папкам /bin, /lib или /usr/share. Вместо этого каждый пакет устанавливается в свою собственную изолированную директорию в /nix/store.
Типичный путь к программе выглядит так: /nix/store/y7irmgx9bi1krcgh6imh36zdz3ha8mvp-python3.13-distlib-0.4.0
Этот путь состоит из трёх частей:
1. /nix/store/ - единое глобальное хранилище(очевидно).
2. Криптографический хэш(y7irmgx9bi1krcgh6imh36zdz3ha8mvp) - уникальный идентификатор. Он генерируется на основе всех входных данных, которые использовались для сборки пакета: исходного кода, зависимостей и флагов компилятора. Если изменить хоть один флаг или версию зависимой библиотеки, хэш станет другим.
3. Имя и версия(python3.13-distlib-0.4.0) - понятное для человеков название программы.
Изоляция и неизменяемость
Вот тут нужно кое-что прояснить! Вы наверняка, услышав про "изоляцию" подумали, что в в директории нашего пакета лежит АБСОЛЮТНО всё и что при установке пакет засовывает все свои зависимости только в свою папку, НО ЭТО НЕ ТАК!
Директория пакета в /nix/store(например, /nix/store/b6gvzjyb2pg0...-firefox-33.1/) содержит файлы только этого самого пакета - его бинарники, библиотеки, конфигурации и т.д. Она не содержит внутри себя копии всех зависимостей.
Каждая зависимость - это отдельный пакет в своей собственной директории в /nix/store. Например, если Firefox зависит от Glibc и OpenSSL, то они будут лежать в других поддиректориях:
```
/nix/store/b6gvzjyb2pg0...-firefox-33.1/
/nix/store/5lbfaxb722zp...-openssl-0.9.8d/
/nix/store/81z9yc6zqmc0...-glibc-2.3.4/
```
Переходим к главному:
- Read-Only: Всё содержимое /nix/store монтируется или защищается в режиме "только для чтения". Ни пользователь, ни сама программа не могут изменить файлы внутри установленного пакета. Это гарантирует, что система не сломается из-за случайного изменения файлов.
- Сосуществование разных версий: Благодаря хэшам в системе могут одновременно и мирно жить две разные версии одной программы (н-р, python-3.10 и python-3.11) или даже одна и та же версия программы, но собранная с разными библиотеками. Они никак не пересекаются и не мешают друг другу.
Симлинки и профили
Поскольку запускать программы напрямую по длинным путям с хэшами неудобно, NixOS использует механизм символических ссылок(симлинков) и профилей.
Когда вы устанавливаете пакет, NixOS создает для вашего пользователя(или для всей системы) специальное окружение, которое состоит из дерева симлинков, указывающих на реальные файлы в /nix/store.
Эти окружения группируются в профили(profiles), которые позволяют разным пользователям иметь разные наборы активных приложений. Симлинк ~/.nix-profile указывает на текущий профиль пользователя. Внутри профиля есть поколения(generations) - ссылки на предыдущие состояния окружения, что и обеспечивает встроенную возможность отката.
Очистка мусора(Garbage Collection)
Поскольку пакеты никогда не перезаписываются, а старые версии не удаляются автоматически при обновлении, /nix/store со временем разрастается.
Для удаления ненужного софта используется мусорщик(Garbage Collector). Утилита nix-collect-garbage сканирует систему, находит те пакеты в хранилище, на которые больше не ссылается ни один профиль пользователя и ни одна конфигурация системы, и безопасно удаляет их с диска.
Атомарные обновления
Это не совсем связано с хранением пакетов, но я подумал, что это также стоит упомянуть.
Атомарные обновления в NixOS - это механизм, который гарантирует, что наша с вами система обновится, грубо говоря, по принципу "всё или ничего". Процесс перехода на новую конфигурацию происходит мгновенно и безопасно, полностью исключая ситуацию, когда система ломается на полпути и перестает загружаться.
Обеспечивается это симлинками, поколениями и хранилищем /nix/store.
Когда вы запускаете обновление системы(например, через nixos-rebuild switch), происходит следующий скрытый процесс:
1. Изолированная сборка: NixOS скачивает новые пакеты и собирает новую конфигурацию - внутри /nix/store. Ваша текущая работающая система при этом вообще никак не затрагивается. Если в процессе сборки отключится свет или пропадет интернет, ничего не сломается, а на диске просто останутся недописанные файлы, которые потом удалит мусорщик.
2. Создание нового поколения: Как только все пакеты и конфиги собраны, NixOS создает новую директорию профиля(Generation), которая состоит исключительно из символических ссылок на файлы в /nix/store.
3. Переключение: Происходит мгновенная смена одной системной ссылки /run/current-system, которая теперь указывает на новое поколение вместо старого.
4. Обновление загрузчика: NixOS автоматически добавляет новую запись в меню загрузчика(GRUB или systemd-boot), сохраняя при этом все старые варианты загрузки.

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

2. Что такое флейки и зачем они нужны?

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

Не поняли? Давайте рассмотрим житейский пример.

Допустим, я на своём Arch Linux написал автоматический скрипт сборки моей системы, который устанавливает нужные пакеты - build.sh:

# Разумеется, это всего лишь максимально упрощённый пример. Настоящие установочные скрипты в крупных сборках выглядят намного крупнее
sudo pacman -S waybar
sudo pacman -S hyprland
sudo pacman -S mako

И вот, мы написали скрипт. Прошёл месяц-два-три - мы ничего в этом скрипте не поменяли, саму систему ни разу не обновляли, но настал день, когда нам по тем или иным причинам нужно переустановить нашу систему. Мы запускаем наш build.sh, переносим наши конфиги и... Они не работают так, как работали раньше - у нас наши пакеты либо вовсе не запускаются, либо работают с багами.

А почему? А потому что наш скрипт УСТАНОВИЛ ПАКЕТ ПОСЛЕДНЕЙ ИЗВЕСТНОЙ ВЕРСИИ, а не той, что стояла у нас на момент написания скрипта. В итоге за все те два месяца разработчики могли добавить какие-нибудь крупные обновления, из-за которых наши старые конфиги перестали работать(привет, хайперленд).

Nix Flakes призван решить эту проблему, и в пункте про flake.nix и flake.lock я вам расскажу, как именно.

Что такое flake.nix, flake.lock

В Nix Flakes есть два ключевых файла: flakes.nix и flake.lock.

flake.nix описывает, ОТКУДА брать зависимости и пакеты.

flake.lock фиксирует каждую зависимость на конкретном Git-коммите. Пока flake.lock не меняется, сборка через месяц, через год или на другой машине даст ровно те же версии пакетов.

Если вы до этого работали с языком программирования Rust, то наверняка встречали файл cargo.lock - именно такую роль и выполняет наш flake.lock: он фиксирует КОНКРЕТНУЮ ВЕРСИЮ всех наших установленных пакетов.

Чтобы вы лучше поняли, вот как выглядит часть содержимого моего flake.lock:

    "xwayland-satellite-stable": {
      "flake": false, # Установлено не через флейки, а через systemPackages
      "locked": {
        "lastModified": 1755491097,
        "narHash": "sha256-m+9tUfsmBeF2Gn4HWa6vSITZ4Gz1eA1F5Kh62B0N4oE=",
        "owner": "Supreeeme",
        "repo": "xwayland-satellite",
        "rev": "388d291e82ffbc73be18169d39470f340707edaa",
        "type": "github"
      },
      "original": {
        "owner": "Supreeeme",
        "ref": "v0.7",
        "repo": "xwayland-satellite",
        "type": "github"
      }
    },
    "xwayland-satellite-unstable": {
      "flake": false,
      "locked": {
        "lastModified": 1783895132,
        "narHash": "sha256-Dl0Gvrig3EpE962hzF3ETPhUztlfuRhcmlpd8ioHN54=",
        "owner": "Supreeeme",
        "repo": "xwayland-satellite",
        "rev": "a2b5c635d8c8c99b286967658d0d177044887eb8",
        "type": "github"
      },
      "original": {
        "owner": "Supreeeme",
        "repo": "xwayland-satellite",
        "type": "github"
      }
    }
  },

Это не помешает знать

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

Композируемость(с этим вы будете чаще всего сталкиваться). Часто может быть так, что нужного вам пакета по каким-то причинам нет в официальных репозиториях nixpkgs, но какой-то энтузиаст портировал его на NixOs(вообще, портирование пакетов, написание дериваций на NixOs - это очень интересная тема) и при этом всё равно не смог попасть в nixpkgs. Такое иногда случается, и флейки решают эту проблему - позволяют нам скачивать чужие nix-пакеты, не попавшие в официальные репозитории. Разумеется, тут следует быть осторожным и задумываться над тем, что вы вообще там скачиваете.
Git. Флейки требуют, чтобы мы сопровождали нашу конфигурацию(которую мы через git init превращаем в полноценный репозиторий) через git.

Чем Nix Flakes отличаются от дефолтного nix-channels и почему флейки вытесняют каналы?

По умолчанию в свежеустановленной системе никакие флейки(только если вы не устанавливали никсу из уже готового конфига, где флейки уже были активированы), разумеется, не работают. Заместо них работает nix-channels, которые Nix Flakes и должны заменить.

Nix-channels(каналы Nix) - это механизм управления версиями пакетов в экосистеме Nix, который определяет, откуда ваша система загружает описания программ и обновлений.

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

Если говорить очень упрощённо, то nix-channels - это что-то вроде классического пакетного менеджера по типу pacman или apt, только работающего по-другому(например, в NixOs программы ставятся в изолированные папки, что решает проблему с несовместимыми зависимостями и прочее).

Но увы - у этого есть свои недостатки:

Каналы хранятся в глобальном или пользовательском профиле системы как изменяемое состояние. Если два человека запустят сборку одного и того же конфигурационного файла configuration.nix на разных машинах(или в разное время), они могут получить разные версии программ, так как их каналы обновились неодинаково.
Продекларированная "воспроизводимость" Nix ломается об каналы. Без жесткой фиксации конкретного коммита репозитория nixpkgs невозможно гарантировать, что сборка системы повторится один в один спустя месяц.
Если после обновления каналов что-то сломалось, откатить сам канал к состоянию «как было три часа назад» стандартными командами довольно неудобно. Приходится искать конкретный коммит в Git вручную.

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

Без флейков NixOs - это просто декларативно управляемая операционная система, но не такая уж и воспроизводимая.

Послесловие

Изначально я планировал написать общую статью, где будет и теория, и практика(половину уже дописал, кстати), но увидев, что объём будет слишком большим, я решил разделить её на две части: теоретическую и практическую.

Источники, с которыми я работал

https://nixos-and-flakes.thiscute.world/nixos-with-flakes/introduction-to-flakes
https://wiki.nixos.org/wiki/Flakes/ru
https://releases.nixos.org/nix/nix-1.8/manual.pdf
Сообщество NixOS RU - консультация
Нейросеть Gemini - консультация
Нейросеть DeepSeek - консультация, грамматические правки

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

0%Всё разложено по полочкам, сложностей не возникло0

0%В целом всё понятно, но некоторые моменты пришлось перечитывать0

View the original on Хабр →

KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.