Konceptet för distributionen AerynOS presenteras med en motivering av arkitektoniska beslut.

Utvecklarna av AerynOS, tidigare känt som SerpentOS, har publicerat en omfattande artikel som avslöjar detaljer om konceptet och den tekniska implementeringen av projektet med en motivering av de valda arkitektoniska besluten. Projektledaren Ikey Doherty betonar att AerynOS inte bara är "ännu en Linux-distribution" utan en plattform, en grund och en uppsättning verktyg som skapats i enlighet med en tydlig vision.

Den grundläggande idén med projektet formuleras som en fråga: "Vad händer om operativsystemet beter sig som en modern infrastruktur?" AerynOS presenteras som svaret på denna fråga — ett system byggt från grunden, snarare än att följa den traditionella modellen av inbäddade mutationer inom distributionen. Projektet bygger på författarnas erfarenhet av att utveckla andra distributioner, inklusive Solus och Clear Linux.

Bland de viktigaste tekniska besluten för AerynOS kan nämnas:

• Användningen av verktygslådan LLVM istället för GNU, med libc++ och compiler-rt som standard. Utvecklarna förklarar detta val inte bara som en preferens för LLVM, utan som ett strategiskt val för att använda högre kvalitet på diagnostik, säkerställa korrekthet och portabilitet för paketen. Systemet använder dessutom glibc istället för musl, vilket är ett medvetet val för att prioritera kompatibilitet och prestanda.

  Som nämnts i artikeln: "Fördelen med glibc över musl i prestanda är väl dokumenterad, särskilt för beräkningsintensiva arbetsbelastningar och applikationer som kräver optimal prestanda för flertrådad bearbetning." Skaparna betonar att deras mål är att bygga ett fungerande, användbart system för många tillämpningsscenarier.

• Konceptet "statelessness" (tillståndslöshet) — paket får inte innehålla några filer utanför katalogen /usr. Som utvecklarna förklarar, tvingar detta till att se till att rimliga standardvärden tillämpas på alla nivåer och eliminerar "fruktansvärda konflikter vid tredubbelsammanfogning vid paketsuppdateringar." Det finns inga konflikter eftersom allt i /etc och /var tillhör användaren, medan /usr uteslutande tillhör systemet. Konceptet utvecklades under tiden för Clear Linux och Solus, och i AerynOS har det fått ytterligare utveckling.
• Atomära uppdateringar — varje moss-transaktion är atomär. Systemet skapar snabbt ett nytt träd /usr med hjälp av hårda länkar från det deduplicerade cache. Efter en framgångsrik skapelse och förberedelse byts det nya trädet atomärt ut. Den faktiska förberedda transaktionen byts med den verkliga katalogen /usr med hjälp av renameat2 med flaggan RENAME_EXCHANGE. Uppdateringen antingen genomförs helt, eller så genomförs den inte alls, utan mellanliggande tillstånd.
• Projektbaserad lasthantering med blsforme och disks-rs. Kännetecknet för denna metod är att systemet dynamiskt skapar parametrar för kärnans kommandorad genom att läsa superblocken i enheter av det grundläggande filsystemet, vilket innebär att AerynOS inte har någon konfigurationsfil som innehåller parametern 'root='. Dessutom kodas moss-transaktions-ID i kärnans kommandorad och behandlas under tidig boot i initramfs. 'Kort sagt, det innebär att varje kärna är korrekt synkroniserad med det motsvarande grundläggande filsystemet, och återställning är billig, enkel och lättillgänglig direkt från bootmenyn', förklarar utvecklarna. En annan fördel är avsaknaden av /etc/default/grub, och om ESP raderas kan moss återställa det från grunden.
• Paketformatet .stone är ett eget binärt paketformat med en versionsagnostisk rubrik för att säkerställa framtida förändringar. Varje .stone-paket innehåller fyra specifika datatyper (payload), varav var och en kan utvecklas oberoende tack vare versionering:
  • Innehållspayload (Content payload) — en sekventiell block av deduplicerade data, det vill säga själva innehållet i pakets filer.
  • Indexpayload (Index payload) — innehåller offset för innehållspayload, indexerade med hash XXH128 av innehållet (övergång till Blake3 planeras). Detta gör det möjligt att effektivt hitta och extrahera data.
  • Layoutpayload (Layout payload) — beskriver den avsedda layouten av filsystemet vid tillämpning av paketet, det vill säga var och vilka filer som ska installeras.
  • Metadata-payload (Metadata payload) — en sekvens av strikt typade, märkta metadata-poster, såsom paketnamn, tillhandahållna funktioner etc.

Komprimering av alla belastningar utförs med hjälp av Zstd, vilket ger utmärkt prestanda vid avpackning samtidigt som en bra komprimeringsgrad bibehålls. Installationsprocessen för .stone skiljer sig radikalt från andra system. Istället för att installera filer direkt, cachas paketet och dess innehåll flätas ihop i ett gemensamt lagringsutrymme med adressering baserat på innehåll (CAS). Metadata och layoutinformation lagras separat och används vid skapandet av transaktionen. Denna metod säkerställer atomära uppdateringar och möjlighet till återställning, eftersom varje transaktion skapar en ny rotpartition istället för att modifiera den befintliga.

Utvecklarna påpekar att den nuvarande metoden med emulering av imperativ paketstyrning "är helt meningslös" och "egentligen ger upphov till fler fel än den löser". Eftersom en ny rotfilsystem skapas för varje transaktion, planeras i framtiden att skapa en ny graf för varje transaktion, överge inbyggda förändringar till förmån för ett deklarativt tillvägagångssätt, liknande Gentoo eller Nix.

En annan intressant förklaring handlar om oförändrat tillstånd (immutability). Skaparna påpekar att AerynOS ofta beskrivs som ett oförändrat operativsystem, men "det är inte helt korrekt". Även om varje transaktion leder till ett nytt träd i /usr och lokala ändringar inte sparas, är systemet inte oförändrat i bemärkelsen att det endast är skrivskyddat. I framtiden planeras en verklig oförändrad implementation av systemet utan behov av omstart, med hjälp av erofs och overlayfs.

För närvarande utvecklas AerynOS aktivt, släpper redan ISO-bilder med GNOME-miljö, är spelvänligt (stöd för NVIDIA-drivrutiner, Steam, Flatpak), har verkliga användare som påpekar systemets stabilitet och nytänkande. Enligt utvecklarna är projektet i alfa-stadiet och har sina problem, men representerar redan ett helt system som "bara fungerar".

Källa: opennet.ru