en ny stabil gren af værktøjet , som tilbyder et system til opbygning af selvstændige pakker, der ikke er bundet til specifikke Linux-distributioner og køres i en speciel container, der isolerer applikationen fra resten af systemet. Understøttelse af eksekvering af Flatpak-pakker er sikret for Arch Linux, , Debian, Fedora, Gentoo, Mageia, Linux Mint og Ubuntu. Pakker med Flatpak er inkluderet i Fedora-repositoriet og understøttes i standard applikationshåndteringsprogrammet GNOME.
Nøglepunkter i Flatpak 1.4-grenen:
- Organisationen af indstillingerne for eksterne repositories er ændret. I kataloget /etc/flatpak/remotes.d anvendes der nu almindelige filer med endelsen «.flatpakrepo» i stedet for *.conf-filer med indstillinger, som automatisk importeres ved første brug af flatpak. Disse filer kan frit redigeres og slettes, svarende til manuelt tilføjede repositories;
- Organisationen af installationer af pakker til hele systemet er betydeligt ændret. I tidligere versioner blev pakken først installeret i en midlertidig mappe tilhørende brugeren, hvorefter system-helper-processen blev kaldt for at importere til systemet fra denne mappe. Denne tilgang medførte stort forbrug af diskressourcer, unødvendig input/output og potentielle sikkerhedsproblemer. I den nye version anvendes et specielt nyt FUSE-filsystem til installation af systempakker, hvor brugeren kan skrive data, men efter at skrivningen er afsluttet, blokeres adgangen til de indskrevne filer for brugeren. Den nye tilgang indebærer, at der skal oprettes en separat bruger til flatpak (som standard «flatpak») og ændringer af SELinux-reglerne;
- Muligheden for at definere filtre for eksterne repositories på klientens side er blevet tilføjet. Ved hjælp af filtre kan man begrænse, hvilke applikationer der er synlige i repository'et, ved at bruge en hvid- og svartlistermodel;
- Der er tilføjet et biblioteks-API for at tilføje eksterne repositories fra flatpakref-filer;
- Der er tilføjet et seccomp-profil til Docker, hvilket muliggør kørsel af flatpak inden for containere;
- Muligheden for installation fra flere P2P-kilder (via USB-drev eller over lokalnetværket) er forbedret;
- I kommandoen «flatpak remote-ls» er der sikret automatisk filtrering af applikationer, for hvilke supporttiden er udløbet;
- I «flatpak remote-ls» og «flatpak remote-info» er der implementeret en mulighed «—cached» for at levere information baseret på lokalt cachelagrede data;
- Muligheden for at angive versionen af pakkens levetid, hvorefter der vil blive tilbudt at skifte til en ny gren, er blevet tilføjet;
- Funktionen «—socket=pcsc» til adgang til smartkort er blevet tilføjet;
- Understøttelse af systemer med flere NVIDIA-grafikkort er blevet tilføjet;
- Understøttelse af dconf, der er placeret i et sandbox-miljø, er blevet implementeret;
- Options «—no-update-[summary,appstream]» og «—static-delta-ignore-ref=PATTERN» er blevet tilføjet til build-update-repo-kommandoen;
- Hastigheden på regenerering af appstream-grene for store repositoryer er blevet væsentligt forbedret.
Vi minder om, at Flatpak giver appudviklere mulighed for at forenkle distributionen af deres programmer, der ikke er inkluderet i de officielle repositoryer af distributioner, ved hjælp af én universel container uden at skulle lave separate builds for hver distribution. For brugere, der bekymrer sig om sikkerheden, tillader Flatpak at køre et tvivlsomt program i en container og giver kun adgang til netværksfunktioner og brugerfiler relateret til programmet. For brugere, der er interesseret i nyheder, giver Flatpak mulighed for at installere de nyeste test- og stabile versioner af applikationer uden at skulle ændre systemet. For eksempel er Flatpak-pakker allerede tilgængelige for LibreOffice, Firefox, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio osv.
For at reducere pakkestørrelsen inkluderer den kun applikationsspecifikke afhængigheder, mens de grundlæggende system- og grafiske biblioteker (Gtk+, Qt, GNOME- og KDE-biblioteker osv.) præsenteres som plug-in standard runtime-miljøer. Den væsentligste forskel mellem Flatpak og Snap er, at Snap bruger komponenter fra hovedsystemets miljø og isolering baseret på filtrering af systemopkald, mens Flatpak opretter en container adskilt fra systemet og opererer med store runtime-sæt, der leverer standard systemmiljøer som afhængigheder (f.eks. alle biblioteker, der kræves for at køre GNOME- eller KDE-programmer).
Ud over det typiske systemmiljø (runtime), der installeres via en speciel , leveres der yderligere afhængigheder (bundle), der kræves for at køre applikationen. Tilsammen danner runtime og bundle fyldet i containeren, idet runtime installeres separat og knyttes til flere containere, hvilket gør det muligt at undgå duplikering af fælles systemfiler for containerne. Der kan installeres flere forskellige runtime-miljøer (GNOME, KDE) eller flere versioner af det samme runtime (GNOME 3.26, GNOME 3.28) på et enkelt system. En container med en applikation som afhængighed bruger kun binding til et specifikt runtime, uden hensyn til de enkelte pakker, som runtime består af. Alle manglende elementer pakkes direkte sammen med applikationen. Når containeren dannes, monteres indholdet af runtime som partitionen /usr, mens bundle monteres i mappen /app.
Fyldet af runtime og applikationscontainere dannes ved hjælp af teknologien , hvor billedet atomisk opdateres fra et Git-lignende lager, som gør det muligt at anvende versionskontrolmetoder på distributionskomponenter (for eksempel kan systemet hurtigt rulles tilbage til en tidligere tilstand). RPM-pakker translitereres til OSTree-repositoriet ved hjælp af et speciallag . Separat installation og opdatering af pakker inden for arbejdsmiljøet understøttes ikke, systemet opdateres ikke på niveauet af enkeltkomponenter, men som helhed, atomisk ændrer sin tilstand. Der stilles redskaber til rådighed for inkrementel anvendelse af opdateringer, hvilket fjerner behovet for at udskifte billedet helt ved hver opdatering.
Det isolerede miljø oprettes fuldstændigt uafhængigt af den anvendte distribution og har, ved passende pakkeindstillinger, ikke adgang til brugerens eller systemets filer og processer. Det kan ikke direkte tilgå hardware, undtagen ved output via DRI og det netværksmæssige subsystem. Grafikoutput og inputorganisation foregår via Wayland-protokollen eller ved at videresende X11-socketen. Interaktionen med det eksterne miljø er bygget på et DBus-baseret meddelelsessystem og et special-API kaldet Portals. For at isolere laget og traditionelle Linux-teknologier til containervirtualisering, baseret på brugen af cgroups, navnerum (namespaces), Seccomp og SELinux. PulseAudio anvendes til lydudgang.
Kilde: opennet.ru
