Qualche anno fa ho scritto un articolo su "Come si installa un programma su Linux" e nel capitolo di chiusura "Uno sguardo al futuro..." parlavo delle innovazioni che stavano nascendo in questo campo; a distanza di 6 anni, il dato è tratto: Flatpak sembra essersi affermato come lo standard de facto per l'installazione dei programmi a fianco, però, del metodo "classico". Come ogni novità ha i suoi entusiasti sostenitori che ne lodano le qualità e i suoi agguerriti detrattori che ne evidenziano i limiti. Cerchiamo di conoscere meglio Flatpak, senza farsi influenzare dagli uni o dagli altri!
» Leggi: Come si installa un programma su Linux?
Che ne è dei concorrenti?
Flatpak sembra aver vinto la corsa per diventare il nuovo metodo per l'installazione dei programmi su Linux e non sono io a dirlo, sono i numeri: infatti è supportato da 36 distro (alcune di queste "immutabili"), di cui 11 lo hanno già abilitato per impostazione predefinita mentre le restanti 25 lo hanno da tempo inserito nei repository ufficiali (e può quindi essere abilitato con un solo comando), si integra perfettamente anche negli "store" di Gnome e KDE e conta ad oggi più di 2100 app che hanno totalizzato più di un miliardo di download!
» Leggi: [Linux] Che cosa sono i sistemi "immutabili"?
Ma che fine hanno fatto i concorrenti? Snap sembra essere ormai ad uso esclusivo di Ubuntu (non sorprende dato che lo sviluppatore è lo stesso, Canonical) e altre 4-5 distro, anche se può essere installato su almeno 22 (sul sito ufficiale è menzionato un "41 distro" senza però specificare quali siano... forse non è un dato aggiornato?) e solo 3 di queste non derivano direttamente da Debian (dal quale si approvvigionano per i pacchetti da installare, snap compreso). Dal lato applicazioni, il repository vanta "migliaia di app" (senza però fornire un numero preciso...) ma non dobbiamo dimenticare che queste sono anche per server a differenza di Flatpak che contiene solo e soltanto app per Desktop.
Terzo in gara era AppImage che fa però un po' storia a sé. Infatti, diversamente dai concorrenti, AppImage non ha bisogno di installare nel sistema le app "pacchettizzate" con questo standard, che rimangono però eseguibili su quasi qualunque distro, senza che queste debbano decidere di "adottarle" o implementare un framework di supporto. Rimane un jolly interessante per la comunità Linux dove, magari, si può trovare un'app, tra le circa 1400 disponibili (anche in questo caso, solo per Desktop) che non è presente negli altri due concorrenti.
La vittoria di Flatpak non è comunque da attribuire solo ai numeri ma anche al modello di distribuzione che nasce per essere decentralizzato (anche se per il momento c'è soltanto un solo grande repository, flathub.org, è possibile aggiungerne altri) contrariamente a Snap che è in mano a Canonical. Un'altra cosa che piace poco alla comunità Linux è proprio il backend di Snap, usato per la distribuzione delle applicazioni, che è proprietario, a differenza di Flatpak, interamente open source (ma comunque utilizzabile per fornire anche applicazioni proprietarie), a garanzia di trasparenza e scongiurando una "dipendenza" da un fornitore che, oggi o domani, potrebbe anche cambiare idea sull'utilizzo del suo servizio da parte di terzi.
Quali sono le principali caratteristiche? Come funziona Flatpak?
Oltre alle caratteristiche già viste fin qui possiamo evidenziarne altre, semplicemente andando a vedere come funziona Flatpak.
Flatpak utilizza una base comune (detta Runtime) contenente delle librerie che sono accessibili in sola lettura da tutti i programmi; queste librerie sono quelle di più comune utilizzo ma possono esserne aggiunte delle altre, ampliando di fatto il Runtime, tramite estensioni che contengono librerie più specifiche come quelle per l'accelerazione hardware o i codec audio/video.
Attualmente sono disponibili 4 ambienti di Runtime che sono scelti dai creatori delle applicazioni (ogni provider di Runtime offre anche un SDK) e che vengono installati automaticamente quando richiesti:
- Freedesktop, che può essere utilizzato per ogni applicazione
- GNOME, basato su Freedesktop ma aggiunge le librerie proprie di questa piattaforma
- KDE, basato su Freedesktop ma aggiunge le librerie proprie di questa piattaforma
- elementary, basato su GNOME ma aggiunge librerie grafiche proprie
L'utilizzo di una base comune, ampliabile al bisogno, ha diversi vantaggi: il primo e probabilmente più evidente è riuscire a diminuire la dimensione dei pacchetti Flatpak (che comunque occupano più spazio dei programmi "classici") perché non è necessario includere le librerie già disponibili nel Runtime ma anche e soprattutto la possibilità di avere un ambiente di lavoro che è uguale per tutti gli utenti indipendentemente dalla distro utilizzata, il che contribuisce ad avere applicazioni stabili e ridurre i malfunzionamenti.
Ma Flatpak è anche flessibile perché offre agli sviluppatori la possibilità di integrare comunque delle librerie nel pacchetto della loro applicazione; questo può essere necessario quando, ad esempio, un particolare programma richiede una precisa versione di una libreria, diversa da quella presente nel Runtime. Questo ha anche un lato negativo: se un'app non viene aggiornata per sfruttare le librerie più recenti, questa può contenere una libreria vulnerabile anche per molto tempo; con il sistema classico di installazione delle applicazioni, i manutentori delle distro solitamente creavano delle patch per... mettere una pezza... su queste vulnerabilità, perché la libreria serviva tutto il sistema!
Fortunatamente le app installate tramite Flatpak sono confinate, grazie a delle funzioni proprie del kernel Linux, in una Sandbox che le isola dal sistema e tra di loro. Ma un programma completamente isolato dal sistema è pressoché inutile (pensate se un editore di testo non potesse leggere i dati dal disco o salvare i file o ad un browser che non può accedere ad internet!) ecco perché un completo sistema di permessi consente di concedere o meno accesso a varie parti del sistema. Esistono due tipi di permessi che possono essere definiti come statici e dinamici.
I permessi statici sono quelli richiesti al momento della creazione del pacchetto flatpak e consentono di regolare l'accesso alle seguenti risorse:
- file presenti su disco
- rete
- dispositivi (camera, microfono, lettori...)
- processi al di fuori della sandbox
- chiamate di sistema (syscall)
- D-Bus (sistema di comunicazione tra processi)
- servizi in esecuzione (X11, PulseAudio, ...)
Anche questi permessi sono flessibili e non sono "o tutto, o nulla", ad esempio, l'accesso ai file può essere concesso solo per una determinata cartella o per tutta la home dell'utente piuttosto che per l'intero sistema (con eccezione di alcuni percorsi che rimangono sempre inaccessibili) e limitato in sola lettura o in lettura e scrittura o, addirittura, consentire solo la creazione di nuovi file.
Al momento dell'installazione di un'applicazione (procedura che vedremo in seguito), prima della conferma, viene mostrato un riepilogo dei permessi statici richiesti; per vederli di nuovo in seguito possiamo impartire il comando:
flatpak info --show-permissions id.applicazione.interessata
Come detto questi permessi sono richiesti in fase di creazione del pacchetto ma possono essere anche aggiunti, rimossi o modificati in maniera permanente (con il comando flatpak override --permesso=modifica id.applicazione.interessata) o solo per una sessione avviando il programma con il comando flatpak run --permesso=modifica id.applicazione.interessata ovviamente sostituendo opportunamente permesso, modifica e id.applicazione.interessata. In caso avessimo modificato i permessi con il comando override, potremo ripristinare i valori preimpostati con il comando flatpak override --reset id.applicazione.interessata
Qualcuno starà pensando: "Come mai definire "statici" questi permessi se possono comunque essere modificati?". "Statici" è riferito all'impossibilità di cambiare questi permessi durante l'esecuzione del programma ma, se si vuole modificarli, temporaneamente o permanentemente, è necessario riavviare il programma.
Dato che Flatpak è dedicato agli utenti Desktop, per modificare i permessi statici dei programmi, possiamo avvalerci di Flatseal che consente la modifica tramite una comoda e molto intuitiva interfaccia grafica
Come possiamo vedere dall'immagine sopra, Flatseal espone tutti i permessi per ognuna delle applicazioni installate e consente una rapida modifica con uno switch, marcando le modifiche effettuate dall'utente con il simbolo di un punto esclamativo racchiuso in un quadrato; ben evidente è anche il tasto Ripristina che consente di resettare i permessi modificati per l'applicazione selezionata con un semplice click.
Flatseal ci offre la possibilità di parlare di un'altra caratteristica dei permessi statici: è possibile impostare dei permessi globali (da riga di comando, sempre con il comando flatpak override, senza però specificare nessuna applicazione) che verranno rispettati da tutti i programmi. Un successivo override di uno o più permessi di una applicazione, "vincerà" sulle regole globali.
I permessi dinamici sono invece permessi che possono essere richiesti dalle applicazioni durante l'esecuzione. Un'applicazione che sfrutta i permessi dinamici, diversamente dai permessi statici, è completamente limitata dalla sandbox fino a quando non viene richiesto l'accesso ad una risorsa che, in alcuni casi, richiede la conferma da parte dell'utente; in questo caso l'applicazione può accedere solo e soltanto alla risorsa richiesta e a nessun'altra. Facciamo un esempio pratico: se concediamo il permesso per accedere ad un file in una cartella contenente altri file, l'applicazione potrà accedere solo e soltanto al file indicato e nessun altro nella cartella. Questi permessi sfruttano una caratteristica dei moderni ambienti Desktop, i Portali (Portal), interfacce che fanno da mediatori per la risorsa richiesta e messi a disposizione al sistema dal pacchetto xdg-desktop-portal (nome che può variare in base alla distro).
Sembra evidente che l'utilizzo dei Portali sia il sistema migliore per concedere i permessi alle applicazioni ma c'è un problema di fondo: i Portali devono essere implementati negli ambienti Desktop (e attualmente l'implementazione non è ancora del tutto perfetta) e i programmi devono essere sviluppati per poterli utilizzare. Ecco perché, al momento, si rendono necessari i permessi statici che, a ben vedere, rappresentano devi veri e propri buchi nella sandbox ma che comunque risultano essere un passo avanti rispetto alle classiche applicazioni da sempre eseguite senza nessuna sandbox ma al massimo limitati da sistemi MAC che possono comunque funzionare anche con Flatpak. In futuro si punterà, ovviamente, ad utilizzare quanto più possibile i permessi dinamici.
Se volete testare i Portali sul vostro sistema, potete installare (tramite flatpak, naturalmente) ASHPD Demo; nell'immagine che segue, potete vedere come, nonostante ASHPD Demo non abbia nessun permesso per accedere al filesystem, possa richiedere comunque di accedere ad alcuni file tramite il portale org.freedesktop.portal.FileChooser.
Come si usa flatpak?
Se la distro che utilizzate non è tra quelle che hanno già installato flatpak potete utilizzare la guida presente nel sito ufficiale oppure semplicemente installare il pacchetto flatpak presente nei repository secondo il modo d'uso della propria distro. In seguito potete verificare se è già stato configurato il repository ufficiale (Flathub) con il comando
sudo flatpak remotes
Se non ottenete nessun risultato potete aggiungerlo con il comando
flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
Dato che i pacchetti dei programmi, in molti casi, sono creati da sviluppatori indipendenti o volontari, non correlati al progetto originale, Flathub, da un po' di tempo, ha reso possibile riconoscere quelli che invece sono realizzati dagli stessi sviluppatori del programma (o da terzi approvati dall'autore originale) con una spunta blu. È anche possibile limitare il repository alle sole applicazioni verificate specificando l'opzione --subset=verified al comando sopra oppure aggiungere un nuovo repository, con un nome diverso (ad esempio, verified) in modo da rendere subito evidente le applicazioni "ufficiali" durante la ricerca (questo sistema ha lo svantaggio di dover indicare da quale repository vogliamo installare un'applicazione verificata).
Attualmente, oltre a quello di Flathub, ci sono soltanto altri 5 repository ufficiali (che salvo casi particolari non consiglio di aggiungere), che elenco qui sotto con il link e una breve descrizione:
- Flathub Beta (https://flathub.org/beta-repo/flathub-beta.flatpakrepo): nome abbastanza esplicativo, contiene le versioni in fase beta di sviluppo delle app presenti in Flathub
- Gnome Nightly (https://nightly.gnome.org/gnome-nightly.flatpakrepo): contiene le applicazioni di Gnome più aggiornate ma assolutamente non stabili
- KDE Testing Applications (https://distribute.kde.org/kdeapps.flatpakrepo): praticamente la versione KDE del precedente
- Liri Apps(https://repo.liri.io/flatpak/files/liri.flatpakrepo): contiene alcune applicazioni di questa distro (ancora in fase di sviluppo, non stabile)
- Winepak (https://dl.winepak.org/repo/winepak.flatpakrepo): contiene alcune applicazioni per Windows (poche e non molto aggiornate a dire il vero...) che girano tramite Wine, isolato in Flatpak
Per ricercare e installare un'applicazione nei repository possiamo utilizzare i comandi search e install da passare all'eseguibile flatpak. La ricerca non è diversa rispetto agli gestori di pacchetti, sarà necessario utilizzare una parola chiave, che può essere il nome del programma (ad esempio, Firefox) o la categoria a cui questo appartiene (ad esempio, browser); la risposta sarà una tabella contenente più o meno righe e composta da sei colonne
Queste colonne contengono il nome del programma (Name), una breve descrizione (Description), l'identificativo del programma (Application ID), la versione (Version), il ramo di sviluppo (Branch) e infine il repository (Remote). Per installare l'applicazione che vogliamo dovremo impartire il comando flatpak install seguito dall'identificativo del programma (se disponibile più di una versione è possibile specificarla indicando prima l'identificativo, poi l'architettura e infine il ramo di sviluppo con la forma id.programma.interessato/architettura/ramodisviluppo). In alternativa potremo indicare il nome del programma e in questo caso flatpak, se saranno presenti più soluzioni possibili (magari programmi che hanno una stessa parola nel nome), chiederà di confermare la scelta offrendo un numero ad ogni programma che ha trovato con quel nome.
Una volta confermato l'installazione dell'applicazione, questa verrà scaricata insieme ad altri pacchetti necessari (l'installazione della prima app richiederà anche un Runtime) ma per l'installazione vera e propria, dato che il comando è stato impartito da un normale utente, verrà richiesta l'elevazione dei privilegi a root. Questo perché, per impostazione predefinita, flatpak installa le applicazioni a livello di sistema in modo che siano utilizzabili da ogni utente presente (proprio come l'installazione vecchio stile). Tuttavia flatpak offre anche la possibilità di installare repository e programmi a livello utente, specificando l'opzione --user al comando di installazione e aggiunta di repository. I due tipi di installazione non sono integrate nel senso che, ad esempio, un programma installato a livello utente non può utilizzare il Runtime installato a livello di sistema (e viceversa) ma rimangono separate e distinte: l'installazione delle applicazioni a livello utente avverrà nella sua home (precisamente in ~/.local/share/flatpak) mentre quelle a livello di sistema nella percorso /var/lib/flatpak. In questo modo è possibile utilizzare l'una e l'altra possibilità contemporaneamente ma questo è senza dubbio sconsigliato. L'installazione a livello utente consente di installare i programmi senza necessità dei privilegi di root e sarebbe pensata principalmente per lo sviluppo delle applicazioni ma niente vieta di usarla normalmente; personalmente preferisco installare i programmi a livello di sistema e piuttosto utilizzare l'opzione di mount noexec per la home del mio utente...
Come accennato sopra, è possibili installare un pacchetto flatpak anche attraverso gli "store" dei principali Desktop, Gnome Software e Discover di KDE, tramite appositi backend che una volta installati (solitamente come dipendenza di flatpak) possono essere da abilitare nelle impostazioni di questi.
Coloro che utilizzano una distro con i suddetti "store", potrebbero trovare conveniente anche l'utilizzo di Flatline. Questo è un componente aggiuntivo (disponibile per Firefox e per Google Chrome/Chromium che, una volta installato nel browser, consente di aprire il pacchetto presente in Flathub.org direttamente in uno degli "store" supportati, semplicemente cliccando su Install anziché scaricare il file.flatpakref dell'applicazione interessata.
Il file con estensione flatpakref è un metodo "alternativo" (ma forse sarebbe meglio definirlo collaterale) al repository per la distribuzione delle applicazioni. È un semplice file di testo, contenente alcuni riferimenti come il nome e l'ID del programma, un repository (ecco perché collaterale!) da dove poterlo scaricare e una chiave GPG per garantire che il programma sia proprio quello descritto.
I programmi installati tramite Flatpak possono essere aggiornati tramite gli store compatibili ma non si aggiornano con i soliti comandi per l'aggiornamento del sistema, richiedono un comando apposito che, come si può facilmente intuire, è flatpak update che funziona per aggiornare tutti i programmi sia quelli installati nel sistema che quelli utenti (è sempre possibile specificare --system o --user per limitare l'aggiornamento all'uno o all'altro): questo mostrerà tutti i pacchetti da aggiornare e dovremo confermare l'operazione. È possibile aggiornare anche una sola applicazione, specificandola dopo il comando base; i Runtime invece verranno aggiornati automaticamente, se necessario, o verrà offerta la disinstallazione se obsoleti, ad ogni comando di aggiornamento. Alcune distro (come OpenSUSE) offrono anche un servizio e un timer per l'aggiornamento automatico dei programmi di Flatpak.
L'operazione di aggiornamento risulta essere molto efficiente, viene scaricato solo la porzione dei file effettivamente modificata e questo grazie al metodo di controllo delle versioni utilizzato che è OSTree. Nell'immagine sotto, nella colonna Download, possiamo vedere la quantità di dati scaricati per l'aggiornamento in rapporto alla dimensione totale del pacchetto
L'utilizzo di questa tecnologia consente anche un rapido e sicuro "downgrade" in caso di problemi (estremamente rari, a dire il vero) con le nuove versioni. Per vedere la storia degli aggiornamenti possiamo utilizzare il comando
flatpak remote-info nomerepository --log id.applicazione.interessata
Una volta identificata la versione a cui vogliamo regredire l'applicazione, dobbiamo prendere nota del commit e poi possiamo impartire il comando di "aggiornamento"
sudo flatpak update --commit=serialedelcommit id.applicazione.interessata
Se vogliamo escludere l'applicazione appena ripristinata da futuri aggiornamenti possiamo utilizzare il comando
flatpak mask id.applicazione.interessata
Per disinstallare un programma il comando sarà
flatpak uninstall id.applicazione.interessata
Il comando sopra, lascia però alcuni dati riferiti del programma nella home dell'utente (anche se era installata a livello di sistema); per rimuovere anche questi dati possiamo aggiungere l'opzione --delete-data al comando precedente. Se in passato abbiamo disinstallato qualche programma senza quest'ultima opzione, possiamo vedere quali dati sono rimasti ed eventualmente cancellarli con Flatsweep, strumento grafico da installare ovviamente tramite Flatpak.
Tutti i comandi visti sopra (downgrade, esclusione da aggiornamenti, rimozioni dati utenti, ...) e altro, possono essere fatti anche tramite interfaccia grafica con un altra applicazione flatpak, Warehouse, dalla quale è possibile anche vedere molte informazioni riguardo ai pacchetti installati come versione dell'applicazione, ramo di sviluppo, architettura, fonte di installazione e runtime utilizzato.
Per rimuovere i pacchetti non più utilizzati come, ad esempio, qualche Runtime utilizzato da un'applicazione non più installata, possiamo utilizzare sempre il comando flatpak uninstall senza specificare nessun ID applicazione ma con l'opzione --unused.
Per controllare che non ci siano file danneggiati tra le installazioni dei programmi e dei Runtime, potete utilizzare il seguente comando:
flatpak repair
Vediamo ancora un altro paio di comandi che potrebbero tornare utili; il primo consente di vedere tutti i pacchetti installati:
flatpak list
Se vogliamo vedere solo i programmi, dobbiamo aggiungere l'opzione --app, se vogliamo vedere solo i Runtime, --runtime mentre se vogliamo vedere tutte le applicazioni che utilizzano un certo Runtime --app-runtime=id.runtime.interessato.
L'ultimo comando che vi presento è:
flatpak history
Mostra tutte le operazioni fatte con flatpak come installazione, rimozione, aggiornamento di programmi e repository.
Conclusioni
Flatpak ha diversi limiti, molti dei quali li abbiamo già visti, come il maggior spazio sul disco occupato dai programmi e una sandbox perfettibile a cui si aggiungono un maggior consumo di risorse per l'esecuzione dei programmi e tempi di avvio delle applicazioni leggermente più lunghi. Qualcuno critica anche il fatto che i programmi sono in molti casi "pacchettizzati" da sviluppatori o volontari "terzi", non correlati, al progetto originale e senza che quest'ultimo neanche patrocini l'iniziativa, ma ritengo che questo non sia un grosso problema, dato che neanche prima i classici pacchetti dei programmi venivano creati dagli sviluppatori bensì dai manutentori delle distro. Vero è che in questo caso la cerchia di coloro che creano i pacchetti Flatpak (e in cui quindi riporre la nostra fiducia) si allarga di molto ma questo può anche essere un bel vantaggio: dato che tutto è liberamente accessibile e consultabile (la forza dell'open source!), più occhi, più controlli, più persone dedicate ad un solo progetto piuttosto che poche che seguono molti progetti contemporaneamente.
Anche dal lato dei manutentori delle distro, questo sistema di distribuzione delle applicazioni offre almeno un vantaggio: meno tempo impiegato a creare pacchetti dei programmi preoccupandosi per la compatibilità di tutte le dipendenze, più tempo da investire sui pacchetti di sistema magari migliorando e velocizzando rilascio di aggiornamenti, correzioni di sicurezza o aggiunta di funzioni. Non è certo un caso se RedHat ha, di recente, scelto di abbandonare il classico pacchetto di LibreOffice in favore di quello Flatpak per i prossimi rilasci della sua distro (e di conseguenza di Fedora). Il sistema di distribuzione, totalmente aperto, consente poi agli sviluppatori di creare un repository per i propri programmi e se anche adesso nessuno o pochi hanno seguito questa via, non è detto che in futuro sarà ancora così.
La sandbox, pur perfettibile, risulta comunque un passo avanti per la sicurezza delle applicazioni e di tutto il sistema, rispetto all'installazione classica e soprattutto per gli utenti meno smaliziati o che si avvicinano per la prima volta a Linux. Il costo da pagare, il maggior consumo di risorse (che non è certo un problema per i moderni hardware), potrebbe però essere un freno per l'adozione di questo standard da parte di quelle distro votate alla leggerezza, molto ricercate per dare nuova vita ad hardware datato.
Le applicazioni disponibili su Flatpak rappresentano poi una risorsa in più soprattutto per gli utenti di distro non basate su Debian (la più fornita di pacchetti), che possono trovare qui programmi già pronti che altrimenti avrebbero, magari, dovuto compilare autonomamente.
Insomma Flatpak è qui e sembra avere un futuro piuttosto roseo davanti a se.
