Stawiam na AppImage a nawet na Snap lub Flatpak
Ostatnimi czasy społeczność opensource obiegły dwie energetyzujące wiadomości – Canonical w końcu unormuje sprawę rozpowszechniania programów dla wszelkich dystrybucji Linuksa. I druga – Red Hat zrobi to samo! Tak dowiedzieliśmy się (lub raczej dostaliśmy potwierdzenie) o niezależnie rozwijanych projektach Flatpak (dawne xdg-apps) oraz Snappy, które pozwolą pozbyć się zmory dręczącej użytkowników, developerów i opiekunów paczek. Rozwiązaniem są bowiem odpowiednio spreparowane paczki, które bez problemu da się zainstalować i uruchomić na każdej dystrybucji. Tyle teorii, a jak to wygląda w praktyce? W praktyce od kilku lat mamy już w użyciu takie rozwiązanie o nazwie AppImage.
Dla zrozumienia powagi sytuacji i ważności dostępu do najświeższego oprogramowania użytkowego, musimy zdać sobie sprawę z tego, że desktop to nie serwer. O ile w przypadku tego drugiego długie cykle wydawnicze, etapy stabilizacji i łatania usług i programów mają swoje uzasadnienie, o tyle nierozsądnym jest upieranie się, że użytkownik na desktopie powinien otrzymywać tylko stabilne wydania po ich półrocznym testowaniu. W większości przypadków rozwój takiego oprogramowania jest na tyle dynamiczny, że praca na wersji sprzed pół roku jest zwyczajnie pisząc frustrująca. Nie mówiąc już o frustracji deweloperów, których programy nie załapały się do repozytoriów, albo są programami zamkniętymi i/lub komercyjnymi. Na dodatek chyba wszyscy znamy ból użytkowania jakiegoś wydania ciągle wspieranej dystrybucji, dla której nikt już nie aktualizuje oprogramowania.
Dlatego tak często podnoszono ostatnio kwestię uniwersalności oprogramowania linuksowego, jego rozpowszechniania i pogodzenia interesu deweloperów oraz twórców wszelakich dystrybucji. Innymi słowy, potrzebny był format paczki, które raz stworzona byłaby możliwa do uruchomienia na jakiejkolwiek współczesnej dystrybucji. Do tego celu należało zlikwidować problem zależności i kilka innych niuansów. Jak sobie z tym poradzono?
W miejsce obowiązujących standardów paczkowania zaproponowano… A jakże, kilka rozwiązań. Przyjrzyjmy się jednak tym, o których było ostatnio najgłośniej i które mają stanowić panaceum na powyższe.
Flatpak aka xdg-app
Tajemnicza nazwa za którą stoi nie kto inny a Red Hat. Koncepcja zrodzona w głowie Alexandera Larssona wydaje się być kompletnym rozwiązaniem i światełkiem w tunelu dla procesu unifikacji sposobu dostarczania oprogramowania w przeróżnych dystrybucjach. Niemniej, gdy przyjrzymy się tematowi bliżej, to okazuje się, że:
- + zależności: w paczce, dzielą się na współdzielony przez paczki zestaw Runtime oraz te, których w Runtime nie ma (albo są w innej wersji),
- + bezpieczeństwo: sandbox i odgrodzenie programu od systemu,
- +/- dystrybucja: paczki organizowane w ramach repozytoriów (aby zainstalować – trzeba znać repozytorium),
- – obsługa: póki co skomplikowana instalacja z linii komend, do wygody potrzebne odrębne narzędzie graficzne (Gnome Software),
- – uniwersalność: rozwiązanie teoretycznie uniwersalne, ale działa jako tako w Fedorze. Uwaga na licencje (Red Hat).
Idąc dalej w dokumentację dowiemy się, że Flatpak jest ściśle powiązany z sesją graficzną, co za tym idzie nie będzie możliwe dystrybuowania tą drogą programów dla serwerów (poniekąd i słusznie). Co więcej, aby zbudować paczkę będziemy potrzebowali podstawowego zestawu bibliotek Runtime – w chwili obecnej GNOME 3.20 Runtime (tak, GNOME – KDE w drodze). Ten sam zestaw będzie też potrzebny, aby nasz program się uruchomił na używanym przez nas systemie. Warto podkreślić jedną rzecz – paczki są zupełnie niezależne od systemu i posiadanych przez nas bibliotek. Zawierają wszystko, co konieczne aby samodzielnie się uruchomić. Pomimo niepokojąco wyglądającego spowinowacenia z Red Hatem, rozwiązanie stara się być w miarę uniwersalne i dostępne dla każdego.
Dla porówniania – jak zainstalować najnowsze LibreOffice.
Snap
To nie pierwszy i nie ostatni raz, gdy Canonical postanawia napisać historię po swojemu. Przesłanki powstania paczek Snappy są oczywiste, Canonical chce swój przyszły sukces zawdzięczać tylko sobie i z nikim tej chwały nie dzielić. Ich koncepcja dystrybucji oprogramowania „od osób trzecich” jest bardzo podobny do koncepcji Flatpak.
- + zależności: w paczce, dzielą się na współdzielony przez paczki zestaw Ubuntu Core oraz te, które tam nie występują (albo są w innej wersji),
- + bezpieczeństwo: sandbox i odgrodzenie programu od systemu,
- +/- dystrybucja: paczki organizowane w ramach repozytorium prowadzonego przez Canonical,
- – obsługa: póki z linii komend, do wygody potrzebne odrębne narzędzie graficzne (na obsługę Snap przez Gnome Software chyba nie ma co liczyć – pora na kolejny fork?),
- – uniwersalność: rozwiązanie teoretycznie uniwersalne, ale działa jako tako w Ubuntu. Uwaga na licencje (Canonical).
Jak widać, różnice są kosmetyczne. Głównie w sposobie dostarczania zbudowanej paczki użytkownikowi końcowemu. Snap ma tę przewagę na Flatpakiem, że źródło paczek jest jedno – „sklep” Canonicala. Choć dla wielu osób może to być wada. Niemniej, nie trzeba przekopywać internetu w poszukiwaniu pożądanego URL z repozytorium dla konkretnego programu. Do tego składnia tekstowego polecenia „snap” do złudzenia przypomina stare dobre apt.
Dla porównania – jak zainstalować najnowsze LibreOffice.
AppImage
Okazuje się jednak, że ani deweloperzy stojący za Flatpakiem, ani Canonical koła nie odkryli. Podobnych koncepcji i podejść było już kilka, o różnych nazwach, z których chyba najlepiej przyjął się AppImage. W sumie to przyjął się w formie szczątkowej (istnieje na rynku już kilka lat), świadomość deweloperów o istnieniu tego rozwiązania jest mizerna i paczki AppImage dostarcza niewiele projektów.
- – zależności: do paczki załączone zostaję te, które nie występują w systemie na którym jest budowana paczka,
- +/- bezpieczeństwo: o oddzielenie programu od systemu trzeba zadbać samodzielnie, za pomocą choćby firejail, który wspiera AppImage,
- + dystrybucja: samodzielny (binarka ELF) i pojedynczy plik, będący obrazem „środowiska uruchomieniowego” dla programu,
- + obsługa: w każdym współczesnym menadżerze plików wystarczy prawy przycisk na pobranej paczce i opcja Uruchom (lub Właściwości i prawa do uruchamiania),
- + uniwersalność: rozwiązanie działa w każdej dystrybucji.
Czyli bez zbędnego udziwniania i ceregieli – po prostu na stronie projektu udostępniany jest plik, który po pobraniu możemy uruchomić na swoim systemie. Zaraz zaraz, ale czy to bezpieczne? Niestety, oblicze takiej wygody ma ponure oblicze znane z wiodącego systemu – w tak dystrybuowaną paczkę każdy może włożyć cokolwiek. Zweryfikuje to dopiero społeczność. Jakimś zabezpieczeniem jest stosowanie wspomnianego FireJail (firejail –appimage nasza_paczka_appimage). Kolejnym mankamentem może być obsługa zależności, która jest nie wiedzieć czemu uzależniona od tego na jakim systemie budujemy paczkę. Więc nie jest to tak, jak w przypadku Flatpak i Snap, że paczka jest samowystarczalna.
Jak można to wszystko skomentować? Powyższe rozwiązania (poza AppImage) wydają się być w powijakach, AppImage z kolei zupełnie niepoważnie podchodzi do kwestii bezpieczeństwa. Pogodzenie funkcjonalności AppImage i bezpieczeństwa Snap lub Flatpaka może wymagać… Kolejnego nowego konceptu i standardu.
A wygra ten system paczek, który będzie najmniej inwazyjny dla deweloperów chcących dostarczać szerokiemu gronu odbiorców tworzonych przez nich program.
36 komentarzy
Dodaj komentarz
Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.
Jak dla mnie trzeba nowego systemu paczek, gdzie deweloper po zarejestrowaniu nazwy paczki może do woli wgrywać aktualizacje (binarne lub budowane w chmurze), ale administracja aka dzisiejszy opiekuni wystawialiby certyfikaty dotyczące bezpieczeństwa i/lub stabilności konkretnym wersjom. Deweloper nie miałby za dużo pracy, rozwiązanie byłoby ok zarówno dla biurka jak i serwera z uwagi na możliwość wyboru (ostatnia certyfikowana lub najnowsza wersja od deva) a nie dostalibyśmy problemów jak w tych paczkach typu ogromny rozmiar / dużo większe ryzyko instalacji malware/spyware itd.
Oczywiście możemy się np. spotkać z sytuacją gdy google-chrome-stable nie ma certyfikatu o stabliności, ale to żaden problem. W praktyce certyfikaty te miałyby znaleźć zastosowanie raczej na serwerach, bo na desktopie i tak dodajemy jak leci PPA, więc na jedno wychodzi. 😛 Zwłaszcza że coś takiego ma przewagę zarówno nad PPA (wymuszenie kompilacji w chmurze) i PKGBUILD. Oczywiście musiałoby to być dobrze przemyślane i zaimplementowane, ale tego typu system paczek niewątpliwie kiedyś się pojawi.
Co jak co, ale dzisiejsze repozytoria są mimo wszystko przestarzałe / niewygodne a takie paczki all-in-one to jednak półśrodek, który koniec końców pewnie nie zasłuży nawet na miano rozwiązania tymczasowego.
Coś gdzieś czytałem,że Snap ma możliwość,czy tez śledzi naszą aktywność,czy mi się coś pomyliło,czy to prawda?
Pewnie tę plotkę wypuścił jakiś hejter Canonicala.
Niestety błędna decyzja z wyświetlaniem wyników z Amazona spowodowała, że łatka szpiegów ciągnąć się będzie za Ubuntu przez długie lata…
No nie tylko wyniki z Amazon,bo coś tam było o tym,że wyniki wyszukiwania w dash trafiają na serwery Cannonical,nie pamiętam dokładnie
Pamiętam, że już kiedyś było podobne rozwiązanie, tylko nie pamiętam nazwy tego… Pobierało się “kontenery” z rozszerzeniem .package bodajże i miało to taki windowsopodobny instalator typu “next-next” – coś jak te paczki od PC-BSD. Pamięta ktoś jak to się nazywało?. Co do tematu – uważam, że to jest mniej lub bardziej, ale zawsze – kompromis. Nie jestem jakimś linuksowym hardkorem, zawsze mi przeszkadzała “świeżość” paczek w Debianie, dlatego wybrałem Archa (a obecnie pochodną)… ale wydaje mi się, że albo mamy “package on demand”, albo – mniej lub bardziej – jesteśmy narażeni na jakieś tam zagrożenia – i tu nie ma złotego środka.
Już wiem, autopackage to się zwało – info dla linuksowych historyków 🙂
No to moich – więcej niż – 5 gr. Kiedyś przetestowałem te 3 rozwiązania w Archu. Efekt przemyśleń na moim blogu. Teraz jednak tylko kilka uwag, to owych “wspaniałych” narzędzi.
Uniwersalność: Ani flatpak, ani snap nie są uniwersalne. Pierwsze w ograniczonym, drugie w pełnym stopniu wymaga systemd do korzystania. Wszystkie dystrybucje, które nie są oparte o systemd oraz ci, którzy nie zdecydowali się na nim stworzyć systemu zostają pozbawieni tych rozwiązań (w przypadku snap – w 100%).
AppImage wprawdzie nie jest powiązany z żadnym initem, ale ze względu na sposób budowania takiej paczki (pomija biblioteki znajdujące się w systemie, na którym jest budowany), jego uniwersalność jest żadna. Wystarczy, że w systemie użytkownika znajdą się nowe wersje (lub starsze) bibliotek i nici z uruchomienia appimage. Efekt zatem żaden, jeśli chodzi o uniwersalność. Mi udało się uruchomić jakąś 1/3 programów. W pozostałej puli znalazły się np. wszystkie przeglądarki oparte o chromium. Nadto nie wszyscy paczkujący tworzą te paczki w standardzie XDG, przez co zawarte w nich *.desktop niekiedy zrobi więcej złego niż dobrego.
Bezpieczeństwo: AppImage – żadne. Flatpak – duże bądź pełne. Snap – podobne do flatpak, ale wyłącznie w… waylandzie (i pewnie mirze). W XOrg nie oferuje żadnego bezpieczeństwa. Aplikacja snap ma dostęp do wszystkich danych, włącznie z poufnymi.
Funkcjonalność aplikacji: Ani aplikacje flatpakowe, ani snapowe – jak na razie – nie oferują 100% funkcjonalności programów z repozytorium. Dla przykładu libreoffice (w obu wersjach) jest pozbawione możliwości korzystania z javy (nawet jeśli ta znajduje się w systemie), przez co część funkcjonalności (LO Base, dodatki takie jak languagetool) nie jest dostępna.
Problemy z wielkością programów: Aplikacje pakowane są w taki sposób, że zawierają biblioteki niezależnie od tego, czy znajdują je w systemie, czy też nie (to oczywiste). Efekt jest taki, że w chwilę można zapełnić mniejsze dyski, jak np. SSD. Pamiętać też trzeba, że – przynajmniej flatpak – to dodatkowe oprogramowanie (runtime), które jest instalowane w systemie, przez co aplikacje te są jeszcze większe. Znów runtime jest instalowane niezależnie od tego czy jego odpowiednik znajduje się w systemie, czy nie (np. runtime gnome 3.20 zostanie zainstalowane nawet w systemie, który jest zbudowany na gnome 3.20, przez co zawiera wszystkie biblioteki składające się na owe runtime).
Stan prac: flatpak – pomijając jego obsługę, do której trzeba się przyzwyczaić i wiedzieć, że np. trzeba zainstalować runtime (co nie jest takie oczywiste) w istocie wydaje się działać dobrze (i to nie tylko na Fedorze). Snapa nie udało mi się w ogóle uruchomić (pomimo spędzenia nad nim wielu godzin). AppImage – jeśli paczki budowane byłyby w sposób taki jak flatpak i snap (czyli z bibliotekami wymaganymi przez program) – byłoby rozwiązaniem w miarę dobrym.
Co ciekawe – instalacja flatpakowego libreoffice (jednej z 2 wersji kandydujących) popsuła LO, które znajdowało się na dysku (pozbawiło ją możliwości drukowania; po usunięciu flatpaka – możliwość ta wróciła).
IMO – efekt prac owych 3 konkurujących ze sobą rozwiązań jest bardzo słaby i w porównaniu z paczkami w repozytoriach – zdecydowanie niedopracowany. W żaden sposób nie usunął dotychczasowych problemów, stworzył nowe. Szczególnie dla użytkowników końcowych.
O opisanych wadach repozytoriów, nie będę się wypowiadał, bo to temat na odrębną dyskusję. Tyle, że brak dostępności oprogramowania w najnowszych wersjach w niektórych dystrybucjach jest bardzo często efektem przyjęcia pewnych założeń “filozoficznych”. Jeśli są one znane użytkownikowi, to nic nie stoi na przeszkodzie, by dobrał sobie taką dystrybucję, która mu pasuje. Zawsze to będzie jakiś kompromis. Z nich jednak składa się nasze życie 🙂
PS: “Runtime” KDE dla flatpaka jest już dostępne. Nie ma natomiast jeszcze (a przynajmniej mi nie są znane) paczek, które są paczkowane jako flatpak, chociaż “przepisy” na to istnieją i są udostępnione na GIT KDE.
Serwery Canonicala miały służyć jak narzędzie filtracji i ukrywania danych użytkownika przed firmą Amazon. Jednak Canonical nie przedstawił dokładnie na czym to polega.
Dobrze,a jak usunąć flatpaka,który jest zainstalowany.Nie widać go w synaptic.
A mnie to całe zamieszanie kojarzy się z pogonią psa za własnym ogonem. Microsoft dąży do własnego repozytorium (sklepu) na wzór linuksowy (androidowy) a Cannonical i Red Hat idą w kierunku “uwolnionych” od systemu paczek na wzór windowsowych exe. Podobnie było (jest?) z interfejsem graficznym. Linux jeszcze z rozpędu próbuje naśladować przeźroczysto-szklany wygląd pulpitu Visty/7 (za pomocą Compiz itp.) a Windows zrobił zwrot na płasko-nudny Material Design z Androida. A to znów będzie próbował naśladować Linux. Programiści biorą przykład z polityków? Zamiast rozwiązywać problemy zajmują się pierdołami a do tego jeszcze nie potrafią się dogadać. Repozytoria może nie są doskonałe ale chyba nie ma lepszego systemu dystrybucji programów. Moim zdaniem lepszym rozwiązaniem od snapów i flatpaków byłoby przyjęcie takich samych, już istniejących paczek dla różnych dystrybucji. Czyli należałoby się dogadać co do formatu (deb, rpm, tar.gz itp.), menedżera pakietów i wspólnych repozytoriów. Ale to czysta utopia. Jak na razie nawet dystrybucje pochodzące z tych samych źródeł (Debian, Ubuntu, Mint itp.) mają własne repozytoria i są coraz mniej ze sobą kompatybilne. Red Hat i Canonical chcą stworzyć własne ekosystemy i nie ma co liczyć na zastosowanie ich w innych dystrybucjach poza zależnymi. Czas pokaże co z tego wyjdzie.
Podzielam wyniki spostrzeżeń. Na dzień dzisiejszy tylko Flatpak, ale długa droga przed nim (kwestie runtime’ów) albo appimage (kwestia porzucenia koncepcji o’ runtime’ie’ w systemie) albo Snap (wyregulowanie kwestii licencyjnych, zdobycie się na większą uniwersalność).
🙂
Jak na razie, flatpaka obsługujesz z konsoli (przynajmniej w Archu nie znam narzędzia GUI). Synaptic jest nakładką na APT zatem nie zobaczysz tam paczek flatpaka (ani appimage, ani snap).
Zatem:
1. otwierasz konsolę
2. wpisujesz flatpak i…
otrzymujesz całą listę komend, którą wprowadzasz w konsoli. O ile pamiętam: flatpak remove nazwa_paczki (nie mam teraz pod ręką flatpaka). Odinstaluje Ci to samą aplikację.
IMO – jeśli w ogóle – to wyłącznie appimage, ale jak piszesz – wyłącznie wówczas, gdy zacznie on być “bundlem” z prawdziwego znaczenia. Snap – na uniwersalność nie ma szans (ścisłe powiązanie z systemd; pomijam inne trudności oraz “dystrybucję” paczek). Flatpak – pośrodku. Po dopracowaniu może się okazać dobrym rozwiązaniem (akurat tu ten systemd nie jest wielkim problemem).
Najlepsze rozwiązanie? Prawidłowy wybór systemu i… repozytoria 🙂 Flatpak, appimage, czy cokolwiek innego (snap pójdzie na drzewo :)) tylko w przypadku wybitnej potrzeby otrzymania jakiejś paczki tak dystrybuowanej i zarazem braku możliwości (bądź opłacalności) stworzenia paczki natywnej. 100x wolę zrobić sobie PKGBUILD i stworzyć w ten sposób paczkę natywną w Archu niż instalować dla jednej paczki od groma zależności (czym się to różni z krytyką np. dawnych aplikacji KDE: chcę zainstalować okulara, dolphina, czy cokolwiek i ciągnie to pół KDE; no to tutaj mamy chcę kalkulator z Gnome i ciągnie mi wszystkie biblioteki Gnome :)).
Dogadanie się do formatu – nie jest możliwe, skoro tego nie ma. Zresztą jest to kwestia wtórna. Istotą jest to, że w różnych dystrybucjach są biblioteki w różnych wersjach. Być może po prostu w końcu trzeba sobie – jako end user – uświadomić: nie każda dystrybucja jest dla każdego. Debian ze swoim konserwatyzmem jest systemem dobrym na serwer. To niech się tego trzyma i na tym skupi. Arch jest dobry na desktop – zatem po hucz tu próba utrzymywania wersji “serwerowej”. Itp. itd. Kwestia paczkowania jest doprawdy wtórna, a najwięcej narzekają ci, którzy po prostu źle wybrali sobie system i na siłę chcą czegoś innego, od tego co… wybrali.
Formaty są: deb, rpm i inne, trzeba tylko dokonać wyboru i używać odpowiednich bibliotek. Za rozwiązywanie zależności odpowiada menedżer pakietów. Mówisz, że Arch lepszy na desktop od Debiana? Dla ciebie może tak jest ale u mnie Debian sprawdza się lepiej bo obsługuje moją drukarkę, której na Archu jakoś nie daje się uruchomić. Jeśli się mylę, to poproszę o informacje o sterownikach dla Brother DCP-J105 w Archu.
W Debianie rowniez nie masz paczki dla dcp-j105 🙂 Masz ja od producenta i bedzie dzialac tak dlugo, jak dlugo biblioteki sie zgodza.
Jesli chcesz dcp-j105 w Archu – prosze bardzo: https://aur.archlinux.org/packages/brother-dcpj105
Nie o to mi chodzilo jednak, a o udostepnianie oprogramowania, ktore jest isstotne z punktu widzenia okreslonego uzytkownika danego systemu (dystrybucji). Pasuje Ci Debian? Ok. Nic mi do tego. Moje preferencje i potrzeby sa zdecydowanie inne.
Dzięki za info, wypróbuję przy następnej okazji. Może tym razem zadziała.
Nie podoba mi się idea tych uniwersalnych paczek-kontenerów. Zrobi się z tego syf w systemie, robactwo, virusy… a wszystko żeby user miał paczki świeższe o 3-4 miesiące. To jest absurd, żadne oprogramowanie nie wprowadza aż takich zmian co miesiąc aby ten problem dotykał więcej niż 1% userów. Problem, który jak już ktoś się z nim zmierzy można rozwiązać, ppa, aur, ręczna kompilacja, to jest upierdliwe, ale raz czy dwa razy w życiu warto to zrobić zamiast poświęcać bezpieczeństwo i stabilność…
A ból d.py developerów to żalenie się że muszą dbać o bezpieczeństwo i stabilność swoich aplikacji… wyobraża sobie ktoś producenta samochodów żalącego się że musi przeprowadzać żmudne i kosztowne testy bezpieczeństwa?
Coś się buja może kiedyś linuks coś zawojuje xD
A buja,buja…
Linux już coś zawojował,można się pobujać po forach,blogach i necie,sprawdzić….
🙂
Ten bez GNU owszem, jak najbardziej zawojował. Natomiast ten drugi raczej nie ma szans* z uwagi na mentalność jego twórców jak też części użytkowników.
__________
* Zawojowanie – co najmniej 10% udziału w rynku desktopów i traktowanie przez twórców komeryjnego oprogramowania jako równorzędną platformę.
Gdzie ten bez GNU zawojował 10% udziału rynku desktopów? Btw Android to też dystrybucja GNU/Linux. W każdym razie u mnie na tablecie siedziało trochę programów z pakietu GNU. 😛
Masz dużo racji, dlatego ja nie używam programów bez paczek a jak już serio muszę to sam robię .deb.
Wiem wiem korzystam z linuxa ile mogę 😀
Android ma coś z GNU? Nawet nie wiedziałem bo nie używam, myślałem że oprócz jaja wszystko jest tam niekoszerne.
Podstawowe narzędzia, ls, mkdir, mv, cp itd. W sumie nie znam żadnego zastosowania gdzie Linux występuje bez GNU. GNU bez Linuksa się zdarzało, ale na odwrót?
//edit: Zajrzę jutro do czystego obrazu Androida 6.0 na VM (trochę się klepie na androida to mam) i dam znać co tam siedzi, w moim przypadku to był Lenovo Ideatab 6000s, ale nie wiem czy może lenovo sobie czegoś nie upraszczało i jak tam w oryginalnym andku.
“snap pójdzie na drzewo” – oj nie byłbym tego pewien 😉 Co będzie z appimage – trudno powiedzieć. Flatpak został zaprojektowany dla desktopu. Jak napisali jego twórcy
“Can Flatpak be used on servers too?
Flatpak is designed to run inside a desktop session and relies on certain session services, such as a dbus session bus and a systemd –user instance. So, is not a good match for a server.”
Natomiast snap był projektowany jako paczka uniwersalna – i dla serwerów, i dla desktopa.
“GNU bez Linuksa się zdarzało, ale na odwrót?” nawet na wikipedi jest opis linuksa bez GNU https://pl.wikipedia.org/wiki/GNU/Linux
Zgoda. Zaprojektowany – ok. Problemem jego jest:
– działa (dobrze) praktycznie w Ubuntu,
– wymaga systemd (“systemowo” – bez tego nie potrafi działać).
Na serwer? Cóż, który z właścicieli serwerów wpuści sobie aplikację (o której nie wie nic, bowiem musi wierzyć, że jest dobrze spakowana i nie zawiera żadnych nieporządanych rzeczy) na serwer, a która może mieć dowolny dostęp do wszelkich informacji na nim zawartych.
Problem ze snapem jest – wg mnie – jego totanie wadliwe zaprojektowanie, albo… wyprzedzenie czasu o kilka-kilkanaście lat, tj. do chwili, gdy obecne rozwiązania odejdą w niepamięć i pozostanie wyłącznie: wszędzie zainstalowany wayland, wszędzie zainstalowany systemd (i pewnie jeszcze kilka innych rozwiązań, o którch nie wiem). Jeśli tak się stanie i jeśli do tego czasu nie zapomnimy o tym rozwiązaniu (a warunkiem jest jego przede wszystkim użyteczność), to może się przyjmie.
No, chyba, że duet coraz lepiej współpracujących: Microsoft+Cannonical będzie w stanie narzucić to rozwiązanie powszechnie. W to ostatnie jednak wątpię.
Swoją drogą – nie znam się na obsłudze, zarządzaniu serwerami – jaka jest potrzeba posiadania takiego rozwiązania jak “snap” na serwerze? Czemu tam to może służyć?
Nie o takich wymysłach czytałem na Wikipedii, mimo wszystko takich zastosowań jest raczej mało, taka nisza niszy. Bo na firewallu mogę zainstalować równie dobrze zwykłego GNU/Linuksa, a taki zlepek małych technologii gdzieś indziej znajdzie zastosowanie?
Jeśli Alpine linux uważasz za niszę – to cóż jest obecnie m.in. “tylko” podstawą dla Dockera 😉
A jest czymś poza tym? Zwłaszcza, że docker chodzi chyba sprawnie też na innych distrach. Ale fajny wynalazek, 83MB .iso robi wrażenie.
Sprawnie może i tak ale nie tak “oszczędnie”. Za ich deweloperami: “A container requires no more than 8 MB and a minimal installation to disk requires around 130 MB of storage.”
Poza tym to normalna dystrybucja nastawiona na bezpieczeństwo. Fakt nie znajdziesz tam gnome czy plasmy ale openbox czy fluxbox już jak najbardziej.
No tak, ale flatpack ma podobne wady, chyba że zostanie przeprojektowany. W liczących się głównych dystrybucjach standardowo systemd nie jest stosowany tylko w Gentoo (choć go posiada i może z niego korzystać). Wayland wejdzie do użytku w przyszłym roku. Liczę, że się w miarę upowszechni w ciągu 9-12 miesięcy po wydaniu go jako podstawowy serwer wyświetlania w Fedorze.
Czy flatpack czy snap instaluje się z repo/sklepu od zaufanego dostawcy, bo czym różni się instalowanie deb od Cannonicala od instalowania od nich snapa.
Do czego może służyć na serwerach – chociażby do zainstalowania oprogramowania z konkretnymi wersjami bibliotek. Jeśli używa się projektów “open source” to pół biedy, ale jeśli na takim zestawie zbuduje się własnościowe rozwiązanie to warto mieć pełnowartościowego “bundla” którego możemy postawić w zasadzie na każdej dystrybucji (jeśli to wreszcie zadziała 😉 )
Z tym podobieństwem wad – i tak i nie. Nie znalazłem w sieci materiału o możliwości dostępu do danych umieszczonych na dysku w przypadku aplikacji flatpak. W przypadku snapa – informacje takie są. Jeśli się nie mylę, to flatpak wprawdzie ma w zależnościach systemd, ale może się obejść bez tego. W przypadku snapa – nie ma takiej możliwości. Oprócz wymienionego Gentoo, masz choćby jeszcze Slackware, który również nie stosuje systemd (i nie ma zamiaru). Nie istnieje żadna różnica między dystrybucją flatpak z repozytorium i snapa ze sklepu z wyjątkiem tej, że dla snapa to jedyny kanał dystrybucyjny, gdzie dostawca oprogramowania musi podpisać “cyrograf” licencyjny z Canonicalem.
A jeśli chodzi o Waylanda… Cóż… Też myślałem, że stosunkowo szybko go ujrzymy. Nie jestem teraz takim optymistą. Realnie – pierwsze jaskółki już są (Enlightenment już domyślnie startuje na Waylandzie), a pierwszą dystrybucją z domyślną sesją w Waylandzie ma być nadchodząca Fedora. Czy tak będzie? Zobaczymy. Oprócz wspomnianego Enlightenmenta jako tako można mówić o dostosowaniu do niego Gnome 3 (ale zdaje się, że dopiero nadchodzącego jesienią wydania). Być może wraz z Plasmą 5.8 to środowisko również przestanie być probematyczne w Waylandzie. Żadne inne środowisko nie jest dostosowane obecnie do pracy w sesji Waylanda. Środowiska budowane od początku dla Waylanda (np. Hawaii, Papyros) są jak na razie w powijakach, a w sumie nie najgorszy (a przede wszystkim działający) Weston, który mógłby zastąpić np. OpenBox nie doczekał się jak na razie wygodnego oprogramowania. Zatem o ewentualnym spopularyzowaniu się Waylanda moglibyśmy mówić wyłącznie w aspekcie ekosystemu Gnome3. Zważ przy tym, że – przynajmniej w dotychczasowej wersji PR – twórca snapa nie będzie miał Waylanda. Stąd – choć w istocie spodziewam się pewnego przyspieszenia – to daleki już jestem od optymizmu, że Wayland na desktopach zagości w 2017 r. w znaczącym udziale. A Wayland na serwerach, to już w ogóle jakaś odległa przyszłość.
I te przemyślenia prowadzą mnie m.in. do wątplliwości co do możliwości spopuaryzowania się snapa.
No to rzeczywiście małe wymagania, pewnie przy kilkudziesięciu/kilkuset kontenerach na “PC” robi to jakąś większą różnicę. Tylko co do bezpieczeństwa – tutaj wyszło im to raczej po drodze i wcale nie tak dobrze, jak się chce być serio bezpiecznym/anonimowym to się używa Tails. 😛 A Gnome i Plasmy szczerze mówiąc nie zainstalowałbym co by się nie działo, raz zobaczyłem jak płynnie działają *boxy i szczerze to polubiłem. Na cinnamonie siedzę głównie z przyzwyczajeń, ale gdyby go zabrakło zainstalowałbym właśnie jakiś menadżer okien i ew. potem coś dodał.