🥇Представлена концепция дистрибутива AerynOS с обоснованием архитектурных решений

Разработчики AerynOS, ранее известного как SerpentOS, опубликовали развёрнутую статью, в которой раскрываются детали концепции и технической реализации проекта с обоснованием принятых архитектурных решений. Руководитель проекта Ikey Doherty подчёркивает, что AerynOS — это не просто «ещё один дистрибутив Linux», а платформа, фундамент и набор инструментов, созданные в соответствии с чётким видением.

Основная идея проекта сформулирована в виде вопроса: «Что, если операционная система будет вести себя как современная инфраструктура?». AerynOS представлен как ответ на этот вопрос — система, построенная с нуля, а не следующая традиционной модели встроенных мутаций внутри дистрибутива. Проект опирается на опыт авторов в разработке других дистрибутивов, включая Solus и Clear Linux.

Среди ключевых технических решений AerynOS можно выделить:

Использование инструментария LLVM вместо GNU, с применением libc++ и compiler-rt по умолчанию. Разработчики объясняют это решение не просто предпочтением LLVM, а стратегическим выбором для использования более качественной диагностики, обеспечения корректности и переносимости пакетов. При этом система использует glibc вместо musl, что является осознанным выбором в пользу совместимости и производительности.
Как указано в статье: «Преимущество glibc над musl в производительности хорошо задокументировано, особенно для вычислительно-интенсивных рабочих нагрузок и приложений, требующих оптимальной производительности многопоточности». Создатели подчёркивают, что их цель — построить работоспособную, пригодную для использования систему для множества сценариев применения.
Концепция «statelessness» (без сохранения состояния) — пакетам запрещено содержать какие-либо файлы за пределами каталога /usr. Как поясняют разработчики, этот подход заставляет обеспечивать разумные значения по умолчанию на всех уровнях и устраняет «ужасные конфликты трёхстороннего слияния при обновлении пакетов». Конфликтов нет, потому что всё в /etc и /var принадлежит пользователю, а /usr — исключительно системе. Концепция была разработана во времена Clear Linux и Solus, а в AerynOS она получила дальнейшее развитие.
Атомарные обновления — каждая транзакция moss является атомарной. Система быстро создаёт новое дерево /usr с использованием жёстких ссылок из дедуплицированного кэша. После успешного создания и подготовки новое дерево атомарно подменяется. Фактически подготовленная транзакция обменивается с реальным каталогом /usr с использованием renameat2 с флагом RENAME_EXCHANGE. Обновление либо выполняется полностью, либо не выполняется вообще, без промежуточных состояний.
Управление загрузкой на основе проектов blsforme и disks-rs. Особенность подхода в том, что система динамически формирует параметры для командной строки ядра, считывая суперблоки устройств корневой файловой системы, поэтому в AerynOS нет конфигурационного файла, содержащего параметр «root=». Более того, идентификатор транзакции moss кодируется в командной строке ядра и обрабатывается во время ранней загрузки в initramfs. «Если говорить коротко, это означает, что каждое ядро правильно синхронизировано с соответствующей корневой файловой системой, и откат является дешёвым, простым и доступным прямо из меню загрузки», — поясняют разработчики. Ещё одно преимущество — отсутствие /etc/default/grub, а если ESP будет стёрт, moss может восстановить его с нуля.
Формат пакетов .stone — собственный бинарный формат пакетов с версионно-агностическим заголовком для обеспечения будущих изменений. Каждый пакет .stone содержит четыре конкретных типа данных (payload), каждый из которых может развиваться независимо благодаря версионированию:
- Контентная нагрузка (Content payload) — последовательный блок дедуплицированных данных, то есть само содержимое файлов пакета.
- Индексная нагрузка (Index payload) — содержит смещения для контентной нагрузки, проиндексированные по хешу XXH128 содержимого (планируется переход на Blake3). Это позволяет эффективно находить и извлекать данные.
- Нагрузка макета (Layout payload) — описывает предполагаемый макет файловой системы при применении пакета, то есть куда и какие файлы должны быть установлены.
- Метаданные (Metadata payload) — последовательность строго типизированных, помеченных записей метаданных, таких как имя пакета, предоставляемые возможности и т.д.

Сжатие всех нагрузок осуществляется с помощью Zstd, что обеспечивает отличную производительность распаковки при сохранении хорошего коэффициента сжатия. Процесс «установки» .stone кардинально отличается от других систем. Вместо непосредственной установки файлов пакет кэшируется, а его содержимое сплетается в общее хранилище с адресацией по содержимому (CAS). Метаданные и информация о макете хранятся отдельно и используются при создании транзакции. Этот подход обеспечивает атомарность обновлений и возможность отката, так как каждая транзакция создаёт новый корневой раздел, а не модифицирует существующий.

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

Ещё одно интересное пояснение касается неизменяемости (immutability). Создатели отмечают, что часто AerynOS описывают как неизменяемую ОС, но «это не совсем верно». Хотя каждая транзакция приводит к новому дереву /usr и локальные изменения не сохраняются, система не является неизменяемой в смысле доступа только для чтения. В будущем планируется реализация истинной неизменяемости системы без необходимости перезагрузки с использованием erofs и overlayfs.

В настоящее время AerynOS активно развивается, уже выпускает ISO-образы с окружением GNOME, пригоден для игр (поддержка драйверов NVIDIA, Steam, Flatpak), имеет реальных пользователей, отмечающих стабильность и инновационность системы. По словам разработчиков, проект находится в стадии альфа-версии и не лишён проблем, но уже представляет собой целостную систему, которая «просто работает».

Источник: opennet.ru

ProHoster Консультант, Технический специалист

A technical specialist at ProHoster with over six years of experience in server administration, VPN solutions, and network security. I manage infrastructure setup and support, monitor service stability, and implement solutions to protect client data. I also contribute to performance optimization and compliance with modern security and privacy requirements.

See Full Bio