wtorek, 5 lipca 2016

AppImage, Snappy, Flatpak... - Cz.2 Flatpak

Druga przygoda z "bundlami", czyli flatpak. Pierwsza różnica w porównaniu do AppImage - by korzystać z tego typu paczek konieczna jest instalacja ich menedżera oraz wykonanie kilku czynności, które umożliwią - przynajmniej w teorii - pracę z programami spaczkowanymi w tym standardzie. W Archu menedżera flatpaków znajdziemy w repozytorium extra lub możemy zainstalować wersję rozwojową kompilowaną z AUR (flatpak-git). To nie wszystko. Po instalacji musimy dodać odpowiednie klucze publiczne oraz biblioteki uruchomieniowe (runtime). Dopiero potem możemy przystąpić do instalacji programów, które instalujemy bądź repozytoriów (czyli dokładnie jak w przypadku każdej dystrybucji), bądź też z lokalnie pobranego pliku (tak np. zainstalujemy LibreOffice). Po dodaniu repozytoriów możemy je przeglądać, możemy instalować, aktualizować, czy odinstalować aplikacje. Sam flatpak po prostu oferuje wszystko to, co każdy inny menedżer pakietów znany z linuksa. Wprawdzie składni należy się nauczyć, a nazwy repozytoriów gdzieś wyszukać, ale może niegdyś dorobimy się jakichś skryptów czy aplikacji, w większym stopniu ułatwiającym zarządzanie owymi paczkami. Jak na początek drogi - obecne narzędzie ocenić można pozytywnie, ale wyłącznie dla osób, które przywykły do instalacji programów w konsoli. Jeśli miałoby to być jednak narzędzie dla bardzo początkujących użytkowników linuksa, to trudno go takim odnaleźć. Jak wspomniałem - kwestią czasu jest kiedy otrzymamy jakiegoś graficznego instalatora, albowiem raczej pewnym jest, że zespół odpowiedzialny za rozwój projektu będzie go starał się promować. Także i w taki, ułatwiający codzienne korzystanie z komputera, sposób.
Po zainstalowaniu aplikacji, pojawia się ona w menu. Przynajmniej powinna. W Plasma 5 tego nie zaobserwowałem.
Czynności, jakie są konieczne do wykonania, opisane zostały dość dobrze na stronach projektu, niekiedy znajdziemy je również na stronach określonych aplikacji, jak np. LibreOffice. Ze względu na dość ścisłe powiązanie projektu z zespołem odpowiedzialnym za rozwój środowiska Gnome, informacje, jakie znajdujemy na stronie projektu są zwykle związane z aplikacjami należącymi do rodziny Gtk. Co ciekawe, pośród dostępnych repozytoriów Gnome jest nie tylko oferujące paczki aktualnego wydania stabilnego, ale również wydania deweloperskie. To cenna informacja dla tych, którzy chcą się włączyć w testowanie i pomoc w rozwoju oprogramowania. Także zespół KDE przygotował swoje repozytorium z bibliotekami uruchomieniowymi dla paczek opartych o Qt5 i KF5 w tym standardzie. Samej jednakże aplikacji flatpak "ze stajni" KDE nie znalazłem. Fakt, niezbyt długo jej poszukiwałem.
Dość dobrze rozwiązana jest lokalizacja programów, albowiem oferowana jest co do zasady przez odpowiednie repozytorium (oczywiście o ile zostało ono przygotowane).
Także rozmiar programów jest do przyjęcia. Dla przykładu około 150MB paczka LibreOffice odpowiada rozmiarowi paczek z repozytorium.
Programy jeśli już się zainstalują, pracują mniej więcej równie sprawnie jak aplikacje instalowane w natywny dla dystrybucji sposób.
Znów jednakże musimy pamiętać, że przygotowane w taki sposób programy mają swoje ograniczenia. Dla przykładu LibreOffice nie zostało spakowane w taki sposób, który umożliwiłby korzystanie z dodatków wykorzystujących javę. Choć ta ostatnia - jak sądzę - prędzej czy później w ogóle z LO zostanie usunięta, to jednakże dzisiaj praca w LO musi się odbywać np. bez możliwości skorzystania choćby z popularnego rozszerzenia LanguageTool.
Ogólnie pozytywne wrażenie psują dwie rzeczy. Stosunkowo długie dodawanie repozytoriów, ale to jest być może związane z szybkością serwerów, a być może z wielkością pobieranych plików z ich danymi, które do małych raczej nie należą (np. ok. 170MB to repozytorium KDE SDK). Pamiętajcie jednak, że to jest wrażenie osoby, która na co dzień korzysta z pacmana, a ten jest niesamowicie szybkim zarządcą pakietów w porównaniu do np. APT-a. Drugi problem, z jakim się spotkałem, to brak możliwości zainstalowania niektórych aplikacji. Dla przykładu próba instalacji obu wersji GIMP-a udostępnione w repozytorium nigthly-graphics powodują naruszenie ochrony pamięci. Tak, nie korzystanie z GIMPa, ale sama jego instalacja.
Według zapewnień twórców, jak również ze specyfikacji rozwiązania wynika, że aplikacje działają w sandboksie (piaskownicy). Takie rozwiązanie ma ponoć sprawiać, że są one odizolowane i w ten sposób bezpieczne dla systemu. Podczas polemiki między zwolennikami flatpaka a snappy właśnie ten argument był wskazywany na korzyść flatpaka, ale sam nie potrafię zweryfikować na ile nasze dane są chronione przed flatpakowymi aplikacjami.
Co ciekawe, flatpak jest zależny od systemd. Przynajmniej w wersji paczkowanej na Archa. Aczkolwiek systemd zaczyna być zdecydowanie dominującym rozwiązaniem w linuksowym świecie, to jednak nie jest jedynym. Dla przykładu, może to oznaczać, że flatpaków nie użyjemy choćby w Manjaro OpenRC. Co najciekawsze - doprawdy nie wiem po co ów systemd jest zależnością flatpaka, albowiem jego używanie nie wymaga uruchomienia żadnej usługi systemd.
Na koniec pierwsze porównanie: AppImage kontra Flatpak. Każde ma swoje dobre i złe strony. Na pewno sama instalacja aplikacji AppImage jest absolutnie prostą czynnością. Oprócz nauczenia się nadania ściągniętemu plikowi atrybutu wykonalności (ale to można zrobić nawet we wszystkich menedżerach plików w sposób "klikalny") nie wymaga żadnych innych czynności. Gorzej z aktualizacją takiej paczki, albowiem jeśli deweloperzy sami nie umieszczą w niej jakiegoś mechanizmu aktualizacji, to obowiązek ten spadnie na użytkownika. Tu znaczną przewagę ma flatpak. Podobnie jest z lokalizacją programów. W znakomitej większości w przypadku flatpaka jest ona organizowana na poziomie repozytorium, a lokalizacja odbywa się automatycznie przy instalacji. Pomimo zalet flatpaka, jedynym chyba czynnikiem, jaki obecnie niektórym użytkownikom może utrudniać korzystanie z tego rozwiązania, jest nieco niezbyt komfortowa (jak na XXI wiek) obsługa.