Storia delle distribuzioni Linux e delle loro origini

Che cos’è realmente una distribuzione Linux

La storia delle distribuzioni Linux parte da una lacuna: il kernel Linux, da solo, non fornisce nulla che una persona possa usare. Si avvia e rileva l’hardware. Poi si arresta. Qualcuno deve aggiungere lo userland, scegliere come installare e aggiornare il software e impegnarsi a correggere i problemi per anni. Una distribuzione è l’insieme di queste scelte, oltre alla comunità che continua a occuparsene nel tempo.

È composta da cinque parti. Se ne cambia una, 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: manutentori dei pacchetti, un team per la sicurezza e qualcuno che risponde quando un pacchetto non funziona.

Il kernel è la parte condivisa. 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 kernel e userland di base vengono sviluppati da un unico progetto e rilasciati insieme. In Linux questi componenti provengono da upstream separati. La distribuzione è ciò che li fa funzionare in modo coerente.

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, tre settimane 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 per iscritto questi termini. 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 dei componenti: main contiene il software conforme alle linee guida, contrib e non-free contengono quello che non lo è, mentre Debian 12 ha aggiunto non-free-firmware, così un laptop con una scheda wireless potesse installarsi senza dover cercare manualmente i componenti necessari.

Anche gli strumenti fanno parte di questa eredità. dpkg installa un pacchetto e si interrompe quando manca una dipendenza, mostrando 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 su ogni derivata Debian discende da quel lavoro.

Il processo di rilascio usa tre suite e una regola. Un maintainer carica i pacchetti in unstable, con il nome in codice permanente sid. Uno script trasferisce il pacchetto in testing dopo circa 5 to 10 giorni, se è stato compilato sulle architetture previste per il rilascio e non ha introdotto nuovi bug critici per il rilascio. Testing viene quindi congelata, il release team risolve i problemi rimanenti e stable viene rilasciata quando l'elenco dei bug è abbastanza breve. Non in una data prestabilita. Per questo stable di Debian sembra datata ma si comporta bene: i numeri di versione restano fermi al momento del freeze, mentre le correzioni di sicurezza vengono sottoposte a backport.

Anche la governance è documentata, 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 il fork Devuan, che pubblicò il primo rilascio nel 2017. Debian non fu né la prima distribuzione a compiere questo passaggio né l'ultima; le ragioni per cui continuò a verificarsi, insieme alle obiezioni che si rivelarono fondate, sono descritte in il resoconto di come systemd sostituì SysV init. Le derivate principali 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 ricostruzione 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 un decennio è diventato la distribuzione server gratuita predefinita, e nel 2014 Red Hat ha acquisito il progetto.

L'8 dicembre 2020 Red Hat ha annunciato che CentOS Linux 8 sarebbe stato dismesso il 31 dicembre 2021, otto anni prima della data pubblicata, e che il nome sarebbe sopravvissuto come CentOS Stream. Stream non è una ricostruzione. È il ramo da cui vengono ricavate le release minori di RHEL, quindi è più avanti rispetto a RHEL anziché seguirlo. Per una macchina che si intende mantenere per anni, essere più avanti è la direzione sbagliata, perché si ricevono le modifiche prima dei clienti paganti di Red Hat.

Nel 2021 sono apparse due ricostruzioni. Rocky Linux è stato avviato da Gregory Kurtzer, che ha cofondato 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 a ricostruzioni identiche. AlmaLinux ha modificato il proprio obiettivo, puntando alla compatibilità ABI (application binary interface): il software compilato per RHEL continua a funzionare, senza però garantire che l'elenco dei bug corrisponda riga per riga. Oracle, SUSE e CIQ hanno istituito OpenELA nello stesso anno per pubblicare sorgenti condivisi. L'intera sequenza, dalla separazione del 2003 alla modifica dei sorgenti del 2023 e agli obiettivi attuali delle varie ricostruzioni, è descritta in la spiegazione più approfondita di Red Hat, CentOS, Rocky e AlmaLinux.

Se l'elenco delle immagini di un provider indica ancora CentOS, verifica quale versione intende prima di utilizzarla per una nuova installazione.

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: 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 famosa dai container

Alpine è nata intorno al 2005 come fork di 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 core utilities GNU, 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 livello base Alpine occupa una frazione dello spazio richiesto da un'immagine base Debian o Ubuntu. Dal 2016 è quindi diventata un'immagine base 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 in bug che sembrano non correlati. Un binario collegato a glibc non viene eseguito su Alpine e mostra un messaggio che porta a cercare un file già presente:

sh: ./myapp: not found

Il programma esiste. Manca però il suo interprete ELF, perché il loader di glibc non è installato. Python è l'altra sorpresa ricorrente: i wheel precompilati per manylinux non vengono installati su musl. Di conseguenza, pip passa alla compilazione dai sorgenti 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 occupa poco spazio durante l'installazione e riceve rapidamente gli aggiornamenti, ma porta fuori dal 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 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 fornita assistenza per una release?

La policy di supporto è l'aspetto di una distribuzione con cui convivi più a lungo ed è espressa in anni. Ecco i periodi 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 mantiene poi le 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 l'uso personale su un numero limitato di macchine. RHEL 10 pubblica 10 anni di supporto. L'add-on a pagamento extended life cycle support estende il periodo a 13 anni. AlmaLinux 10 offre lo stesso periodo di RHEL, pari a 10 anni, senza alcun abbonamento. È proprio questo il 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 puoi lasciare una macchina senza interventi. Questo 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

A quale famiglia di distribuzioni Linux appartiene il mio server?

Eseguire 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 ricostruzione con questo nome, è arrivato al termine del ciclo di vita il 31 December 2021, mentre CentOS Linux 7 è arrivato al termine del ciclo di vita il 30 June 2024. Il progetto ancora attivo, CentOS Stream, è il ramo da cui vengono create le versioni minor di RHEL, quindi riceve le modifiche prima di RHEL e non dopo. Le ricostruzioni gratuite che hanno sostituito il ruolo precedente sono AlmaLinux e Rocky Linux, entrambe con un ciclo di supporto di ten years.

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

Perché il numero di versione resta invariato mentre continuano ad arrivare le correzioni. Debian applica le patch di sicurezza alla versione distribuita invece di importare una versione upstream più recente, quindi 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 a una conclusione errata.

Devo eseguire una distribuzione rolling come Arch su un VPS?

Solo se la aggiornerai secondo una pianificazione. Una distribuzione rolling presuppone che ogni macchina converga verso l'insieme corrente dei pacchetti, quindi aggiornare un singolo pacchetto con pacman -Sy foo può lasciare librerie non allineate e generare errori come cannot open shared object file. Eseguire regolarmente pacman -Syu, leggere la pagina delle notizie del progetto prima di ogni esecuzione e il sistema resterà stabile. Se lo lasci senza aggiornamenti per 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, 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 risulta quindi completamente aggiornata oppure completamente non aggiornata, senza uno stato parzialmente applicato. Non puoi più installare il software modificando direttamente i file, quindi le applicazioni vengono spostate nei container o nei pacchetti a livelli.