Snap, Flatpak, AppImage i co z tego dziś mamy
Pamiętacie mroczne czasy pod peleryną opiekunów pakietów, którzy mogli wykazać się raz na rok – dwa lata i zaktualizować jakiś program? Pamiętacie przełom jaki dokonał się z pojawieniem się Arch Linuksa, repozytoriów PPA Ubuntu? Owszem, wprowadziło to wszystko pewną dozę bałaganu, ale jeżeli ktoś się orientował co i jak może popsuć zależności, dawał sobie radę. Niemniej, ogół społeczności oczekiwał rozwiązań które wprowadzą łatwość uruchamiania najnowszego oprogramowania ot tak po prostu, bez czekania na opiekuna pakietów lub PPA. W świecie OpenSource nie ma rzeczy niemożliwych. Szkoda tylko, że na wskutek tego stworzono od razu trzy różne „uniwersalne” formaty.
Założenia „uniwersalnych” formatów są takie, że każdy deweloper powinien w prosty sposób przygotować taką paczkę (vide .exe dla Windowsa) i udostępnić ją gdziekolwiek. Użytkownik końcowy powinien do takiej paczki mieć dostęp niemal natychmiastowy w dniu premiery nowej wersji programu. Co więcej, uruchomienie powinno nastąpić po nieskomplikowanych czynnościach, jak np. dwuklik. Czy coś z tych wzniosłych ideałów zostało przemycone do naszej rzeczywistości? No cóż, gdzie kucharek sześć w trzech osobach, tam nie ma co jeść.
Bowiem miało być pięknie, a wszystko jak zawsze. Są trzy formaty z których da się korzystać pod warunkiem… Spełnienia zależności i zainstalowania odpowiedniego menedżera wspomnianych paczek (nie uprzedzając faktów). Czyli powstały kolejne repozytoria gdzie te paczki mogą wylądować oraz kolejne menedżery pakietów, które potrafią je zainstalować. I czy nam przez to jest łatwiej? Czy łatwiej jest twórcom programów? Powiem tak – trzeba mieć ogromne pokłady wiary, aby obecne rozwiązania uznać za zbawienie.
| Snap | Flatpak | AppImage | |
|---|---|---|---|
| Snap | Flatpak | AppImage | |
| Używalne bez dodatkowego oprogramowania | nie | nie | tak |
| Centralne repozytorium | tak | tak | nie |
| Automatyczne aktualizacje | tak | tak | nie |
| Niezależność | nie (Canonical) | nie (Red Hat) | tak (Społeczność) |
| Bezpieczeństwo i piaskownica | tak (tylko AppArmor) | tak (tylko Bubblewrap) | tak (AppArmor, FireJail, Bubblewrap) |
| Uruchamianie bez piaskownicy | nie | nie | tak |
| Współdzielenie bibliotek | podstawowe | pełne | nie |
| Integracja tematyczna z systemem | nie | nie | tak |
Zatem reasumując. Twórcy nadal muszę przechodzić nieżyciowe procedury (vide opis jak stworzyć i zgłosić coś do repozytorium Flatpak). Użytkownik nadal musi organizować odpowiednie oprogramowanie (Menedżer pakietów) które obsłuży mu uniwersalne formaty. Jeżeli nawet skupimy się na AppImage które jest najmniej uciążliwe, to wyobraźcie sobie bałagan w systemie za pół roku. Bo AppImage się nie zaktualizują automatycznie i wszystko trzeba robić ręcznie.
Na dzień dzisiejszy w zbiorczym AppImageHub znajduje się 276 paczek. W przypadku uAppExplorer dla paczek Snap jest ich tam 1343 sztuk. Flashub udostępnia zaś około 200 paczek Flatpak.
Co wybrać? Najrozsądniej jest polegać na własnych potrzebach i na własnym głosie rozsądku. Jakkolwiek powyższe paczki rozwiązują w pewnym stopniu problem „przenoszenia” programów pomiędzy dystrybucjami bez konieczności rekompilacji, to w ostatecznym rozrachunku są dość niewygodne w użyciu. Duża objętość, mizerna integracja z systemem a w niektórych przypadkach brak automatycznej aktualizacji. Dla twórców oprogramowania jest to jakieś rozwiązanie – jeżeli uda im się przebrnąć przez niuanse tworzenia takich paczek (Github wydatnie w tym pomaga), to za jednym ruchem i za jedną paczką mają ogarnięte niemal wszystkie dystrybucje. Gra jest zatem warta świeczki. A nam pozostaje traktować powyższe jako doraźną formę szybkiego dostępu do najświeższego oprogramowania. A potem pozostaje spokojnie zaczekać, aż zostanie przygotowana standardowa paczka do standardowych repozytoriów.
36 komentarzy
-
Pingback: Snaps łączą i dzielą | przystajnik
Dodaj komentarz
Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.
Nie bardzo wiem, co chciałeś przez tę tabelkę przekazać w niektórych miejscach, ale:
1. Flatpak wprawdzie w istocie ma “centralne repozytorium”, jednakże nie istnieje bezwzględny wymóg rozpowszechniania tego paczek przez nie. Istnieją zarówno inne repozytoria (oprócz owego “centralnego”), jak i niektóre paczki rozpowszechniane są bezpośrednio przez deweloperów programów, a nawet przez niezależne podmioty, które takie paczki przygotowują nawet bez udziału twórców danego oprogramowania.
2. AppImage natomiast ma coś na kształt repozytorium (składnicy tych paczek). Tu istnieje jednak większa dowolność w ich udostępnianiu.
3. Flatpak, choć jego podwaliny w istocie są związane z RedHatem, a w zasadzie z jednym z jego deweloperów, to obecnie jest rozwijany przez zespół osób nie tylko związanych z RedHatem.
4. Współdzielenie bibliotek – przynajmniej w przypadku flatpak – występuje jedynie wobec bibliotek (runtime) dostarczonych w ramach tej platformy. Paczki te nie korzystają z bibliotek (nawet w tych samych wersjach) zainstalowanych już w systemie. Z tego typu bibliotek mogą – i często to mimo wszystko robią – korzystać paczki AppImage.
Niemniej jednak, zasadniczą bolączką wszystkich tych paczek jest to, że… żadna z nich nie jest uniwersalna. W przypadku snapów nie da się ich pogodzić z systemami, które nie stosują systemd, a nawet i tu są z tym problemy. W przypadku flatpak jak dotychczas nie da się tego zrobić, choć są prowadzone prace by udało się to zrobić bodaj w systemach z OpenRC. AppImage natomiast miewa dwojakiego rodzaju problemy. Działa dobrze jedynie w przypadku uruchomienia go na zbliżonym systemie do tego, na którym został zbudowany oraz jedynie wówczas, gdy przy jego budowie nie założono, że w systemie będzie znajdowało się określone oprogramowanie, które jest konieczne do jego uruchomienia i to niekiedy w określonej wersji. Duża część dostępnych paczek AppImage nie jest też budowana bezpośrednio ze źródeł, a jest wynikiem przebudowania do tego formatu paczek deb, czy – rzadziej – rpm. Tego typu paczki praktycznie nie różnią się zatem od paczek przebudowanych takimi programami jak np. alien, czy z użyciem PKGBUILDów itp. Tego typu oprogramowanie również może, ale nie musi działać na docelowych systemach.
Próbowałem w taki sposób skorzystać z oKulara pod Ubuntu 16.04. Chodziło o uniknięcie instalowania wszystkich zależności z KDE, ale w sumie miałem pretekst do wypróbowania takiego sposobu instalowania programów. Snap zainstalował się, ale już nie chciał się uruchomić (problem znany, ale bez rozwiązania, co przyznawał wówczas deweloper Canonicala, zresztą Polak), a niedługo później okazało się, że popsuł drukowanie (konieczne było ponowne zainstalowanie CUPS). Natomiast appimage oKulara nie uruchamia się bo ma niespełnione zależności. Błąd na githubie zgłoszony ponad rok temu i nic się w sprawie nie dzieje. Z pozytywnych podejść: appimage Krity działa, chociaż nie integruje się z systemem.
W rezultacie nie widzę żadnych korzyści z tych uniwersalnych formatów. Pozostają PPA, a jak trzeba, to zawsze można samemu zbudować paczkę ze źródeł i zainstalować lokalnie. Robię tak w przypadku kilku programów, które nie mają pacze kpod Ubuntu (przynajmniej w nowych wersjach), tzn. buduję deb-a na jednym komputerze, a później mam plik instalacyjny do wykorzystania również na innych komputerach. Finalnie dużo prostsze i mniej uciążliwe.
Następne podejście do snapa mam zamiar zrobić za 5 lat. Może do tego czasu będzie używalny.
Znając Canonical to za 5 lat nie będzie snapa
Zmartwiłbym się tylko wówczas, gdyby miał się stać obowiązkowy. Podobno były takie plany. Mam nadzieję, że to nieaktualne.
Z okularem appimage, to raczej nie “błąd zgłoszony i nic się nie dzieje”, a sam twórca tej paczki ma problemy i nie potrafi ich rozwiązać. Nic zresztą dziwnego, bowiem jeśli chodzi Ci o stronę appimage-packages na githubie, to zaglądnij na: https://github.com/appimage-packages i przeczytaj opis 🙂
W innych miejscach, gdzie appimage bywają – okulara nie ma, a zatem po prostu należy uznać, że paczka taka nie została przygotowana.
To, czego brakuje, to poppler-qt5. Normalnie powiedziałbym: zainstaluj poppler-qt5 (z repo) i powinno pójść, jednakże nie jestem pewny, czy debianowate (“stable”) mają wystarczającą wersję popplera, by zadowolić okular (kiedyś to był koszmar: w Debianie dwadzieścia kilka wersji do tyłu). Jeśli to tylko ten problem – może warto spróbować. Z drugiej strony – okular appimage jest ze stycznia 2017 r. To już dawno niewspierana wersja.
Sam okular ma dość “wysoko” postawione zależności jeśli chodzi o KF5, a zatem czy to ściągniesz w formie appimage, czy doinstalujesz – jeden pies (chyba, że ktoś źle zbudował zależności dla niego).
Dziękuję, komentarz jak zwykle nadzwyczaj merytoryczny. Miałem na myśli mniej więcej to, co napisałeś, tylko byłem nieprecyzyjny. Nawiązywałem dokładnie do tego miejsca na githubie, gdzie autor sam zgłosił problem.
Zdaję sobie sprawę, że prostsze byłoby zainstalowanie okulara wprost z repozytorium i nie ma wielkiego znaczenia, gdzie tafią biblioteki z zależnościami – i tak nie da się uniknąć ich ściągnięcia. Instalowałem poprzez snap, żeby zobaczyć, co to za zjawisko i czy da się z tego normalnie korzystać i przekonałem się, że na razie nie bardzo.
Ogólnie, moją myślą przewodnią było to, że uniwersalne paczki jedynie dokładają problemów do już istniejących. Może tylko możliwość sandboxowania wnosi coś nowego, ale dla prywatnego użytkownika ma to niewielkie znaczenie.
“moją myślą przewodnią było to, że uniwersalne paczki jedynie dokładają problemów do już istniejących.”
Absolutna zgoda. Od długiego czasu im się przyglądam. W sumie, to chyba jedynie dobrze zrobiony appimage mógłby uchodzić za “uniwersalny” format. Podkreślam: dobrze zrobiony. I niestety – w tym przypadku, to dla twórców aplikacji chyba więcej kłopotów niż zrobienie jakichś 2-3 podstawowych paczek w “normalnych” formatach. Mógły takim formatem (bo ma zalety) być flatpak, gdyby nie przywiązanie do systemd. Po co? Absolutnie nie wiem. Snap jest natomiast kompletnym nieporozumieniem i mam nadzieję, że szybko odejdzie w niepamięć. Jedynie użytkownicy, bloggerzy itp. mogą podgrzewać niezdrową atmosferę nt. snapa.
Jeśli jednak jest ktoś, kto czyta te słowa i jest mi w stanie przedstawić merytoryczne uzasadnienie nie tylko jego istnienia, ale także uznawania go za “uniwersalny” format paczek, to z wielką przyjemnością przeczytam. Niestety – jak do tej pory – nie zauważam praktycznie jednej pozytywnej cechy tego formatu. Sama możliwość “zdalnej” aktualizacji w żaden sposób nie jest dla mnie cechą pozytywną. Raczej oceniam ją negatywnie.
Co wybierają moi dystrybutorzy softu?
– KSP – spakowane binarki w ZIP
– gcc-arm-none-eabi – spakowane binarki ze strony ARM
– Arduino – spakowane binarki
– Godot 3 – spakowana binarka bez żadnych dodatkowych plików
– Cura 3 – AppImage
– Chrome – deb/rpm (dodaje własne repozytorium w celu aktualizacji)
– Visual Studio Code – deb/rpm (dodaje własne repozytorium w celu aktualizacji)
Używam też kilku modułów Pythona instalowanych przez Pip3 (także binarnych).
Wszystko działa bez żadnych problemów na XUbuntu.
Zalety snapa?
Mozliwosc snapowania aplikacji systemowych.
Sandbox apparmora.
Narzekanie
na systemd brzmi dziwnie. Rownie dobrze moznaby narzekac ze nie dziala
na bsd. Systemy non-systemd to nisza z ktorej korzysta moze z 1%
userbase.
Chyba wielkiej tajemnicy nie ma, dlaczego Canonical lansuje u siebie to całe snapy. Chodzi jak rozumiem o oprogramowanie komercyjne z zamkniętym kodem, które będzie można rozprowadzać przez sklep. Wówczas pięknie się wszystko zgrywa: połączenie wygody związanej z centralnym punktem dystrybucji i automatycznych aktualizacji z ochroną przed piractwem . To w zasadzie, z komercyjnego punktu widzenia Canonical, autorów oprogramowania i pewnie części użytkowników, byłoby lepsze niż cokolwiek, co jest dostępne na pecetach (windows i macos), coś jak odpowiednik androida i ios.
Akurat dla mnie to żadna zaleta, bo prywatnie jestem w stanie obyć się bez komercyjnego oprogramowania (Ubuntu cały czas zaliczam do niekomercyjnego). Na komputerze, z którego teraz piszę nawet UEFI mam otwartoźródłowe (coreboot). Ale rozumiem, że ludzie mają różne potrzeby i takie połączenie komercyjnego z otwartoźródłowym mogłoby dawać prawdziwy wybór. Rzeczywista możliwość zrealizowania powyższego to oczywiście inna sprawa.
Nie narzekam, a jedynie twierdzę, że uzależnianie możliwości korzystania z aplikacji od systemu initów, od którego nie jest ta aplikacja zależna przekreśla uniwersalność takiego formatu jako “uniwersalnego”. Z Twojego punktu widzenia być może i systemy “non-systemd” to nisza, ale wcale nie taka mała.
Jeśli Ci się chce – znów z chęcią przeczytam konkretne informacje nt. zasadności wiązania systemu paczek z initami oraz wykaż proszę, że “może 1%” linuksów nie korzysta z systemd.
Ktore distro wspiera inne inity?
Gentoo, Slackware, Devuan, Artix, Void…? Moze z 1% sie z tego uzbiera.
Zasadnosc wiazania paczek z jedynym slusznym initem jest take ze oszczedza zasoby w porownaniu do wspierania wszystkiego co ktos sobie wymysli. Wsparcie dla innego initu raczej nie zmiesci sie w pierwszej setce rzeczy ktore warto by zrobic.
A także RHEL, starsze wersje Debiana, czy *buntu i wiele innych. Nie ma to znaczenia. Nie jest uniwersalnym jakiś format paczek, jeśli do jej zainstalowania wymaga określonych rozwiązań, których sama aplikacja nie wymaga. Zastanów się zatem gdzie, w czym tkwi powiązanie z systemd oraz czy wymaga jego sama aplikacja.
Brawo! Wyjątkowo trzeźwe spojrzenie na “uniwersalne” paczki. W tym momencie rzeczywiście brakuje w pełni wygodnego rozwiązania. Ja na razie postawiłem na Snap-a, bo działa bez problemu na 2 dystrybucjach z których korzystam, tj. Solus i Ubuntu. Najfajniejsze w tym wszystkim są automatyczne aktualizacje.
Zadna zyjaca wersja ubuntu nie wspiera innych initow. Ostatni non-systemd debian konczy zywot w maju. Jedna wersja RHEL jest na upstarcie wydana 8(!!!) lat temu na ktorej zaden snap i tak by nie ruszyl.
Tworcy snapa definuja jego uniwersalnosc jako “Snaps are available for any Linux OS running snapd, the service that runs and manages snaps.”
Ty mozesz sobie definiowac uniwersalnosc jak chcesz i uzywac jakiego chcesz initu ale warto by wziasc na klate fakt ze dla innych nie ma to zadnego znaczenia poza ewentualnym wpolczuciem zamiast publicznie wylewac gorzkie zale w stylu “u mnie nie dziala”.
Na debiana zawsze będą najlepsze paczki deb! Olać snapa flatpaka i inne badziewia!!!
Jak dla mnie tylko AppImage: kopiuję gdzie chcę, a jeden program mogę mieć w kilku różnych wersjach bez żadnego kombinowania.
Ale przecież Appimage obsługuje moduł aktualizacji. Tylko to czy zostanie on wykorzystany zależy od developera aplikacji. I powiem szczerze, że jest ono bardzo mało problematyczne, podobne do aktualizacji znanych z Windowsa czy też z linuksowych (niebrandowanych) aplikacji jak Firefox (=–>Pomoc–>O Programie Firefox –> Sprawdź aktualizację–>Zrestartuj aby zainstalować aktualizację). Tyle, albo aż tyle. Niestety jeżeli bierzemy “nieoficjalną” paczkę w appimage to często niewiele osób zaprząta sobie głowę jej aktualizacją. Po prostu wydają nową wersję i tyle.
Jak dla mnie to Appimage jest idealnym formatem. Używam od lat i sobie chwalę. Dzięki temu mogę mieć wiele aplikacji, których nie ma w mojej dystrybucji albo są tylko w przestarzałych wersjach. Appimage rozwiązuje również spory problem dystrybucji własnościowego oprogramowania np. Voltra.
Dodatkowo spore repozyotium z aplikacjami w Appimage można znaleźć tutaj: https://bintray.com/probono/AppImages/
A ktoś wie co się stało z flathub?? Wcześniej była cała lista aplikacji z komendami do konsoli, a teraz kilka programow i nic. Zna ktoś adres na aktualną liste aplikacji dostepna na flathub?
W sumie najbardziej uniwersalnym byłby AppImage, ale korzystam z standardowych źródeł, PPA, pip pythona, snapa i że by było śmiesznie to wszystko działa dość wydajnie i nie powoduje problemów. Snap wydaje mi się dobry bo mogę dostać z niego zawsze świeże wydanie niektórych programów co jest dla mnie ważne bez ingerencji w system pakietów mogących robić bałagan w systemie 🙂
Pytanie po co?
czy dlatego,żeby mieć nowsze wersje?
jest PPA,AUR i mnóstwo innych rozwiązań…
Komu tak naprawdę zależy na tym,aby de facto przejąc kontrolę nad tym co można wsadzić do tych paczek?
W PPA jest to jeszcze jakoś pilnowane…
Teoria spiskowa?
Jest taka stara rzymska zasada:
“ten zrobił,kto skorzystał”
Co takiego i jak, jest “jakoś pilnowane” w PPA?
Możesz zaklinać rzeczyistość jak chcesz i przypisywać komuś słowa, których nie wypowiedział oraz współczuć mu w czymś czego nie doświadcza, ale zejdź na ziemię i nie przeinaczaj faktów.
Spośród “zyjacych wersji ubuntu” systemd nie działa w 14.04LTS (wsparcie do 2019). Dodam jeszcze Linux Mint 17.x do tej listy, bo zdaje się, że oparta na 14.04 wykorzystuje ten sam system initów.
RHEL to praktycznie standard enterprise…
Jeśli coś chcemy określać w jakiś sposób, to róbmy to precyzyjnie: snap jest być może uniwersalny, ale dla dystrybucji korzystających z systemd, flatpak – jak na razie również. Jedynym uniwersalnym (sprawdź sobie znaczenie tego słowa, bowiem nie ja je odmiennie definuję, a właśnie Ty) formatem paczek dla linuksa jest appimage.
Mnie natomiast dalej ciekawi odpowiedź na pytanie – dlaczego wiązać możliwość zainstalowania określonego oprogramowania, które systemd nie wymaga, właśnie z nim.
Myślę, że @zbgns to już zasugerował. Niemniej jednak – ów uniwersalny (obojętnie jaki) format jest/ma być w zamiarze dla tych, którzy nie chcą otworzyć swojego kodu. Tutaj możliwość zbudowania paczki dla dystrybucji innej niż ta, na którą została wydana (i to jej konkretne wydanie) bywa mocno problematyczna, niekiedy także z przyczyn licencyjnych. Mając do dyspozycji “ogólny” format, twórca takiej aplikacji mógłby ją umieścić w jednym formacie i “mieć z głowy”.
W przypadku aplikacji z otwartym kodem sens takiego rozwiązania występuje chyba głównie w przypadku współczesnych aplikacji, które po prostu nie budują się na starociach, wymagają zależności, których tam nie ma itp. Lub w przypadku… wadliwie napisanych aplikacji.
Nawiasem mówiąc – z pewnego punktu widzenia taką uniwersalną platformą do dystrybucji aplikacji mógłby być flatpak, który oferuje współdzielony runtime i każda aplikacja w tym formacie winna to uwzględniać i pracować tam poprawnie. Jeśli jeszcze prace Gentoo-flatpak umożliwią odseparowanie flatpaków od systemd, to zapowiada się to ciekawie.
Inna sprawa, że… miłej lektury: https://forum.archlinux.org.pl/viewtopic.php?id=637
Flatpak nie wymaga systemd.
Cóż, jego twórcy uważają inaczej 🙂 http://docs.flatpak.org/en/latest/introduction.html
“Flatpak uses a number of pre-existing technologies. It generally isn’t
necessary to be familiar with these in order to use Flatpak, although in
some cases it might be useful. They include:
…
* systemd to set up cgroups for sandboxes
…”
W istocie od wersji 0.6.10 nie wymaga. Miło słyszeć i rozumiem zatem, że należy zgłosić błąd: https://www.archlinux.org/packages/extra/x86_64/flatpak/ 🙂
“A ktoś wie co się stało z flathub??”
Dobra zmiana :DD się dzieje
masz na twitterze flathuba: https://twitter.com/JorgeEscriu/status/972966648398434306
a podgląd tego co będzie masz tam na githubie ” See demo at: http://45.55.104.129/apps ” – znajdziesz tam komendy do konsoli chociaż równie dobrze możesz znaleźć czego szukasz przez “flatpak search ” i zainstalować “flatpak install flathub “
Cóż, kiepsko korzystasz z wyszukiwarki. 🙂
https://flatpak.org/faq.html#Is_Flatpak_tied_to_systemd_
@barthalion – Serio: dlaczego w Archu jest dla flatpak systemd w zależnościach oraz dlaczego namcap tak się tu pluje na błędach?
Kto jak kto, ale Ty powinieneś wiedzieć, gdzie zgłasza się błędy w Archu.
Namcap także nie jest wyrocznią co się powinno, a co nie, bo tak jak każdy linter tego typu potrafi zgłaszać mnóstwo false positive’ów. W przypadku flatpaka zgłasza co najwyżej pakiety, które już są dociągane jako zależności przez inne, co jest co najwyżej pluciem się, ale nie błędem. Błędem byłoby poleganie na transitive dependencies; mając Archa albo masz systemd i wsparcie zespołu/community albo problemy z którymi trzeba radzić sobie samemu.
To, że namcap nie wyrocznia – wiem. Nie to istotne. Błąd oczywiście, że mogę zgłosić – po prostu myślałem, że od Ciebie się dowiem co Wami kieruje obecnie, by nadal dawać systemd jako zależność flatpaka. Bo, że dawniej tak musiało być, to wiem.
Prosta odpowiedź: paczek we wszytkich repozytoriach jest trochę mniej niż 8000, a zaufanych użytkowników i developerów łącznie 76 (w praktyce może 60, bo pozostali są nieaktywni albo zajmują się mikroskopijnym kawałkiem tortu), z czego 6 osób opiekuje się ~58% repozytoriów. Go figure.
Bartek – prosto z mostu – mam rozumieć, że tak nie powinno być? Bo już się zastanawiałem, czy coś nie stoi za tym. Nie znalazłem jednak niczego co by miało przemawiać. Zrobię wrzutkę na BBS wpierw. Może coś się wyjaśni.