Stawiam na AppImage a nawet na Snap lub Flatpak

Ostatnimi czasy społeczność opensource obiegły dwie energetyzujące wiadomości – Canonical w końcu unormuje sprawę rozpowszechniania programów dla wszelkich dystrybucji Linuksa. I druga – Red Hat zrobi to samo! Tak dowiedzieliśmy się (lub raczej dostaliśmy potwierdzenie) o niezależnie rozwijanych projektach Flatpak (dawne xdg-apps) oraz Snappy, które pozwolą pozbyć się zmory dręczącej użytkowników, developerów i opiekunów paczek. Rozwiązaniem są bowiem odpowiednio spreparowane paczki, które bez problemu da się zainstalować i uruchomić na każdej dystrybucji. Tyle teorii, a jak to wygląda w praktyce? W praktyce od kilku lat mamy już w użyciu takie rozwiązanie o nazwie AppImage.

Repozytoria z oprogramowaniem dla Linuksa to rzecz bezwzględnie znakomita. Uchroniły nas od plagi wirusów, malware, adware i innych śmieci z którymi od lat walczą użytkownicy wiodącego systemu. Jednak wobec gwałtownego rozwoju oprogramowania opensource (i nie tylko), ujawniła się ich podstawowa słabość. Ktoś musi w repozytoriach umieścić zaktualizowany program – a to oznacza jego skompilowanie, zbudowanie paczki, przekonanie opiekunów repozytoriów, że ten program powinien się tam znaleźć. Przy dobrych wiatrach i następnym wydaniu dystrybucji dla której robiliśmy paczkę otrzymujemy program w wersji, która… jest o dwa, trzy miesiące do tyłu w stosunku do jego obecnej numeracji. I tak w kółko. Pośrednio problem próbowało rozładować Ubuntu i koncepcja repozytoriów PPA, openSUSE i 1click install wprost ze strony WWW, ale nadal – ktoś te programy musi tam umieścić, zbudować a użytkownik musi być świadom takich kanałów dystrybucji oprogramowania (czyt. samodzielnie musi odnaleźć to, na czym mu zależy). Nawet wybitnie sprytne paczki dla Arch Linuksa i uniwersalne repozytorium AUR wymagają opieki ze strony osób tworzących PKGBUILDy.
Dla zrozumienia powagi sytuacji i ważności dostępu do najświeższego oprogramowania użytkowego, musimy zdać sobie sprawę z tego, że desktop to nie serwer. O ile w przypadku tego drugiego długie cykle wydawnicze, etapy stabilizacji i łatania usług i programów mają swoje uzasadnienie, o tyle nierozsądnym jest upieranie się, że użytkownik na desktopie powinien otrzymywać tylko stabilne wydania po ich półrocznym testowaniu. W większości przypadków rozwój takiego oprogramowania jest na tyle dynamiczny, że praca na wersji sprzed pół roku jest zwyczajnie pisząc frustrująca. Nie mówiąc już o frustracji deweloperów, których programy nie załapały się do repozytoriów, albo są programami zamkniętymi i/lub komercyjnymi. Na dodatek chyba wszyscy znamy ból użytkowania jakiegoś wydania ciągle wspieranej dystrybucji, dla której nikt już nie aktualizuje oprogramowania.

Dlatego tak często podnoszono ostatnio kwestię uniwersalności oprogramowania linuksowego, jego rozpowszechniania i pogodzenia interesu deweloperów oraz twórców wszelakich dystrybucji. Innymi słowy, potrzebny był format paczki, które raz stworzona byłaby możliwa do uruchomienia na jakiejkolwiek współczesnej dystrybucji. Do tego celu należało zlikwidować problem zależności i kilka innych niuansów. Jak sobie z tym poradzono?

W miejsce obowiązujących standardów paczkowania zaproponowano… A jakże, kilka rozwiązań. Przyjrzyjmy się jednak tym, o których było ostatnio najgłośniej i które mają stanowić panaceum na powyższe.

Flatpak aka xdg-app

Tajemnicza nazwa za którą stoi nie kto inny a Red Hat. Koncepcja zrodzona w głowie Alexandera Larssona wydaje się być kompletnym rozwiązaniem i światełkiem w tunelu dla procesu unifikacji sposobu dostarczania oprogramowania w przeróżnych dystrybucjach. Niemniej, gdy przyjrzymy się tematowi bliżej, to okazuje się, że:

• + zależności: w paczce, dzielą się na współdzielony przez paczki zestaw Runtime oraz te, których w Runtime nie ma (albo są w innej wersji),
• + bezpieczeństwo: sandbox i odgrodzenie programu od systemu,
• +/- dystrybucja: paczki organizowane w ramach repozytoriów (aby zainstalować – trzeba znać repozytorium),
• – obsługa: póki co skomplikowana instalacja z linii komend, do wygody potrzebne odrębne narzędzie graficzne (Gnome Software),
• – uniwersalność: rozwiązanie teoretycznie uniwersalne, ale działa jako tako w Fedorze. Uwaga na licencje (Red Hat).

Idąc dalej w dokumentację dowiemy się, że Flatpak jest ściśle powiązany z sesją graficzną, co za tym idzie nie będzie możliwe dystrybuowania tą drogą programów dla serwerów (poniekąd i słusznie). Co więcej, aby zbudować paczkę będziemy potrzebowali podstawowego zestawu bibliotek Runtime – w chwili obecnej GNOME 3.20 Runtime (tak, GNOME – KDE w drodze). Ten sam zestaw będzie też potrzebny, aby nasz program się uruchomił na używanym przez nas systemie. Warto podkreślić jedną rzecz – paczki są zupełnie niezależne od systemu i posiadanych przez nas bibliotek. Zawierają wszystko, co konieczne aby samodzielnie się uruchomić. Pomimo niepokojąco wyglądającego spowinowacenia z Red Hatem, rozwiązanie stara się być w miarę uniwersalne i dostępne dla każdego.

Dla porówniania – jak zainstalować najnowsze LibreOffice.

Snap

To nie pierwszy i nie ostatni raz, gdy Canonical postanawia napisać historię po swojemu. Przesłanki powstania paczek Snappy są oczywiste, Canonical chce swój przyszły sukces zawdzięczać tylko sobie i z nikim tej chwały nie dzielić. Ich koncepcja dystrybucji oprogramowania „od osób trzecich” jest bardzo podobny do koncepcji Flatpak.

• + zależności: w paczce, dzielą się na współdzielony przez paczki zestaw Ubuntu Core oraz te, które tam nie występują (albo są w innej wersji),
• + bezpieczeństwo: sandbox i odgrodzenie programu od systemu,
• +/- dystrybucja: paczki organizowane w ramach repozytorium prowadzonego przez Canonical,
• – obsługa: póki z linii komend, do wygody potrzebne odrębne narzędzie graficzne (na obsługę Snap przez Gnome Software chyba nie ma co liczyć – pora na kolejny fork?),
• – uniwersalność: rozwiązanie teoretycznie uniwersalne, ale działa jako tako w Ubuntu. Uwaga na licencje (Canonical).

Jak widać, różnice są kosmetyczne. Głównie w sposobie dostarczania zbudowanej paczki użytkownikowi końcowemu. Snap ma tę przewagę na Flatpakiem, że źródło paczek jest jedno – „sklep” Canonicala. Choć dla wielu osób może to być wada. Niemniej, nie trzeba przekopywać internetu w poszukiwaniu pożądanego URL z repozytorium dla konkretnego programu. Do tego składnia tekstowego polecenia „snap” do złudzenia przypomina stare dobre apt.

Dla porównania – jak zainstalować najnowsze LibreOffice.

AppImage

Okazuje się jednak, że ani deweloperzy stojący za Flatpakiem, ani Canonical koła nie odkryli. Podobnych koncepcji i podejść było już kilka, o różnych nazwach, z których chyba najlepiej przyjął się AppImage. W sumie to przyjął się w formie szczątkowej (istnieje na rynku już kilka lat), świadomość deweloperów o istnieniu tego rozwiązania jest mizerna i paczki AppImage dostarcza niewiele projektów.

• – zależności: do paczki załączone zostaję te, które nie występują w systemie na którym jest budowana paczka,
• +/- bezpieczeństwo: o oddzielenie programu od systemu trzeba zadbać samodzielnie, za pomocą choćby firejail, który wspiera AppImage,
• + dystrybucja: samodzielny (binarka ELF) i pojedynczy plik, będący obrazem „środowiska uruchomieniowego” dla programu,
• + obsługa: w każdym współczesnym menadżerze plików wystarczy prawy przycisk na pobranej paczce i opcja Uruchom (lub Właściwości i prawa do uruchamiania),
• + uniwersalność: rozwiązanie działa w każdej dystrybucji.

Czyli bez zbędnego udziwniania i ceregieli – po prostu na stronie projektu udostępniany jest plik, który po pobraniu możemy uruchomić na swoim systemie. Zaraz zaraz, ale czy to bezpieczne? Niestety, oblicze takiej wygody ma ponure oblicze znane z wiodącego systemu – w tak dystrybuowaną paczkę każdy może włożyć cokolwiek. Zweryfikuje to dopiero społeczność. Jakimś zabezpieczeniem jest stosowanie wspomnianego FireJail (firejail –appimage nasza_paczka_appimage). Kolejnym mankamentem może być obsługa zależności, która jest nie wiedzieć czemu uzależniona od tego na jakim systemie budujemy paczkę. Więc nie jest to tak, jak w przypadku Flatpak i Snap, że paczka jest samowystarczalna.

Jak można to wszystko skomentować? Powyższe rozwiązania (poza AppImage) wydają się być w powijakach, AppImage z kolei zupełnie niepoważnie podchodzi do kwestii bezpieczeństwa. Pogodzenie funkcjonalności AppImage i bezpieczeństwa Snap lub Flatpaka może wymagać… Kolejnego nowego konceptu i standardu.

A wygra ten system paczek, który będzie najmniej inwazyjny dla deweloperów chcących dostarczać szerokiemu gronu odbiorców tworzonych przez nich program.