Gli sviluppatori di AerynOS, precedentemente noto come SerpentOS, hanno pubblicato un articolo dettagliato che rivela i dettagli del concetto e dell'implementazione tecnica del progetto, giustificando le scelte architettoniche adottate. Il project manager Ikey Doherty sottolinea che AerynOS non è semplicemente "un'altra distribuzione Linux", ma una piattaforma, una base e un insieme di strumenti creati secondo una visione chiara.
L'idea principale del progetto è formulata sotto forma di domanda: "E se il sistema operativo si comportasse come un'infrastruttura moderna?". AerynOS è presentato come risposta a questa domanda: un sistema costruito da zero, e non una continua evoluzione delle tradizionali mutazioni integrate in una distribuzione. Il progetto si basa sull'esperienza degli autori nello sviluppo di altre distribuzioni, tra cui Solus e Clear Linux.
Tra le principali scelte tecniche di AerynOS si possono evidenziare:
- 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à 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 intensivi in calcolo e applicazioni che richiedono prestazioni ottimali nel multi-threading". I creatori sottolineano che il loro obiettivo è costruire un sistema funzionante, utilizzabile in moltissimi scenari.
- Il concetto di "statelessness" (senza stato) – ai pacchetti è vietato contenere file al di fuori della directory /usr. Come spiegano gli sviluppatori, questo approccio impone di garantire valori ragionevoli per impostazione predefinita a tutti i livelli e elimina "terribili conflitti di merge triplo durante l'aggiornamento dei pacchetti". Non ci sono conflitti, perché tutto in /etc e /var appartiene all'utente, mentre /usr appartiene esclusivamente al sistema. Questo concetto è stato sviluppato ai tempi di Clear Linux e Solus, e in AerynOS ha trovato ulteriore sviluppo.
- Gli aggiornamenti atomici - ogni transazione moss è 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 viene eseguito completamente oppure non viene eseguito affatto, senza stati intermedi.
- Gestione dell'avvio basata sui progetti blsforme e disks-rs. La peculiarità dell'approccio è che il sistema genera dinamicamente i parametri per la riga di comando del kernel, leggendo i superblocchi dei dispositivi del file system di root, quindi in AerynOS non esiste un file di configurazione che contenga il parametro "root=". Inoltre, l'identificatore della transazione moss è codificato nella riga di comando del kernel e viene elaborato durante l'avvio iniziale in initramfs. "In breve, questo significa che ogni kernel è correttamente sincronizzato con il corrispondente file system di root e il ripristino è economico, semplice e accessibile direttamente dal menu di avvio", spiegano gli sviluppatori. Un altro vantaggio è l'assenza di /etc/default/grub, e se l'ESP viene cancellato, moss può ripristinarlo da zero.
- Il formato dei pacchetti .stone è un formato binario proprietario per i pacchetti con un'intestazione indipendente dalla versione per garantire modifiche future. Ogni pacchetto .stone contiene quattro tipi specifici di dati (payload), ognuno dei quali può evolversi in modo indipendente grazie alla versioning:
- Payload contenutistico (Content payload) - un blocco sequenziale di dati deduplicati, cioè il contenuto stesso dei file del pacchetto.
- Payload indice (Index payload) - contiene gli offset per il payload contenutistico, indicizzati con l'hash XXH128 del contenuto (è previsto il passaggio a Blake3). Questo consente di trovare ed estrarre i dati in modo efficiente.
- Payload layout (Layout payload) - descrive il layout previsto del file system quando viene applicato il pacchetto, cioè dove e quali file devono essere installati.
- Payload metadati (Metadata payload) - una sequenza di registrazioni di metadati tipizzati e contrassegnati, come il nome del pacchetto, le funzionalità fornite, ecc.
La compressione di tutti i carichi avviene tramite Zstd, il che garantisce eccellenti prestazioni di decompressione mantenendo un buon rapporto di compressione. Il processo di "installazione" di .stone è 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 archivio comune 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à degli aggiornamenti e la possibilità di rollback, poiché ogni transazione crea una nuova partizione radice anziché modificare quella esistente.
Gli sviluppatori notano che l'attuale approccio all'emulazione della gestione imperativa dei pacchetti è "totalmente insensato" e "effettivamente introduce più errori di quanti ne risolva". Poiché per ogni transazione viene creata una nuova radice del filesystem, in futuro si prevede di creare un nuovo grafo per ogni transazione, abbandonando le modifiche incorporate a favore di un approccio dichiarativo, simile a Gentoo o Nix.
Un ulteriore chiarimento interessante riguarda l'immutabilità. I creatori evidenziano 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 vengono salvate, il sistema non è immutabile nel senso di avere accesso solo in lettura. In futuro, si prevede l'implementazione di una vera immutabilità del sistema senza la necessità di riavvio utilizzando erofs e overlayfs.
Attualmente, AerynOS è in fase attiva di sviluppo, genera già immagini ISO con ambiente GNOME, adatto per il gioco (supporto per driver NVIDIA, Steam, Flatpak), e ha utenti reali che segnalano stabilità e innovazione del sistema. Secondo gli sviluppatori, il progetto è in fase alfa e non è privo di problemi, ma rappresenta già un sistema coerente che "funziona semplicemente".
Fonte: opennet.ru
