Reperire software su Linux: Snap, Flatpak ed AppImage

21/03/2025

Vedi anche Reperire software su Linux: repository e compilazione .
Vedi anche Reperire software su Linux: Distrobox e macchine virtuali .

Oltre il classico package manager

Abbiamo visto come l'uso di un package manager sia estremamente comodo e funzionale (da riga di comando o frontend grafico), ma non privo di criticità. Con migliaia di pacchetti e dipendenze, la frammentazione ed i conflitti non mancano.
Per ovviare a questo tipo di incovenienti, nel corso degli anni si è cercato di creare soluzioni di pacchettizzazione che prediligessero portabilità e sandboxing.

Come scusa?

È più facile di quanto sembri.
Avete presente le portable apps di Windows? Sono fondamentalmente archivi che contengono al loro interno tutto il necessario per l'esecuzione di un software; i sistemi di pacchettizzazione universali hanno un funzionamento simile.
Ciò implica che qualsiasi libreria e componente aggiuntivo (dai quali dipende il programma vero e proprio) dovranno risiedere all'interno dell'archivio stesso, e non verranno interpellati i file del sistema operativo dell'utente.
In questo modo si evitano a monte problemi di conflitti, oltre a garantire un'approccio agnostico rispetto ad una specifica distribuzione. Si possono anche far convivere più istanze di applicativi in versioni differenti.
Tali archivi non sono altro che dei file compressi che godono di portabilità, potendo essere facilmente spostati ed avviati su più macchine (soprattutto nell'implementazione di AppImage).

Sandboxing, invece, è sinonimo di isolamento.
Le applicazioni girano in un ambiente separato con permessi controllati e che non comunica direttamente con il resto dell'OS, garantendo maggiore sicurezza, ma con potenziali effetti negativi sull'integrazione nel sistema.

Riassumendo, quindi, software standalone e sandboxato per ovviare ai limiti intrinsechi dei package manager tradizionali.
Le librerie necessarie sono contenute nell'archivio dei programmi, sempre nella versione specifica per garantire il corretto funzionamento ovunque.
Tutti i sistemi elencati sono parzialmente o totalmente open source.

Snap

Croce e delizia delle distribuzioni di Canonical (e alcune derivate), Snap è un sistema di pacchettizzazione sviluppato a partire dal 2014 ed inizialmente esclusiva di Ubuntu.
È basato su uno store propietario (che contiene anche programmi non open source), controllato esclusivamente da Canonical e che esclude qualsiasi tipo di repository indipendente.
Le applicazioni possono essere installate e gestite con un tool da riga di comando, da store grafici, o anche direttamente agendo da file .snap .
I programmi Snap girano in container isolati, con permessi gestiti granularmente dall'utente. Un apposito servizio, snapd, si occupa della gestione completa di tutti i pacchetti, aggiornamenti compresi.

PRO
• Sicurezza
  Le app sono confinate all'interno di un container che utilizza varie tecnologie di sandboxing, tra cui anche AppArmour. Senza il consenso esplicito dell'utente, ci sono molti limiti sui permessi.
• Vasto catalogo
  Un catalogo così ampio di applicazioni, che comprende anche molti famosi software commerciali, è difficile da trovare altrove.
  Al contrario delle altre soluzioni illustrate, Snap può essere utilizzato anche per pacchettizzare applicazioni prive di interfaccia grafica.
• Semplicità ed immediatezza
  Tutto molto facile ed immediato, anche in distro pensate per server.
  Di fatto è comunque presente un package manager interno.

CONTRO
• Repository proprietario
  Lo store di Snap si basa su un unico, grande, repository in mano a Canonical.
  Nel corso del tempo, il controllo centralizzato e la scansione dei pacchetti prima della pubblicazione, non hanno evitato la presenza di malware. Da specificare che è comunque possibile creare e distribuire un file .snap al di fuori dello store.
• Controversie
  Snap sta diventando sempre più uno dei core business di Canonical ed Ubuntu.
  Se il futuro si prospetta del tutto privo del package manager apt, già ad oggi gli utenti subiscono quelle che potrebbero essere interpretate come "imposizioni dall'alto", a scapito della libertà di scelta tipica dell'ambiente open source.
  Oltre alle eliminazioni di pacchetti molto importanti dai repository apt di Ubuntu, capita di venire dirottati sui pacchetti Snap anche digitando esplicitamente comandi per l'uso del package manager tradizionale, e senza un chiaro avvertimento preventivo.
• Implicazioni su performance e spazio di archiviazione
  Ambienti isolati in sandbox, per quanto basati su container ottimizzati, non hanno le stesse prestazioni di pacchetti nativi con librerie condivise.
  Anche se oggi la situazione è in costante miglioramento, Snap tende ad appesantire l'avvio delle distro, dilatando i tempi di boot.
  La decompressione on-the-fly, al volo, degli archivi nel momento della loro esecuzione, può inoltre incidere negativamente sulla velocità di apertura dei programmi. Dulcis in fundo, di default gli aggiornamenti sono impostati per essere eseguiti più volte al giorno, in background e senza la conferma dell'utente, quasi alla stregua di Windows Update. Inevitabile poi aumentare la mole di dati necessari per l'esecuzione di ogni programma, a scapito dello spazio di archiviazione occupato (in favore dell'efficienza, esistono comunque librerie condivise anche tra le applicazioni Snap).

Flatpak

Flatpak è un sistema in realtà molto simile a Snap (persino a livello cronologico), tranne per alcune sottili differenze.
Le caratteristiche relative a containerizzazione e sandboxing sono sovrapponibili a quelle del sistema di pacchettizzazione di Canonical, ma la sua natura più open ha contribuito ad una migliore reputazione di Flatpak rispetto a Snap.
Una delle sue peculiarità più apprezzate è quella di non limitare la creazione di repository indipendenti. Oltre a Flathub, lo store principale che è diventato sinonimo stesso di Flatpak, chiunque può gestire una repo alternativa per la distribuzione dei suoi pacchetti.
Anche in questo caso è agire sui sia da CLI che GUI. Seppur indipendente, il progetto Flatpak si può considerare in qualche modo più vicino all'ambiente RPM (Red Hat, Fedora, openSUSE... ) e Gnome.
Molte distribuzioni dichiaratamente contrarie alla filosofia di Snap (tra cui spicca sicuramente Linux Mint) integrano nativamente Flatpak al loro interno.

PRO
• Sicurezza ed installazione senza privilegi amministrativi
  Anche qui valgono le stesse considerazioni espresse per Snap. Le app sono isolate e con permessi concessi in maniera opt-in.
  Flatpak non necessita di privilegi di root per l'installazione dei software, inoltre si può scegliere di rimanere completamente in ambiente utente.
• Apertura e controllo
  Almeno finora, una maggiore apertura ha evitato a Flatpak le fastidiose controversie di Snap.
  Gli sviluppatori sono liberi di usare repository personali, e l'utente ha maggiore controllo di quello che avviene sulla propria macchina.
  Gli updates sono gestiti in maniera più razionale, spesso parallelamente a quelli dei package manager tradizionali.
• Utilizzabile anche sulle distribuzioni immutabili
  La possibilità di operare a livello utente si rivela molto utile per intervenire anche sulle distro immutabili.
  Su openSUSE microOS, ad esempio, uno dei pochissimi metodi consigliati per ampliare il parco software è proprio quello di ricorrere a Flatpak.

CONTRO
• Disponibilità di programmi più limitata
  Flathub è un punto di riferimento per l'approvvigionamento di software su Linux, ma a livello di numeri resta ancora indietro rispetto allo Snap Store.
  Buona parte delle applicazioni usa librerie grafiche GTK, più affini al mondo Gnome e potenzialmente meno integrabili altrove.
  Anche su Flatpak la sicurezza dei pacchetti non è mai assoluta, e solo alcuni sono verificati (a quanto sembra solo al momento del primo caricamento da parte degli sviluppatori).
• Eccesso di dati
  Come avviene per Snap, in misura forse leggermente superiore, Flatpak è un sistema che richiede il download di grandi quantità di dati per l'installazione dei pacchetti; le prestazioni altalenanti dei server di Flathub non aiutano.
• Scarsa integrazione
  Flatpak si potrebbe considerare meno "invasivo" rispetto a Snap, ma anche meno integrato.
  Pur agendo sui permessi delle singole applicazioni con tool come Flatseal, può capitare di imbattersi in problemi di varia natura mentre si eseguono applicativi Flatpak.
  Bene come il comando flatpak agisca anche da package manager interno.

AppImage

Davvero interessante l'approccio dell'ormai pluriventennale AppImage (presentato nel 2004, ma con il nome di klik), molto vicino a quello dei file dmg di macOs.
Se "less is more", qui niente repository, store e tool di gestione; solo file contenitori (con estensione .AppImage) distribuiti ovunque e pronti da rendere eseguibili ed avviare.
I file AppImage non vanno estratti, ma montati su un filesystem virtuale attraverso FUSE, l'unico vero requisito necessario per l'avvio dei software pacchettizzati in questo modo.
Ottimo poter eseguire software senza nessuna reale modifica al sistema operativo sottostante, anche da dischi esterni (potrebbero essere comunque creati dei file di configurazione nella home dell'utente).

PRO
• Libero
  Nessun organo centralizzato, chiunque può distribuire in completa autonomia il proprio software con compatibilità teoricamente universale su Linux. AppImage è open source, ma anche un formato che si potrebbe definire libero.
• Dimensioni su disco
  Il peso degli AppImage è mediamente inferiore a quello degli archivi Snap o Flatpak.
  I file possono essere trasferiti facilmente ed utilizzati su più macchine.
• Compatibilità
  Solo potenzialmente universale si, ma di certo meno soggetto a problemi rispetto agli altri sistemi di pacchettizzazione illustrati in questa sede.
  Prestazioni quasi paragonabili a quelle dei pacchetti nativi.

CONTRO
• Sicurezza
  Non sono previsti meccanismi di containerizzazione o sandboxing out of the box. Niente che non si possa implementare, comunque.
  L'assenza di store unificati garantisce grande libertà di distribuzione, ma aumenta potenzialmente la possibilità di reperire file malevoli.
• Integrazione molto scarsa
  Se non si passa per strumenti aggiuntivi, di base l'integrazione degli AppImage nel sistema è praticamente nulla.
  Si può ovviare in vari modi, ma si sente la mancanza di un meccanismo che sia almeno simile a quello di un gestore di pacchetti interno.
• Gestione degli aggiornamenti
  Agire solo su singoli file ha i suoi benefici, ma comporta che gli aggiornamenti andrebbero eseguiti tutti manualmente. Tool come AppImageUpdate possono venire in aiuto.