Probabilmente esistono migliaia di distribuzioni Linux differenti in forma, peso, colore, sapore, spin e… insomma ci vuole la teoria delle stringhe per elencare e descrivere tutte le distribuzioni Linux che esistono. Perché sono così tante?
Sicuramente perché esistono infiniti (letteralmente) modi diversi di fare la stessa cosa. Sicurasmente perché è relativamente facile iniziare la propria distribuzione Linux personalizzata. Per esempio uno può usare Bedrock Linux, una meta distribuzione Linux con la quale è possibile basarsi su distribuzioni esistenti, anzichè partire da zero, per intraprendere questo viaggio.
Comunque, per quanto sia facile iniziare una nuova distribuzione, ben più difficile è ottenere successo (come tutte le cose d’altronde) e ancora di più è mantenere quel successo nel tempo. Per esempio Ubuntu è (era) probabilemente la più nota distribuzione in assoluto in ambito desktop, ma ormai da anni sta sempre più perdendo terreno per svariati motivi.
Comunque non siam qui a creare l’ennesima derivata di Ubuntu che sistema questo o quel piccolo dettaglio. Siamo qui per parlare di distribuzioni nuove (e vecchie) che hanno quella particolarità o funzione aggiuntiva rispetto alle distribuzioni classiche che le rendono speciali in un oceano di possibilità.
Vediamo le principali e più importanti distribuzioni classiche in ambito videoludico secondo GamingOnLinux (perché in ambito videoludico? perché mi torna bene usare questa “classifica”):
- Debian
- Ubuntu
- Fedora
- Arch
- Altre che non tratto qui…
Tutte queste (con le loro ennemila derivate) sono diverse tra loro, ma piuttosto simili.
Ad esempio, tutte queste usano il sistema di init (o di inizializzazione) systemd. Già una distribuzione che usa una roba diversa da systemd sarebbe da annoverare nelle distribuzioni con caratteristiche speciali. Però non è mica detto che solo per questo sia anche interessante. Per esempio esistono distribuzioni banali e noiose come Devuan che si limitano a sostituire systemd con altro sistema ante-guerra con, se va bene, la metà delle funzionalità offerte da systemd. Ad essere onesti systemd è qualcosa di più di un semplice sistema di init e quindi si ragiona male a dire “sostituiamo systemd con SysVinit”, perché dovremmo dire invece “sostituiamo systemd con SysVinit + questo + quell’altro”.
Che dire… i loghi dei sistemi di init non sono troppo accattivanti, ansi la maggior parte non ne ha uno…
Comunque, per quel che ne so, systemd è il più avanzato e attivamente sviluppato sistema di init in circolazione. Lo uso quotidianamente per gestire i servizi offerti da questo server.
Attenzione: con questo non sto dicendo hail systemd e morte agli altri progetti. Solo che al momento non ho trovato (forse perché non ne ho sentito il bisogno) un degno sostituto di systemd. Sicuramente è giusto ed è positivo che esistano e si finanzino progetti alternativi a systemd.
Chiusa la parentesi systemd, vediamo in cosa si distinguono: Debian e Ubuntu usano il gestore di pacchetti apt che usa i pacchetti “.deb”. Fedora usa il gestore di pacchetti yum/dnf e i pacchetti “.rpm”. Arch usa il gestore di pacchetti pacman e i pacchetti… semplice archivio tar compresso, con xz o zstd che sia.
Per quanto diversi, tutti questi sistemi funzionano in modo analogo: l’utente sceglie i pacchetti da installare, il gestore risolve le dipendenze e le aggiunge all’elenco dei pacchetti da installare e scarica, controlla e infine installa tutti i pacchetti richiesti con dipendenze necessarie al funzionamento. Esistono differenze “minori” nel comportamento del gestore, ad esempio: su Debian e Ubuntu quando si installa un servizio, questo viene installato con una configurazione base e viene automaticamente avviato al termine dell’installazione. Questo non succede su Arch, dove i pacchetti tendono ad essere più minimali (a volte proprio essenziali, a volergli fare un complimento) ed è richiesto un maggior convolgimento dell’utente che deve necessariamente smanettare e consultare la ben fatta ArchWiki (probabilmente la migliore), per ottenere qualsiasi cosa.
Il succo è che tutti questi gestori di pacchetti vanno ad alterare in modo spesso irreversibile la radice (la partizione root sul quale è installata la distro) del nostro sistema. Questa alterazione avviene perché diamo dei comandi al gestore di pacchetti e lui obbedisce provocando la modifica richiesta al sistema per mezzo di pacchetti.
Notiamo un paio di caratteristiche: la presenza di pacchetti in qualche forma e l’interazione dell’utente con il gestore di pacchetti per mezzo di comandi. Quindi possiamo dire che apt, pacman e dnf funzionano tutti a pacchetti e comandi.
Nota: per comandi si intendono quelli della riga di comando, ma anche i vari pulsanti installa, aggiorna e disinstalla delle varie interfacce grafiche come GNOME Software.
Quindi la domanda è se esistano soluzioni che non fanno uso di pacchetti. E la risposta è positiva.
Soffermiamoci un attimo su Fedora Silverblue. Si tratta di una variante di Fedora che invece di usare i pacchetti (in realtà li usa eccome, ma non come si intende normalmente) fa uso di immagini o container. In pratica la radice del sistema viene montata in sola lettura e non è possibile alterarla con i comandi che normalmente si usano su Fedora classico. In realtà la radice è memorizzata su di un file system particolare che si chiama OSTree, che potremmo definire un “git per file system”, in quanto condividono struttura e funzionamento. Entrambi sono “content-addressed object store” con branch, ref e commit. La differenza è che git versiona il codice sorgente dei software, mentre OSTree le immagini di file system radice ed è anche in grado di configurare il bootloader in modo appropriato.
Grazie ad OSTree gli aggiornamenti di sistema arrivano come una lista di modifiche da apportare al file system affinchè da uno stato A si giunga ad uno stato B. Questo sistema ignora il fatto che l’immagine contenga millemila pacchetti, semplicemente dice al sistema quali file devono esserci sulla radice e basta. E se volessimo installare un pacchetto che non è presente sull’immagine? Si potrebbe modificare l’immagine, ma questo è sconsigliato perché si vanifica l’utilità di questo sistema. Quel che si può fare è aggiungere un nuovo livello al file system ostree in modo che nella radice si vedano i contenuti di più immagini e, quindi, i pacchetti che si trovano sulle due immagini. Questi livelli possono essere aggiunti e tolti e aggiornati indipendentemente. Se un aggiornamento va storto, non succede nulla perché il livello precedente è sempre lì sul disco. Quindi abbiamo aggiornamenti atomici (o si aggiorna fino in fondo o non si aggiorna per niente) e il ritorno allo stato precedente (rollback) facile.
Una altro modo di installare software aggiuntivo in ambito desktop è quello di usare flatpak, che ha un funzionamento simile a quello appena descritto in quanto integra l’uso di immagini in sola lettura al suo interno e non altera mai la radice (mette solo dei dati sotto /var, che nei sistemi che rispettano FHS deve restare scrivibile).
L’approccio perseguito da Fedora Silverblue è interessante, tuttavia ci lascia intendere che sia una disto poco personalizzabile. D’altronde la radice in sola lettura implica che certi tipi di modifiche diventino più rognose da attuare. La sensazione è che Fedora Silverblue rappresenti un prodotto finito di elevata qualità e facilità d’uso, tuttavia poco personalizzabile e forse poco adatta ai programmatori? Tra l’altro l’approccio Silverblue è sostanzialmente quello intrapreso anche da Steam Deck, la console portatile di Valve che monta una derivata di Arch Linux personalizzata da Valve e chiamata SteamOS.
Vediamo adesso il discorso dei comandi, cioè vediamo se è possibile rendere meno distruttivi i comandi e se è possibile redurre al minimo la possibilità di un errore da parte dell’utente.
Se lanciamo un comando del gestore di pacchetti, non è detto che si possa tornare indietro con la stessa facilità di premere invio sul terminale. Se si esegue un aggiornamento di sistema e le cose si rompono male, non si riesce ad annullare tutto con un click e talvolta l’unica soluzione praticabile è il ricorso ad una copia di backup.
Inoltre conta l’ordine con cui diamo i comandi al gestore di pacchetti. Questo può sembrare ovvio: se prima lancio il comando di aggiornamento e poi quello per disinstallare un pacchetto, ho sprecato un po’ di tempo a scaricare una cosa che non serviva e che avrei potuto evitare scambiando l’ordine delle due operazioni. Questo per dire che lo stile con cui usate apt, pacman o dnf è detto imperativo. Ebbene sì, d’ora in avanti vi sentirete così:
Ecco che siamo incappati in una idea interessante, ovvero un sistema a pacchetti che però non si basi sui comandi. Benvenuti nello stile funzionale dichiarativo.
Le distro più note in questo campo (forse non ce ne sono altre?) sono senz’altro NixOS e GNU Guix System. Di NixOS ho già parlato in un mio precedente articolo, quindi parliamo un po’ di Guix.
GNU Guix è una distro approvata dalla Free Software Foundation, quindi è pura e rispetta tutte le libertà del software sempre e comunque. Più pragmaticamente questo significa che girerà solo su pochi computer (per lo più obsoleti) perché di default usa il kernel linux-libre che è privo di firmware e blob proprietari che invece si trovano su linux normale e sono necessari per far funzionare quasi tutti gli hardware moderni.
Oltre a questo, GNU Guix System usa il gestore di pacchetti GNU Guix che è scritto in Guile, un linguaggio della famiglia LISP. Anche i pacchetti sono generati a partire da programmi scritti in Guile. È facile notare le somiglianze con NixOS, che invece usa il gestore nix scritto nel linguaggio funzionale nix (si, nella Terra di nix si chiama tutto nix).
Inoltre GNU Guix System non usa systemd, bensì il sistema di init GNU Shepherd (l’unica distro linux che lo usa) che è scritto e configurabile anch’esso nel linguaggio Guile. Non avendo mai provato ne GNU Guix System, nè GNU Shepherd non posso lasciarvi una valutazione. Ci sta che ci rincontreremo su questo blog a parlare di GNU Guix System e GNU Shepherd.
Da un po’ di tempo a questa parte mi sono appassionato di Clojure, un linguaggio funzionale che appartiene sempre alla famiglia LISP, di cui ho avuto un’impressione molto positiva, tant’è che anche Guile, essendo sempre LISP, mi attira abbastanza, specialmente rispetto a nix, che invece ha una sintassi più stile C.
Un altra ragione per cui mi interessa Guix e Guile è il Fediverse. Ecco, seguo varie persone che apprezzano molto Guile e mi capita spesso di imbattermi in discussioni che riguardano Guile. Imparare qualcosa di questo linguaggio, potrebbe farmi guadagnare molte stelline dai miei ammiratori. Potrei persino fare soldi da Guile influencer.
Comunque queste sono le distro del futuro. Facilmente riproducibili, configurazione dichiarativa, linguaggi funzionali, file system immutabili, aggiornamenti atomici, rollback a portata di click.
Forse un giorno esisterà la distro perfetta, ma fino ad allora, vi auguro una buona sperimentazione e frammentazione dell’ecosistema delle distribuzioni Linux. Per un futuro più diverso e migliore!