Efter halvandet \u00e5rs udvikling er den nye stabile version af v\u00e6rkt\u00f8jet Flatpak 1.18 offentliggjort. Det giver et system til at bygge selvst\u00e6ndige pakker, der ikke er knyttet til specifikke Linux-distributioner og k\u00f8rer i et specielt container, der isolerer applikationen fra resten af systemet. Flatpak-pakker underst\u00f8ttes p\u00e5 Fedora, CentOS, Debian, Arch Linux, Gentoo, Linux Mint, Alt Linux og Ubuntu. Flatpak-pakker er inkluderet i Fedora-repositoriet og underst\u00f8ttes i de indbyggede applikationsstyringsprogrammer GNOME og KDE.<\/p>\n
N\u00f8gleinnovationer i Flatpak 1.18:<\/p>\n
Flatpak forenkler distributionen af programmer, der ikke er inkluderet i standard repositorys for distributioner, ved at forberede en universel container, der befrier programudviklere fra n\u00f8dvendigheden af at lave separate builds til hver distribution. For brugere, der bekymrer sig om sikkerhed, giver Flatpak mulighed for at k\u00f8re tvivlsomme applikationer i en container, hvilket giver selektiv adgang kun til n\u00f8dvendige netv\u00e6rksfunktioner og brugerfiler. For brugere, der er interesserede i nyheder, muligg\u00f8r Flatpak installation af de nyeste test- og stabile versioner af applikationer uden behov for at \u00e6ndre systemet. For eksempel er Flatpak-pakker tilg\u00e6ngelige for LibreOffice, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Telegram Desktop, Android Studio osv.<\/p>\n
For at reducere st\u00f8rrelsen inkluderer pakken kun applikationsspecifikke afh\u00e6ngigheder. Grundl\u00e6ggende system- og grafiske biblioteker (GTK, Qt, GNOME og KDE biblioteker osv.) leveres som plug-in type runtime-milj\u00f8er. Den vigtigste forskel mellem Flatpak og Snap er, at Snap bruger komponenter fra det prim\u00e6re systems milj\u00f8 og isolering baseret p\u00e5 filtrering af systemopkald, mens Flatpak opretter en separat container fra systemet og opererer med store runtime-s\u00e6t, der leverer typiske systemmilj\u00f8er som afh\u00e6ngigheder (for eksempel alle biblioteker n\u00f8dvendige for at k\u00f8re GNOME eller KDE programmer).<\/p>\n
Udover det standard systemmilj\u00f8 (runtime), der installeres via et specielt repository, leveres der yderligere afh\u00e6ngigheder (bundle), der er n\u00f8dvendige for applikationens drift. I sum danner \u00abruntime\u00bb og \u00abbundle\u00bb indholdet af containeren, idet \u00abruntime\u00bb installeres separat og knyttes til flere containere, hvilket g\u00f8r det muligt at undg\u00e5 duplikering af f\u00e6lles systemfiler for containerne. <\/p>\n
I \u00e9t systeme kan der v\u00e6re installeret flere forskellige «runtime» (GNOME, KDE) eller flere versioner af den samme «runtime» (GNOME 50, GNOME 49). En container med en applikation som afh\u00e6ngighed bruger binding udelukkende til en bestemt «runtime», uden hensyntagen til de enkelte pakker, der danner den valgte «runtime». Alle manglende elementer pakkes direkte sammen med applikationen. Ved oprettelsen af containeren monteres indholdet af «runtime» som partitionen \/usr, mens «bundle» monteres i katalogen \/app. <\/p>\n
Indholdet af «runtime» og applikationscontainere dannes ved hj\u00e6lp af OSTree-teknologi, hvor billedet atom\u00e6rt opdateres fra et Git-lignende lager, der muligg\u00f8r anvendelse af versionskontrolmetoder p\u00e5 distributionskomponenterne (for eksempel kan systemet hurtigt rulles tilbage til en tidligere tilstand). RPM-pakker overs\u00e6ttes til OSTree-lageret ved hj\u00e6lp af rpm-ostree-laget. <\/p>\n
Valgfri installation og opdatering af pakker inden for det arbejdsmilj\u00f8 underst\u00f8ttes ikke — systemet opdateres ikke p\u00e5 niveauet for enkelte komponenter, men helt, og atom\u00e6rt \u00e6ndrer sin tilstand. Der leveres v\u00e6rkt\u00f8jer til inkrementelt anvendelse af opdateringer, der fjerner behovet for en fuld udskiftning af billedet ved hver opdatering.<\/p>\n
Det isolerede milj\u00f8, der dannes, er uafh\u00e6ngigt af den anvendte distribution og har under passende pakkeindstillinger ikke adgang til brugerens filer og processer eller hovedsystemet, og kan heller ikke direkte tilg\u00e5 hardware, bortset fra output gennem DRI. Grafikudgang og indtastningsorganisering er realiseret ved hj\u00e6lp af Wayland-protokollen eller gennem videresendelse af X11-sockets. Interaktion med det eksterne milj\u00f8 er bygget op gennem DBus-messagesystemet og en speciel API Portals. <\/p>\n