Udviklerne af AerynOS, tidligere kendt som SerpentOS, har offentliggjort en omfattende artikel, der afslører detaljerne om konceptet og den tekniske implementering af projektet med en begrundelse for de vedtagne arkitektoniske løsninger. Projekts lederen Ikey Doherty understreger, at AerynOS ikke bare er 'endnu en Linux-distribution', men en platform, et fundament og et sæt værktøjer skabt i overensstemmelse med en klar vision.
Den grundlæggende idé bag projektet er formuleret som et spørgsmål: 'Hvad nu hvis operativsystemet opfører sig som moderne infrastruktur?'. AerynOS præsenteres som svaret på dette spørgsmål — et system bygget fra bunden og ikke blot en videreførelse af den traditionelle model for indbyggede mutationer i distributionen. Projektet bygger på forfatternes erfaring med udviklingen af andre distributioner, herunder Solus og Clear Linux.
Blandt de vigtigste tekniske beslutninger i AerynOS kan nævnes:
- Brug af LLVM-værktøjet i stedet for GNU, med libc++ og compiler-rt som standard. Udviklerne forklarer, at denne beslutning ikke kun er et præference for LLVM, men et strategisk valg for at sikre bedre Diagnose, korrekthed og portabilitet af pakkerne. Systemet bruger glibc i stedet for musl, hvilket er et bevidst valg til fordel for kompatibilitet og ydeevne.
Som nævnt i artiklen: 'Fordelen ved glibc frem for musl i ydeevne er veldokumenteret, især for beregningstunge arbejdsbelastninger og applikationer, der kræver optimal ydeevne ved multitrådning'. Skaberne understreger, at deres mål er at konstruere et brugbart system, der er anvendeligt til mange anvendelsesscenarier.
- Konceptet 'statelessness' (uden vedholdenhed) — pakker er forbudt at indeholde nogen som helst filer uden for kataloget /usr. Som udviklerne forklarer, tvinger denne tilgang til at sikre rimelige standardværdier på alle niveauer og eliminerer 'forfærdelige konflikter ved trevejs-sammensmeltning ved opdatering af pakker'. Der er ikke konflikter, fordi alt i /etc og /var tilhører brugeren, mens /usr udelukkende tilhører systemet. Dette koncept blev udviklet i tiden for Clear Linux og Solus, og det har fået yderligere udvikling i AerynOS.
- Atomare opdateringer — hver moss-transaktion er atomar. Systemet opretter hurtigt et nyt træ /usr ved hjælp af hårde links fra et dedupliceret cache. Efter en vellykket oprettelse og forberedelse bliver det nye træ atomisk udskiftet. Den faktiske forberedte transaktion udveksles med det virkelige katalog /usr ved hjælp af renameat2 med flaget RENAME_EXCHANGE. Opdateringen gennemføres enten fuldt ud, eller den gennemføres slet ikke, uden mellemtilstande.
- Projektbaseret boot management fra blsforme og disks-rs. Kernen i tilgangen er, at systemet dynamisk genererer parametre til kernelens kommandolinje ved at læse superblokkene fra enhedsroot-filsystemet, hvilket betyder, at der i AerynOS ikke er en konfigurationsfil, der indeholder parameteren 'root='. Desuden er moss-transaktions-ID'et kodet i kernelens kommandolinje og behandles under tidlig boot i initramfs. 'Kort sagt betyder det, at hver kerne er korrekt synkroniseret med det tilsvarende root-filsystem, og en rollback er billig, enkel og tilgængelig direkte fra boot-menuen,' forklarer udviklerne. En anden fordel er fraværet af /etc/default/grub, og hvis ESP bliver slettet, kan moss genskabe det fra bunden.
- Pakkeforformatet .stone er et proprietært binært pakkeformat med versionsagnostisk header for at muliggøre fremtidige ændringer. Hver .stone-pakke indeholder fire specifikke typer data (payload), som hver især kan udvikle sig uafhængigt takket være versionering:
- Indholdspayload (Content payload) — en sekventiel blok af deduplikerede data, det vil sige selve indholdet af pakke-filerne.
- Indexpayload (Index payload) — indeholder offsets til indholdspayload, indekseret efter hash XXH128 af indholdet (overgang til Blake3 er planlagt). Dette muliggør effektiv lokalisering og udtrækning af data.
- Layoutpayload (Layout payload) — beskriver den forventede layout af filsystemet ved anvendelse af pakken, det vil sige hvor og hvilke filer der skal installeres.
- Metadata payload — en sekvens af strengt typede, mærkede metadataoptegnelser, såsom pakkens navn, de tilbudte funktioner osv.
Komprimering af alle belastninger udføres ved hjælp af Zstd, hvilket sikrer fremragende decompression-ydeevne samtidig med at der opretholdes en god komprimeringsgrad. Instillationsprocessen af .stone adskiller sig radikalt fra andre systemer. I stedet for direkte at installere filer, caches pakken, og dens indhold vævdes ind i et overordnet lager med indholdsadressering (CAS). Metadata og layoutinformation opbevares separat og bruges ved oprettelsen af en transaktion. Denne tilgang sikrer atomaritet i opdateringer og muligheden for rollback, da hver transaktion opretter en ny rodpartition i stedet for at modificere den eksisterende.
Udviklerne bemærker, at den nuværende tilgang med emulering af imperativ pakkeadministration "er helt meningsløs" og "faktisk introducerer flere fejl, end den løser." Da der oprettes et nyt rodfilsystem for hver transaktion, planlægges det i fremtiden at skabe en ny graf for hver transaktion, at opgive indbyggede ændringer til fordel for en deklarativ tilgang, der ligner Gentoo eller Nix.
En anden interessant forklaring handler om uforanderlighed (immutability). Skaberne bemærker, at AerynOS ofte beskrives som et uforanderligt OS, men "det er ikke helt korrekt." Selvom hver transaktion fører til et nyt træ /usr og lokale ændringer ikke gemmes, er systemet ikke uforanderligt i betydningen kun-læseadgang. I fremtiden planlægges gennemførelsen af ægte uforanderlighed i systemet uden behov for genstart ved hjælp af erofs og overlayfs.
I øjeblikket er AerynOS aktivt under udvikling og udgiver allerede ISO-billeder med GNOME-miljø, er egnet til spil (understøttelse af NVIDIA-drivere, Steam, Flatpak), har reelle brugere, der bemærker systemets stabilitet og innovation. Ifølge udviklerne er projektet i en alpha-tilstand og er ikke uden problemer, men det udgør allerede et sammenhængende system, der "bare virker."
Kilde: opennet.ru
