Przejdź do głównej zawartości

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.

Popularne posty z tego bloga

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy: [DEB_Arch_Extra]SigLevel = Optional TrustAllServer = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/ Nadto musimy jeszcze dodać klucz: gpg --receive-keys BF…

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. …

Co naprawdę oznacza, że pacman (Arch) nie wspiera częściowej aktualizacji

Pośród osób pracujących na Arch Linux jak mantra powtarzane jest twierdzenie: pacman (Arch) nie wspiera częściowej aktualizacji. Co w istocie to oznacza? Jakie są najczęściej popełniane błędy?

1. Synchronizacja repozytoriów dla zabawy
Zdarzyło się Wam wydać polecenie pacman -Sy bądź pacman -Syy, a za jakiś czas instalować program poprzez pacman -S? Jeśli nie, to jak dowodzą świadectwa innych użytkowników tu i ówdzie rozsiane po internecie praktyka ta wcale nie jest tak rzadka. Zobaczmy zatem co się dzieje w takich przypadkach i do czego to prowadzi.
Pierwsze polecenie dokona synchronizacji informacji o dostępnych paczkach (w tym ich wersjach) w repozytoriach z informacjami lokalnie przechowywanymi w bazie pacmana. Nie jest dokonywana żadna aktualizacja systemu. Następne polecenie oczywiście zainstaluje paczkę. Paczkę w takiej wersji, jaka jest w danym momencie w repozytorium.
Zwróćmy teraz uwagę na to w jaki sposób budowane są paczki w repozytoriach Archa oraz jakie informacje przekaz…