nuova versione stabile dello strumento , che fornisce un sistema per la creazione di pacchetti autonomi, non legati a distribuzioni specifiche di Linux e eseguiti in un contenitore speciale, che isola l'applicazione dal resto del sistema. Il supporto per l'esecuzione di pacchetti Flatpak è garantito per Arch Linux, , Debian, Fedora, Gentoo, Mageia, Linux Mint e Ubuntu. I pacchetti Flatpak sono inclusi nel repository di Fedora e supportati dal gestore di applicazioni GNOME integrato.
Le chiave nella versione Flatpak 1.8:
- Semplificata l'implementazione dell'installazione in modalità P2P (consente di organizzare il download di applicazioni e runtime tramite nodi intermedi o dispositivi di archiviazione per sistemi senza connessione di rete). Terminato il supporto per l'installazione attraverso host intermedi nella rete locale. Disabilitato per impostazione predefinita il download automatico di repository (sideload) posizionati su dispositivi USB locali. Per attivare i repository locali intermedi, è necessario configurare il repository creando un collegamento simbolico da /var/lib/flatpak/sideload-repos o
/run/flatpak/sideload-repos. Изменение позволило упростить внутреннюю реализацию режима P2P и повысить его эффективность. - Aggiunta un'unità systemd opzionale per la rilevazione automatica di ulteriori repository su dispositivi USB esterni collegati.
- Per le applicazioni che hanno accesso al file system, è fornito il passaggio della directory /lib dell'ambiente host a /run/host/lib.
- Aggiunti nuovi diritti di accesso al FS – "host-etc" e "host-os", che consentono l'accesso alle directory di sistema /etc e /usr.
- Per generare un codice più efficiente per l'analisi dei file GVariant da ostreee è stato impiegato .
- Nella cripte di configurazione di assemblaggio è stata fornita la possibilità di compilare senza
libsystemd; - È assicurato il montaggio dei socket di Journal in modalità di sola lettura.
- In document-export è stato aggiunto il supporto per l'esportazione di directory.
- Consentito accesso diretto ai dispositivi audio ALSA per le applicazioni che hanno accesso a Pulseaudio.
- Nell'API aggiunto il segnale "install-authenticator", che può essere utilizzato dai client per installare gli autenticatori necessari per completare la transazione.
- Assicurato l'uso dei dati sul fuso orario basati su /etc/localtime del sistema host, risolvendo i problemi legati ai fusi orari in alcune applicazioni.
- Terminata l'installazione del file env.d da gdm, poiché i generatori systemd gestiscono meglio questo compito.
- Nell'utilità create-usb, per impostazione predefinita è abilitata l'esportazione di commit parziali.
- Fornito il file sysusers.d per creare gli utenti necessari tramite systemd.
- Ai comandi «flatpak remote-add» e «flatpak modify» è stata aggiunta l'opzione «—[no-]follow-redirect» per vietare/consentire il reindirizzamento a un altro repository.
- Nel sistema
è stata aggiunta l'API Spawn per ottenere l'identificativo reale del processo (PID) dell'applicazione in esecuzione. - Tutti i repository OCI (Open Container Initiative) sono stati convertiti per utilizzare l'autenticatore flatpak-oci-authenticator.
- Ai comandi «flatpak remote-info» e «flatpak update» è stata aggiunta l'opzione «—commit=» per specificare una versione particolare dei repository OCI.
- È stata aggiunta la prima supporto per gli aggiornamenti delta per i repository OCI.
- È stato aggiunto il comando «flatpak upgrade», che è un alias del comando «flatpak update».
- Sono stati implementati gli script di completamento per la shell fish.
Ricordiamo che agli sviluppatori di applicazioni Flatpak viene offerta la possibilità di semplificare la distribuzione dei loro programmi, che non sono inclusi nei repository principali delle distribuzioni, grazie a di un unico contenitore universale senza la necessità di creare assemblaggi separati per ogni distribuzione. Gli utenti attenti alla sicurezza possono utilizzare Flatpak per eseguire un'applicazione potenzialmente sospetta in un contenitore, consentendo l'accesso solo alle funzionalità di rete e ai file utente associati all'applicazione. Gli utenti interessati alle novità possono installare le versioni testate e stabili più recenti delle applicazioni senza dover apportare modifiche al sistema. Ad esempio, attualmente i pacchetti Flatpak già per LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, ecc.
Per ridurre le dimensioni del pacchetto, include solo le dipendenze specifiche per l'applicazione, mentre le librerie di base del sistema e grafiche (Gtk+, Qt, librerie GNOME e KDE, ecc.) sono presentate come ambienti di runtime modulari. La differenza fondamentale tra Flatpak e Snap è che Snap utilizza i componenti dell'ambiente del sistema principale e un'isolamento basato sulla filtrazione delle chiamate di sistema, mentre Flatpak crea un contenitore separato dal sistema e utilizza grandi set di runtime, fornendo come dipendenze non pacchetti, ma ambienti di sistema modulari (ad esempio, tutte le librerie necessarie per l'esecuzione di programmi GNOME o KDE).
Oltre all'ambiente di sistema standard (runtime), installato tramite uno speciale , vengono fornite dipendenze aggiuntive (bundle) necessarie per il funzionamento dell'applicazione. In totale, runtime e bundle formano il contenuto del container, dato che il runtime viene installato separatamente e collegato a più container, il che consente di evitare la duplicazione di file di sistema comuni per i container. In un sistema possono essere installati diversi runtime (GNOME, KDE) o più versioni di uno stesso runtime (GNOME 3.26, GNOME 3.28). Il container con l'applicazione come dipendenza utilizza il collegamento solo a un determinato runtime, senza considerare i singoli pacchetti di cui è composto il runtime. Tutti gli elementi mancanti vengono confezionati 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.
Il contenuto del runtime e dei container delle applicazioni è costituito utilizzando la tecnologia , in cui l'immagine viene aggiornata in modo atomico da un repository simile a Git, consentendo di applicare metodi di controllo versione ai componenti della distribuzione (ad esempio, è possibile riportare rapidamente il sistema a uno stato precedente). I pacchetti RPM vengono trasmessi al repository OSTree tramite un apposito strato . L'installazione e l'aggiornamento separati dei pacchetti all'interno dell'ambiente di lavoro non sono supportati; il sistema viene aggiornato non a livello di singoli componenti, ma nel complesso, modificando in modo atomico il proprio stato. Vengono forniti strumenti per l'applicazione incrementale degli aggiornamenti, eliminando la necessità di una sostituzione completa dell'immagine ad ogni aggiornamento.
L'ambiente isolato creato è completamente indipendente dalla distribuzione utilizzata e, con le dovute configurazioni del pacchetto, non ha accesso ai file e ai processi dell'utente o del sistema principale, non può accedere direttamente all'hardware, ad eccezione dell'output tramite DRI, e al sottosistema di rete. L'output grafico e l'organizzazione dell'input avviene utilizzando il protocollo Wayland o tramite il passaggio del socket X11. L'interazione con l'ambiente esterno è basata sul sistema di messaggistica DBus e su un'API Portals specifica. Per l'isolamento strato intermedio e le tecnologie tradizionali di virtualizzazione dei container in Linux, basate sull'uso di cgroups, spazi dei nomi (namespaces), Seccomp e SELinux. Per l'output audio viene utilizzato PulseAudio.
Fonte: opennet.ru
