Vývojáři AerynOS, dříve známého jako SerpentOS, zveřejnili podrobný článek, ve kterém odhalují detaily koncepce a technické realizace projektu s odůvodněním přijatých architektonických rozhodnutí. Vedoucí projektu Ikey Doherty zdůrazňuje, že AerynOS není jen "další distribuce Linuxu", ale platforma, základ a soubor nástrojů vytvořený v souladu s jasnou vizí.
Hlavní myšlenka projektu je formulována jako otázka: "Co kdyby operační systém fungoval jako moderní infrastruktura?" AerynOS je představen jako odpověď na tuto otázku — systém, postavený od nuly, nikoli další tradiční model vestavěných mutací v rámci distribuce. Projekt čerpá z zkušeností autorů s vývojem dalších distribucí, včetně Solus a Clear Linux.
Mezi klíčová technická řešení AerynOS patří:
- Použití nástrojů LLVM místo GNU, s využitím libc++ a compiler-rt jako výchozí. Vývojáři vyjadřují toto rozhodnutí nejen jako preferenci LLVM, ale strategickou volbu pro zajištění kvalitnější diagnostiky, správnosti a přenositelnosti balíčků. Systém přitom používá glibc místo musl, což je vědomá volba pro zajištění kompatibility a výkonu.
Jak je uvedeno v článku: "Výhoda glibc oproti musl v výkonu je dobře zdokumentována, zejména pro výpočetně intenzivní pracovní zátěže a aplikace vyžadující optimální výkon vícevláknového zpracování." Tvůrci zdůrazňují, že jejich cílem je postavit funkční, použitelní systém pro širokou škálu scénářů použití.
- Koncepce "statelessness" (bez stavů) — balíčkům je zakázáno obsahovat jakékoli soubory mimo adresář /usr. Jak vývojáři objasňují, tento přístup nutí zajišťovat rozumné výchozí hodnoty na všech úrovních a eliminuje "hrozné konflikty třístranného sloučení při aktualizaci balíčků". Konflikty nejsou, protože vše v /etc a /var patří uživateli, zatímco /usr je výhradně systémové. Tato koncepce byla vyvinuta v dobách Clear Linux a Solus, a v AerynOS byla dále rozvinuta.
- Atomarizovaná aktualizace – každá transakce moss je atomární. Systém rychle vytváří nový strom /usr pomocí tvrdých odkazů z deduplikovaného cache. Po úspěšném vytvoření a přípravě je nový strom atomárně vyměněn. Fakticky připravená transakce se zaměňuje s reálným adresářem /usr pomocí renameat2 s příznakem RENAME_EXCHANGE. Aktualizace je buď provedena celá, nebo se neprovede vůbec, bez mezistavů.
- Správa načítání na základě projektů blsforme a disks-rs. Specifikou přístupu je, že systém dynamicky vytváří parametry pro příkazový řádek jádra, čtením superbloků zařízení kořenového souborového systému, proto v AerynOS neexistuje konfigurační soubor, který by obsahoval parametr "root= ". Navíc je identifikátor transakce moss zakódován v příkazovém řádku jádra a zpracováván během brzkého načítání v initramfs. "Jinými slovy, to znamená, že každé jádro je správně synchronizováno s odpovídajícím kořenovým souborovým systémem, a návrat je levný, jednoduchý a dostupný přímo z nabídky bootování," uvádějí vývojáři. Další výhodou je absence /etc/default/grub, a pokud bude ESP vymazán, moss ho může obnovit od základů.
- Formát balíčků .stone je vlastní binární formát balíčků s verzionálně agnostickým záhlavím pro zajištění budoucích změn. Každý balíček .stone obsahuje čtyři konkrétní typy dat (payload), z nichž každý se může vyvíjet nezávisle díky verzionování:
- Obsahová zátěž (Content payload) – sekvenční blok deduplikovaných dat, tedy samotný obsah souborů balíčku.
- Indexová zátěž (Index payload) – obsahuje posuny pro obsahovou zátěž, indexované podle hash XXH128 obsahu (plánuje se přechod na Blake3). To umožňuje efektivně vyhledávat a extrahovat data.
- Zátěž uspořádání (Layout payload) – popisuje očekávané uspořádání souborového systému při použití balíčku, tedy kam a jaké soubory by měly být nainstalovány.
- Metadata (Metadata payload) – sekvence přísně typovaných, označených záznamů metadat, jako je název balíčku, poskytované možnosti atd.
Komprese všech zatížení se provádí pomocí Zstd, což zajišťuje výborný výkon dekomprese při zachování dobrého poměru komprese. Proces "instalace" .stone se zásadně liší od ostatních systémů. Místo přímé instalace souborů se balíček ukládá do mezipaměti a jeho obsah se splétá do společného úložiště s adresací podle obsahu (CAS). Metadata a informace o rozložení se uchovávají zvlášť a používají se při vytváření transakce. Tento přístup zajišťuje atomaritu aktualizací a možnost návratu, neboť každá transakce vytváří nový kořenový oddíl, místo aby modifikovala stávající.
Vývojáři upozorňují, že současný přístup k emulaci imperativního řízení balíčků je "zcela nesmyslný" a "ve skutečnosti zavádí více chyb, než řeší". Protože pro každou transakci vzniká nový kořenový souborový systém, v budoucnu se plánuje vytvoření nového grafu pro každou transakci, opuštění vestavěných změn ve prospěch deklarativního přístupu, podobného Gentoo nebo Nix.
Další zajímavé vysvětlení se týká neměnnosti (immutability). Tvůrci upozorňují, že AerynOS je často popisován jako neměnný operační systém, ale "to není úplně pravda". I když každá transakce vede k novému stromu /usr a lokální změny se neuchovávají, systém není neměnný ve smyslu přístupu pouze pro čtení. V budoucnu se plánuje implementace skutečné neměnnosti systému bez nutnosti restartu pomocí erofs a overlayfs.
V současné době se AerynOS aktivně vyvíjí, již vydává ISO obrazy s prostředím GNOME, je vhodný pro hry (podpora ovladačů NVIDIA, Steam, Flatpak), má skutečné uživatele, kteří uvádějí stabilitu a inovativnost systému. Podle vývojářů je projekt v alfa verzi a není bez problémů, ale již představuje ucelený systém, který "jednoduše funguje".
Zdroj: opennet.ru
