Gli sviluppatori di AerynOS, precedentemente conosciuto come SerpentOS, hanno pubblicato un articolo esaustivo che svela i dettagli del concetto e della realizzazione tecnica del progetto, giustificando le scelte architettoniche fatte. Il responsabile del progetto, Ikey Doherty, sottolinea che AerynOS non è semplicemente "un altro distribuzione Linux", ma una piattaforma, una base e un insieme di strumenti concepiti secondo una visione chiara.
L'idea principale del progetto è formulata sotto forma di domanda: "E se un sistema operativo si comportasse come un'infrastruttura moderna?" AerynOS è presentato come la risposta a questa domanda: un sistema costruito da zero, invece di seguire il modello tradizionale delle mutate incorporate all'interno di una distribuzione. Il progetto si basa sull'esperienza degli autori nello sviluppo di altre distribuzioni, tra cui Solus e Clear Linux.
Tra le soluzioni tecniche chiave di AerynOS si possono evidenziare:
- L'uso degli strumenti LLVM invece di GNU, con libc++ e compiler-rt utilizzati come standard. Gli sviluppatori spiegano che questa scelta non è solo una preferenza per LLVM, ma una decisione strategica per sfruttare diagnosi di qualità superiore, garantire correttezza e portabilità dei pacchetti. Inoltre, il sistema utilizza glibc invece di musl, una scelta consapevole a favore della compatibilità e delle prestazioni.
Come indicato nell'articolo: "Il vantaggio di glibc rispetto a musl in termini di prestazioni è ben documentato, specialmente per carichi di lavoro computazionalmente intensivi e applicazioni che richiedono prestazioni ottimali per il multi-threading." I creatori sottolineano che il loro obiettivo è costruire un sistema funzionante e utilizzabile per molteplici scenari d'uso.
- Il concetto di "statelessness" (senza stato) - i pacchetti non possono contenere file al di fuori della directory /usr. Come spiegano gli sviluppatori, questo approccio costringe a garantire valori ragionevoli per impostazione predefinita a tutti i livelli ed elimina "orribili conflitti di merge a tre vie durante l'aggiornamento dei pacchetti". I conflitti non si verificano, poiché tutto in /etc e /var appartiene all'utente, mentre /usr appartiene esclusivamente al sistema. Questo concetto è stato sviluppato durante l'era di Clear Linux e Solus, e ha trovato ulteriore sviluppo in AerynOS.
- Aggiornamenti atomici - ogni transazione moss è atomica. Il sistema crea rapidamente un nuovo albero /usr utilizzando link rigidi da una cache deduplicata. Dopo la creazione e preparazione di successo, il nuovo albero viene sostituito in modo atomico. La transazione preparata viene scambiata con il vero catalogo /usr utilizzando renameat2 con il flag RENAME_EXCHANGE. L'aggiornamento viene eseguito completamente o non viene eseguito affatto, senza stati intermedi.
- Gestione del boot basata sui progetti blsforme e disks-rs. La particolarità dell'approccio è che il sistema genera dinamicamente i parametri per la riga di comando del kernel, leggendo i superblocchi dei dispositivi del file system radice, quindi in AerynOS non esiste un file di configurazione contenente il parametro "root=". Inoltre, l'identificativo della transazione moss è codificato nella riga di comando del kernel e viene trattato durante il caricamento iniziale in initramfs. "In breve, questo significa che ogni kernel è correttamente sincronizzato con il corrispondente file system radice, e il rollback è economico, semplice e disponibile direttamente dal menu di avvio", spiegano gli sviluppatori. Un ulteriore vantaggio è l'assenza di /etc/default/grub e se l'ESP viene cancellato, moss è in grado di ripristinarlo da zero.
- Il formato dei pacchetti .stone è un formato binario di pacchetti proprietario con un'intestazione indipendente dalla versione per garantire modifiche future. Ogni pacchetto .stone contiene quattro specifici tipi di dati (payload), ognuno dei quali può evolversi indipendentemente grazie alla versione:
- Contenuto del payload (Content payload) - un blocco sequenziale di dati deduplicati, cioè il contenuto stesso dei file del pacchetto.
- Payload dell'indice (Index payload) - contiene gli offset per il contenuto del payload, indicizzati tramite l'hash XXH128 del contenuto (è previsto un passaggio a Blake3). Questo consente di trovare ed estrarre i dati in modo efficiente.
- Payload di layout (Layout payload) - descrive il layout previsto del file system all'applicazione del pacchetto, cioè dove e quali file devono essere installati.
- Payload dei metadati (Metadata payload) - una sequenza di voci di metadati fortemente tipizzati e etichettati, come il nome del pacchetto, le funzionalità fornite, ecc.
La compressione di tutti i carichi è realizzata tramite Zstd, offrendo un'ottima velocità di decompressione mantenendo un buon rapporto di compressione. Il processo di 'installazione' di .stone è radicalmente diverso da quello di altri sistemi. Invece di installare direttamente i file, il pacchetto viene memorizzato nella cache e il suo contenuto si intreccia in uno spazio di archiviazione comune con indirizzamento basato sul contenuto (CAS). I metadati e le informazioni sul layout vengono conservati separatamente e utilizzati durante la creazione della transazione. Questo approccio garantisce l'atomicità degli aggiornamenti e la possibilità di rollback, poiché ogni transazione crea una nuova radice di partizione, anziché modificare quella esistente.
Gli sviluppatori osservano che l'attuale approccio all'emulazione del controllo imperativo dei pacchetti è 'completamente insensato' e 'introdurre più errori di quanti ne risolve'. Poiché per ogni transazione viene creata una nuova radice del file system, in futuro si prevede di creare un nuovo grafo per ogni transazione, abbandonando le modifiche integrate a favore di un approccio dichiarativo simile a Gentoo o Nix.
Un'altra interessante spiegazione riguarda l'immutabilità. I creatori notano che spesso AerynOS è descritto come un sistema operativo immutabile, ma 'questo non è del tutto corretto'. Anche se ogni transazione porta a un nuovo albero /usr e le modifiche locali non sono conservate, il sistema non è immutabile nel senso di accesso solo in lettura. In futuro è prevista l'implementazione di una vera immutabilità del sistema senza la necessità di un riavvio, utilizzando erofs e overlayfs.
Attualmente, AerynOS è in fase di sviluppo attivo, con ISO già disponibili che includono l'ambiente GNOME, è adatto per il gioco (supporto per driver NVIDIA, Steam, Flatpak), con utenti reali che segnalano stabilità e innovazione del sistema. Secondo gli sviluppatori, il progetto è in fase alpha e presenta alcune problematiche, ma rappresenta già un sistema coerente che 'funziona semplicemente'.
Fonte: opennet.ru
