{"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\/da\/blog\/news\/predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij","title":{"rendered":"Pr\u00e6sentationen af AerynOS-distributionens koncept med en begrundelse for de arkitektoniske l\u00f8sninger","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Udviklerne af AerynOS, tidligere kendt som SerpentOS, har offentliggjort en udf\u00f8rlig artikel, der afsl\u00f8rer detaljerne om konceptet og den tekniske implementering af projektet, med en begrundelse for de arkitektoniske beslutninger. Projektleder Ikey Doherty understreger, at AerynOS ikke blot er \"endnu en Linux-distribution\", men en platform, et fundament og et s\u00e6t v\u00e6rkt\u00f8jer, der er skabt i overensstemmelse med en klar vision. <\/p>\n
Den grundl\u00e6ggende id\u00e9 bag projektet er formuleret som et sp\u00f8rgsm\u00e5l: \"Hvad hvis et operativsystem fungerer som moderne infrastruktur?\". AerynOS pr\u00e6senteres som svaret p\u00e5 dette sp\u00f8rgsm\u00e5l - et system bygget fra bunden af, ikke blot en videreudvikling af den traditionelle model for indbyggede mutationer inden for distributionen. Projektet bygger p\u00e5 forfatternes erfaring med udvikling af andre distributioner, herunder Solus og Clear Linux. <\/p>\n
Blandt de vigtigste tekniske beslutninger i AerynOS kan n\u00e6vnes: <\/p>\n
\n
Brug af LLVM-v\u00e6rkt\u00f8jet i stedet for GNU, med libc++ og compiler-rt som standard. Udviklerne forklarer, at denne beslutning ikke kun er et pr\u00e6ference 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.\n
Som n\u00e6vnt i artiklen: \"Fordelen ved glibc over musl i ydeevne er veldokumenteret, is\u00e6r for beregningsintensive arbejdsbelastninger og applikationer, der kr\u00e6ver optimal ydeevne i flertr\u00e5det programmering\". Skaberne understreger, at deres m\u00e5l er at bygge et funktionelt, brugbart system til mange anvendelsesscenarier. <\/p>\n
Konceptet 'statelessness' (uden tilstand) - pakker m\u00e5 ikke indeholde nogen filer uden for kataloget \/usr. Som udviklerne forklarer, tvang denne tilgang til at sikre rimelige standardv\u00e6rdier p\u00e5 alle niveauer og eliminerer \"forf\u00e6rdelige konflikter ved tredobbelt sammensmeltning under opdatering af pakker\". Der er ingen konflikter, fordi alt i \/etc og \/var tilh\u00f8rer brugeren, mens \/usr udelukkende tilh\u00f8rer systemet. Konceptet blev udviklet i tiden for Clear Linux og Solus og har f\u00e5et yderligere udvikling i AerynOS.\n
Atomiske opdateringer - hver moss-transaktion er atomisk. Systemet opretter hurtigt et nyt \/usr-tr\u00e6 ved hj\u00e6lp af h\u00e5rde links fra deduplikeret cache. Efter en vellykket oprettelse og forberedelse byttes det nye tr\u00e6 atomisk. Den faktiske forberedte transaktion byttes med det virkelige katalog \/usr ved hj\u00e6lp af renameat2 med flaget RENAME_EXCHANGE. Opdateringen udf\u00f8res enten helt eller slet ikke, uden mellemtilstande.\n
Projektbaseret belastningsstyring af blsforme og disks-rs. Det specielle ved tilgangen er, at systemet dynamisk genererer parametre til kernekommandolinjen ved at l\u00e6se superblockene for enhederne i rodfilsystemet, derfor findes der ikke en konfigurationsfil i AerynOS, der indeholder parameteren «root=». Desuden er transaktions-id'et moss kodet i kernekommandolinjen og behandles under tidlig opstart i initramfs. «Kort sagt betyder det, at hver kerne er korrekt synkroniseret med det tilsvarende rodfilsystem, og tilbagespring er billigt, enkelt og tilg\u00e6ngeligt direkte fra opstartsmenuen», forklarer udviklerne. En anden fordel er, at der ikke er nogen \/etc\/default\/grub, og hvis ESP slettes, kan moss genoprette det fra bunden.\n
.stone pakkeformatet er et propriet\u00e6rt bin\u00e6rt pakkeformat med versionsagnostisk header for at muligg\u00f8re fremtidige \u00e6ndringer. Hver .stone pakke indeholder fire specifikke datatyper (payload), som hver is\u00e6r kan udvikles uafh\u00e6ngigt takket v\u00e6re versionering:\n
\n
Indholdspayload (Content payload) - en sekventiel blok af deduplicerede data, alts\u00e5 selve indholdet af pakke-filerne.\n
Indexpayload (Index payload) - indeholder offsets for indholdspayload, indekseret efter hash XXH128 af indholdet (overgangen til Blake3 er planlagt). Dette muligg\u00f8r effektiv s\u00f8gning og udvinding af data.\n
Layoutpayload (Layout payload) - beskriver den forventede layout af fildistributionssystemet ved anvendelse af pakken, det vil sige hvor og hvilke filer der skal installeres.\n
Metadata payload - en sekvens af strikt typede, m\u00e6rkede metadata-poster, s\u00e5som pakke navn, leverede funktioner osv. <\/ul>\n<\/ul>\n
Komprimering af alle belastninger sker ved hj\u00e6lp af Zstd, hvilket sikrer fremragende decompressionsydelse samtidigt med, at der opretholdes en god komprimeringsgrad. Installationsprocessen for .stone adskiller sig markant fra andre systemer. I stedet for at installere filer direkte, caches pakken, og dens indhold flettes ind i et samlet lager med indholdsadressere (CAS). Metadata og layoutinformation opbevares separat og anvendes ved oprettelse af transaktioner. Denne tilgang sikrer atomaritet i opdateringer og muligheden for rollback, da hver transaktion skaber et nyt rodpartition i stedet for at \u00e6ndre den eksisterende. <\/p>\n
Udviklerne bem\u00e6rker, at den nuv\u00e6rende tilgang med emulering af imperativ paketstyring er \"helt meningsl\u00f8s\" og \"faktisk introducerer flere fejl, end den l\u00f8ser\". Da der for hver transaktion oprettes et nyt rodfilesystem, planl\u00e6gges der i fremtiden at skabe et nyt graf for hver transaktion og frav\u00e6lge indbyggede \u00e6ndringer til fordel for en deklarativ tilgang som Gentoo eller Nix. <\/p>\n
En anden interessant forklaring handler om uforanderlighed (immutability). Skaberne bem\u00e6rker, at AerynOS ofte beskrives som et uforanderligt OS, men \"det er ikke helt korrekt\". Selvom hver transaktion resulterer i et nyt tr\u00e6 \/usr, og lokale \u00e6ndringer ikke gemmes, er systemet ikke uforanderligt i betydningen kun-l\u00e6seadgang. I fremtiden planl\u00e6gges det at implementere \u00e6gte uforanderlighed i systemet uden behov for genstart ved hj\u00e6lp af erofs og overlayfs. <\/p>\n
AerynOS er i \u00f8jeblikket under aktiv udvikling, frigiver allerede ISO-billeder med GNOME-milj\u00f8et, er velegnet til gaming (underst\u00f8ttelse af NVIDIA-drivere, Steam, Flatpak) og har faktiske brugere, der bem\u00e6rker systemets stabilitet og innovationsniveau. If\u00f8lge udviklerne er projektet i alpha-fase og har sine problemer, men det repr\u00e6senterer allerede et sammenh\u00e6ngende system, der \"bare fungerer\". \n Kilde: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"