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.
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.
Komentarze
Prześlij komentarz