Сказ о том, как я атомарные Linux-дистрибутивы пробовал

Атомарно-обновляемые Linux-дистрибутивы — это, по-простому, вид дистрибутивов, в котором корневой раздел с основными файлами операционной системы является неизменяемым и обновляется как один цельный пакет. Основное преимущество такого подхода — надёжность, поскольку такая модель поставки системы гарантирует, что в процессе обновления будет получена ровно та система, какой её задумали разработчики.

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

Началось это приключение весьма просто — мне нужен был какой-нибудь Linux с KDE, чтобы установить его в виртуальную машину и использовать для создания скриншотов моего софта. Собственно, исключительно из интереса, этим дистрибутивом стала Fedora 41 Kinoite. Программу я приносил туда в виде уже собранного Flatpak-пакета, и показала она себя неплохо. Ну и любопытство взяло вверх, в один из вечером я пошёл ставить её на железо.

Первое, что я осознал после появления этой системы на моей машине, это то, что наш мир прогнил, и кругом один обман. Система не совсем неизменяемая. Да, корневой раздел, /boot и /usr монтируются только для чтения, но мало кто упоминает, что /usr/local, /var, /etc, /opt (ссылается на /var/opt) и, очевидно, /home, всё ещё находятся под контролем пользователя. А этого в большинстве случаев достаточно для установки стороннего софта, как ни странно. Причём в стандартном наборе довольно много библиотек, так что даже проприетарный софт, вроде сред разработки от JetBrains, работает как надо.

Причём система весьма продумана, из коробки пользователю доступен Podman и утилита Toolbox, позволяющая в одну команду запустить маленькую Fedora. Ну а даже если нужная программа не запускается ни через Flatpak, ни через контейнеры, есть возможность “наложить” или "наслоить" её на образ системы через rpm-ostree.

Ну и вроде всё совсем неплохо, накатил весь нужный мне софт через Flatpak, накатил NodeJS и Python через nvm и pyenv соответственно, docker-контейнеры отлично собираются podman-ом, виртуальные машины спокойно запускаются в gnome-boxes, драйвера накладываются через rpm-ostree. Консольные утилиты можно и вовсе просто собрать из исходников. А тогда даже непонятно, зачем нам Toolbox, если всё встаёт нативно.

Однако… это не то, чего хотели разработчики дистрибутива.

Осознавать этот факт я начал далеко не сразу, а постепенно. Для начала, установка htop из исходников притащила вместе с собой новую версию libncurses, которая поломала пару встроенных утилит. NodeJS и Python работают вроде неплохо, но постепенно осознаёшь, какую помойку два их установщика устраивают в домашней папке. Установленный из tarball-а WebStorm почему-то очень плохо дружит с nvm, и постоянно просит ткнуть его носом в исполняемый файл NodeJS. Да и в принципе, а что поменялось-то, кроме того что у меня просмотрщик картинок теперь стоит через Flatpak?

А в том и суть, это всё, хоть и привычные пути решения проблем для Linux, но не те, что предполагают разработчики дистрибутива, и они постепенно начинают стрелять в ногу. И в этот момент приходит осознание, что этот дистрибутив не просто запрещает тебе доступ к части папок, а заставляет тебя решать привычные проблемы иным путём. И Toolbox из коробки дан не просто так.

Возможно, кто-то, из читающих этот бред, понял всё ещё по запаху ISO-файла, но мне потребовалось несколько дней чтобы осознать, чего от меня хочет система. Как решение этих проблем предполагали разработчики? И, до меня дошло. Хочет система от меня самого страшного, чего только может себе представить мой заточенный под bash мозг. Она хочет, что бы я не лез в системную консоль. Серьёзно.

Большая часть того, что начало сыпаться в системе, произошло из-за того, что я туда полез со своим сторонним ПО. И в этот момент Podman и Toolbox обретают смысл. Атомарная Fedora хочет принести на настольные компьютеры то, что уже много лет применяется на серверах — контейнеризацию всего и вся. Нужен Syncthing? Запускай через Podman. Нужно нагадить в файл hosts? Засунь в контейнер DNS-сервер и гадь в него. Хочешь покрасить кнопки через WebStorm? Создаёшь новый toolbox, ставишь туда его, все зависимости и работаешь. Аналогично с консольным софтом, хочешь во тьме ночной сидеть и прошивать свой Xiaomi? Создаёшь контейнер и пихаешь ADB/Fastboot туда.

С одной стороны, это звучит как бред и неудобная шляпа, но, имея опыт в настройке серверов, понимаешь, что это хорошая идея. Проблемы с конфликтующими зависимостями или неподходящими библиотеками пропадают, поскольку в отдельный контейнер можно установить любой дистрибутив любой версии. Огромный bashrc, подтягивающий в себя чёрти знает сколько других конфигов от всяких там nvm, тоже плавно перестаёт существовать. При этом как-то постепенно становится не важно, какой дистрибутив стоит на железе, можно взять любой, лишь бы были Flatpak и Podman, можно переехать с одного на другой вместе со своим уже настроенным софтом.

И в этот момент, Fedora Kinoite становится реально отличным дистрибутивом. Настолько вылизанного KDE я ещё не видел, за те 2 месяца, что я ей пользовался, Plasma упала буквально дважды, а это прям достижение. Интеграция с Flatpak доведена до блеска, даже вставка картинок из буфера обмена в Telegram работает, чего я до этого ни разу не видел.

Особенно хорошо преимущества такой модели понимаешь, когда решаешь очередной раз навести порядок в домашней папке: вот твои видимые файлы, вот конфиги KDE, вот .var с настройками Flatpak-приложени и папка с контейнерами. Всё просто и понятно, тут исключена вероятность найти в ~/.config папку с настройками проги, которую удалил ещё два десятилетия назад. И такой опыт не даст ни macOS, ни Windows.

Также нужно отметить простоту смены окружения рабочего стола. Поскольку в дотфайлах (~/.*) не лежит ничего, кроме настроек рабочего стола (ну кроме .var), а система представляет собой по сути один цельный пакет, переход с KDE на GNOME, например, сводится по сути к трём шагам: первый – сделать rpm-ostree rebase на нужную версию Fedora Silverblue (атомарная версия Fedora с GNOME Shell), второй – куда-нибудь убрать эти все .config/.local что бы они не конфликтовали, третий – перезагрузиться. И вуаля, KDE как будто бы и не было никогда, только Flatpak-и установленные будут о нём напоминать.

Само собой, уникальный != лучший, и недостатков тут хватает. Для начала, как я отмечал в начале, кастомизация интерфейса ограничена тем, что можно сделать с текущим окружением рабочего стола. Да, темы оформления и виджеты KDE встают без проблем, но если виджет просит какие-то дополнительные утилиты или библиотеки, то начинаются проблемы. Аналогично возникают сложности с ПО, требующим себе какие-либо особо высокие полномочия, вроде гипервизоров. Единственный способ получить себе полноценный virt-manager — наслоить его через rpm-ostree поверх системы, а это решение имеет в себе ряд недостатков, но работать будет. По этой же причине я не стал даже пытаться ставить этот дистрибутив на свой ноутбук-трансформер, ему надо много чего тюнить ручками, да и версию ядра он просит специфичную. Хотя с популярным железом проблем быть не должно, даже репозиторий с драйвером для NVIDIA висит среди подключенных по умолчанию.

В какой-то мере можно отнести к недостаткам тот факт, что работают атомарные версии Fedora только с загрузчиком systemd-boot, который не умеет в Dual-Boot c Windows, но лично мне на это плевать. Я же готов к ним отнести обязательное использование файловой системы btrfs, меня она не раз подводила, умирая вместе со всем содержимым диска.

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

Большая часть описанных недостатков вызваны лишь тем, что Fedora даёт весьма мало способов повлиять на базовую систему. Точнее, она оставляет ровно один такой способ — наслаивание rpm-пакетов, чего не всегда достаточно. Эх, вот бы существовал такой дистрибутив, что предлагает ту же идею, но при этом предлагал средства для сборки базовой системы из, скажем, какого-нибудь большого, единого конфигурационного файла… В общем, продолжение следует.