Az AerynOS fejlesztői, akik korábban SerpentOS néven voltak ismertek, közzétettek egy részletes cikket, amelyben bemutatják a projekt koncepciójának és technikai megvalósításának részleteit, valamint indokolják az elfogadott architekturális döntéseket. A projekt vezetője, Ikey Doherty hangsúlyozza, hogy az AerynOS nem csupán "még egy Linux disztribúció", hanem egy platform, alap és eszközkészlet, amelyet egy világos vízió alapján alakítottak ki.
A projekt fő ötlete kérdés formájában van megfogalmazva: "Mi lenne, ha az operációs rendszer modernebb infrastruktúráként viselkedne?" Az AerynOS ennek a kérdésnek a válaszaként jelentkezik — egy olyan rendszer, amelyet a nulláról építettek fel, nem pedig egy hagyományos disztribúció belső mutációi következményeként. A projekt a szerzők korábbi disztribúciók, mint például a Solus és a Clear Linux fejlesztésében szerzett tapasztalataira támaszkodik.
Az AerynOS kulcsfontosságú technikai megoldásai közé tartozik:
- Az LLVM eszközkészlet használata a GNU helyett, libc++ és compiler-rt alapértelmezett alkalmazásával. A fejlesztők ezt a döntést nem csupán az LLVM preferálása miatt, hanem a jobb diagnosztika, a csomagok helyességének és hordozhatóságának biztosítása érdekében hozták meg. Emellett a rendszer glibc-t használ a musl helyett, ami tudatos választás a kompatibilitás és a teljesítmény érdekében.
Ahogy a cikkben is meg van fogalmazva: "A glibc teljesítménybeli előnye a musl-lal szemben jól dokumentált, különösen a számításigényes munkaterhelések és az optimális több szálú teljesítményt igénylő alkalmazások esetében." A készítők hangsúlyozzák, hogy céljuk egy működőképes, széleskörű felhasználásra alkalmas rendszer megalkotása számos alkalmazási forgatókönyv számára.
- A "statelessness" (állapot nélküli) koncepció — a csomagok számára tilos bármilyen fájl tárolása a \/usr könyvtáron kívül. Ahogy a fejlesztők kifejtik, ez a megközelítés arra kényszeríti a rendszert, hogy minden szinten ésszerű alapértelmezett értékekkel rendelkezzen, és megszünteti a "szörnyű háromoldalú egyesítési konfliktusokat a csomagok frissítésekor". Konfliktusok nincsenek, mivel minden a \/etc és a \/var könyvtárakban a felhasználó birtokában van, míg a \/usr kizárólag a rendszeré. Ezt a koncepciót a Clear Linux és a Solus idején dolgozták ki, az AerynOS-ban pedig további fejlesztéseket kapott.
- Az atomikus frissítések során minden moss tranzakció atomikus. A rendszer gyorsan létrehozza az új fa struktúrát a /usr alatt a deduplikált gyorsítótárból készült kemény linkek felhasználásával. A sikeres létrehozás és előkészítés után az új fa atomikusan cserélve van. A ténylegesen előkészített tranzakció a valós /usr könyvtárral cserélődik ki a renameat2 segítségével az RENAME_EXCHANGE flag használatával. A frissítés teljes mértékben végrehajtódik, vagy egyáltalán nem, köztes állapotok nélkül.
- A betöltés kezelése a blsforme és disks-rs projektek alapján történik. A megközelítés sajátossága, hogy a rendszer dinamikusan formálja a kernel parancssori paramétereit a gyökér fájlrendszer superblokkjainak beolvasásával, így az AerynOS-ben nincs olyan konfigurációs fájl, amely tartalmazza a "root=" paramétert. Továbbá, a moss tranzakció azonosító parancssorba van kódolva, és az initramfs korai indításakor feldolgozzák. „Röviden ez annyit jelent, hogy minden kernel helyesen van szinkronizálva a megfelelő gyökér fájlrendszerrel, és a visszaállítás olcsó, egyszerű és közvetlenül a betöltési menüből elérhető” - magyarázzák a fejlesztők. További előny, hogy nincs /etc/default/grub, és ha az ESP törlődik, a moss képes újrakezdeni azt.
- .stone csomagformátum – saját bináris csomagformátum verziófüggetlen fejlécet alkalmazva a jövőbeli változások biztosítása érdekében. Minden .stone csomag négy specifikus típusú adatot (payload) tartalmaz, amelyek függetlenül fejlődhetnek a verziózásnak köszönhetően:
- Tartalmi payload – egy sorozatos blokkjelenlegi deduplikált adat, vagyis a csomag fájljainek tényleges tartalma.
- Index payload – a tartalmi payload eltolásait tartalmazza, amelyeket a tartalom XXH128 hash alapján indexeltek (tervezik a Blake3-ra való áttérést). Ez lehetővé teszi az adatok hatékony keresését és kinyerését.
- Elrendezési payload – leírja a fájlrendszer várható elrendezését a csomag alkalmazásakor, vagyis hogy hová és milyen fájlokat kell telepíteni.
- Metaadatok payload – szigorúan tipizált, megcímkézett metaadatbejegyzések sorozata, mint például a csomag neve, a biztosított képességek stb.
Az összes terhelés tömörítése a Zstd segítségével történik, amely kiváló kibontási teljesítményt biztosít jó tömörítési arány mellett. A .stone "telepítési" folyamata alapvetően eltér más rendszerektől. A fájlok közvetlen telepítése helyett a csomag gyorsítótárba kerül, és tartalma egy közös tárolóba fonódik bele tartalom alapján történő címezéssel (CAS). A metaadatok és a layout információk külön tárolódnak, és tranzakciók létrehozásakor kerülnek felhasználásra. Ez a megközelítés biztosítja a frissítések atomaritását és a visszavonás lehetőségét, mivel minden tranzakció új gyökérválasztó létrehozását eredményezi, nem a meglévő módosítását.
A fejlesztők megjegyzik, hogy a csomagok imperatív kezelésének emulálásával járó jelenlegi megközelítés "teljesen értelmetlen" és "tulajdonképpen több hibát vezet be, mint amennyit megold". Mivel minden tranzakció új gyökérfájlrendszert hoz létre, a jövőben új gráf létrehozása van tervben minden tranzakcióhoz, a beágyazott módosítások elhagyása az olyan deklaratív megközelítések előnyben részesítésével, mint például a Gentoo vagy a Nix.
Egy másik érdekes magyarázat az immutable (meg nem változtatható) jellegre vonatkozik. A készítők megjegyzik, hogy gyakran jellemzik az AerynOS-t, mint meg nem változtatható operációs rendszert, de "ez nem egészen igaz". Bár minden tranzakció egy új /usr fá tree-t eredményez, és a helyi módosítások nem kerülnek mentésre, a rendszer nem tekinthető meg nem változtathatónak olvasásra korlátozott hozzáféréssel. A jövőben a rendszer valódi meg nem változtathatóságának megvalósítása van tervben, szükség esetén erofs és overlayfs használatával.
Jelenleg az AerynOS aktívan fejlődik, már ISO képeket ad ki GNOME környezettel, játékokra alkalmas (NVIDIA meghajtók, Steam, Flatpak támogatással), valós felhasználókkal, akik a rendszer stabilitását és innovativitását emelik ki. A fejlesztők szerint a projekt alfa fázisban van, és nem mentes a problémáktól, de már egy olyan átfogó rendszer, amely "egyszerűen működik".
Forrás: opennet.ru
