Storia delle distribuzioni Linux e delle loro origini

Che cos'è realmente una distribuzione Linux

La storia delle distribuzioni Linux inizia da una lacuna: il kernel Linux, da solo, non fa nulla che una persona possa utilizzare. Si avvia e rileva l'hardware. Poi si ferma. Qualcuno deve aggiungere uno userland, scegliere come installare e aggiornare il software e impegnarsi a correggere i problemi per anni. Una distribuzione è l'insieme di queste scelte, oltre al gruppo di persone che continua a occuparsene nel tempo.

Ha cinque componenti. I progetti che le scelgono in modo diverso realizzano distribuzioni diverse, anche quando la maggior parte dei binari coincide:

• Un kernel, alla versione scelta dal progetto, con le patch e i driver aggiunti. Una release può offrirne più di uno: Ubuntu 24.04 LTS installa per impostazione predefinita sui server il kernel GA (general availability) e offre come opzione il kernel HWE (hardware enablement) più recente.
• Uno userland: la libreria C, la shell, il sistema init e i comandi standard.
• Un formato per i pacchetti e lo strumento che li installa.
• Una politica di rilascio: cosa può cambiare, con quale frequenza e per quanto tempo viene mantenuta ogni release.
• Le persone: manutentori dei pacchetti, un team di sicurezza e qualcuno che risponde quando un pacchetto presenta problemi.

Il kernel è la parte condivisa, quindi due distribuzioni Linux sono molto più vicine tra loro di quanto ciascuna lo sia a un altro Unix. È importante ricordarlo quando si confrontano Linux e FreeBSD come piattaforme server, dove il kernel e lo userland di base sono sviluppati da un unico progetto e rilasciati insieme. In Linux questi componenti provengono da upstream distinti, e la distribuzione è ciò che li rende compatibili.

Una storia delle distribuzioni Linux in tre famiglie

Tre progetti avviati nel 1993 e nel 1994 sono diventati famiglie: Slackware, Debian e Red Hat. Oggi quasi tutte le immagini disponibili in un pannello di controllo VPS appartengono a una di queste famiglie oppure a una loro derivata. Una derivata eredita il formato dei pacchetti, la struttura del filesystem e in genere anche le modalità di rilascio. Per questo una derivata Debian continua a comportarsi come Debian anche dopo la rimozione del branding.

I progetti indipendenti meritano una sezione a parte, perché non derivano da nessun altro progetto. Arch, Gentoo, Alpine, NixOS e Void hanno sviluppato ciascuno il proprio gestore dei pacchetti e le proprie regole. Due di questi, Arch e Alpine, sono comunque finiti nell'elenco delle immagini del provider, per motivi che non avevano nulla a che fare con l'ambiente desktop.

1992: le distribuzioni prima delle famiglie

MCC Interim Linux è comparsa nel febbraio 1992, assemblata da Owen Le Blanc presso il Manchester Computing Centre. Includeva il kernel e gli strumenti GNU (GNU's not Unix) in una coppia di immagini floppy, con un installer basato su menu. È nata perché eseguire manualmente quelle operazioni richiedeva una giornata di lavoro.

SLS (Softlanding Linux System), rilasciata da Peter MacDonald nel 1992, si spinse oltre e aggiunse X (the X Window System) e il networking TCP/IP. SLS è il motivo per cui il termine distribuzione ha il significato attuale. Era anche piena di bug e veniva mantenuta lentamente. Nel 1993, due persone decisero separatamente di correggere il problema. Una la ricostruì. L'altra ripartì da zero seguendo regole scritte.

Slackware, 1993: la famiglia più antica ancora distribuita

Patrick Volkerding ha rilasciato Slackware 1.00 il 16 luglio 1993, a partire da SLS e correggendone i bug. Il progetto è ancora mantenuto, quindi Slackware è la distribuzione Linux più antica tuttora esistente.

Un pacchetto Slackware è un archivio tar compresso che contiene uno script di installazione. Non esiste alcuna risoluzione delle dipendenze: nessun componente verifica che la libreria richiesta dal nuovo pacchetto sia già presente sul disco. Questa singola scelta ha determinato tutto il resto. Se lo strumento non risolve le dipendenze, l'insieme dei pacchetti distribuiti deve essere coerente per costruzione, quindi le release sono rare e conservative. Slackware 15.0 è arrivata nel febbraio 2022, sei anni dopo la 14.2.

La famiglia è ridotta. Le prime release di SUSE, a metà degli anni 1990, erano basate su Slackware, prima che il progetto seguisse una propria direzione con YaST e, in seguito, con il formato di pacchetto RPM. Quest'ultimo aspetto genera confusione. SUSE e openSUSE usano pacchetti RPM, ma non sono derivate da Red Hat. Il formato si è diffuso. La linea evolutiva no.

Debian, 1993: un contratto sociale e una pipeline a tre suite

Ian Murdock annunciò Debian il 16 agosto 1993, un mese dopo Slackware e per lo stesso motivo. Il nome unisce quello della sua compagna, Debra, al proprio. Il Debian Manifesto seguì nel gennaio 1994 e stabilì i termini: questa distribuzione sarebbe stata mantenuta apertamente da volontari, non da un'azienda.

Debian mise quindi i termini per iscritto. Il Debian Social Contract e le DFSG (linee guida Debian per il software libero) furono adottati nel luglio 1997 e le DFSG divennero la base dell'Open Source Definition nel 1998. Un documento scritto per stabilire cosa potesse appartenere a una distribuzione finì per definire una categoria di licenze per l'intero settore. È anche il motivo per cui il tuo sources.list ha componenti: main contiene software conforme alle linee guida e che non richiede nulla al di fuori di main, contrib contiene software che le rispetta ma richiede qualcosa al di fuori di main per essere compilato o eseguito, non-free contiene ciò che non le rispetta e Debian 12 ha aggiunto non-free-firmware, così un laptop con una scheda wireless potesse installare il sistema senza una ricerca complessa dei pacchetti necessari.

Gli strumenti sono l'altra eredità. dpkg installa un pacchetto e si interrompe quando manca qualcosa, stampando dpkg: dependency problems prevent configuration of. APT (strumento avanzato per i pacchetti), diventato predefinito con Debian 2.1 nel 1999, è il livello che determina cos'altro scaricare e in quale ordine. Ogni comando apt presente in ogni derivata di Debian discende da quel lavoro.

Il processo di rilascio usa tre suite e una regola. Un maintainer carica i pacchetti in unstable, con nome in codice permanente sid. Uno script migra il pacchetto in testing dopo 2, 5 o 10 giorni, in base all'urgenza del caricamento, se il pacchetto è compilato e aggiornato su ogni architettura per cui era stato compilato, non presenta bug critici per il rilascio assenti nella versione di testing e si installa senza danneggiare ciò che è già presente in testing. Testing viene quindi congelata, il release team risolve i problemi rimasti e stable viene rilasciata quando l'elenco dei bug è abbastanza breve. Non in una data prestabilita. Per questo Debian stable appare datata e si comporta bene: i numeri di versione per lo più si fermano al freeze, mentre le correzioni di sicurezza continuano a essere applicate tramite backport. Per lo più, perché il security team a volte rilascia invece una versione upstream più recente, come è accaduto con Tomcat 11 nel giugno 2026.

Anche la governance è definita per iscritto, con un project leader eletto e risoluzioni generali vincolanti. Nel 2014 questo meccanismo scelse systemd come sistema init predefinito e le persone in disaccordo crearono un fork, Devuan, che pubblicò il primo rilascio nel 2017. Debian non fu né la prima distribuzione a compiere questo passaggio né l'ultima, e le ragioni per cui continuò a verificarsi, insieme alle obiezioni che si rivelarono fondate, sono descritte in il resoconto di come systemd ha sostituito SysV init. Le derivate più importanti sono Ubuntu, Raspberry Pi OS, Proxmox VE, Kali e Linux Mint.

Red Hat, 1994: RPM, poi la separazione tra Fedora e RHEL

Marc Ewing pubblicò la prima versione di Red Hat Linux intorno ad Halloween del 1994. Nel 1995 la società di Bob Young la acquistò e insieme crearono la prima azienda Linux che vendeva assistenza invece del software. Red Hat fu quotata in borsa l'11 agosto 1999. IBM concluse l'acquisizione della società nel luglio 2019 per circa 34 miliardi di dollari; da allora, quindi, la distribuzione rispetto alla quale viene certificata la maggior parte del software aziendale è di proprietà IBM.

Il contributo tecnico più duraturo è RPM (Red Hat package manager), scritto da Erik Troan e Marc Ewing per Red Hat Linux 2.0 nel 1995. Un pacchetto RPM dichiara le proprie dipendenze e viene prodotto a partire da un file spec, cioè una ricetta di build che chiunque può eseguire. È proprio questa seconda caratteristica che in seguito ha reso possibili le build indipendenti del prodotto enterprise di Red Hat.

Red Hat Linux 9, pubblicato nel 2003, è stata l'ultima versione della linea originale. L'azienda la divise in due: Fedora Core 1, pubblicata nel novembre 2003 come release community a sviluppo rapido, e RHEL (Red Hat Enterprise Linux), nata come Advanced Server 2.1 nel 2002, come versione commerciale a sviluppo più lento. Il motivo è semplice. Un unico prodotto non può essere sia l'ambiente in cui vengono provate le nuove versioni sia la piattaforma che una banca utilizza senza modifiche per dieci anni. Le due linee restano collegate: una versione principale di RHEL deriva da una release Fedora, viene stabilizzata e poi congelata. Anche lo strumento per la gestione dei pacchetti è avanzato secondo la stessa sequenza, da yum negli anni 2000 a dnf come impostazione predefinita di Fedora nel 2015, con rpm alla base di entrambe.

Perché CentOS ha smesso di essere una rebuild gratuita di RHEL

CentOS è nato nel 2004 con un obiettivo semplice: prendere i pacchetti sorgente pubblicati da Red Hat, rimuovere i marchi registrati, ricompilarli e distribuire gratuitamente il risultato. Per dieci anni è diventato la distribuzione server gratuita predefinita. Nel 2014 Red Hat ha acquisito il progetto.

L'8 dicembre 2020 Red Hat ha annunciato che CentOS Linux 8 sarebbe terminato il 31 dicembre 2021, otto anni prima della data precedentemente pubblicata, e che il nome sarebbe sopravvissuto come CentOS Stream. Stream non è una rebuild. È il ramo da cui vengono ricavate le release minor di RHEL, quindi precede RHEL invece di seguirlo. Per una macchina che si intende mantenere per anni, precedere RHEL è la direzione sbagliata, perché si ricevono le modifiche prima dei clienti paganti di Red Hat.

Nel 2021 sono apparse due rebuild. Rocky Linux è stato avviato da Gregory Kurtzer, cofondatore di CentOS. AlmaLinux è stato finanziato da CloudLinux. Nel giugno 2023 Red Hat ha limitato le sorgenti pubbliche di RHEL a CentOS Stream, al portale clienti e alle immagini sorgente pubblicate insieme ai propri container UBI (Universal Base Image). Rocky ha continuato a puntare su rebuild identiche. AlmaLinux ha modificato il proprio obiettivo adottando la compatibilità ABI (application binary interface), il che significa che il software compilato per RHEL funziona, senza però garantire che l'elenco dei bug corrisponda voce per voce. Oracle, SUSE e CIQ hanno istituito OpenELA più tardi nello stesso anno per pubblicare sorgenti condivise. L'intera sequenza, dalla separazione del 2003 alla modifica delle sorgenti del 2023 e alle garanzie attuali di ciascuna rebuild, è descritta in il resoconto completo di Red Hat, CentOS, Rocky e AlmaLinux.

Se l'elenco delle immagini di un provider riporta ancora CentOS, verifica a quale versione si riferisce prima di usarla come base.

cat /etc/os-release

NAME="CentOS Stream" è un ramo di sviluppo rolling che precede RHEL. NAME="AlmaLinux" o NAME="Rocky Linux" è una rebuild che lo segue, con un ciclo di dieci anni.

Ubuntu, 2004: un'istantanea di Debian unstable, secondo un calendario

Ubuntu 4.10 è stato rilasciato il 20 ottobre 2004, con il finanziamento di Mark Shuttleworth. Il rapporto con Debian è meccanico, non sentimentale. Ogni ciclo inizia importando i pacchetti da Debian unstable nella nuova release di Ubuntu. Le importazioni continuano fino al Debian Import Freeze, a metà del ciclo. Dopo questo passaggio, Ubuntu mantiene le proprie modifiche. Molti pacchetti Ubuntu sono costituiti dal pacchetto Debian più un delta, come indicato nel changelog.

L'altra metà riguarda il calendario. Debian viene rilasciata quando è pronta. Ubuntu viene rilasciata ad aprile e a ottobre, e il numero di versione indica la data: 24.04 è stata rilasciata ad aprile 2024. Una release di aprile ogni due è una LTS (long term support), ovvero quella che un provider intende quando elenca Ubuntu senza qualificatori. La scelta della release da usare su un server è l'argomento di scegliere tra Ubuntu LTS e le release interim, mentre il passaggio da una LTS alla successiva segue una procedura specifica, descritta in aggiornare dalla 24.04 alla 26.04.

Ogni anno un dettaglio interessa gli amministratori di server. L'archivio di Ubuntu è suddiviso in componenti. main è gestito da Canonical per l'intero periodo di supporto. universe è gestito dalla community e la relativa copertura di sicurezza segue un impegno diverso. apt install non mostra alcuna informazione sulla differenza. Un comando la visualizza:

apt-cache policy nginx

Una riga di repository che termina con /main indica che il pacchetto è sotto la responsabilità del team di sicurezza di Canonical. Una riga che termina con /universe indica che se ne occupa la community. Verifica questo aspetto per ogni componente esposto a Internet.

Arch, 2002: rolling release e il costo di un aggiornamento parziale

Judd Vinet ha rilasciato Arch 0.1 l'11 marzo 2002, con un gestore di pacchetti scritto da lui, pacman, e ricette di compilazione costituite da semplici script shell. Arch non ha alcuna release con versione. I supporti di installazione sono snapshot datati degli stessi repository rolling. Di conseguenza, una macchina installata nel 2019 e aggiornata ogni settimana esegue la stessa versione di Arch di una macchina installata oggi. AUR (Arch user repository) contiene ricette di compilazione fornite dagli utenti. Non sono pacchetti verificati. Prima di eseguire un PKGBUILD è quindi necessario leggerlo.

Il modello rolling ha una modalità di errore, causata ogni volta dall'amministratore. L'installazione di un singolo pacchetto con pacman -Sy foo aggiorna il database dei pacchetti e installa quindi un nuovo binario collegato a librerie più recenti di quelle presenti sul disco. I programmi possono quindi terminare con errori come questo:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

L'operazione supportata è pacman -Syu, che aggiorna tutti i pacchetti insieme. Il progetto pubblica inoltre avvisi che indicano quando è necessario un intervento manuale prima di determinati aggiornamenti. Eseguire l'aggiornamento senza leggerli può lasciare una macchina che non si avvia.

Per questo Arch è una scelta poco adatta per un server che si prevede di trascurare. Un server aggiornato ogni settimana non crea problemi. Un server aggiornato una sola volta dopo un anno applica in un'unica esecuzione tutti gli interventi ignorati in precedenza.

Alpine: la piccola distribuzione resa popolare dai container

Alpine è nata intorno al 2005 come fork di Gentoo, influenzata da LEAF (Linux embedded appliance framework), a sua volta derivato dal Linux Router Project. Natanael Copa l’ha sviluppata per gli appliance, non per i desktop. Sostituisce gran parte del consueto userland: musl al posto della libreria GNU C, BusyBox al posto delle utilità core GNU, OpenRC al posto di systemd e apk come gestore dei pacchetti. Alpine 3.0, nel 2014, è stata la release che ha introdotto musl.

I container l’hanno resa popolare. Un’immagine di base Alpine occupa una frazione dello spazio richiesto da un’immagine di base Debian o Ubuntu. Dal 2016 è quindi diventata un’immagine di base comune e molte persone che non avevano mai installato Alpine l’hanno eseguita ogni giorno.

Il limite è che musl non è glibc, e la differenza si manifesta con bug apparentemente scollegati. Un binario collegato a glibc non riesce ad avviarsi su Alpine e restituisce un messaggio che porta a cercare un file già presente:

sh: ./myapp: not found

Il programma esiste. Manca il suo interprete ELF, perché il loader di glibc non è installato. Python riserva un’altra sorpresa frequente: i wheel precompilati creati per manylinux non vengono installati su musl, quindi pip ripiega sulla compilazione dal codice sorgente e si interrompe quando non è installato alcun compilatore. Lo standard dei wheel musllinux del 2021 ha risolto il problema per i progetti che pubblicano questi wheel, ma non per gli altri.

Come sistema operativo host su un VPS, Alpine richiede poco spazio per l’installazione e riceve rapidamente gli aggiornamenti, ma segue un percorso diverso da quello previsto dalla maggior parte della documentazione. Ogni guida che indica di eseguire systemctl enable deve essere adattata a rc-update add.

La generazione immutabile: aggiornamenti atomici e server basati su immagini

Il ramo più recente cambia il modello degli aggiornamenti, non l’elenco dei pacchetti. Un sistema basato su ostree mantiene /usr in sola lettura. Un aggiornamento consiste in un nuovo albero completo del filesystem, che viene scaricato, preparato e attivato al riavvio successivo. L’albero precedente resta disponibile come voce di avvio. Se un aggiornamento presenta problemi, è quindi possibile annullarlo riavviando il sistema con la versione precedente.

Fedora Silverblue ha introdotto questo modello sui desktop nel 2018. Fedora CoreOS lo ha portato sui server nel 2019, dopo l’acquisizione di CoreOS da parte di Red Hat nel 2018. Flatcar Container Linux ha proseguito il progetto originale Container Linux, ritirato nel 2020. openSUSE MicroOS raggiunge lo stesso risultato tramite snapshot btrfs e transactional-update. Nel 2024 Red Hat ha aggiunto a RHEL una modalità basata su immagini, costruita su bootc. In questa modalità il sistema operativo viene distribuito come container image e una macchina viene aggiornata indirizzandola verso un nuovo tag. Talos Linux applica il modello in modo ancora più radicale e rimuove completamente shell e SSH: la macchina viene configurata tramite un’API, quindi non esiste un accesso interattivo al sistema. NixOS, rilasciato per la prima volta nel 2007, segue un approccio diverso. L’intero sistema viene costruito a partire da una configurazione dichiarativa e le generazioni precedenti restano avviabili.

Probabilmente il tuo provider non offre nessuno di questi sistemi come immagine installabile con un clic. Questi sistemi prevedono infatti la configurazione al primo avvio tramite Ignition o cloud-init, invece della modifica manuale dei file da parte di un amministratore tramite SSH. Il vantaggio emerge quando si gestiscono molte macchine identiche. È la situazione in cui ti trovi quando stai gestendo più server Linux contemporaneamente e hai bisogno di dimostrare che ciascuno sia effettivamente uguale agli altri.

Per quanto tempo viene supportata una release?

La politica di supporto è l'aspetto di una distribuzione con cui si convive più a lungo ed è espressa in anni. Di seguito sono indicate le finestre per le 5 release server attualmente disponibili.

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 14
  }
]

Alpine supporta il repository main di ogni ramo 3.x per 2 anni e il repository community soltanto fino alla release stabile successiva. Per questo è più adatta a un'immagine container che viene ricostruita spesso che a un host lasciato invariato. Il team di sicurezza Debian copre una release stable per circa 3 anni; il team LTS mantiene poi un insieme selezionato di architetture fino a circa 5 anni complessivi. Una Ubuntu LTS offre 5 anni per i pacchetti in main, mentre un abbonamento Ubuntu Pro estende il periodo a 10 anni, gratuitamente per l'uso personale su un numero limitato di macchine. Un componente aggiuntivo Legacy a pagamento per Ubuntu Pro estende ulteriormente il periodo, fino a 15 anni. RHEL 10 pubblica 10 anni di supporto; il componente aggiuntivo Extended Life Cycle Premium a pagamento estende il periodo a 14 per l'ultima release minor, mentre i termini Long-Life rinnovabili possono prolungare la copertura oltre tale limite. AlmaLinux 10 offre la stessa finestra di RHEL, pari a 10 anni, senza alcun abbonamento. Questo è l'intero motivo per cui esistono queste ricostruzioni.

Arch non compare nella tabella, perché una distribuzione rolling non ha una release da supportare. Per Arch conta per quanto tempo si può lasciare una macchina senza interventi; il periodo si misura in settimane.

Perché l’elenco delle immagini VPS è strutturato in questo modo

Un provider distribuisce le immagini che i clienti richiedono esplicitamente e che si installano senza intervento sul suo hypervisor. Per questo quasi tutti gli elenchi iniziano con Ubuntu LTS e Debian stable, aggiungono AlmaLinux o Rocky per chi usa software certificato per RHEL e collocano Alpine, Arch e Fedora più avanti nella pagina. Dopo aver capito che cos’è un VPS e come l’immagine viene scritta sul disco, il criterio è chiaro: il provider sceglie sistemi operativi che tollerano un’installazione automatica e rimangono supportati più a lungo del periodo medio di utilizzo del server da parte dei clienti.

La scelta vincola più del solo package manager. Determina il tipo di aggiornamento che eseguirai tra tre anni, e le procedure cambiano completamente a seconda della famiglia. Debian e Ubuntu supportano gli aggiornamenti major in place. La famiglia Red Hat li esegue tramite leapp. Arch non richiede un aggiornamento perché non ha versioni. In Alpine consiste nel modificare /etc/apk/repositories ed eseguire apk upgrade --available. La scelta determina anche quale software puoi installare senza aggiungere un repository di terze parti, chi distribuisce la patch quando una voce CVE (common vulnerabilities and exposures) riguarda un componente che utilizzi e quale init system e quale C library il software futuro presumerà presenti.

C’è un ulteriore effetto facile da sottovalutare. La maggior parte delle risposte pubblicate su Internet presuppone una procedura della famiglia Debian o della famiglia Red Hat; scegliere al di fuori di queste due famiglie significa quindi dover tradurre le istruzioni per tutta la durata del server. Scegli la famiglia il cui criterio di rilascio corrisponde alla frequenza con cui sei disposto a intervenire sul server, quindi mantienila. Cambiare i pacchetti installati sopra il sistema è semplice. Cambiare la distribuzione sottostante significa ricostruire il server.

FAQ

Qual è la famiglia della distribuzione Linux del mio server?

Esegui cat /etc/os-release. Il campo ID indica la distribuzione e ID_LIKE la relativa famiglia; una macchina Ubuntu restituisce ID_LIKE=debian, mentre una macchina AlmaLinux restituisce ID_LIKE="rhel centos fedora". Anche il gestore dei pacchetti fornisce un'indicazione utile. apt e dpkg indicano la famiglia Debian, dnf e rpm indicano la famiglia Red Hat, apk indica Alpine e pacman indica Arch.

CentOS è ancora una versione gratuita di RHEL?

No. CentOS Linux 8, l'ultima ricompilazione con quel nome, è arrivato a fine vita il 31 dicembre 2021, mentre CentOS Linux 7 è arrivato a fine vita il 30 giugno 2024. Il progetto ancora attivo, CentOS Stream, è il ramo da cui vengono create le release minor di RHEL, quindi riceve le modifiche prima di RHEL, non dopo. Le ricompilazioni gratuite che hanno sostituito il vecchio ruolo sono AlmaLinux e Rocky Linux, entrambe con cicli di supporto di dieci anni.

Perché Debian stable distribuisce versioni con numeri così vecchi?

Perché il numero di versione rimane quasi invariato mentre continuano ad arrivare le correzioni. Per la maggior parte dei pacchetti, Debian applica le patch di sicurezza alla versione già rilasciata invece di importare una release upstream più recente; per questo un pacchetto che riporta 2.4.57-2+deb13u1 può contenere una correzione pubblicata la settimana scorsa. Il suffisso dopo la versione upstream è la revisione Debian e apt changelog <package> elenca le modifiche incluse. Valutare la sicurezza di un server Debian in base ai numeri di versione porta sempre alla conclusione sbagliata.

Devo usare una rolling release come Arch su un VPS?

Solo se puoi aggiornarla secondo una pianificazione regolare. Una distribuzione rolling presuppone che ogni macchina converga sull'insieme di pacchetti corrente; quindi l'aggiornamento di un singolo pacchetto con pacman -Sy foo può lasciare librerie non allineate e generare errori come cannot open shared object file. Esegui regolarmente pacman -Syu, leggi la pagina delle notizie del progetto prima di ogni esecuzione e il sistema rimarrà stabile. Se lasci passare un anno, il primo aggiornamento diventerà quello rischioso.

Che cosa cambia realmente con una distribuzione immutable o atomic?

Cambia il momento in cui vengono applicati gli aggiornamenti e il modo in cui puoi annullarli. /usr viene montato in sola lettura, un aggiornamento viene preparato come un nuovo albero completo e il passaggio avviene al riavvio; l'albero precedente rimane disponibile come voce di boot per il rollback. Ottieni una macchina completamente aggiornata oppure completamente non aggiornata, senza stati parziali. Rinunci a installare software modificando direttamente i file, quindi le applicazioni vengono spostate nei container o nei pacchetti a livelli.