Dopo un anno e mezzo di sviluppo, \u00e8 stata pubblicata una nuova versione stabile del toolkit Flatpak 1.18, che fornisce un sistema per la creazione di pacchetti autonomi, non legati a specifiche distribuzioni Linux e eseguiti in un contenitore speciale che isola l'applicazione dal resto del sistema. Il supporto per l'esecuzione dei pacchetti Flatpak \u00e8 garantito per Fedora, CentOS, Debian, Arch Linux, Gentoo, Linux Mint, Alt Linux e Ubuntu. I pacchetti Flatpak sono inclusi nel repository Fedora e supportati nei programmi di gestione delle applicazioni GNOME e KDE.<\/p>\n
Novit\u00e0 principali nella versione Flatpak 1.18:<\/p>\n
Flatpak semplifica la distribuzione di software non presente nei repository standard delle distribuzioni, preparando un unico contenitore universale che libera gli sviluppatori dalla necessit\u00e0 di creare diverse build per ogni distribuzione. A coloro che si preoccupano della sicurezza, Flatpak offre la possibilit\u00e0 di eseguire applicazioni sospette all'interno di un contenitore, fornendo accesso selettivo solo alle funzionalit\u00e0 di rete e ai file necessari. A coloro che sono interessati alle novit\u00e0, Flatpak consente di installare le versioni pi\u00f9 recenti di test e stabili delle applicazioni senza necessit\u00e0 di modificare il sistema. Ad esempio, i pacchetti Flatpak vengono creati per LibreOffice, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Telegram Desktop, Android Studio, ecc.<\/p>\n
Per ridurre le dimensioni, nel pacchetto vengono incluse solo le dipendenze specifiche per l'applicazione. Le librerie di base del sistema e grafiche (GTK, Qt, librerie GNOME e KDE, ecc.) vengono fornite sotto forma di ambienti runtime standardizzati. La principale differenza tra Flatpak e Snap \u00e8 che Snap utilizza i componenti dell'ambiente del sistema principale e l'isolamento basato sulla filtrazione delle chiamate di sistema, mentre Flatpak crea un contenitore separato dal sistema e opera con ampi set di runtime, fornendo come dipendenze non pacchetti, ma ambienti di sistema standardizzati (ad esempio, tutte le librerie necessarie al funzionamento dei programmi GNOME o KDE).<\/p>\n
Oltre all'ambiente di sistema tipico (runtime), installato tramite un repository speciale, vengono fornite ulteriori dipendenze (bundle) necessarie per il funzionamento dell'applicazione. Insieme, «runtime» e «bundle» formano il contenuto del contenitore, con «runtime» che viene installato separatamente e associato a pi\u00f9 contenitori, permettendo di evitare duplicazioni di file di sistema comuni per i contenitori. <\/p>\n
In un sistema possono essere installati diversi «runtime» (GNOME, KDE) o pi\u00f9 versioni di uno stesso «runtime» (GNOME 50, GNOME 49). Un container con un'applicazione come dipendenza utilizza il binding solo a un certo «runtime», senza considerare i singoli pacchetti che formano il «runtime» selezionato. Tutti gli elementi mancanti vengono imballati direttamente insieme all'applicazione. Durante la creazione del container, il contenuto del «runtime» viene montato come partizione \/usr, mentre il «bundle» viene montato nella directory \/app. <\/p>\n
Il contenuto del «runtime» e dei container delle applicazioni viene creato utilizzando la tecnologia OSTree, secondo la quale l'immagine viene aggiornato in modo atomico da un repository simile a Git, che consente di applicare metodi di controllo delle versioni ai componenti della distribuzione (ad esempio, \u00e8 possibile ripristinare rapidamente il sistema a uno stato precedente). I pacchetti RPM vengono trasmessi nel repository OSTree tramite un layer rpm-ostree. <\/p>\n
L'installazione selettiva e l'aggiornamento dei pacchetti all'interno dell'ambiente di lavoro non sono supportati \u2014 il sistema viene aggiornato non a livello di singoli componenti, ma in modo completo, cambiando il proprio stato in modo atomico. Vengono forniti strumenti per l'applicazione incrementale degli aggiornamenti, eliminando la necessit\u00e0 di una sostituzione totale dell'immagine ad ogni aggiornamento.<\/p>\n
L'ambiente isolato creato non dipende dalla distribuzione utilizzata e, con le giuste impostazioni del pacchetto, non ha accesso ai file e ai processi dell'utente o del sistema principale, n\u00e9 pu\u00f2 accedere direttamente all'hardware, eccetto per l'output tramite DRI. L'output grafico e l'organizzazione dell'input sono realizzati utilizzando il protocollo Wayland o tramite il forwarding del socket X11. L'interazione con l'ambiente esterno avviene tramite il sistema di messaggistica DBus e un'API Portals specifica. <\/p>\n