Storia delle distribuzioni Linux: origini e differenze

Che cos’è realmente una distribuzione Linux

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

Una distribuzione ha cinque componenti. Se ne cambia anche una sola, si ottiene una distribuzione diversa, anche quando la maggior parte dei binari coincide:

• Un kernel, a una versione scelta dal progetto, con le patch e i driver aggiunti dal progetto.
• Uno userland: la libreria C, la shell, il sistema init e i comandi standard.
• Un formato dei pacchetti e lo strumento che li installa.
• Una politica di rilascio: cosa può cambiare, con quale frequenza e per quanto tempo viene corretto ogni rilascio.
• Le persone: i manutentori dei pacchetti, un team per la sicurezza e qualcuno che risponde quando un pacchetto non funziona.

Il kernel è il componente condiviso. Per questo due distribuzioni Linux sono molto più vicine tra loro di quanto ciascuna lo sia rispetto 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 progetti upstream separati, e la distribuzione è ciò che li fa funzionare insieme.

Cronologia 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 nei pannelli di controllo VPS appartengono a una di queste famiglie o a una loro derivata. Una derivata eredita il formato dei pacchetti, la struttura del filesystem e, in genere, le modalità di rilascio. Per questo una derivata Debian continua ad avere il comportamento tipico di Debian anche dopo la rimozione del relativo branding.

Le distribuzioni indipendenti meritano un paragrafo separato, perché non derivano da alcun altro progetto. Arch, Gentoo, Alpine, NixOS e Void hanno sviluppato ciascuna il proprio gestore di pacchetti e le proprie regole. Due di queste, Arch e Alpine, sono comunque entrate 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 due immagini floppy, con un programma di installazione basato su menu. Esisteva perché eseguire manualmente quelle operazioni richiedeva un'intera giornata di lavoro.

SLS (Softlanding Linux System), rilasciata da Peter MacDonald nel 1992, fece un ulteriore passo avanti e aggiunse X (the X Window System) e il networking TCP/IP. SLS è all'origine del significato attuale della parola distribuzione. Era però afflitta da bug e la manutenzione procedeva lentamente. Nel 1993, due persone decisero separatamente di correggerla. Una la ricostruì. L'altra ripartì da zero, seguendo regole messe per iscritto.

Slackware, 1993: la famiglia più antica ancora in produzione

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

Un pacchetto Slackware è un archivio tar compresso che contiene uno script di installazione. Non esiste la 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 rilasciati deve essere coerente per progettazione, quindi le release sono rare e conservative. Slackware 15.0 è arrivata nel febbraio 2022, sei anni dopo la 14.2.

La famiglia è ristretta. 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, successivamente, il formato dei pacchetti 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 di discendenza no.

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

Ian Murdock annunciò Debian il 16 agosto 1993, tre settimane dopo Slackware e per lo stesso motivo. Il nome unisce Debra, la sua compagna, 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 (Debian free software guidelines) 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 dei componenti: main contiene software conforme alle linee guida, contrib e non-free contengono quello che non lo è, e Debian 12 ha aggiunto non-free-firmware, così un laptop con una scheda wireless poteva installare il sistema senza dover cercare manualmente i firmware.

Anche gli strumenti fanno parte di questa eredità. dpkg installa un singolo pacchetto e si interrompe quando manca qualcosa, visualizzando dpkg: dependency problems prevent configuration of. APT (advanced package tool), 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, il cui nome in codice permanente è sid. Uno script trasferisce il pacchetto in testing dopo circa 5 a 10 giorni, se è stato compilato sulle architetture previste per il rilascio e non ha introdotto nuovi bug release-critical. Testing viene quindi congelata, il team di rilascio risolve i problemi rimanenti e stable viene rilasciata quando l’elenco dei bug è abbastanza breve. Non in una data prestabilita. Per questo Debian stable sembra datata ma è affidabile: i numeri di versione si fermano al momento del freeze, mentre le correzioni di sicurezza continuano a essere applicate alle versioni esistenti.

Anche la governance è documentata, con un project leader eletto e risoluzioni generali vincolanti. Nel 2014 questo meccanismo scelse systemd come init system predefinito, e le persone in disaccordo crearono il fork Devuan, che pubblicò il primo rilascio nel 2017. Le derivate più importanti sono Ubuntu, Raspberry Pi OS, Proxmox VE, Kali e Linux Mint.

Red Hat, 1994: RPM, quindi la suddivisione in Fedora e RHEL

Marc Ewing pubblicò la prima versione di Red Hat Linux intorno ad Halloween 1994. Nel 1995 la acquistò l'azienda di Bob Young e insieme crearono la prima attività commerciale basata su Linux che vendeva supporto invece del software. Red Hat fu quotata in borsa l'11 agosto 1999. IBM concluse l'acquisizione dell'azienda nel luglio 2019 per circa 34 miliardi di dollari. Da allora, quindi, la distribuzione rispetto alla quale viene certificata la maggior parte dei software aziendali appartiene a 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 creato a partire da un file spec, cioè una ricetta di compilazione che chiunque può eseguire. È proprio questa seconda caratteristica ad aver reso possibili, in seguito, le ricompilazioni indipendenti del prodotto enterprise di Red Hat.

Red Hat Linux 9, pubblicato nel 2003, fu l'ultima versione della linea originale. L'azienda la divise in due: Fedora Core 1, pubblicato nel novembre 2003 come release community a evoluzione rapida, e RHEL (Red Hat Enterprise Linux), nato come Advanced Server 2.1 nel 2002, come prodotto a pagamento con un ciclo più lento. Il motivo è semplice. Un solo prodotto non può essere contemporaneamente l'ambiente in cui vengono provate le nuove versioni e 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 di Fedora, viene stabilizzata e poi congelata. Anche lo strumento di gestione dei pacchetti è passato allo stesso modello, 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 ricostruzione gratuita di RHEL

CentOS è nato nel 2004 con un obiettivo semplice: prendere i pacchetti sorgente pubblicati da Red Hat, rimuovere i marchi registrati, ricostruirli e distribuire gratuitamente il risultato. Per un decennio è diventato la distribuzione server gratuita predefinita. Nel 2014 Red Hat ha integrato il progetto nella propria organizzazione.

L'8 dicembre 2020 Red Hat ha annunciato che CentOS Linux 8 avrebbe raggiunto la fine del ciclo di vita il 31 dicembre 2021, otto anni prima della data precedentemente pubblicata, e che il nome sarebbe sopravvissuto come CentOS Stream. Stream non è una ricostruzione. È il ramo da cui vengono create le release minor di RHEL, quindi viene aggiornato prima di RHEL invece che dopo. Per un sistema che si intende mantenere per anni, ricevere gli aggiornamenti in anticipo è la scelta sbagliata, perché le modifiche arrivano prima che ai clienti paganti di Red Hat.

Nel 2021 sono comparse due ricostruzioni. Rocky Linux è stato avviato da Gregory Kurtzer, cofondatore di CentOS. AlmaLinux è stato finanziato da CloudLinux. Nel giugno 2023 Red Hat ha smesso di pubblicare i sorgenti di RHEL ovunque, tranne che su CentOS Stream e nel portale clienti. Rocky ha continuato a puntare su ricostruzioni identiche. AlmaLinux ha modificato il proprio obiettivo, puntando alla compatibilità ABI (application binary interface). Questo significa che il software compilato per RHEL può essere eseguito, senza però garantire che l'elenco dei bug corrisponda voce per voce. Oracle, SUSE e CIQ hanno istituito OpenELA più avanti nello stesso anno per pubblicare sorgenti condivisi.

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

cat /etc/os-release

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

Ubuntu, 2004: uno snapshot di Debian unstable, con una cadenza precisa

Ubuntu 4.10 è stato rilasciato il 20 ottobre 2004, grazie ai finanziamenti 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 proseguono fino al Debian Import Freeze, a metà del ciclo; dopo quel momento Ubuntu gestisce le proprie modifiche. Molti pacchetti Ubuntu sono costituiti dal pacchetto Debian più un delta, come indicato nel changelog.

L'altra metà è 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), che è ciò a cui si riferisce un provider quando elenca Ubuntu senza ulteriori qualificatori. La scelta della versione da installare su un server è l'argomento di come scegliere tra Ubuntu LTS e le release intermedie, mentre il passaggio da una LTS alla successiva segue una procedura specifica, descritta in l'aggiornamento da 24.04 a 26.04.

Ogni anno, un dettaglio richiede l'attenzione degli 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 consente di visualizzarla:

apt-cache policy nginx

Una riga del repository che termina con /main indica che il pacchetto è gestito dal team di sicurezza di Canonical. Una riga che termina con /universe indica che è gestito dalla community. Verificare questa informazione per tutti i pacchetti esposti 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 dei pacchetti scritto da lui, pacman, e ricette di compilazione costituite da semplici script shell. Arch non prevede alcuna release versionata. I supporti di installazione sono snapshot datati degli stessi repository rolling. Di conseguenza, una macchina installata nel 2019 e aggiornata ogni settimana esegue lo stesso Arch di una macchina installata oggi. L'AUR (Arch User Repository) contiene ricette di compilazione fornite dagli utenti. Non sono pacchetti verificati. Leggere un PKGBUILD prima di eseguirlo fa quindi parte dell'attività di amministrazione.

Il modello rolling ha una modalità di errore, che dipende sempre da un'azione dell'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 iniziano quindi a non funzionare, ad esempio:

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 notizie che indicano quando è necessario un intervento manuale prima di determinati aggiornamenti. Eseguire l'aggiornamento senza leggerle può lasciare una macchina che non si avvia.

Per questo Arch è una scelta poco adatta per un server che si prevede di non amministrare regolarmente. Una macchina aggiornata ogni settimana non presenta problemi. Una macchina aggiornata una sola volta, dopo un anno, applica in un'unica esecuzione tutti gli interventi ignorati.

Alpine: la distribuzione compatta resa popolare dai container

Alpine è nata intorno al 2005 come fork di LEAF (Linux embedded appliance framework), a sua volta derivata 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 GNU core utilities, OpenRC al posto di systemd e apk come gestore dei pacchetti. Alpine 3.0, nel 2014, è stata la release che ha introdotto il passaggio a musl.

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

Il problema è che musl non è glibc e la differenza si manifesta con bug apparentemente non correlati. Un binario collegato a glibc non viene eseguito su Alpine e mostra un messaggio che spinge a cercare un file già presente:

sh: ./myapp: not found

Il programma esiste. Manca il suo interprete ELF, perché il loader di glibc non è presente. Python è l'altra sorpresa ricorrente: i wheel precompilati per manylinux non possono essere installati su musl. Di conseguenza pip tenta di compilare il pacchetto dal codice sorgente e si interrompe quando non è installato alcun compilatore. Lo standard per i wheel musllinux, introdotto nel 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 ti porta al di fuori del percorso seguito 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 modifica il modello di aggiornamento, non l’elenco dei pacchetti. Un sistema basato su ostree mantiene /usr in sola lettura. Un aggiornamento è un nuovo albero completo del filesystem, che viene scaricato, preparato e attivato al riavvio successivo. L’albero precedente resta disponibile come voce di avvio, quindi un aggiornamento difettoso può essere annullato riavviando il sistema con la versione precedente.

Fedora Silverblue ha introdotto questo modello nei desktop nel 2018 e Fedora CoreOS lo ha portato sui server nel 2019, dopo che Red Hat aveva acquisito CoreOS 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 cui il sistema operativo viene distribuito come immagine container e una macchina viene aggiornata indirizzandola a un nuovo tag. Talos Linux si spinge oltre e rimuove completamente shell e SSH: la macchina viene configurata tramite un’API, quindi non esiste alcun sistema a cui accedere. NixOS, rilasciato per la prima volta nel 2007, segue un approccio diverso. L’intero sistema viene costruito a partire da un’unica configurazione dichiarativa e le generazioni precedenti restano avviabili.

Probabilmente il provider non offre nessuna di queste opzioni come immagine disponibile con un clic, perché prevede che vengano configurate al primo avvio tramite Ignition o cloud-init, invece che da un amministratore che modifica file tramite SSH. Queste soluzioni sono vantaggiose quando si gestiscono molte macchine identiche. È la situazione in cui ti trovi quando gestisci più server Linux contemporaneamente e devi poter dimostrare che ciascuno è identico agli altri.

Per quanto tempo è supportata una release?

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

[
  {
    "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": 13
  }
]

Alpine supporta ogni ramo 3.x per 2 anni. Per questo è più adatta a un'immagine container che ricompili spesso che a un host che lasci invariato. Il team di sicurezza Debian copre una release stable per circa 3 anni. Il team LTS estende poi il supporto alle architetture più comuni fino a circa 5 anni complessivi. Una Ubuntu LTS offre 5 anni di supporto per i pacchetti in main. Un abbonamento Ubuntu Pro estende il periodo a 10 anni ed è gratuito per uso personale su un numero ridotto di macchine. RHEL 10 pubblica 10 anni di supporto. L'add-on a pagamento extended life cycle support estende questo periodo a 13 anni. AlmaLinux 10 offre la stessa finestra di supporto di RHEL, pari a 10 anni, senza alcun abbonamento. Questo è il motivo principale per cui esistono i rebuild.

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

Perché l’elenco delle immagini del tuo VPS ha questo aspetto

Un provider rende disponibili le immagini che i clienti richiedono più spesso e che possono essere installate senza intervento sull’hypervisor. Per questo quasi ogni elenco inizia con Ubuntu LTS e Debian stable, aggiunge AlmaLinux o Rocky per chi utilizza software certificato per RHEL e propone Alpine, Arch e Fedora più avanti nella pagina. Una volta compreso che cos’è un VPS e come l’immagine viene scritta sul disco, il criterio è chiaro: il provider sceglie sistemi operativi che resistono a un’installazione automatizzata e restano supportati più a lungo del periodo medio per cui il cliente mantiene il server.

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

C’è un altro effetto che è facile sottovalutare. La maggior parte delle istruzioni pubblicate su Internet presuppone una procedura della famiglia Debian o della famiglia Red Hat. Scegliere una distribuzione diversa significa quindi adattare 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, poi mantienila. Cambiare i package installati sopra la distribuzione è semplice. Cambiare la distribuzione sottostante significa ricreare 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 rebuild con questo nome, è arrivato a fine vita il 31 December 2021, mentre CentOS Linux 7 è arrivato a fine vita il 30 June 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 e non dopo. Le rebuild gratuite che hanno sostituito il vecchio ruolo sono AlmaLinux e Rocky Linux, entrambe con finestre di supporto di dieci anni.

Perché Debian stable distribuisce numeri di versione così vecchi?

Perché il numero di versione resta invariato mentre continuano ad arrivare le correzioni. Debian integra le patch di sicurezza nella 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 eseguire una rolling release come Arch su un VPS?

Solo se la aggiornerai secondo una pianificazione. Una distribuzione rolling presuppone che ogni macchina converga verso l'insieme di pacchetti corrente; quindi l'aggiornamento di un solo 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 aggiornamento e il sistema resta stabile. Se lo lasci fermo per un anno, il primo aggiornamento diventa quello più 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, l'aggiornamento viene preparato come un nuovo albero completo e il passaggio avviene al riavvio; l'albero precedente resta disponibile come voce di avvio per il rollback. La macchina si trova quindi in uno stato completamente aggiornato oppure completamente non aggiornato, senza stati parziali. Non puoi più installare software modificando direttamente i file, quindi le applicazioni vengono spostate nei container o nei pacchetti stratificati.