{"id":125413,"date":"2025-05-22T15:05:15","date_gmt":"2025-05-22T13:05:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij"},"modified":"2025-05-22T15:05:15","modified_gmt":"2025-05-22T13:05:15","slug":"predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij","title":{"rendered":"De conceptie van de AerynOS-distributie is gepresenteerd met onderbouwing van architecturale beslissingen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
De ontwikkelaars van AerynOS, voorheen bekend als SerpentOS, hebben een uitgebreid artikel gepubliceerd waarin de details van het concept en de technische uitvoering van het project worden onthuld, met een onderbouwing van de gekozen architecturale keuzes. Projectleider Ikey Doherty benadrukt dat AerynOS geen \"gewone Linux-distributie\" is, maar een platform, fundament en set gereedschappen, ontwikkeld volgens een duidelijke visie. <\/p>\n
De kern van het project is geformuleerd als de vraag: \"Wat als een besturingssysteem zich gedraagt als moderne infrastructuur?\" AerynOS wordt gepresenteerd als antwoord op deze vraag \u2014 een systeem dat vanaf nul is gebouwd en niet voortbouwt op het traditionele model van ingebedde mutaties binnen een distributie. Het project is gebaseerd op de ervaring van de auteurs met het ontwikkelen van andere distributies, waaronder Solus en Clear Linux. <\/p>\n
Onder de belangrijkste technische beslissingen van AerynOS vallen: <\/p>\n
\n
Het gebruik van de LLVM-toolchain in plaats van GNU, met libc++ en compiler-rt als standaard. De ontwikkelaars leggen deze keuze uit als een strategische beslissing om gebruik te maken van betere diagnostiek, correctheid en draagbaarheid van pakketten. Tegelijkertijd gebruikt het systeem glibc in plaats van musl, wat een bewuste keuze is voor compatibiliteit en prestaties.\n
Zoals in het artikel staat: \"De voordelen van glibc ten opzichte van musl in prestaties zijn goed gedocumenteerd, vooral voor rekentaak-intensieve werklasten en applicaties die optimale prestaties bij meerdere threads vereisen.\" De makers benadrukken dat hun doel is om een functioneel, bruikbaar systeem te bouwen voor een verscheidenheid aan toepassingsscenario's. <\/p>\n
Het concept van \"statelessness\" (geen status bijhouden) \u2014 pakketten mogen geen bestanden buiten de map \/usr bevatten. Zoals de ontwikkelaars uitleggen, dwingt deze benadering om redelijke standaardwaarden op alle niveaus te waarborgen en elimineert het \"vreselijke conflicten van driedimensionale samenvoegingen bij het bijwerken van pakketten.\" Er zijn geen conflicten, omdat alles in \/etc en \/var van de gebruiker is, terwijl \/usr uitsluitend voor het systeem is. Dit concept is ontwikkeld in de tijd van Clear Linux en Solus, en heeft in AerynOS verdere ontwikkeling gekregen.\n
Atomaire updates \u2014 elke moss-transactie is atomair. Het systeem cre\u00ebert snel een nieuwe \/usr-structuur met behulp van harde links uit een gededupliceerde cache. Na succesvolle creatie en voorbereiding wordt de nieuwe structuur atomair verwisseld. De feitelijk voorbereide transactie wordt uitgewisseld met de werkelijke \/usr-map door gebruik te maken van renameat2 met de vlag RENAME_EXCHANGE. De update wordt ofwel volledig uitgevoerd, of helemaal niet, zonder tussenliggende staten.\n
Beheer van op projecten gebaseerde laadstrategie\u00ebn blsforme en disks-rs. Het kenmerk van deze aanpak is dat het systeem dynamisch parameters voor de kernelcommandoregel genereert door superblocks van de rootbestandssysteemapparaten te lezen, waardoor er in AerynOS geen configuratiebestand bestaat dat de parameter «root=» bevat. Bovendien wordt de moss transactie-ID gecodeerd in de kernelcommandoregel en verwerkt tijdens de vroege opstart in initramfs. «Kort gezegd betekent dit dat elke kernel correct is gesynchroniseerd met het bijbehorende rootbestandssysteem, en dat terugrollen goedkoop, eenvoudig en direct vanuit het opstartmenu beschikbaar is», verduidelijken de ontwikkelaars. Een ander voordeel is het ontbreken van \\\/etc\\\/default\\\/grub, en als de ESP wordt gewist, kan moss deze vanaf nul herstellen.\n
Het .stone-pakketformaat is een eigen binair pakketformaat met een versieonafhankelijke header om toekomstige wijzigingen te waarborgen. Elk .stone-pakket bevat vier specifieke soorten gegevens (payload), die onafhankelijk kunnen evolueren dankzij versiebeheer:\n
\n
Content payload \u2013 een opeenvolgende blok van gededupliceerde gegevens, dat wil zeggen de inhoud van de pakketten.\n
Index payload \u2013 bevat offsets voor de content payload, die is ge\u00efndexeerd op basis van de XXH128-hash van de inhoud (overgang naar Blake3 is gepland). Dit maakt het mogelijk om gegevens effici\u00ebnt te vinden en te extraheren.\n
Layout payload \u2013 beschrijft de verwachte lay-out van het bestandssysteem bij het toepassen van het pakket, dat wil zeggen waar en welke bestanden moeten worden ge\u00efnstalleerd.\n
Metadata payload \u2013 een reeks strikt getypeerde, gemarkeerde metadata-records, zoals de naam van het pakket, geleverde mogelijkheden, enz. <\/ul>\n<\/ul>\n
Comprimeren van alle belasting gebeurt met behulp van Zstd, wat uitstekende decompressieprestaties biedt bij een goed compressieverhouding. Het proces van «installatie» .stone verschilt radicaal van andere systemen. In plaats van directe installatie van bestanden wordt het pakket in de cache opgeslagen en de inhoud wordt geweven in een gezamenlijke opslag met adressering op basis van inhoud (CAS). Metadata en informatie over de layout worden apart opgeslagen en gebruikt bij het cre\u00ebren van een transactie. Deze aanpak zorgt voor atomiciteit van updates en de mogelijkheid om terug te rollen, aangezien elke transactie een nieuwe root-partitie aanmaakt en niet de bestaande wijzigt. <\/p>\n
Ontwikkelaars merken op dat de huidige aanpak van het emuleren van imperatieve pakketbeheer «volledig zinloos» is en «feitelijk meer fouten introduceert dan oplost». Aangezien voor elke transactie een nieuw root-bestandssysteem wordt aangemaakt, is het in de toekomst gepland om een nieuwe grafiek voor elke transactie te cre\u00ebren, en om afstand te nemen van ingebouwde wijzigingen ten gunste van een declaratieve aanpak, vergelijkbaar met Gentoo of Nix. <\/p>\n
Een andere interessante verklaring betreft onveranderlijkheid (immutability). De makers merken op dat AerynOS vaak als een onveranderlijk besturingssysteem wordt beschreven, maar «dat is niet helemaal waar». Hoewel elke transactie leidt tot een nieuwe boom in \/usr en lokale wijzigingen niet worden opgeslagen, is het systeem niet onveranderlijk in de zin van alleen-lezen toegang. In de toekomst is het de bedoeling om ware onveranderlijkheid van het systeem te implementeren zonder dat een herstart nodig is, met gebruik van erofs en overlayfs. <\/p>\n
Op dit moment is AerynOS actief in ontwikkeling, en worden er al ISO-images uitgegeven met GNOME-omgeving, geschikt voor gaming (ondersteuning voor NVIDIA-drivers, Steam, Flatpak), en heeft het echte gebruikers die de stabiliteit en innovativiteit van het systeem waarderen. Volgens de ontwikkelaars bevindt het project zich in de alfa-fase en is het niet zonder problemen, maar het vormt al een integraal systeem dat «simply works». \n Bron: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"