Дорогие читатели, вы, наверное, не слышали об AerynOS. Это — новый дистрибутив, который его автор — Ikey Doherty — спроектировал прямо с нуля, используя свой богатый опыт с Solus Linux и ClearLinux. Хорошая новость — в том, что всё получилось, и дистрибутив сейчас в стадии твёрдой альфы, плохая — что автор снова отошёл от дел на неопределённое время.
Но, прежде чем взять долгую паузу в разработке, Ikey Doherty написал длинный пост о технической стороне вопроса — какие идеи были заложены в AerynOS и как они воплощались на практике. Несмотря на то, что всё удалось реализовать, как задумывалось, в некоторых вопросах, всё‑таки, выяснилось, что «зашли не в тот подъезд». Но в целом, после прочтения этого поста складывается некоторая картина - как должен выглядеть современный дистрибутив — чем и хочу с вами поделиться.
За этим проектом — раньше он назывался SerpentOS — я следил с относительным интересом: всё‑таки, новые дистрибутивы появляются не так часто. Кстати, есть надежда, что это будет меняться: долгое время десктопные дистрибутивы находились в тени серверных, а сейчас, с бумом контейнеризации, десктопные дистрибутивы будут вынуждены стать самостоятельными.
Кроме того, есть основание думать, что с развитием ИИ, простые, хорошо изученные системы будут приобретать популярность - потому что ИИ будет отлично их понимать. Например, это касается SQL: как бэкенд‑разработчик, скажу вам, что сейчас имеет смысл делать бэкенд‑приложение максимально близким к чистому SQL: ИИ отлично в нём разбирается. Так вот, то же самое касается и дистрибутивов линукса.
Возвращаясь к AerynOS: он с самого начала задумывался как stateless дистрибутив. ClearLinux тогда уже существовал как яркий пример. Если вы не знаете, то, грубо говоря, stateless означает, что пакеты — это просто файлы и конфигурация и не содержат произвольные скрипты для установки.
ClearLinux поддерживал установку так называемых бандлов — предопределённых списков пакетов. Понятно, что это — не гибко, так что автор хотел сделать пакетный менеджер более user‑friendly, как это принято в традиционных дистрибутивах. В частности, иметь возможность устанавливать любой пакет по имени:
moss install golangПроблема в том, что это — императивный способ, принятый в традиционных stateful дистрибутивах. Stateless же дистрибутивы стараются использовать вместо этого конфигурацию. В итоге, автор решил эмулировать императивный подход, сохраняя список установленных пакетов неявно для пользователя.
В конце, он всё‑таки пришёл к выводу, что это было ошибочно: конфигурация всё равно нужна для разных целей, и прятать её от пользователя нет никакого смысла. Лучше, вместо этого, сохранять и редактировать списки установленных пакетов в явном виде.
Вторая фича — это атомарность апдейтов. В AerynOS каждая транзакция приводит к отдельной rootfs, так что можно откатиться к предыдущему состоянию. Как, вы думаете, это реализовано? Ответ — с помощью «фермы хардлинков». То есть, файловая система создаётся из хардлинков на уже существующие данные.
Там это называется «blitting the filesystem» — это терминология из компьютерной графики. Надо признать, «blitting» там происходит достаточно быстро — обычно, за несколько секунд. В итоге, атомарные апдейты работают, и это очень круто, но есть одно «но»: EROFS не поддерживает хардлинки — а это, идеологически, была бы самая подходящая файловая система для такого дистрибутива.
В своём посте‑ретроспективе автор рассказал, что решил в будущем отказаться от «фермы хардлинков» в пользу нативной поддержки EROFS.
To do so we“ll implement something similar to composefs, without the drawbacks.”
Using the same transaction driven approach we have now, we“ll simply produce an erofs metadata image dynamically instead of the exploded filesystem tree.”
Но вне зависимости от того, появится ли в AerynOS что‑то похожее на composefs или останется ферма хардлинков, суть останется примерно той же: бинарные пакеты скачиваются и распаковываются в Content‑Addressable Store (CAS) — хранилище данных, адресуемое по хэш‑суммам, а потом уже динамически создаётся rootfs.
Я думаю, так и должна быть устроена работа с файловой системой в современном дистрибутиве: у нас должны быть заранее все мета‑данные о желаемом состоянии rootfs, все хэш‑суммы, в частности. Мы выясняем, все ли файлы присутствуют локально, скачиваем недостающие. И уже в самую последнюю очередь — записываем образ rootfs на диск. Семь раз отмерь — один отрежь. Это вполне логично, учитывая, что файловая система — довольно медленная в принципе, а для read‑only файловой системы — логично вдвойне.
Должен сказать, что мне нравится идея иммутабельных дистрибутивов, но не только в том смысле, что файлы должны быть защищены от записи, а ещё в том, что, наверное, пора перестать пытаться изменить и адаптировать легендарные дитрибутивы прошлой эпохи и ‑сделать уже новый. Ориентированный на нужды десктопа, в первую очередь. Кстати, модель rolling‑release отлично зарекомендовала себя для этих целей.
Как мы увидели на примере AerynOS и composefs, технологии для серверных и десктопных дистрибутивов иногда пересекаются. Но тут ключевое слово — иногда, лучше, всё‑таки, исходить из того, что это разные области. Тот факт, что серверные дистрибутивы сейчас предназначены исключительно для работы с контейнерами, а на десктопах популярны snap и flatpak, только на руку новым дистрибутивам. Новый KDE Linux, например, собираются выпустить вообще без пакетного менеджера — вот увидите, клиенты не будут сильно возмущаться. Требования к новым дистрибутивам сейчас — минимальные.
Так что, мне кажется, сейчас оптимальное время, чтобы увидели свет дистрибутивы вроде AerynOS. Они должны сосредоточиться на том, что максимально разумно и производительно выполнять основные функции линукс‑дистрибутива. А быть user‑friendly — это уже не их забота: для этого есть графические оболочки, snap, flatpak, контейнеры и прочее.
AerynOS, надо сказать, не всегда придерживалась этих приоритетов. Например, они посвятили кучу времени дилемме musl/glibc и тьюнингу compiler toolchain — тому, что имеет достаточно прикладное значение. Потом — как‑то упустили из виду EROFS. Но в целом — это чудесный прогрессивный дистрибутив. Пожелаем ему удачи!
Комментарии (44)
kt97679
07.11.2025 19:44Если вы не знаете, то, грубо говоря, stateless означает, что пакеты - это просто файлы и конфигурация и не содержат произвольные скрипты для установки.
Если пакет обновляет работающий сервис, то как можно без скриптов перезапустить этот сервис после обновления?
abetkin Автор
07.11.2025 19:44нужно добавить этот сервис в конфигурацию и после обновления всего дистрибутива понять, что она изменилась
kt97679
07.11.2025 19:44Т.е. post install скрпит есть, но он является частью системы, а не пакета?
abetkin Автор
07.11.2025 19:44Да
kt97679
07.11.2025 19:44Пакетов много, package scripts у них очень разные, вряд ли получится упихать логику всех скриптов в один универсальный.
abetkin Автор
07.11.2025 19:44В AerynOS получилось) Там это называется триггеры
kt97679
07.11.2025 19:44Можно посмотреть на реализацию?
abetkin Автор
07.11.2025 19:44Конечно! https://github.com/AerynOS/os-tools
kt97679
07.11.2025 19:44Вижу в документации
AerynOS supports the use of triggers, or actions, that run at the end of package installations.
Значит ли это, что перед установкой пакета ничего сделать нельзя? Обычно при обновлении сервиса preinstall останавливает сервис, postinstall запускает его опять.
emeykey
Я так и не понял, зачем это нужно. Автор хотел сделать откат апдейтов, в итоге отказался. Также я не понял, зачем нужен KDE Linux, без менеджера пакетов. Для чего они нужны объективно?
Разве для всего этого уже не существуют разные Gentoo и подобные ему дистрибутивы? Тот же Arch можно собрать с нуля.
abetkin Автор
Он не отказался, откат апдейтов работает, он планирует в будущем перейти на EROFS, но чтобы откат апдейтов по-прежнему работал. Arch чудесен, но можно сделать ещё лучше
V1tol
Можно сделать тот же арч лучше, причём бесплатно. Btrfs с настоящими снапшотами (которые можно делать по pacman хуку\расписанию\самому факту успешной загрузки) и загрузчик с возможностью грузиться с этих снапшотов уже делают то же самое, при этом не ограничивая пользователя в свободной модификации системы.
ValdikSS
Классические дистрибутивы Linux теряют свою консистентность в общем смысле сразу после установки на файловую систему.
Современные дистрибутивы стремятся так или иначе перенять подход мобильных систем: чтобы был некий rootfs, поставляемый дистрибутивом, который монтируется в неизменяемом виде, поверх него при необходимости монтируются overlay-файловые системы (с драйверами и другими системными изменениями), либо же «разработческий» слой при необходимости внесения изменений в rootfs.
Приложения все устанавливаются в пользовательские директории. Конфигурационные файлы хранятся на отдельной ФС (покрывающей /etc и /var), либо же у пользователя.
Преимущества: возможность нормального аудита, возможность сброса настроек как на телефонах, атомарные обновления, понимание состояния/консистентности системы.
Самое толковое видение, что я читал — у Леннарта Поттеринга, разрабтчика systemd: https://0pointer.net/blog/fitting-everything-together.html
kt97679
Мне кажется, что Поттеринг тяготеет к монструозным переусложненным решениям. То, что он предлагает, является образцом еще одного подобного решения. ИМХО.
ValdikSS
Вы переусложнением считаете что-то конкретное?
В Embedded-индустрии применяется многое, о чём он пишет, да и разрабатываемые, но ещё не мейнстримные дистрибутивы Fedora Atomic / Ubuntu Core Desktop реализуют большинство из описываемого.
Linux в плане безопасности (и удобства использования подсистем безопасности) отстает на годы от конкурентов, увы.
abetkin Автор
Это всё маркетинг, что линуксу не хватает безопасности. Стратегия линукса в плане безопасности - повышение IQ пользователей)
ValdikSS
Если вы не специалист по безопасности и не отслеживаете индустрию, со стороны здраво оценить состояние дел не представляется возможным: многие критические уязвимости просто не попадают в поле зрения технических СМИ, а другие не расписываются понятным для обычного человека языком, и становятся информационным шумом, а не полезной новостью, на которую можно отреагировать осмысленным действием.
Security-журналистика, нацеленная на простых смертных, мертва. Не уверен, что она вообще существовала.
kt97679
Кого вы в данном случае имеете в виду под конкурентами?
ValdikSS
Десктопы: macOS, Windows (в плане защиты ядра). Смартфонные Android и iOS давно впереди любой десктопной ОС, про них и говорить не стоит.
kt97679
Мы сейчас говорим про безопасность только с точки зрения возможности откатиться на предыдущее состояние или более широко?
ValdikSS
В более широком смысле, но в предыдущем сообщении я имел конкретно безопасность на этапах загрузки (secure boot, trusted boot, verified boot).
Банально даже такая вещь, как Secure Boot, которая корректно реализована на macOS и Windows лет 12, наверное, в Linux фактически только защищает и верифицирует ядро, а что там в initramfs — доверенном юзерспейсе, который может и PID'ы запущенного ПО скрывать, и файлы на файловой системе перезаписывать, и keylogger установить, и обращаться ко всем системам ядра от root'а, естественно — уже никого не волнует, он не верифицируется во время загрузки.
Шифрование диска с использованием аппаратного доверенного хранилища тоже реализовано в обоих системах, а в Linux по умолчанию TPM никак не используется, а настройка verified boot состоит из костылей и подпорок. Благо опять же Леннарт исправляет эту ситуацию внедрением UKI, чтобы избавиться от проблемы с непроверяемым initramfs. TPM cryptenroll также он реализовал ранее.
И вот в Linux с безопасностью почти везде так — подсистемы в принципе существуют, но ими пользуются только профессионалы из считанных компаний, потому что для их корректного и безопасного использования нужно быть экспертом. А Windows и macOS делают так, что можно раскатывать по умолчанию на миллиарды пользователей.
kt97679
Мне кажется главное слабое место подобного подхода, что когда утекает ключ, которым подписывались компоненты загрузки, то все старые системы (полагающиеся на этот ключ) оказываются уязвимы с очень низкими шансами на то, что это исправят. Или я не прав?
abetkin Автор
Пользователю и не нужна возможность свободной модификации, идейно неизменяемая файловая система очень даже подходит
Andrusha
Про каких пользователей идёт речь?
Современным основным пользователям линуксов на десктопах - разным айтишникам - обычно как раз-таки нужна.
abetkin Автор
Ну, я их и имею в виду, а не домохозяек. Ставить и обновлять пакеты - нужно, а произвольным образом изменять системный раздел - нет
kt97679
Почему нет?
Andrusha
Так а что конкретно будет в этом неизменяемом системном разделе, а что - вне его?
abetkin Автор
Бинарники, библиотеки, хедеры. Вне его, конечно, фотки
Andrusha
Так и чем это отличается от текущего состояния дел в линуксовых дистрибутивах? Тем, что для того чтобы туда что-то записать, помимо повышения прав, нужно будет ещё перемонтировать раздел?
abetkin Автор
Принципиально - ничем
abetkin Автор
Просто всё будет лучше работать и быстрее
Andrusha
Или не будет
kt97679
Почему быстрее? И какой смысл вы вкладываете в "лучше"?
abetkin Автор
Например, erofs производительнее, чем остальные. А лучше - в смысле что "умнее", глобально более продуманная
kt97679
Можно попросить вас привести результаты бенчмарков, чтобы стало понятно насколько быстрее erofs и в каких тестах это проявляется?
abetkin Автор
Честно говоря, не знаю, насколько
ValdikSS
rootfs поставляется производителем дистрибутива в минимальном виде, вместе со всеми метаданными и чексуммами (CAS; dm-verity/fs-verity, заверенный ключом поставщика), обновляется единым целым;
по сети передаётся минимум данных благодаря Content‑Addressable Store (CAS): сначала ваш существующий rootfs хешируется маленькими блоками, а затем с сервера скачивается только разница между новым rootfs и существующим, поблочно (блоки могут быть в разных местах, главное совпадение хеша);
все немногочисленные дополнительные системные пакеты переустанавливаются при каждом обновлении, формируя доп. слой поверх rootfs (почти как docker build);
Вы всегда видите разницу (можете сделать diff) между эталонным образом и вашими изменениями (dev-слоя, например). Если что-то сломалось, можете отбросить dev-слой и загрузиться в неизменённую систему. Dev-слоев может быть несколько (и в глубь, и в ширь), можете безопасно экспериментировать с системой, нужны в переустановке не возникнет никогда, потому что снизу у вас эталонный неизменяемый образ.
Сейчас в подавляющем большинстве дистрибутивов у вас нет понятия эталонной файловой системы, вы не можете посмотреть только ваши изменения поверх ФС, не можете легко их откатить.
При этом rootfs-образ может быть изначально оптимизирован под порядок чтения с него (блоки расположены в том порядке, в котором система к ним обращается во время загрузки, из-за чего с диска производится быстрое последовательное чтение вместо медленного случайного), сжат. Преимуществ много.
Andrusha
П. 2 в сочетании с п.1 выглядит стремновато по сравнению с классическими апдейтами, где тупо файлы переписываются - если что-то пойдёт не так, то я останусь с поломанной файловой системой.
Если я хочу позаниматься каким-то экспериментами, которые могут серьёзно поломать систему, то я просто беру chroot/Docker/VirtualBox и делаю всё там.
В целом подход интересный, но на практике большинство, видимо, выбирает дистрибутивы по каким-то другим преимуществам.
ValdikSS
На практике с этим подходом также применяют A/B-обновления: новые данные записываются в другой слот, и следующая перезагрузка загрузит обновлённую версию. А если что-то пошло не так, автоматика это поймёт и загрузит предыдущий, старый и рабочий слот.
kt97679
Чем плох подход с использованием снэпшотов (к примеру zfs)? grub позволяет вам загрузиться с любого снэпшота. Так что можно экспериментировать и в случае проблем откатиться даже не на один шаг, а на несколько.
ValdikSS
Это разные инструменты.
Снапшот делает слепок вашего текущего состояния всей ОС (файловой системы, каким бы оно ни было, в каком бы состоянии оно ни находилось), а принцип неизменяемого rootfs+слёв его просто исключает: у вас есть версии, и всё (ну разве что состояние ваших собственных слоёв/developer-слоя, если он включён).
Иными словами, после установки обычной ОС состояние файловой системы — головная боль администратора системы (пользователя), а в случае слоёв — поставщика слоёв (разработчика дистрибутива).
В первом случае состояние недетерминировано (у меня Fedora 43 и у вас Fedora 43, но я обновлялся на прошлой неделе, а вы сегодня — у нас разный набор пакетов разных версий, и чтобы определить проблему, нужно скрупулёзно сверять всё установленное ПО), а в случае Atomic-дистрибутива у меня Fedora 43.123, и у вас Fedora 43.123, с абсолютно одинаковым набором файлов у всех пользователей конкретной версии.
kt97679
Как у нас с вами может один и тот же набор файлов, если, к примеру, вы занимаетесь разработкой и вам нужны компиляторы и иде, а я видеомонтажем и мне нужны совершенно другие программы и библиотеки? Или вы предлагаете сразу ставить все, что есть в репозитории?
ValdikSS
Это пользовательское ПО и оно устанавливается в домашнюю директорию (или какую-то общую директорию с ПО), а не в систему.
В Ubuntu Core это Snap'ы.
kt97679
Если я хочу использовать один display manager, а вы - другой, значит ли это, что они тоже должны устанавливаться в привязке к конкретному пользователю?