Przejdź do głównej zawartości

AppImage, Snappy, Flatpak - Cz. 4 - Refleksja końcowa

Udało mi się zapoznać z 3 rodzajami "bundli". W zasadzie czterema, albowiem z jeszcze jednym w czasach, gdy używałem Chakry. Tam wówczas, bo już obecnie tak nie jest, aplikacje Gtk były umieszczane również w swoich "kontenerach" - rozwiązanie zbliżone do omawianych. Pozostałe, wprawdzie istniejące, jakoś nie ściągnęły mej uwagi po próbie przeszukania dostępnych aplikacji. Na placu boju pozostały zatem: appimage, flatpak i snappy.
Każde rozwiązanie ma pewnie swoje zalety i wady - pora na bardzo subiektywną refleksję.
Spośród tych trzech, na pewno nie będę używał snappy. Nie dość, że skomplikowane, używające bez sensu systemd (tzn. wiem do czego go używa, ale nie znajduję wytłumaczenia na to po co go używa), to przede wszystkim kompletnie nieużyteczne. Być może w jakimś systemie, być może osobie bardziej zdeterminowanej ode mnie w próbie uruchomienia tu czegokolwiek, uda się coś uruchomić. Mi się nie udało. Biorąc pod uwagę moją wiedzę jako użytkownika systemów linuksowych od wielu lat, to raczej trudno uważać ów produkt jako user-friendly. Do tego dochodzi już wątpliwa reputacja w zakresie bezpieczeństwa. Odinstalowanie snapd (tzn. całego systemu zarządzania tymże) to również katorga.
Pozostają zatem dwa rozwiązania: appimage i flatpak. W pierwszym przypadku mam wątpliwości co do bezpieczeństwa tego rozwiązania. Niemniej jednak sam pomysł wydaje się być sensowny. Niczego nie muszę instalować, ściągam aplikację w jednym pliku, zmieniam atrybut na wykonywalny i powinno działać. Otóż istotą jest owe słowo "powinno". Jak wynika z mojego wpisu poświęconego temu typowi paczkowania - nie zawsze się to udaje. Być może nie przetestowałem większości dostępnych appimage (na pewno nie), ale udało mi się to zrobić z jakąś 1/6-1/7 aplikacji (nie jest ich wiele). Około połowa odmówiła współpracy, w tym wszystkie oparte o chromium. Ciekawe. To rozwiązanie ma też jedną wadę - w żaden sposób nie zmienimy aplikacji poprzez użycie dodatków, spolszczeń itp. Dodatki zadziałały tylko w przypadku Firefoksa, ale spolszczenie już nie. Nie mam pojęcia dlaczego, wszak jedne i drugie to pliki xpi. Na pewno też nie ma możliwości spolszczenia takich aplikacji jak np. LibreOffice, które wymagają "podmiany" plików dla uzyskania lokalizacji.
Wydaje się zatem, że najsensowniejszym rozwiązaniem jest flatpak. Jeśli uda się mu uzyskać pewną łatwość obsługi, a taką przyniosą zapewnie narzędzia GUI, które dla niego powstaną, to pomysł wydaje się być sensowny. Był też najmniej kłopotliwy.
Pozostaje jeszcze kwestia rozmiaru aplikacji i duplikacji bibliotek zawartych w poszczególnych paczkach. Pierwsze - ma znaczenie w przypadku małych dysków. Nie jest to jednak jakaś wielka różnica. Niemal wszystkie paczki (z wyjątkiem snappy) miały rozmiar zbliżony do paczek zawartych w repozytoriach. Problem zaczyna się, jeśli zainstalujemy sobie więcej aplikacji, które korzystają, bądź mogą korzystać z tych samych komponentów. Tu w istocie dysk się szybko zapełnia. Niestety jak na razie nikt nie znalazł pomysłu na ograniczenie duplikowania się paczek w systemie. Co ciekawe, kilka lat temu właśnie problem z tym związany spowodował przyjęcie innego rozwiązania w Chakrze (nie ma sensu tu wskazywać jak go rozwiązano).
Ogólny wniosek dla mnie jest taki: nie używać żadnego z tych rozwiązań, dopóki na pewno się nie musi. Nie ma to sensu. Zaczyna on istnieć wyłącznie wówczas, gdy jakąś aplikację mogę zainstalować wyłącznie z appimage lub flatpaka (snappy - z powyżej przytoczonych względów odrzucam). Żadne z tych rozwiązań nie należy również rozpatrywać jako jakiekolwiek panaceum na "bolączki" obecnej koegzystencji wielu różnych systemów paczkowania i zarządzania paczkami w linuksie. Niby niosą one uniwersalność rozwiązań, ale same również rodzą nowe problemy. Pomijam już aspekt ekonomiczny, albowiem aplikacje rozprowadzane w tych formatach są mocno przerośnięte. Największe paczki otrzymujemy w snappy - tu ich rozmiar zaczyna być olbrzymi (co z tego, że libreoffice udało się spaczkować do blisko 290MB, skoro nie zawiera on wszystkiego, co jest potrzebne do użytkowania tego pakietu, a nie ma moliwości doinstalowania do tego niczego).
Innymi słowy - dziękuję bardzo, pozostanę przy pacmanie.

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…