Alexander Larsson, inżynier oprogramowania w firmie Red Hat, ogłosił wydanie pierwsze wersji Flatpak. Jest to system pakowania oprogramowania, który pozwala na szybkie przygotowanie paczki z potrzebnymi bibliotekami i zależnościami. Tak gotowy program można udostępnić w repozytorium i uruchomić na dowolnym systemie operacyjnym z jądrem Linux. Flatpak jest wspólnym dziełem zespołów GNOME i Red Hata, a jego początków można upatrywać w eksperymentalnym narzędziu xdg-app. Dostępny jest na takie systemy, jak Arch Linux, Fedora, Debian, Mageia oraz Ubuntu.
Flatpak podczas uruchomienia izoluje aplikację w tzw. piaskownicy. Widzi ona jedynie siebie, swoje pliki i biblioteki, a także interfejsy jądra Linux. Jest całkowicie odcięta od sprzętu, procesów systemowych, a także można wymusić inne blokady.
Nie tak dawno mieliśmy też premierę formatu Snap od Canonical. Który zawojuje rynek? A może deweloperzy połączą siły i stworzą coś jeszcze lepszego?
Rynek zwojują ci, którzy pierwsi ogarną wydajną deduplikację plików między kontenerami i wybranymi katalogami w systemie.
Wtedy kontenery będą dostępne dla zwykłych ludzi, bez dysku 2TB.
Święte słowa.A na razie-kto bogatemu zabroni?
Logika, są jednak granice przy marnowaniu miejsca. Nawet jeśli ma się 16TB. :p
Jeżeli program i tak miałby zajmować ładne parę GiB (np. MatLab), to te paredziesiąt MiB zduplikowanych plików nie robi dużej różnicy, a wydawcy tracą wymówkę „jest problem z zależnościami na różnych dystrybucjach”.
Dlaczego miałby zajmować tyle miejsca? Zakładając że programy byłyby linkowanie dynamicznie i w paczkach byłyby luźne pliki .so, to można by je deduplikować w ogromnych ilościach. To samo tyczy się powielonych zestawów grafik itd.
Oczywiście wymagałoby to dużego nakładu pracy ze strony paczkujących, ale dostalibyśmy coraz mniejszą ilość miejsca zajmowanego przez kolejną paczkę (bo dużo plików byłoby na miejscu).
Czasami programy mają tyle swojego własnego kodu i plików z danymi. Takim przykładem jest właśnie MatLab, który jak pamiętam ostatnio mi zajmował ponad 2GiB. Prostszym przykładem są gry, taki BioShock zajmuje gdzieś około 25GiB.
Dobra, ale bioshock ważyłby też tyle w .deb, mi chodzi o zminimalizowanie różnicy w rozmiarze na dysku tego samego zestawu aplikacji w .deb i snapach.
Sorry – z całym szacunkiem – ale ulegasz PR Canonicala i różnych blogerów. Taką wymówkę stracili kilkanaście lat temu. Pierwsze znane mi rozwiązania tego typu pochodzą bodaj z 2002, czy 2004 r. i na pewno w postaci appimage są rozwijane do dzisiaj. Nie łudźmy się zatem, że samo pojawienie się flatpaka (wcześniej xdg-apps) czy snappy nagle firmy jak np. Adobe czy Corel zdecydują się na wspieranie swoimi produktami linuksa.
Równie dobrze można było robić zwykłe instalatory, które pakują program do /opt ze skryptem uruchamiającym przygotowującym środowisko (i w tym zależności) pod ten program. Adobe i Corel raczej żyją w przekonaniu że nikt Linuksa nie używa i się po prostu nie opłaca.
W przypadku AppImage nawet to nie jest konieczne. Ściągasz, umieszczasz, gdzie chcesz, nadajesz uprawnienia wykonalne i finito. Nie zawsze jednak to działa. Znalazłem kilka aplikacji, które odmówiły współpracy.
A mnie zabrakło jednej informacji: jaka jest różnica pomiędzy snapem a flatpakiem?
Przeszukując sieć znalazłem coś takiego (tłumaczenie własne i na szybko):
Za pomocą snapów można tworzyć paczki z oprogramowaniem zarówno dla serwerów, jak i dla desktopów. Deweloperzy flatpaka twierdzą natomiast, że „Flatpak został zaprojektowany tak, aby działał w sesji desktopowej. Wyorzystywane są różne usługi, takie jak dbus czy systemd. Nie jest więc dobrym rozwiązaniem dla serwerów.”.
Na swoim blogu porównuję różne systemy tego „paczkowania”, choć należałoby powiedzieć „bundle’owania”. Jak na razie doszedłem do flatpaka i… snappy raczej już nie zainstaluję. Dlaczego? O tym u mnie będzie niebawem.
Różnice:
– przynajmniej w X11 paczki snappy są totalnie niebezpieczne – mają pełny dostęp do dysku i z łatwością wykradają dowolne hasła; wg testujących we flatpaku nie jest to możliwe,
– wbrew szumnym zapowiedziom Canonicala – snappy nie działa we wszystkich systemach, a jedynie tych, które korzystają z systemd; wiem, że to obecnie pracuje na zdecydowanej większości dystrybucji, jednakże jest całkiem spora ilość takich, gdzie systemd albo w ogóle nie jest wspierany, albo nie musi być; co ciekawe – przynajmniej w Archu – flatpak jako zależność ma również systemd, ale w przeciwieństwie do snappy – nie wymaga on jednak podniesienia tej usługi,
– odinstalowanie snappy to koszmar :)
Podrzuciłbyś link do swojego bloga, chętnie bym o tym poczytał. :) Najlepiej wstaw go sobie do profilu na disqus, wszyscy będą mieli łatwiej.
linux-pavbaranov.blogspot.com – o snappy jeszcze nie ma, a o flatpaku muszę „zupgrade’ować” :) Inna sprawa, że… biorąc pod uwagę jak problematycznym jest rozwiązanie snappy, nie bardzo wiem, czy zdecyduję się na instalowanie tego „czegoś”.
Bardzo ciekawe. Dodaję do feedly sobie :-) Jak skończysz serię, to mogę rzucić informację do nas na portal :]
Jasne, ale najpierw muszę poprawić materiał o flatpaku. Nie wiem, czy będzie test snappy. Chciałbym jeszcze przetestować inne tego typu rozwiązania (jest ich kilka), o ile uda mi się w ogóle znaleźć jakieś aplikacje zrobione w ich standardzie. Na koniec będzie podsumowanie.
Nie ukrywam, że jak na razie, najbardziej jestem przekonany do flatpaka (generalnie), a dla poszczególnych aplikacji, z których potrzebuję skorzystać incydentalnie – appimage (gdyby jednak chciało w 100% działać).
Skończyłem :)
Pobierz Ubuntu Core (tak to się nazywało?) i odpal na VM, niskie wymagania a sobie potestujesz. ;)
W każdym razie leci do rss.
Nie mam VM :) (przynajmniej na tym, kernelu, którego najczęściej używam). Nie w tym jednak problem.
Snappy – przynajmniej tak jak to jest przedstawiane – ma być „panaceum” na bolączki deb, rpm i czego tam jeszcze, dostępne we wszystkich systemach. Nie interesuje mnie zatem, że ktoś to w Ubuntu skonfiguruje i wciśnie mi na siłę. Chcę zrobić to na innym systemie i dokładnie wiedzieć, co się dzieje.
Jak na razie – przed 2 dni – nie było dostępu do snapcraft.io, zatem nie było sensu testować. Samo już problematyczne działanie strony źle wróży.
[…] generowane dynamicznie. Przywrócono funkcję cofania zmian. Autorzy przeszli na format paczek Flatpak, porzucając całkowicie […]