AppImage, Snappy, Flatpak... i wiele innych. Cz. 1 - AppImage
Już jakiś miesiąc po publikacji Ubuntu 16.04 blogerzy linuksowi całego świata zauważyli "nowy system paczkowania" jakim Ubuntu nazywa swoje snappy, czy snaps (raz tak, raz inaczej o nim pisze, zatem sam nie wiem jak się nazywa). Pewnie gdyby informacja nie pochodziła od Canonicala, pewnie wszyscy przeszliby koło niej jak koło AppImage, Autopackage, 0install, czy xdg-apps (obecnie Flatpak). Co ciekawe... przeszli, skoro najstarszy z wymienionych wyżej (a przecież nie wszystkich) systemów uniwersalnego paczkowania dla linuksa obecny jest na rynku od... 2002 roku.
Biorąc ten fakt pod uwagę, w zasadzie kończą się dyskusje na temat, że o to w tej chwili, dzięki oprogramowaniu Canonicala, które dostępne jest na różne systemy, firmy produkujące komercyjne i zamknięte oprogramowanie, rzucą się w ramiona linuksa i zaczną na ten system produkować swoje ulubione Photoshopy itp. Pies z kulawą nogą tego nie chce. Skoro przez całe lata nikt się tym nie zainteresował, to nowy "standard" Canonicala nic tu nie zmieni, chyba, że jednemu bogatemu człowiekowi uda się namówić innego równie bogatego, by stworzył coś, co może być w ten sposób dystrybuowane. Wątpię. Szczerze wątpię.
Niemniej jednak sam pomysł - choć znany mi z czasów, gdy korzystałem z Chakry, która wówczas wszystkie programy oparte o Gtk+ rozpowszechniała w postaci tzw. bundle - wydał się ciekawy. Mógłbym w ten sposób utrzymywać swój system we względnym porządku toolkitowym, zaś gdybym potrzebował czegoś innego, instalowałbym sobie taki właśnie "pakiet".
Postanowiłem zatem przetestować owe "standardy", umożliwiające uniwersalne paczkowanie aplikacji, tak, by mogły być uruchamiane niezależnie od linuksowej dystrybucji.
Na pierwszy ogień poszedł AppImage, którego użytkownicy linuksa z większym stażem mogą znać pod nazwą Klik. Pod taką bowiem po raz pierwszy pojawił się na rynku.
Dlaczego AppImage na początek? Cóż, w przeciwieństwie do np. Snappy wydaje się on być banalnie prosty i w istocie multidystrybucyjny. Snappy bowiem nie uruchomimy na niektórych systemach.
Aplikacje AppImage są rozprowadzane w pojedynczym pliku o rozszerzeniu appimage. Po ściągnięciu ze strony producenta takiego oprogramowania lub ze strony z aplikacjami AppImage należy tylko nadać plikowi atrybut wykonywalności i voila. Można sobie używać do woli. Większość skryptów, które przeglądnąłem dostosowane są do lokalizacji ~/Applications, a zatem sensownie, by w takim katalogu były przechowywane, choć nie jest to bezwzględnie konieczne.
Owe aplikacje *.appimage winny w zasadzie mieć w sobie wszelkie niezbędne im zależności, biblioteki itd. itp., które umożliwiają im uruchomienie się i prawidłowe działanie. Nie ma przy tym znaczenia w jakim języku napisana jest aplikacja.
Jak dotąd nie wpadła mi w ręce żadna aplikacja komercyjna, paczkowana w ten sposób. Fakt nie szukałem zbyt intensywnie. Znakomita większość aplikacji dostępnych w wymienionym powyżej "sklepie" jest dostępna również w postaci paczek binarnych w systemach. Gdzie i kiedy ma zatem sens instalowanie takiej paczki? Dla mnie np. do przyglądnięcia się nowościom w nadchodzącym LibreOffice 5.2, czy Firefox, a także by zainstalować jakieś oprogramowanie, z którego chcę skorzystać incydentalnie (np. Darktable). Także w przypadku sporych aplikacji, które nie są dostępne w repozytorium, a są budowane ze źródeł, co zwykle długo trwa, pomysł skorzystania z appimage wydaje się być sensowny.
Zanim jednak wyniki testów - muszę się wytłumaczyć z systemu, na którym przyszło mi paczki te testować. Nie jest wykluczone, że przetestuję je jeszcze na systemie mniej "ekstremalnym" od mojego, by wykluczyć błędy związane z konfiguracją (a w zasadzie z używanymi wersjami oprogramowania) mojego systemu.
Krótko: dystrybucja, której bazą jest Arch Linux, z otwartymi repozytoriami testing, community-testing, multilib-testing i kde-unstable, używająca również oprogramowania pochodzącego z tzw. unofficial repositories (w tym przypadku są to programy związane z KDE, które oficjalnie nie są jeszcze dostępne w wersjach opartych o KF5 oraz repozytorium mesa-git), nadto oparta o kernel, który sam kompiluję.
Wypróbowałem kilka programów, wszystkie z ww. sklepu: obie wersje Firefox, Krita, LibreOfficeDev (czyli 5.2.0Beta2), Chromium (51.0.2684), Darktable, GIMP, Iridium - ok. 1/7 dostępnego oprogramowania w sklepie i nadto Drawpile ze strony programu.
Można powiedzieć koncepcja prawie się sprawdza. Zwracam jednak uwagę na słowo "prawie". Spośród powyższych programów nie udało mi się uruchomić żadnego opartego o Blinka. Ani Chromium, ani Iridium nie uruchamiają się, powodując dość nieładny zrzut pamięci. Wersja Chromium zainstalowana z repozytorium działa prawidłowo.
W przypadku Firefox nie ma możliwości ingerencji w język interfejsu. Pomimo doinstalowania spolszczenia, przeglądarka uparcie komunikuje się ze mną w języku Szekspira. Co ciekawe, niektóre inne dodatki zainstalowały się i działają prawidłowo.
Drawpile... cóż wymaga SELinux. Bez zainstalowania - nie będzie działać. W Archu SELinux dostępny wyłącznie z AUR. Zatem o co chodzi z ową interdystrybuowością?
GIMP, Darktable, Krita - działają w zasadzie perfekcyjnie.
LIbreOfficeDev i działa i nie. W przeciwieństwie do wersji przebudowanej z rpm - niekiedy zalicza niezapowiedzianą wpadkę. Oczywiście nie można również zmienić języka interfejsu.
Co ciekawe - wszystkie aplikacje, które działały w Xach udało się również uruchomić na Waylandzie.
Stwierdzić zatem należy, że AppImage mają swoje dobre i złe strony. Część aplikacji nie uruchamia się, w części nie można zmienić ustwień interfejsu. Prawodpodobieństwo, by dla linuksa np. LO, czy FF były paczkowane we wszystkich wersjach językowych jest iluzoryczne. Jeśli zatem ktoś wymaga spolszczenia interfejsu, to otrzyma go chyba wyłącznie tam, gdzie aplikacje używają jakichś ustawień systemowych, albo zostały spaczkowane ze wszystkimi wersjami językowymi (Krita), jakie są dostępne.
Niestety nie doczytałem się (jeszcze) informacji na temat bezpieczeństwa tego rozwiązania. Wspominam o tym, albowiem z w przypadku konkurencyjnego snappy nie jest z tym najlepiej w przypadku uruchamiania tych aplikacji w X11.
Biorąc ten fakt pod uwagę, w zasadzie kończą się dyskusje na temat, że o to w tej chwili, dzięki oprogramowaniu Canonicala, które dostępne jest na różne systemy, firmy produkujące komercyjne i zamknięte oprogramowanie, rzucą się w ramiona linuksa i zaczną na ten system produkować swoje ulubione Photoshopy itp. Pies z kulawą nogą tego nie chce. Skoro przez całe lata nikt się tym nie zainteresował, to nowy "standard" Canonicala nic tu nie zmieni, chyba, że jednemu bogatemu człowiekowi uda się namówić innego równie bogatego, by stworzył coś, co może być w ten sposób dystrybuowane. Wątpię. Szczerze wątpię.
Niemniej jednak sam pomysł - choć znany mi z czasów, gdy korzystałem z Chakry, która wówczas wszystkie programy oparte o Gtk+ rozpowszechniała w postaci tzw. bundle - wydał się ciekawy. Mógłbym w ten sposób utrzymywać swój system we względnym porządku toolkitowym, zaś gdybym potrzebował czegoś innego, instalowałbym sobie taki właśnie "pakiet".
Postanowiłem zatem przetestować owe "standardy", umożliwiające uniwersalne paczkowanie aplikacji, tak, by mogły być uruchamiane niezależnie od linuksowej dystrybucji.
Na pierwszy ogień poszedł AppImage, którego użytkownicy linuksa z większym stażem mogą znać pod nazwą Klik. Pod taką bowiem po raz pierwszy pojawił się na rynku.
Dlaczego AppImage na początek? Cóż, w przeciwieństwie do np. Snappy wydaje się on być banalnie prosty i w istocie multidystrybucyjny. Snappy bowiem nie uruchomimy na niektórych systemach.
Aplikacje AppImage są rozprowadzane w pojedynczym pliku o rozszerzeniu appimage. Po ściągnięciu ze strony producenta takiego oprogramowania lub ze strony z aplikacjami AppImage należy tylko nadać plikowi atrybut wykonywalności i voila. Można sobie używać do woli. Większość skryptów, które przeglądnąłem dostosowane są do lokalizacji ~/Applications, a zatem sensownie, by w takim katalogu były przechowywane, choć nie jest to bezwzględnie konieczne.
Owe aplikacje *.appimage winny w zasadzie mieć w sobie wszelkie niezbędne im zależności, biblioteki itd. itp., które umożliwiają im uruchomienie się i prawidłowe działanie. Nie ma przy tym znaczenia w jakim języku napisana jest aplikacja.
Jak dotąd nie wpadła mi w ręce żadna aplikacja komercyjna, paczkowana w ten sposób. Fakt nie szukałem zbyt intensywnie. Znakomita większość aplikacji dostępnych w wymienionym powyżej "sklepie" jest dostępna również w postaci paczek binarnych w systemach. Gdzie i kiedy ma zatem sens instalowanie takiej paczki? Dla mnie np. do przyglądnięcia się nowościom w nadchodzącym LibreOffice 5.2, czy Firefox, a także by zainstalować jakieś oprogramowanie, z którego chcę skorzystać incydentalnie (np. Darktable). Także w przypadku sporych aplikacji, które nie są dostępne w repozytorium, a są budowane ze źródeł, co zwykle długo trwa, pomysł skorzystania z appimage wydaje się być sensowny.
Zanim jednak wyniki testów - muszę się wytłumaczyć z systemu, na którym przyszło mi paczki te testować. Nie jest wykluczone, że przetestuję je jeszcze na systemie mniej "ekstremalnym" od mojego, by wykluczyć błędy związane z konfiguracją (a w zasadzie z używanymi wersjami oprogramowania) mojego systemu.
Krótko: dystrybucja, której bazą jest Arch Linux, z otwartymi repozytoriami testing, community-testing, multilib-testing i kde-unstable, używająca również oprogramowania pochodzącego z tzw. unofficial repositories (w tym przypadku są to programy związane z KDE, które oficjalnie nie są jeszcze dostępne w wersjach opartych o KF5 oraz repozytorium mesa-git), nadto oparta o kernel, który sam kompiluję.
Wypróbowałem kilka programów, wszystkie z ww. sklepu: obie wersje Firefox, Krita, LibreOfficeDev (czyli 5.2.0Beta2), Chromium (51.0.2684), Darktable, GIMP, Iridium - ok. 1/7 dostępnego oprogramowania w sklepie i nadto Drawpile ze strony programu.
Można powiedzieć koncepcja prawie się sprawdza. Zwracam jednak uwagę na słowo "prawie". Spośród powyższych programów nie udało mi się uruchomić żadnego opartego o Blinka. Ani Chromium, ani Iridium nie uruchamiają się, powodując dość nieładny zrzut pamięci. Wersja Chromium zainstalowana z repozytorium działa prawidłowo.
W przypadku Firefox nie ma możliwości ingerencji w język interfejsu. Pomimo doinstalowania spolszczenia, przeglądarka uparcie komunikuje się ze mną w języku Szekspira. Co ciekawe, niektóre inne dodatki zainstalowały się i działają prawidłowo.
Drawpile... cóż wymaga SELinux. Bez zainstalowania - nie będzie działać. W Archu SELinux dostępny wyłącznie z AUR. Zatem o co chodzi z ową interdystrybuowością?
GIMP, Darktable, Krita - działają w zasadzie perfekcyjnie.
LIbreOfficeDev i działa i nie. W przeciwieństwie do wersji przebudowanej z rpm - niekiedy zalicza niezapowiedzianą wpadkę. Oczywiście nie można również zmienić języka interfejsu.
Co ciekawe - wszystkie aplikacje, które działały w Xach udało się również uruchomić na Waylandzie.
Stwierdzić zatem należy, że AppImage mają swoje dobre i złe strony. Część aplikacji nie uruchamia się, w części nie można zmienić ustwień interfejsu. Prawodpodobieństwo, by dla linuksa np. LO, czy FF były paczkowane we wszystkich wersjach językowych jest iluzoryczne. Jeśli zatem ktoś wymaga spolszczenia interfejsu, to otrzyma go chyba wyłącznie tam, gdzie aplikacje używają jakichś ustawień systemowych, albo zostały spaczkowane ze wszystkimi wersjami językowymi (Krita), jakie są dostępne.
Niestety nie doczytałem się (jeszcze) informacji na temat bezpieczeństwa tego rozwiązania. Wspominam o tym, albowiem z w przypadku konkurencyjnego snappy nie jest z tym najlepiej w przypadku uruchamiania tych aplikacji w X11.
Komentarze
Prześlij komentarz