Paczki Snaps łączą i dzielą

31 komentarzy

• Comments 31
• Pingbacks 0

1. Pod jakim względem appimage wydaje się wygranym?

2. Tylko, że z takich tabelek bez liczb nic nie wynika. Tylko tyle, że użytkownicy tych systemów zainstalowali chociaż kilka razy aplikacje.
   Też nie wydaje mi się by appimage był wygrany pod jakimkolwiek względem.

3. Snapa jednak ludzie używają, nawet o tym nie wiedząc. A nie znam nikogo, kto używa AppImage

4. To już znasz 🙂 AppImage jest cholernie wygodny, jeśli np. potrzebujesz zrobić coś jednorazowo na jakiejś apce. Ściągasz, uruchamiasz, kasujesz plik.
   Ja natomiast w ogóle nie znam nikogo, kto używałby snap 🙂 Każdy ma inne doświadczenia, każdy inne preferencje.

5. Niektóre paczki się aktualizują, ale jakie to ma znaczenie? Jest nowsza wersja – pobrać plik, uruchomić w miejsce poprzedniego. No, kurcze, nie róbmy z ludzi większych debili niż są. Podobnie jak ze “wspieraniem” tych paczek przez distro. No cud miód. Jeśli ktoś nie potrafi sobie znaleźć czegoś, to niech siedzi na tym co wybrał. Serio. Jego lenistwo nie powinno być wyznacznikiem absolutnie niczego. Inaczej dochodzimy do społeczeństwa, którego jedyną cechą i jedynym wkładem w rozwój będzie totalna bezmyślność.
   Jeśli jednak już przy “wspieraniu” AppImage, to np. każdy kto zainstaluje sobie w Plazmie Discover ma lub może mieć lub za chwilę mieć będzie mógł możliwość instalowania z tej aplikacji wszelkiego rodzaju paczek: dystrybucyjnych, flatpak, snap czy appimage.
   W sumie, to dość sporo jest paczek w AppImage. Spośród bardzo znanych to np. LibreOffice, który w dodatku ma ciekawe narzędzie do tworzenia nowych paczek w tym formacie. Sięgam po niego niekiedy, gdy chcę się dowiedzieć, czego się spodziewać mogę w nowej wersji LO. Sporo aplikacji ze “stajni” KDE/Qt również w appimage, a na githubie zaczyna być to – oprócz źródeł – chyba najpopularniejszy format.

   PS: Na Ubuntu świat się nie kończy. Równie dobrze można dać argument, że jeśli ktoś siedzi na Fedorze to mało prawdopodobne, by coś pobrał w postaci Snapa, choć jak widać z tabelki zdarzają się i tacy. Pewnie znacznie więcej użytkowników pobiera flatpak, jeśli już. Jak już ktoś tu napisał – bez liczb to absolutnie nic nie mówi. Same liczby (pobrań) też nie mówią nic. Niestety.
   PS2: Osobiście uważam, że każdy z tych uniwersalnych formatów ma coś za uszami. Najlepiej pozostać przy paczkach dystrybucyjnych. Jeśli już byłbym zmuszony do wyboru (choć u mnie to świadome “spróbowanie” czegoś) to z uwagi na wygodę i bezproblematyczność sięgnę właśnie po appimage. Ale to moje preferencje.

6. Jedno słowo: wygoda. Rozumiem, że nie w każdym słowniku to słowo występuje i zapewne nie przypadkowo siedzisz na Archu, ale już nie nazywajmy debilizmem tego, że ktoś wybiera rozwiązania z jego perspektywy prostsze czy lepsze. Ja chcę po prostu wygodnie korzystać z systemu i aplikacji na nim posadowionych. Zaraz wyskoczy ktoś i powie, że debilizmem jest kupowanie pieczywa, skoro zdrowiej – i być może taniej – jest samemu wypiekać bułki czy inne bagietki. Przecież dedykowanego sprzętu oraz składników do tego potrzebnych jest w brud obecnie, więc w czym problem? Jedną apkę można od czasu do czasu “zaktualizować” w taki sposób, ale nawet wówczas uważam to za stratę czasu (i transferu, jeśli ktoś musi liczyć każdy bit, bo nie ma teraz lub w ogól nielimitowego dostępu do neta, ale to samo poniekąd dotyczy się Flatpaków i Snapów), ale jeśli to ma być domyślny sposób aktualizacji różnych narzędzi, to ja podziękuję.

   P.S. Totalnie nie wiem co chciałeś przekazać w ostatnim fragmencie. Napisałem tylko, że dla Ubuntu to dość powszechna forma dostarczenia aplikacji graficznych i mało prawdopodobne by użytkownik tego systemu nigdy nie skorzystał ze Snap, a jest ich całkiem sporo. Więc Twój komentarz o tym, że na Ubuntu się świat nie kończy i dalej, zupełnie nie klei mi się z moim komentarzem,

7. Używam i Snap i AppImage, ale mojego distro nie ma na liście. Widać Solus wciąż w awangardzie. Do Flatpaka jakoś nie mogę się przekonać. Swego czasu pod Mintem instalacja z Flatpaków szła bardzo powoli.

8. Spokojnie, całkiem poprawnie to zrozumiałem 😉

   Natomiast – skoro już przy kondycji ludzi jako ogółu jesteśmy – po prostu tutaj również różnimy się (chyba?) w ocenie i mój przykład z pieczywem miał to zobrazować. To nie jest tak, że uważam, iż statystycznego Kowalskiego przerastają pewne czynności, czasem wręcz banalne, nawet jeśli “obiektywne” racje za nimi są dość oczywiste i poza dyskusją. Jako gatunek – to moje zdanie – nie jesteśmy przesadnie pracowici albo inaczej: szybko się przyzwyczajamy do pewnych rzeczy (zwłaszcza do tych dobrych i wygodnych), co ma wyraz w powiedzeniu, że “przyzwyczajenia są drugą naturą człowieka”. Faktycznie nie lubimy wychodzić poza swoją strefę komfortu (zwłaszcza z wiekiem), a ponieważ automatyczne aktualizacje są niewątpliwie wygodne, to nie widzę powodu, by z nich rezygnować, jeśli mam dwa porównywalne rozwiązania. Dlatego ten Kowalski – tego nie podważam – poradzi sobie z pobraniem nowszej wersji i sobie ją podmieni, bo przez wiele lat tak właśnie wyglądały update’y programów, ale skoro to rozwiązanie może mieć podane na tacy, to po co ma się wysilać? Skoro AppImage nadal w niewielkim stopniu wpisuje się w ten model aktualizacji, to w mojej opinii nie ma szans na większą popularyzację niż obecnie, tym bardziej że nie stoi za nim żadna korporacja jak za Sanp czy Flatpak. Tylko tyle.

9. “Jednorazowo” słowo klucz 😉 No chyba, że został rozwiązany problem automatycznych aktualizacji. Natomiast prawda jest tak, że znam tylko jedno dość niszowe distro, które wspiera – choć nie wiem na jakiej zasadzie – AppImage.

   Ten format ma chyba z 10 lat (wcześniej pod inną nazwą) i jak dotąd nie przebił się przesadnie do świadomości zwykłych użytkowników oraz developerów i z aplikacji, które pobierać muszę spoza repozytorium binarek, to rzadko widuję opcję w postaci AppImage (bodajże Etcher dystrybuowany jest w ten sposób z tych mi znanych).

   Edyta: jak ktoś siedzi na Ubuntu to mało prawdopodobne, by niczego nie pobrał w postaci Snapów. Bez kombinowania w ten sposób dostępne jest właśnie Spotify, PyCharm, WPS (z sensowną polonizacją) i sporo więcej.

10. Absolutną rację masz – za AppImage – nie stoi nic. Za pozostałymi się biją. Nt. “rozwiązanie na tacy” nie będę rozwijać tematu. Po prostu uważam, że korzystanie z szarych komórek jeszcze nikomu nie zaszkodziło.
    Wracając do snap vs. flatpak vs. appimage – moje zdanie jest proste: żaden z nich. Najgorzej wspominam pracę ze snap. Z flatpak – może być. Appimage – do poszczególnych zastosowań, jak wcześniej wspomniałem. Przynajmniej mi do tego służy. Istotą jest jednak paczka dystrybucyjna. To, że niektóre dystrybucje kompletnie są oderwane od rzeczywistości, to zupełnie inna rzecz. Nie trzeba ich wybierać.
    Niemniej jednak – niestety – zmierzamy powoli w stronę flatpako-snapowo-appimagowego formatu paczek. Szkoda.

11. Wielka szkoda, że Snap jeszcze nie umarł — powinien umrzeć jak najszybciej. Nie jest open source i jest zarządzany przez jedną firmę komercyjną, w scentralizowany sposób. Podczas gdy wysiłki społeczności idą we Flatpak, Canonical jak zwykle przeszkadza swoimi pomysłami. Oby jak najszybciej to umarło, albo pozostało tylko na serwerach (do których snap jest przeznaczony.

    AppImage nie jest konkurentem dla Snapów i Flatpaków, bo to inna kategoria — to format, który nie wymaga instalacji, jest po prostu oddzielną formą.

    Ja sam osobiście nie używam żadnego z powyższych formatów, bo preferuję natywne pakiety mojego systemu. Jestem natomiast w stanie w pełni zrozumieć potrzebę takich formatów i w pełni im kibicuję! AppImage daje przenośność (dosłowną: appka w jednym pliku). Flatpak daje uniwersalność (jeden format na każde distro), niezależność od libek systemowych oraz piaskownicę (appka odpala się w oddzielnym środowisku, co jest bezpieczniejsze). Snap za to nie daje za wiele, prócz kalkulatora odpalającego się w Ubuntu 2 minuty. 🙂

12. Wziąłeś do siebie coś, co absolutnie nie pod Twoim kątem padło. Jeśli przez przypadek (a kompletnie niezamierzony) tak to odczytałeś – to przepraszam najmocniej. Ot, ogólna refleksja nt. obecnej kondycji intelektualnej społeczeństwa.

13. Zdarzyło mi się okazjonalnie korzystać z każdego z wymienionych formatów paczek uniwersalnych pod Ubuntu i moje przemyślenia są takie:
    1. Snap – jestem uprzedzony po wcześniejszych doświadczeniach i staram się unikać, jak tylko mogę. Widzę to jedynie jako użyteczny model dystrybucji komercyjnego płatnego oprogramowania i w takiej postaci jestem w stanie to przetrawić. Na plus: chyba lepsza integracja z Ubuntu niż Flatpak i chyba żwawszy niż Flatpak (nie robiłem bezpośrednich porównań).
    2. AppImage – świetny jako swojego rodzaju demo programu do przetestowania i pomocy przy podjęciu decyzji czy instalować w normalny sposób.
    3. Flatpak – jak dla mnie to dostarczanie do Linuksa wrażeń zgoła windowsowych. Integruje się z systemem, ale w niepełny sposób, wyraźnie wolny przy uruchamianiu, nieraz gigantyczna objętość (Okular to 1,5 GB), mam poczucie, że jest ciałem obcym w systemie. Używam tylko do programów z KDE, żeby nie dociągać połowy KDE do Gnome (tak, wiem, że przy kilku programach będę miał biblioteki z KDE radośnie zwielokrotnione, ale łatwiej zniosę to marnotrawstwo niż miksowanie bibliotek z różnych środowisk – takie moje natręctwo).

    Ogólnie jak dla mnie uniwersalne paczki to odpowiedź na realne potrzeby i wypełnienie jakichś nisz, ale na pewno nie równoprawny sposób na instalowanie oprogramowania pod Linuksem. Na dodatek nie są “uniwersalne” w tym sensie, że każdy ich rodzaj służy do czegoś innego więc nie zastępują się wzajemnie. Czyli zamiast uniwersalności jest jeszcze większe rozdrobnienie. W rezultacie realizacja przeciwna do zakładanego celu.

14. Jeśli chodzi o AppImage, to dodałbym, że to świetny sposób na testowanie wydań beta, czy kandydujących i włączenie się w testy takiego oprogramowania. Ot, choćby teraz jest dostępna w ten sposób Krita 4.2.7.
    Pomysł na ominięcie przez flatpak, a zwłaszcza snap dociągania “połowy KDE” (czy GNOME) w przypadku instalacji oprogramowania stworzonego na innym toolkicie niż stosowany w naszym systemie jest złudny. Każde oprogramowanie musi mieć swoje zależności i niezależnie od tego, czy to program z repo, czy flatpak, czy snap, te zależności dociągnie. Stąd Okular musi np. dociągnąć znaczną część KDE Frameworks 5 (wymaga paczek z Tier 4, a te wymagają z wcześniejszych) oraz Qt5 i w ten sposób jego rozmiar rośnie. Pół biedy, jeśli te zależności potrafią być wykorzystane również przez inne programy (tak jest na pewno w przypadku flatpak i tak nie było, bo nie wiem jak obecnie, w przypadku snap). W przypadku flatpak zatem instalacja kolejnego programu z KDE (czy z GNOME, czy z czegokolwiek) nie spowoduje ponownego dociągnięcia tych samych bibliotek, a jedynie ewentualnie nowych, które nie są wykorzystywane przez zainstalowany już program. Nic tu nie będzie “zwielokrotnione”. Te nowe natomiast potrafią wykorzystać już znajdujące się w “systemie flatpaka”. Jeśli zatem masz Okulara i dociągniesz np. Gwenview, to ten ostatni znajdzie już zainstalowane w systemie np. kactivities czy purpose (wraz z ich zależnościami), ale dociągnie np. baloo czy libkipi (i ich zależności), bo te nie zostały zainstalowane przy okazji instalacji Okulara.
    W istocie gorzej jestj, gdy każdy program ciągnie te zależności oddzielnie (tak są budowane paczki AppImage i tak niegdyś przynajmniej było w przypadku snap). Tyle, że w przypadku AppImage tego po prostu nie widać, bo cały program wraz z wszystkimi niezbędnymi zależnościami jest w jednym pliku.

15. Dzięki za wyprostowanie moich nieścisłości. W każdym razie wnioski podtrzymuję.

16. Mam jak najbardziej podobne doświadczenia, przy czym jeszcze:
    – snap okazał się w moim przypadku najbardziej problematyczny i bezużyteczny; instalacja się udała, ale pobranie już jakichś aplikacji – nie; pomijając zatem dodatkowe jeszcze aspekty jak scentralizowany sposób dystrybucji, możliwość instalacji aplikacji bez mojej zgody (nie wiem, czy to wprowadzili już, czy jeszcze nie), raczej nigdy po niego nie sięgnę,
    – appimage – tu miewałem problemy z niektórymi aplikacjami z uwagi na sposób “pakowania” w tym formacie; otóż niektóre elementy są tu zakładane jako istniejące w systemie (tym systemem był jeszcze z końcem ub.r. bodaj Ubuntu 14.04 albo 16.04 – mniejsza o to, mam sporo nowszy) i kompilacja do paczki odbywa się właśnie na takim systemie, z takimi bibliotekami; zdarza się, że z nowszymi bibliotekami już nie działa aplikacja, a nie bardzo mi się chce robić nieporządek w systemie,
    – flatpak – w sumie dość bezproblemowe, ale zasadniczy problem to niewielka ilość aplikacji, głównie ze stajni GNOME (co dla mnie jest pewną zaletą zresztą).
    Wobec powyższego – appimage, jak wspomniałem wyżej – używam do jednorazowych czynności, do przetestowania nowszych wersji aplikacji, także testowych. by ewentualnie włączyć się w program doszlifowania ich. Pozostałych nie używam. Dość, że w ogóle jako flatpak miałem zainstalowane bodaj 3-4 aplikacje, w tym jedną tylko po to, by sprawdzić coś w celu udzielenia odpowiedzi na forum.

17. Snapy to zaprzeczenie konteneryzacji aplikacji. Są paczki, które wymagają innych paczek, czyli mają zależności. Do tego menadżer snapów nie pilnuje tych zależności. Można wywalić zależną paczkę i aplikacja nie wstanie. Nie widzę sensu instalowania czegoś takiego, skoro zajmuje więcej miejsca niż deby i ma zależności. W appImage instaluje jeden plik i mam wszystko, bez zależności. Podobnie w Flatpaku.

18. To nie jest do końca tak. W appimage zależności, które nie są uznawane za te, które w systemie (i niestety w określonych wersjach) muszą być, są pakowane w paczkę *.appimage. W przypadku flatpaka instaluje on zależności również z flatpaka. Inaczej nie miałoby to prawa działać.

19. o proszę, czyli flatpak też jest tak samo ch*jowy jak snapy

20. Dlaczego, bo instalują się wraz z paczką zależności programu? No jeśli to masz na myśli, to kurcze imponujące.

21. Kontenery powstały po to aby w nich było wszystko co jest potrzebne do uruchomienia aplikacji. Jeśli Snap i Flatpak mają zależności do tego więcej zajmują miejsca niż deby nie widzę sensu używania takiego wynalazku. Deby z czymś takim wygrywają, bo mając zależności zajmują mniej miejsca. Do tego mają menedżera pakietów który pilnuje zależności. Czego nie ma w Snapach co już w ogóle jest absurdem. Nie wiem jak jest w Flatpakach.

22. Flatpak zależności pilnuje w ten sposób, że wszystko jest tworzone na określonych bibliotekach, w jego repozytoriach dostępnych. Czy coś więcej – nie wiem.
    Nie tylko deb, ale każda “normalna” paczka wygrywa z tymi uniwersalnymi. Problem w tym, że dla takiego Debiana Stable, czy Ubuntu LTS, czy RHEL ciężko jest zrobić paczkę z nowszym oprogramowaniem, albowiem często zdarza się, że nie buduje się na tych bibliotekach, które są w tych dystrybucjach dostępne. Stąd użytkownicy tego typu dystrybucji byli pozbawiani dostępu do oprogramowania, które oferuje jakąś inną funkcjonalność. M.in. stąd pomysł na uniwersalne, choć to nie jedyne wytłumaczenie. W Archu nie mam z tym problemów, ale i tak z AppImage niekiedy korzystam. Dla tych celów, o których już wspominałem. Snapa uważam za najgorszy z możłiwych formatów uniwersalnych, o którym jak najwcześniej należałoby zapomnieć, bo to jest absolutnie krok w ślepą uliczkę. Flatpak – od biedy może być. Tylko paczek brak 🙂 A miało być tak ładnie i dzięki uniwersalnym wszyscy mieli się na to rzucić 🙂

23. Jeśli w oficjalnych repo nie ma nowszych wersji co jest z resztą nagminne, to zawsze można użyć oficjalnego repo w postaci ppa czy coś podobnego. Dużo oprogramowania tak robi. Snapy instaluje tylko wtedy gdy nie ciągną za sobą zależności lub gdy potrzebuje uruchomić jakiś stary program który nie jest wspierany dla nowych bibliotek. Takim przykładem jest menedżer połączeń SSH PAC.
    Widzę że niektórzy komercyjni producenci poszli właśnie w Snapy, na przykład ostatnio instalowałem IntelliJ Idea. Nie ma zależności więc jest ok.

24. PPA niekoniecznie jest oficjalne. W 99,9% nie. Nadto… PPA to tylko świat Ubuntu, a na nim się linux ani nie kończy, ani nie zaczyna.

25. zacytuje siebie “ppa czy coś podobnego”. wiele z rozwijanych programów ma swoje oficjalne repo. jak na przykład Midnight Commander. Wiele programów ma właśnie w PPA dla Ubuntu swoje oficjalne kanały dystrybucji. Więc nie koniecznie trzeba polegać na tym co jest w oficjalnych repo. Zawsze jest jakieś wyjście sytuacji w pakietach. Snapy czy Flaki to już ostateczność.

26. Ale mówisz o PPA, a to jest wyłącznie Ubuntu, na którym świat się nie kończy. Znajdź mi PPA dla openSUSE choćby.

27. Dlatego za przykład dałem MC które ma różne repo.

28. Akurat mc to dość – chyba – niedobry przyklad, albowiem to się da budować praktycznie na czymkolwiek. Problem zaczyna się wówczas, gdy mamy do czynienia ze skomplikowaną aplikacją GUI, która ma zależności uniemożliwiające koegzystencję nowej paczki z bibliotekami, które są w danym wydaniu, jakiejś dystrybucji.

29. Ja o jednym, ty i drugim. Piszemy o paczkach binarnych a nie o budowaniu.
    O tym co piszesz pisałem już wcześniej. Jedyny powód instalacji takiego snapa jest oprogramowanie używające starych bibliotek. Ale nie chce mi się pisać po raz setny tego samego.

30. Taaa… zauważ jednakże, że taka paczka binarna nie bierze się znikąd i musi zostać jakoś zbudowana. Jeśli w danej dystrybucji nie ma zależności w minimalnej wersji, to PPA tu nic nie pomoże. Może być i tak jak piszesz – biblioteki będą zbyt świeże, by zbudować coś. Sam pomysł uniwestalnych paczek nie jest taki zły.

31. “Flatpak – od biedy może być. Tylko paczek brak 🙂 A miało być tak ładnie i dzięki uniwersalnym wszyscy mieli się na to rzucić :)”
    To już się dzieje. Dla projektu Fedora Silverblue flatpaki to podstawowy sposób instalowania oprogramowania. Wygląda na to, że taka będzie przyszłość linuksowego desktopu.

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.