{"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\/novosti-interneta\/predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij","title":{"rendered":"Presentata la concezione della distribuzione AerynOS con la motivazione delle scelte architettoniche","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Gli sviluppatori di AerynOS, precedentemente conosciuto come SerpentOS, hanno pubblicato un articolo dettagliato che svela le informazioni sulla concezione e sull'implementazione tecnica del progetto, giustificando le decisioni architettoniche adottate. Il responsabile del progetto, Ikey Doherty, sottolinea che AerynOS non \u00e8 solo \"un altro sistema operativo Linux\", ma una piattaforma, una base e un insieme di strumenti creati secondo una visione chiara. <\/p>\n
L'idea principale del progetto \u00e8 formulata tramite 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 un'evoluzione della tradizionale serie di modifiche all'interno di un distribuzione. Il progetto si basa sull'esperienza degli autori nello sviluppo di altre distribuzioni, tra cui Solus e Clear Linux. <\/p>\n
Tra le soluzioni tecniche chiave di AerynOS si possono evidenziare: <\/p>\n
\n
L'uso degli strumenti LLVM invece di GNU, con libc++ e compiler-rt utilizzati come standard. Gli sviluppatori spiegano che questa scelta non \u00e8 solo una preferenza per LLVM, ma una decisione strategica per sfruttare 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 in multi-threading\". I creatori sottolineano che il loro obiettivo \u00e8 costruire un sistema funzionale e utilizzabile per una moltitudine di scenari. <\/p>\n
Il concetto di \"statelessness\" (senza stato) implica che ai pacchetti \u00e8 vietato contenere file al di fuori della directory \/usr. Gli sviluppatori spiegano che questo approccio costringe a fornire valori predefiniti ragionevoli a tutti i livelli ed elimina \"orribili conflitti di fusione a tre vie durante l'aggiornamento dei pacchetti\". Non ci sono conflitti, poich\u00e9 tutto in \/etc e \/var appartiene all'utente, mentre \/usr \u00e8 esclusivamente di sistema. Questo concetto era stato sviluppato durante il periodo di Clear Linux e Solus, e in AerynOS ha trovato un ulteriore sviluppo.\n
Aggiornamenti atomici: ogni transazione moss \u00e8 atomica. Il sistema crea rapidamente un nuovo albero \/usr utilizzando collegamenti rigidi da una cache deduplicata. Dopo la creazione e la preparazione riuscite, il nuovo albero viene scambiato in modo atomico. In effetti, la transazione preparata viene scambiata con la directory reale \/usr utilizzando renameat2 con il flag RENAME_EXCHANGE. L'aggiornamento avviene interamente o non avviene affatto, senza stati intermedi.\n
Gestione dell'avvio basata sui progetti blsforme e disks-rs. Caratteristica di questo approccio \u00e8 che il sistema forma dinamicamente i parametri per la riga di comando del kernel, leggendo i superblocchi dei dispositivi del file system radice, pertanto in AerynOS non esiste un file di configurazione che contenga il parametro \"root=\u201c. Inoltre, l'identificativo 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 corrispondente file system radice e il rollback \u00e8 economico, semplice e disponibile direttamente dal menu di avvio,\" spiegano gli sviluppatori. Un ulteriore vantaggio \u00e8 l'assenza di \/etc\/default\/grub; se l'ESP viene cancellato, moss pu\u00f2 ripristinarlo da zero.\n
Il formato pacchetti .stone \u00e8 un formato binario proprietario per i pacchetti con un'intestazione indipendente dalla versione per garantire modifiche future. Ogni pacchetto .stone contiene quattro specifici tipi di dati (payload), ognuno dei quali pu\u00f2 evolversi indipendentemente grazie al versionamento:\n
\n
Payload di contenuto (Content payload) - un blocco sequenziale di dati deduplicati, ovvero il contenuto stesso dei file del pacchetto.\n
Payload di indice (Index payload) - contiene gli offset per il payload di contenuto, indicizzati in base all'hash XXH128 del contenuto (si prevede di passare a Blake3). Questo consente di trovare ed estrarre i dati in modo efficiente.\n
Payload di layout (Layout payload) - descrive il layout previsto del file system quando si applica il pacchetto, cio\u00e8 dove e quali file devono essere installati.\n
Payload di metadati (Metadata payload) - una sequenza di record di metadati rigorosamente tipizzati e 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 offre eccellenti 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 \u00e8 intrecciato in un deposito comune con indirizzamento basato sul contenuto (CAS). I metadati e le informazioni sul layout sono memorizzati separatamente e utilizzati durante la 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 anzich\u00e9 modificare quella esistente. <\/p>\n
Gli sviluppatori sottolineano che l'attuale approccio all'emulazione della gestione imperativa dei pacchetti \u00e8 \"completamente insensato\" e \"in realt\u00e0 introduce pi\u00f9 errori di quanti ne risolva\". Poich\u00e9 ogni transazione crea un nuovo filesystem radice, in futuro \u00e8 previsto lo sviluppo di un nuovo grafo per ogni transazione, abbandonando le modifiche integrate in favore di un approccio dichiarativo, simile a Gentoo o Nix. <\/p>\n
Un altro interessante chiarimento riguarda l'immutabilit\u00e0. I creatori osservano che spesso AerynOS viene descritto come un sistema operativo immutabile, ma \"questo non \u00e8 del tutto corretto\". Anche se ogni transazione porta a un nuovo albero \/usr e le modifiche locali non vengono memorizzate, il sistema non \u00e8 immutabile nel senso di essere accessibile solo in lettura. In futuro \u00e8 prevista 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 sviluppo attivo, gi\u00e0 rilascia immagini ISO con l'ambiente GNOME, \u00e8 adatto per il gaming (supporto per driver NVIDIA, Steam, Flatpak), e ha utenti reali che segnalano stabilit\u00e0 e innovazione del 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 e basta\". \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"