«Не могу перейти ни на что другое»: разработчик из Google рассказал о любимой (и ненавистной) ОС

Один из разработчиков операционной системы Google Fuchsia Уэсли Аптекар-Касселса рассказал об опыте работы с NixOS. Он использует ее в течение последних трех лет и уверен, что заложенные в ОС идеи и принципы заслуживают внимания. 

Вот что он написал. 

Я пользуюсь NixOS в течение последних трех лет. Ее установка была чем-то вроде наказания: с одной стороны, это единственная операционная система (ОС), которая понимает, как должно осуществляться управление пакетами. После ее использования я не могу вернуться ни к чему другому.

С другой стороны, это чрезвычайно сложное, периодически меняющееся программное обеспечение, которое требует постоянной настройки с помощью одного из самых ужасных родных языков программирования, который я когда-либо использовал. Речь о Nix — функциональном ленивом языке программирования с динамической типизацией. Далее — о плюсах и минусах системы. 

Плюсы 

#1 

Один из главных плюсов NixOS в том, что программное обеспечение никогда не устанавливается глобально. Все пакеты находятся в хранилище с возможностью адресации содержимого, Например, редактор кода хранится в каталоге /nix/store/frlxim9yz5qx34ap3iaf55caawgdqkip-neovim-0.5.1/ — бинарные файлы, глобальная конфигурация, библиотеки и все остальное, входящее в пакет vim, находится в этом каталоге. Однако простое скачивание не «устанавливает» его. В NixOS нет такого понятия, как «установка» в традиционном смысле. Вместо этого пользователь может открыть оболочку, у которой переменная $PATH установлена так, чтобы она могла видеть neovim. Это довольно просто сделать: для этого нужно запустить nix-shell -p neovim, и пользователя перебросит в оболочку, у которой neovim есть в $PATH. 

Процесс не влияет на программы, у которых не изменен $PATH. Это означает, что возможно одновременное сосуществование стольких различных версий одного и того же программного пакета, сколько нужно, что невозможно в большинстве дистрибутивов. Пользователь может иметь одну оболочку с Python 3.7, другую — с Python 3.9, и на обеих установить разный набор библиотек. Если есть две разные части программного обеспечения, которые имеют одну и ту же зависимость, не нужно заботиться о том, чтобы они были совместимы с одной и той же версией, поскольку каждая из них может использовать ту версию зависимости, которую хочет. 

NixOS

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

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

#2 

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

#3 

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

Минусы 

В NixOS есть две фундаментальные ошибки, которые приводят к проблемам. 

#1 

Создатели ОС разработали собственный язык программирования для конфигурирования, который не очень хорош и чрезвычайно труден для изучения. Подавляющее большинство пользователей NixOS не понимают языка и просто копипастят примеры конфигураций. Это рабочая схема, пока не нужно сделать что-то сложное. Есть единицы людей, которые создают большую часть инфраструктурной работы с пониманием дела, но больше — тех, кто не имеет ни малейшего представления о том, что происходит.

Это усугубляется плохой документацией. Есть документация по изучению Nix как языка и документация по использованию NixOS, но как они связаны, нигде не написано. К сожалению, Nix настолько сложен для изучения. Язык нуждается в большем количестве документации, глубоко объясняющей, как работают практические приложения языка Nix. Также не помешал бы менее уродливый синтаксис (похож на SML, OCaml и Haskell), но, думаю, что его менять уже поздно. 

Синтаксис Nix: в языке нет отдельного синтаксиса для объявления функций. Функции задаются через присваивание, так же как и другие значения

#2 

Второй недостаток заключается в том, что NixOS не обеспечивает реальной изоляции. Выполнив bash -c 'type $0', вы получите bash is /nix/store/90y23lrznwmkdnczk1dzdsq4m35zj8ww-bash-interactive-5.1-p8/bin/bash — bash знает, что он запущен из хранилища Nix. Это означает, что все программы должны быть перекомпилированы для работы на NixOS, часто с ужасными последствиями. Плюс невозможно наверняка узнать, от каких других пакетов может зависеть данный пакет.

В настоящее время этот способ реализован, по сути, в виде поиска пакета по /nix/store/, чтобы попытаться выяснить зависимости, что, очевидно не очень хорошо. Это также означает, что двоичные файлы, которые ссылаются на /lib/ld-linux.so.2 или скрипты, использующие #!/bin/bash, не будут работать без исправлений. 

К сожалению, лекарства от этого пока нет. Прошлой осенью я создал прототип дистрибутива Linux, пытаясь объединить хранилище пакетов в стиле nix-store с overlayfs. К сожалению, overlayfs становится очень неустойчивым при попытке наложить много путей, что сильно ограничивает этот подход. Попытка создать хранилище с адресацией содержимого, прозрачное для установленных в нем приложений, требует, по сути, создания образа контейнера для каждой композиции пакетов (именно такого подхода придерживается Silverblue), что меня в корне не устраивает. 

Преимущество этого подхода в том, что пользователь может использовать существующие репозитории пакетов. Одним из основных препятствий для принятия новых дистрибутивов Linux является упаковка, но дистрибутив, использующий подход «адресное хранилище контента + оверлей», может автоматически получить все преимущества NixOS вместе со всеми пакетами из Debian, Ubuntu, RedHat, Arch, NixOS и любых других дистрибутивов, которые ему понравятся. 

Заключение

NixOS четко придерживается правильного подхода к управлению зависимостями, но ей мешают несколько плохих технических решений, принятых очень давно. По словам автора, он продолжит использовать ОС, потому что, попробовав NixOS раз, сложно найти что-то столь же удобное, но надеется, что на ее месте появится что-то новое, что извлечет уроки NixOS и реализует возможности операционной системы более удобным для пользователя способом.