Distribuce softwaru linuxovým uživatelům vždycky trpěla roztříštěností. Pokud jste chtěli distribuovat aplikaci třetí strany, v jakém formátu? Zdrojový kód je univerzální, ale je nejméně pohodlný pro uživatele. Když uděláte RPM, bude fungovat ve Fedoře, RHELu, openSUSE, SLEDu i Mageie? Autoři aplikací pro Linux opravdu neměli a nemají jednoduchý život. Flatpak by jim ho měl zjednodušit.

Flatpak jsme začali vyvíjet před zhruba dvěma lety. Ještě před měsícem nesl projekt název xdg-app, ale nebyl to z marketingového pohledu ideální název, takže jsme ho změnili, když se projekt dostal do stavu, kdy je široce použitelný. Není to nic postaveného na zelené louce, ale sdílí to celou řadu věcí s dalšími kontejnerovými technologiemi. Používá to LContainers, namespaces, cgroups,… Akorát je zaměřený na desktopové aplikace.

Tradičním způsobem distribuce softwaru ve světě Linuxu jsou balíčky se závislostmi. Aplikace knihovnu, na které závisí, nebundluje, ale používá tu, kterou jí poskytuje systém. To má velkou výhodu především v bezpečnosti, protože když se objeví zranitelnost, stačí opravit jednu komponentu v distribuci a máte po problému. Má také výhody, co se týče diskových a paměťových nároků, i když to je věc, která je čím dál méně důležitá. Nevýhodou tohoto řešení je, že se všechny aplikace musí shodnout na jedné konkrétní verzi knihovny v distribuci. Pokud chcete novější verzi aplikace, často ji dostanete až s dalším vydáním distribuce, protože to může znamenat upgrade celé sítě závislostí.

Změnil se také přístup vývojářů. Dřív byly distribuce jediným způsobem, jak se dostat k uživatelům, takže si dávali víc záležet na tom, aby v nich mohly být jejich aplikace obsažené. Dnes už je to čím dál více z nich jedno. Uživatelé si k nim najdou cestu i mimo distribuci a dostanou možnost instalace cestou nejmenšího odporu – velký bundle. Ukazuje se také, že distribuce také neumí škálovat, aby dokázaly nabídnout veškerý software, který jejich uživatelé chtějí. Ty nejobsáhlejší distribuce dnes nabízí desítky tisíc balíčků, ale ve světě jsou open-source projektů miliony.

Nárůst popularity kontejnerů celý trend jen umocnil a bundlování začalo vítězit nad balíčky s dynamickým linkováním. Dá se říct, že to směřuje k tomu, co funguje na Windows a OS X roky. Je to právě hlavně bundlování, které umožňuje, že spustíte stejnou aplikaci na Windows 10 i Windows XP. Jak už jsem zmínil výše, takové bundlování přináší bezpečnostní problémy. Nejenže se musí jedna bezpečností chyba opravit ve více instancích té samé knihovny místo jedné, ale ještě se musíte většinou spolehnout na autory aplikace, že to skutečně udělají. Proto je lepší takovým bundlům apriori nedůvěřovat a co nejvíce je izolovat od zbytku systému a to je právě to, co Windows a OS X dříve nedělaly.

Flatpak se snaží z tohoto poučit. Aplikačním bundlům se apriori nedůvěřuje a proto běží v sandboxu. Ten momentálně není uzavřený dokonale. Chceme-li, aby se stávající aplikace ve Flatpaku fungovaly, aniž by se kvůli němu musely měnit, musíme do sandboxu udělat díry. Např. do něj připojíme adresář /home nebo aplikaci dovolíme přístup k X serveru, přes který má přístup ke všem datům, který přes něj tečou. Už dnes jsou ale aplikace ve Flatpaku zabezpečenější, než když je pouštíte tradičním způsobem.

Momentálně se pracuje na tzv. portálech. Ty by měly umožnit kontrolovaný přístup aplikace ke zdrojům mimo sandbox. Aplikace tak třeba nebude přistupovat přímo k webkameře, ale zeptá se Pinos (něco jako PulseAudio pro video, měl by poskytovat abstrakční vrstvu nad různými video vstupy a výstupy), jestli může dostat video stream z webkamery, a uživatel o tom bude vědět.

Flatpak také částečně řeší problém s více instancemi stejné knihovny. Pracuje totiž s runtimy, které poskytují sadu komponent, které může aplikace použít. Ty se jako read-only připojují do sandboxu a mohou být sdíleny. Pokud je knihovna obsažená v runtimu, nemusí se i její aktualizace vývojář aplikace starat a oprava chyby v ní vyřeší daný problém pro více aplikací naráz. Je to tak na půl cesty k tradičnímu způsobu linkování na systémové knihovny. Momentálně jsou poskytované runtimy GTK a FreeDesktop, které jsou postavené na distribuci Yocto, což je docela neutrální projekt. Do budoucna bude zajímavé sledovat, jak se bude ekosystém runtimů vyvíjet. Bude tam asi hodně politiky. Jestli se třeba bude lidem z RPM světa líbit, že některé projekty používají runtimy postavené na Debianu, a naopak. Konečné slovo ale budou mít vždy tvůrci dané aplikace.

Flatpak má nově také oficiální webovou stránku, kde se můžete dozvědět víc o tom, jak funguje, jak s ním pracovat, jak pro něj balit aplikace, jaké aplikace už jsou pro něj k dispozici. Dnes byl třeba oznámen LibreOffice pro Flatpak. K dispozici už je také 23 aplikací z GNOME, Darktable Nightly, GIMP Nightly, GTK3 GIMP Nightly, Inkscape Nightly, MyPaint Nightly. Právě provozování vývojových verzí aplikací ve Flatpaku má své nesporné výhody: běží izolovaně, nemůžou vám rozbít nic jiného, nemusíte mít nejnovější verze systémových knihoven.

Zájem o Flatpak je také v projektu KDE a komunikujeme také s několika významnými tvůrci softwaru (nejen) pro Linux. Flatpak by měl také řešit roztříštěnost Linuxu. Aplikace pro něj půjdou nainstalovat na všechny distribuce, které Flatpak obsahují, což by neměl být problém pro drtivou většinu moderních distribucí. Od začátku byl navržen jako řešení nezávislé na distribuci a množství závislostí je malé. Už nyní Flatpak můžete najít ve Fedoře, Arch Linuxu, openSUSE, Debianu, Ubuntu (přes PPA). Plánujeme ho mít také v RHELu a počítám, že brzo se rozšíří i do dalších distribucí.

Ve Fedoře 24 lze aplikace zatím instalovat pouze pomocí konzolového nástroje flatpak. Již v další verzi už by měla být instalace souborů .flatpak podporovaná také GNOME Software, takže bude stačit na soubor poklepat a on se zázračně nainstaluje bez ohledu na to, jestli jej instalujete ve Fedoře, Debianu nebo Archu.

Co tedy Flatpak v kostce přináší?

• Jeden instalační soubor bez ohledu na distribuci a její verzi.
• Aplikace běží sandboxu. (zatím nejsou izolované kompletně, ale stále výrazně více než tradiční)
• Upstreamové projekty můžou jednoduše software distribuovat přímo uživatelům, není potřeba prostředník v podobě distribučního balíčkáře.