{"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\/it\/blog\/news\/predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij","title":{"rendered":"\u00c8 stata presentata la concept di distribuzione AerynOS con una giustificazione delle scelte architetturali.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Gli sviluppatori di AerynOS, precedentemente noto come SerpentOS, hanno pubblicato un articolo dettagliato che rivela le specifiche della concezione e dell'implementazione tecnica del progetto, giustificando le scelte architetturali adottate. Il project manager Ikey Doherty sottolinea che AerynOS non \u00e8 solo \"un'altra distribuzione Linux\", ma una piattaforma, una base e un insieme di strumenti realizzati secondo una visione chiara. <\/p>\n
L'idea principale del progetto \u00e8 formulata come una domanda: \"Cosa succederebbe se un sistema operativo si comportasse come un'infrastruttura moderna?\". AerynOS \u00e8 presentato come la risposta a questa domanda: un sistema costruito da zero, non una semplice evoluzione tradizionale delle mutazioni all'interno di una distribuzione. Il progetto si basa sull'esperienza degli autori nello sviluppo di altre distribuzioni, tra cui Solus e Clear Linux. <\/p>\n
Tra le principali scelte tecniche di AerynOS si possono evidenziare: <\/p>\n
\n
L'uso di strumenti LLVM invece di GNU, con libc++ e compiler-rt impostati per default. Gli sviluppatori spiegano questa scelta non solo come una preferenza per LLVM, ma come una decisione strategica per utilizzare diagnosi di qualit\u00e0 superiore, garantire correttezza e portabilit\u00e0 dei pacchetti. Inoltre, il sistema utilizza glibc invece di musl, una scelta consapevole a favore della compatibilit\u00e0 e delle prestazioni.\n
Come indicato nell'articolo: \"Il vantaggio di glibc rispetto a musl in termini di prestazioni \u00e8 ben documentato, specialmente per carichi di lavoro computazionalmente intensivi e applicazioni che richiedono prestazioni ottimali nella multithreading\". I creatori sottolineano che il loro obiettivo \u00e8 costruire un sistema funzionante e utilizzabile per una vasta gamma di scenari. <\/p>\n
Il concetto di \"statelessness\" (senza stato) vieta ai pacchetti di contenere file al di fuori della directory \/usr. Come spiegano gli sviluppatori, questo approccio costringe a fornire valori di default ragionevoli a tutti i livelli ed elimina \"terribili conflitti di merge a tre vie durante l'aggiornamento dei pacchetti\". Non ci sono conflitti perch\u00e9 tutto in \/etc e \/var appartiene all'utente, mentre \/usr \u00e8 riservato al sistema. Questo concetto \u00e8 stato sviluppato ai tempi di Clear Linux e Solus, e ha subito ulteriori sviluppi in AerynOS.\n
Gli aggiornamenti atomici: ogni transazione moss \u00e8 atomica. Il sistema crea rapidamente un nuovo albero \/usr utilizzando hard link da un cache deduplicata. Dopo la creazione e la preparazione di successo, il nuovo albero viene sostituito in modo atomico. In pratica, la transazione preparata viene scambiata con la directory reale \/usr utilizzando renameat2 con il flag RENAME_EXCHANGE. L'aggiornamento viene completato completamente oppure non viene eseguito affatto, senza stati intermedi.\n
Gestione del caricamento basata sui progetti blsforme e disks-rs. La particolarit\u00e0 di questo approccio \u00e8 che il sistema forma dinamicamente i parametri per la riga di comando del kernel, leggendo i superblocchi dei dispositivi del filesystem radice, pertanto in AerynOS non esiste un file di configurazione che contenga il parametro \"root= \". Inoltre, l'identificatore della transazione moss \u00e8 codificato nella riga di comando del kernel e viene elaborato durante il caricamento iniziale in initramfs. \"In breve, ci\u00f2 significa che ogni kernel \u00e8 correttamente sincronizzato con il rispettivo filesystem radice, e il rollback \u00e8 economico, semplice e disponibile direttamente dal menu di avvio\", spiegano gli sviluppatori. Un altro vantaggio \u00e8 l'assenza di \/etc\/default\/grub; se l'ESP viene cancellato, moss pu\u00f2 ripristinarlo da zero.\n
Il formato dei pacchetti .stone \u00e8 un formato binario di pacchetti proprietario con una testata agnostica rispetto alla versione per garantire future modifiche. Ogni pacchetto .stone contiene quattro specifici tipi di dati (payload), ognuno dei quali pu\u00f2 evolversi in modo indipendente grazie alla gestione delle versioni:\n
\n
Contenuto (Content payload) - un blocco sequenziale di dati deduplicati, cio\u00e8 il contenuto stesso dei file del pacchetto.\n
Indice (Index payload) - contiene gli offset per il contenuto, indicizzati in base all'hash XXH128 del contenuto (\u00e8 previsto il passaggio a Blake3). Ci\u00f2 consente di trovare ed estrarre i dati in modo efficiente.\n
Layout (Layout payload) - descrive il layout previsto del filesystem quando viene applicato il pacchetto, cio\u00e8 dove e quali file devono essere installati.\n
Metadati (Metadata payload) - una sequenza di record di metadati strettamente tipizzati, contrassegnati, come il nome del pacchetto, le funzionalit\u00e0 fornite, ecc. <\/ul>\n<\/ul>\n
La compressione di tutti i carichi avviene tramite Zstd, che garantisce ottime prestazioni di decompressione mantenendo un buon rapporto di compressione. Il processo di \"installazione\" di .stone \u00e8 radicalmente diverso da altri sistemi. Invece di installare direttamente i file, il pacchetto viene memorizzato nella cache e il suo contenuto viene intrecciato in un'unica archiviazione con indirizzamento basato sul contenuto (CAS). I metadati e le informazioni sul layout sono conservati separatamente e vengono utilizzati nella creazione della transazione. Questo approccio garantisce l'atomicit\u00e0 degli aggiornamenti e la possibilit\u00e0 di rollback, poich\u00e9 ogni transazione crea una nuova partizione radice, senza modificare quella esistente. <\/p>\n
Gli sviluppatori notano che l'attuale approccio di emulazione del controllo imperativo dei pacchetti \u00e8 \"completamente insensato\" e \"in effetti introduce pi\u00f9 errori di quanti ne risolva\". Poich\u00e9 per ogni transazione viene creata una nuova filesystem radice, in futuro si prevede la creazione di un nuovo grafo per ogni transazione, abbandonando le modifiche incorporate a favore di un approccio dichiarativo simile a Gentoo o Nix. <\/p>\n
Un'altra interessante spiegazione riguarda l'immuabilit\u00e0. I creatori notano che spesso AerynOS viene descritto come un sistema operativo immutabile, ma \"non \u00e8 del tutto corretto\". Anche se ogni transazione porta a un nuovo albero \/usr e le modifiche locali non vengono mantenute, il sistema non \u00e8 immutabile in senso di accesso solo in lettura. In futuro si prevede l'implementazione di una vera immutabilit\u00e0 del sistema senza la necessit\u00e0 di riavvio, utilizzando erofs e overlayfs. <\/p>\n
Attualmente AerynOS \u00e8 in fase di attivo sviluppo, pubblica gi\u00e0 immagini ISO con l'ambiente GNOME, \u00e8 adatto per il gaming (supporto per driver NVIDIA, Steam, Flatpak) e ha utenti reali che riscontrano stabilit\u00e0 e innovazione nel sistema. Secondo gli sviluppatori, il progetto \u00e8 in fase alpha e non \u00e8 privo di problemi, ma rappresenta gi\u00e0 un sistema coeso che \"funziona semplicemente\". \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"