Snap & Flatpak

Prima di leggere: una domanda sul disco

Nelle due lezioni precedenti hai contato i pacchetti della tua macchina. Adesso una domanda sullo spazio: secondo te quanto occupano sul disco i programmi installati con il gestore di pacchetti della distribuzione, e quanto quelli installati con i formati indipendenti come snap o flatpak? Scrivi un ordine di grandezza per ciascuno, non un numero preciso.

Sulla mia macchina uno dei due numeri è ventisei gigabyte, e l'ho misurato perché non ci avrei scommesso. Quale dei due sia, e perché quel formato costi tanto, è il contenuto di questa lezione: non per dire che un formato è peggio dell'altro, ma perché i tre formati che coesistono su una macchina moderna fanno compromessi diversi, e sceglierli senza saperlo significa pagarne uno senza averne il beneficio.

Il problema: un programma che la tua distribuzione non ha, o ha vecchio

Il gestore della distribuzione ha un vantaggio decisivo, che hai visto nelle lezioni precedenti: una versione per ogni pacchetto, dipendenze condivise fra tutti i programmi, aggiornamenti di sicurezza centralizzati. E ha un costo che si sente: quella versione è una sola, è quella che la distribuzione ha scelto, e cambia quando la distribuzione cambia.

Da qui nascono i formati indipendenti. La promessa è che il programma porti con sé tutto ciò che gli serve, quindi una versione recente gira su una distribuzione vecchia e viceversa, e il programma funziona identico su macchine diverse. La promessa si paga, e il prezzo è su tre voci: spazio su disco, tempo di avvio, e integrazione col resto del sistema.

Una precisazione, perché conta per come leggi il resto. Su questa macchina snap è presente e lo ho misurato; flatpak non è installato, verificato con command -v flatpak che non restituisce nulla e con apt-cache policy flatpak che dichiara Installato: (nessuno) e candidato 1.16.6-1. Quindi su snap ti darò misure, su flatpak ti darò il modello e la differenza di progetto, e non ti darò numeri che non ho preso.

Come è fatto uno snap: non è una cartella

Un pacchetto della distribuzione installa dei file in cartelle normali: lo hai visto con dpkg -L. Uno snap non installa file: è un'immagine compressa che viene montata come un filesystem a sé, in sola lettura. Il comando che lo rende evidente è quello che hai imparato nella prima lezione.

$ findmnt -t squashfs -o TARGET,SOURCE,FSTYPE,OPTIONS | head -3
TARGET                        SOURCE      FSTYPE   OPTIONS
/snap/antigravity-ide-snap/7  /dev/loop0  squashfs ro,nodev,relatime,errors=continue
/snap/astral-uv/1773          /dev/loop1  squashfs ro,nodev,relatime,errors=continue

$ findmnt -nt squashfs | wc -l
85

Ottantacinque filesystem montati, uno per revisione di snap, ciascuno su un dispositivo di anello e ciascuno in modo ro, cioè sola lettura. Le due parole ro e nodev non sono dettagli: sono la ragione per cui un file dentro uno snap non si modifica, e la prova è un comando che hai già visto.

$ touch /snap/antigravity-ide-snap/7/prova-scrittura
touch: cannot touch '/snap/antigravity-ide-snap/7/prova-scrittura': Read-only file system

Non è una questione di permessi, come nella lezione sui permessi: è il filesystem stesso a essere di sola lettura, e nemmeno l'amministratore può scriverci. Questo risolve un problema reale, cioè l'integrità del programma installato, e crea un altro problema, cioè che le personalizzazioni devono vivere altrove.

Perché due revisioni dello stesso programma

Nell'elenco dei montaggi lo stesso programma compare due volte, con due numeri diversi:

$ findmnt -nt squashfs -o TARGET | grep astral-uv
/snap/astral-uv/1773
/snap/astral-uv/1781

La revisione precedente non viene cancellata quando arriva la nuova: resta montata, e questo è il meccanismo che permette di tornare indietro con un comando se l'aggiornamento rompe qualcosa. È una capacità che il gestore della distribuzione non ha nella stessa forma, e che vale molto su una macchina in esercizio.

Ed è anche metà della risposta alla domanda d'apertura. Il numero misurato è questo:

$ du -sh /var/lib/snapd/snaps
26G	/var/lib/snapd/snaps
$ ls -1 /var/lib/snapd/snaps/*.snap | wc -l
86
$ snap list | tail -n +2 | wc -l
49

Ventisei gigabyte per quarantanove programmi, conservati come ottantasei file di immagine perché per diversi di essi ci sono due revisioni. Il confronto con il gestore della distribuzione non è nemmeno vicino: nelle lezioni precedenti ho contato duemilaottocentosedici pacchetti installati, e l'intera installazione di Ubuntu che li contiene occupa una frazione di quel numero. La ragione è che ogni snap porta con sé le proprie librerie invece di condividerle.

Il confinamento, cioè che cosa il programma può toccare

La terza differenza di progetto è l'isolamento. Uno snap in modo stretto vede una parte limitata del sistema e deve dichiarare le connessioni che gli servono; uno snap in modo classico vede tutto, come un programma normale, e il modo classico esiste perché per certi programmi, come un ambiente di sviluppo, l'isolamento è incompatibile col loro lavoro. La proporzione reale, misurata:

$ snap list | awk 'NR>1{print $6}' | sort | uniq -c | sort -rn
     33 -
     10 classic
      5 base
      1 snapd

Trentatré in modo stretto, dieci in modo classico, cinque immagini di base che servono agli altri, e il gestore stesso. Dieci su quarantanove in modo classico significa che su questa macchina un quinto degli snap non ha l'isolamento che è uno dei motivi per cui il formato esiste: è un dato da sapere prima di dire che gli snap sono isolati.

Il confronto fra i tre formati, su criteri decidibili

I tre formati non si confrontano su «quale è meglio», si confrontano su cinque criteri per i quali una risposta esiste. Il primo è la versione: la distribuzione ne offre una, i formati indipendenti offrono canali diversi fra cui scegliere, e la differenza si legge nel loro elenco.

$ snap info core24
channels:
  latest/stable:          20260824      2026-09-10 (2124) 70.0MB -
  latest/candidate:       20260824      2026-09-10 (2124) 70.0MB -
  latest/beta:            20261022      2026-10-23 (2307) 70.1MB -
  latest/edge:            20261029      2026-10-29 (2317) 70.1MB -

Quattro canali, con la data di pubblicazione e la dimensione. Fra stable e edge ci sono due mesi di differenza, e il numero fra parentesi è la revisione: è il numero che ritrovi nei percorsi di montaggio.

Il secondo criterio è lo spazio, e il numero l'hai visto. Il terzo è l'aggiornamento di sicurezza: con la distribuzione, una libreria vulnerabile si aggiorna una volta e tutti i programmi che la usano ne beneficiano; con un formato indipendente, ogni pacchetto contiene la propria copia, quindi serve che ciascun autore rilasci una versione nuova. Questa è la differenza che conta di più su un server, e non è una questione di gusto.

Il quarto è l'aggiornamento automatico: snap aggiorna da sé, per progetto, e la cosa si può ritardare ma non disattivare in modo definitivo; il gestore della distribuzione aggiorna quando glielo chiedi. Su un desktop il primo comportamento è comodo, su un server che non vuoi vedere cambiare da solo è esattamente ciò che non vuoi, e questo da solo decide la scelta in molti casi.

Il quinto è l'isolamento, che hai misurato sopra. Qui le due famiglie indipendenti si distinguono fra loro: snap usa un sistema di confinamento basato su profili del kernel e un'infrastruttura centrale gestita da un solo fornitore; flatpak usa un meccanismo di sandbox diverso e un modello di distribuzione con più fonti possibili. Su quest'ultimo punto riporto la differenza di progetto e non una misura, perché flatpak su questa macchina non c'è: per verificarlo dovrei installarlo, e installare un pacchetto su una macchina per scrivere una lezione è un prezzo che non vale la pena fare pagare a chi quella macchina la usa.

L'errore di classificazione plausibile è trattare i tre formati come tre modi di fare la stessa cosa e scegliere per abitudine. Il criterio che uso: sui server, il gestore della distribuzione per default, e un formato indipendente solo quando mi serve una versione che la distribuzione non ha e dopo aver guardato chi aggiorna le librerie incluse. Sui desktop, il formato indipendente per le applicazioni grandi che evolvono in fretta, e la distribuzione per tutto il resto.

Esercizio 1, guidato: tre domande sullo stesso programma

Scegli un programma che hai installato sulla tua macchina in formato indipendente. Rispondi a tre domande con tre comandi: quante revisioni sono presenti sul disco, da quale canale arriva, e se ha l'isolamento o il modo classico. Poi rispondi a una quarta domanda senza comando: se domani scoprissero una vulnerabilità in una libreria che quel programma include, chi dovrebbe rilasciare l'aggiornamento?

Esercizio 2, autonomo: lo stesso programma, due formati

Trova un programma disponibile sia nel gestore della tua distribuzione sia in formato snap, e confronta la versione offerta dai due. Non installarli entrambi: la domanda si risponde interrogando le fonti, con gli strumenti della lezione su apt e con quelli di questa. Criterio di successo: hai due numeri di versione con la loro provenienza, e sai dire quale sceglieresti per un server e quale per il tuo portatile, con la ragione.

Soluzioni commentate

Esercizio 1. I tre comandi sono findmnt -nt squashfs -o TARGET | grep nome per le revisioni montate, snap list per il canale che compare nella colonna di tracciamento, e la colonna delle note della stessa uscita per il confinamento. Sul mio caso, astral-uv ha due revisioni montate, traccia latest/stable, e ha la nota classic.

Perché snap list da solo non basta per la prima domanda. Quel comando elenca una riga per programma, con la revisione attiva: le revisioni conservate non le vedi. La domanda «quanto spazio sta occupando questo programma» si risponde solo guardando i montaggi o i file di immagine, e questa è la ragione per cui nell'esercizio ho chiesto il numero di revisioni e non il numero del programma.

La quarta domanda è quella che conta e non ha un comando. La risposta è: l'autore del pacchetto, non la tua distribuzione e non tu. Con un pacchetto della distribuzione, la libreria è un pacchetto a sé e il suo aggiornamento di sicurezza arriva dai canali della distribuzione, che è un'organizzazione con un processo e una scadenza. Con un formato che include le proprie librerie, l'aggiornamento arriva quando l'autore ricompila, e se l'autore è un singolo che ha pubblicato due anni fa, non arriva. Questo è il costo meno visibile e più grave del formato, e non si vede in nessun comando: si vede nella data dell'ultima pubblicazione.

Esercizio 2. I due comandi sono apt-cache policy nome, che hai imparato, e snap info nome, che mostra i canali con le date. Sulla risposta di merito, il criterio che mi aspetto da te è questo: per un server, quello della distribuzione, a meno che la versione sia troppo vecchia per il tuo uso e tu abbia verificato che l'altro formato è pubblicato da chi mantiene davvero il programma; per il portatile, quello più recente, perché il costo di un aggiornamento automatico che cambia qualcosa lo paghi tu e non un servizio.

Perché la risposta «il più recente è meglio» è sbagliata senza qualificazioni. La versione più recente del programma può contenere librerie più vecchie di quelle della distribuzione, se l'autore ha compilato il pacchetto tempo fa: la data del programma e la data delle sue dipendenze sono due cose diverse, e nel formato indipendente la seconda non si legge dall'esterno con facilità. È il motivo per cui su un server la scelta prudente non è la versione nuova.

Domande per fissare il concetto

Perché un file dentro uno snap non si può modificare nemmeno con i privilegi di amministratore, e dove vivono allora le configurazioni che l'utente cambia? Se un formato include le proprie librerie, quale categoria di aggiornamento diventa più lenta e quale diventa più semplice? E come spiegheresti a un collega la differenza fra «questo programma è isolato» e «questo formato supporta l'isolamento», usando il dato dei dieci su quarantanove?

Fine del percorso: che cosa sai davvero

Questa è l'ultima lezione, e la domanda che resta non è se ricordi i comandi. La familiarità con un testo appena letto si confonde facilmente con la capacità di usarlo, e il modo di distinguerle è provare a fare la cosa senza riaprire niente. Per ciascuna delle voci seguenti, decidi se sai farla adesso, su una macchina, senza consultare.

1. Davanti a un «Permission denied», stabilire se il problema è il file, il gruppo, o una cartella del percorso.
2. Scrivere uno script che si ferma al primo guasto e ripulisce le proprie risorse anche uscendo per errore.
3. Diagnosticare una macchina che non comunica in rete con tre domande in ordine.
4. Stabilire se una regola di firewall è stata valutata, leggendo un numero dal sistema.
5. Fermare un processo nella sequenza che non corrompe i suoi dati.
6. Scrivere un file di unità e verificare che systemd abbia capito ogni riga.
7. Validare un'espressione temporale prima di aspettare che il lavoro parta.
8. Risalire da un file al pacchetto che lo possiede, su entrambe le famiglie di distribuzioni.

Per ogni voce su cui esiti, il piano di ripasso del percorso dice quale lezione riaprire e con quale attività, e l'attività non è rileggere. Le voci su cui non esiti vanno messe alla prova nella prova finale del percorso, che è l'unico posto in cui la differenza fra familiarità e capacità viene misurata invece di dichiarata.

Che cosa adesso sai fare

Sai che uno snap non è una cartella ma un'immagine montata in sola lettura, e sai dimostrarlo con due comandi. Sai perché più revisioni dello stesso programma coesistono, e qual è il beneficio che giustifica lo spazio che costano. Sai distinguere il confinamento stretto da quello classico, e sai che su questa macchina un quinto degli snap rinuncia all'isolamento.

Sai confrontare i tre formati su cinque criteri decidibili invece che per preferenza, e sai qual è il costo meno visibile dei formati che includono le proprie librerie: la catena di chi rilascia un aggiornamento di sicurezza. La verifica concreta: misura con du -sh quanto occupano i formati indipendenti sulla tua macchina, e confronta il numero con quello che avevi previsto all'inizio di questa lezione.