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