Разработчиците на 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
