Snaps wita was
Jeśli zapytać by dowolną osobę o największą bolączkę Linuksa, to w większości przypadków bez chwili zastanowienia otrzymamy odpowiedź: „Za dużo dystrybucji”, a po chwili „Za dużo systemów paczkowania”. I jest to to poniekąd prawda, ale to nie liczba dystrybucji jest tutaj największą przeszkodą, a rozdźwięk w sposobie dystrybuowania oprogramowania dla tychże. Owszem można się upierać, że przecież w zasadzie mamy tylko paczki deb, rpm, xz, tgz. Ale ich przyspawanie do konkretnej wersji dystrybucji jest, delikatnie mówiąc, uciążliwe. Owszem, są rozwiązania sprytne jak system paczek w Arch Linuksie, ale to nadal rozwiązanie dla jednego systemu (i dystrybucji pochodnych). Co w takim przypadku powinno się zrobić? Wprowadzić kolejny system paczek – Snaps.
Jeżeli przyjrzeć się problemowi od strony technicznej, to jedynym usprawiedliwieniem dla systemów paczek są zależności (wygodny sposób ich definiowania i rozwiązywania) oraz to, że binarna wersja programu dla danej dystrybucji jest przygotowywana w oparciu o kompilację z użyciem kompilatora i bibliotek zawartych w takim systemie. Dlatego paczki deb z Debiana 8 próżno próbować uruchamiać na Debianie 5, 6 czy nawet 7. A co, jeśli to wszystko – zależności, biblioteki użyte przy kompilacji, zawrzeć w jednej niezależnej paczce razem z binariami? Tak też pomyślano w Canonical i tak narodził się system paczek Snaps. System od momentu narodzin wyśmiewany, skazany na ostracyzm i niewybredne zestawianie w jednym szeregu z dotychczasowymi przedsięwzięciami twórców Ubuntu. Ale z drugiej strony, nikt nigdy nie zadeklarował, że Snaps ma zastąpić używane w Ubuntu paczki deb. Standard ten powstał, by rozwiązać problemy twórców niezależnych gier i programów, tak aby mogli bez większego angażowania sił tworzyć i umieszczać / rozprowadzać uniwersalne paczki dla Ubuntu. Przecież coś takiego robi już Valve w swoim SteamOS (i samym Steamie dla Linuksa) – choć może nie w tak oczywisty sposób. Gry kupowane za pośrednictwem Steama zainstalują się na każdym Linuksie, bez konieczności domyślania się, jakie biblioteki i zależności są nam potrzebne. Tą samą drogą podążyła koncepcja paczek Snap – łatwe do przenoszenia między dystrybucjami oprogramowanie.
Otóż to, pomiędzy dystrybucjami. Chociaż Snaps było pomyślane na początku jako rozwiązanie stricte dla Ubuntu, zainteresowanie ze strony deweloperów innych systemów spowodowało, że już teraz Snaps możemy używać w Debianie, Arch Linuksie Fedorze. Trwają prace nad implementacją w CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt. Pomyślcie tylko – jedna paczka, którą pobieramy i uruchamiamy na niemal dowolnej dystrybucji. W dniu premiery nowej wersji programu. Bez konieczności czekania, aż ktoś stworzy paczkę, zaktualizuje zależności i tak dalej. Oczywiście, bez porzucania dotychczasowego menadżera pakietów przynależnego naszemu systemowi.
No dobrze, brzmi to wspaniale, ale jak Snaps sprawdza się w praktyce? (Snaps – paczki Snap, Snap – system paczkowania). W kwestii marketingowej nie bardzo, paczki są ogromne (100 – 150MB) – to wymaga jeszcze dopracowania. W kwestii logiki standardu jest lepiej. Snaps oprócz instalowania się niezależnie od całości systemu, starają się też być całkowicie od niego oddzielone. To daje nadzieję na odpowiednie opanowanie kwestii bezpieczeństwa i innych zagrożeń, które można mnożyć na przykładzie wiodącego systemu i uniwersalnych plików exe.
Czy Snaps się przyjmie i ułatwi życie deweloperom oraz użytkownikom? Cóż, wobec całej ostrożności w ocenie rozwiązań serwowanych przez Canonical, Snaps może być rozwiązaniem naszych odwiecznych dylematów – system ze świeżym oprogramowaniem, czy system stabilny, itp. Samo zaangażowanie ze strony deweloperów przeróżnych dystrybucji już o czymś świadczy – oni sami ujrzeli światełko w tunelu niekończącej się epopei paczkowanie, przepakowywania, uzupełniania zależności i tak co każda wersja systemu.
58 komentarzy
Dodaj komentarz
Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.
Dalej mnie fascynuje dlaczego to nie ma deduplikacji plików na podstawie sum kontrolnych albo (lepsza opcja) jakichś metadanych?
A to się nie nazywa przypadkiem Snappy? 🙂
Kolejny system “bundle”, których wiele było i jest. Wrzawa – jedynie dlatego, że wprowadza to Canonical.
Jak do tej pory – żaden bundle się powszechnie nie przyjął. I marne prawdopodobieństwo, by się nagle snaps przyjął. Coraz więcej mamy komputerów wyposażonych w SSD. O ile w przypadku terabajtowych HDD kalkulator o wielkości 100MB może i nie jest problemem, ale wyobraźmy sobie jakieś bardziej skomplikowane programy.
IMO – cały problem leży po stronie z jednej strony deweloperów dystrybucji, z drugiej strony użytkowników. Skoro instalujesz sobie jakiś przedpotopowy (w sensie aktualności bibliotek) system, to nie wymagaj, by pracowały na nim programy, które korzystają z nowszych bibliotek. I vice versa.
Samo rozwiązanie – jak wspomniałem – jakich wiele (flatpak, appimage, by wymienić najpopularniejsze) jest fajne w przypadku jakichś aplikacji z zamkniętym kodem, bądź… dla właśnie takich “skostniałych” dystrybucji.
A jeśli chodzi o dylemat “system ze świeżym oprogramowaniem, czy system stabilny”, to jest to bardzo kłamliwa teza. Ręczę Ci, że systemy oferujące “świeże oprogramowanie”, w tym przede wszystkim tzw. dystrybucje rolling release nie są mniej stabilne od “systemów stabilnych”, zaś. takie tezy, jak postawiona przez Ciebie jedynie wprowadzają ludzi w błąd.
No właśnie chodzi o to, że różnica w przypadku kalkulatora jest nieporównywalna do większych programów. Inaczej- im większy program tym różnica jest mniejsza. Stąd 150 MB zamiast 2 MB robi wrażenie, ale już 2,2 GB zamiast 1,85 GB nie robi takiej różnicy. Zresztą- ten system nie jest przeznaczony do drobnych aplikacji systemowych, a do kobył pokroju Photoshopa.
“No właśnie chodzi o to, że różnica w przypadku kalkulatora jest
nieporównywalna do większych programów. Inaczej- im większy program tym
różnica jest mniejsza.”
Buahahaha.
LibreOffice Windows x64 MSI: 238 MB
LibreOffice OS X Bundle: 201 MB
LibreOffice Flatpack: 156 MBs
LibreOffice x64 Deb package: 229 MBs
LibreOffice x64 RPM package: 229 MBs
LibreOffice AppImage: 246 MB
LibreOffice snap: 1.1 GB
O totalnej kompromitacji bezpieczeństwa systemu nie wspominając 🙂
Te całe snapy skończy jak Unity, Upstart, Mir, Compiz, USC i cała reszta ubuntowej myśli technicznej.
Nie rozumiem dla kogo to ma być, przecież jak ktoś chce system operacyjny z niełatanymi miesiącami dziurami, z dziurami w bibliotekach, które już nigdy nie zostaną załatane. Z systemem który na start zajmuje 80GB na dysku. Nie wspominając o innych głupotach Ubuntu jak spyware, dziwny niekonfigurowalny interfejs, czy ubogi sklep z aplikacjami to przecież w tych kwestiach nigdy nie dogonią mistrza Windowsa…
Mnie martwi to,że w tych paczkach będę zaszyte jakieś świństwa,a znając cannonical….Jest jakiś system sprawdzanie tego,co ta paczka instaluje,jak w normalnym repo?
Panowie,co się znacie na tym,wypowiedzcie się proszę!
W sumie czekam na ts3 w wersji synaps bo do dzisiaj nie potrafię zainstalować go poprawnie na linuxie :D. Wyjątkiem jest arch gdzie zainstalowałem sobie bez problemu jogurtem i śmiga ładnie”wgryziony w system”.
A w ogóle to nie było takich paczek,co zawierają wszystkie zależności we FreBSD?Czy w czymś takim?
Ej, ale Compiza to Ty szanuj, to że niestety obecnie jedynie devom Ubuntu chce się go rozwijać to nie znaczy, że jest to ubuntowa myśl techniczna.
Wystarczy ją rozpakować i zobaczyć co jest w środku. 😡
Wszędzie były, nie raz nie dwa. Jako dodatek zawsze. I zawsze kończyły tak samo.
Budowa całego środowiska w oparciu o Compiza to właśnie ubuntowa myśl techniczna.
W tym samym czasie autor Compiza porzucił ten projekt i przepraszał za jego wątpliwą jakość, a inne dystrybucje wywalały go z repozytoriów.
Canonical ma już wieloletnie tradycje w wielu takich genialnych planach 🙂
To był konflikt między autorem a Cannonicalem, które nie uwzględniło jego poprawek. Strzelił focha i zarzucił projekt zwłaszcza, że w tamtym momencie priorytetem był mir, na którym compiz nie chodzi. No cóż historia potoczyła się inaczej, od tamtego czasu wciąż mamy compiza a mira ani widu ani słychu 😉
“A jeśli chodzi o dylemat “system ze świeżym oprogramowaniem, czy system stabilny”, to jest to bardzo kłamliwa teza. Ręczę Ci, że systemy oferujące “świeże oprogramowanie”, w tym przede wszystkim tzw. dystrybucje rolling release nie są mniej stabilne od “systemów stabilnych”, zaś. takie tezy, jak postawiona przez Ciebie jedynie wprowadzają ludzi w błąd.” – to nie żadna kłamliwa teza tylko niezaprzeczalny fakt. Wynika on z rozwoju oprogramowania, po wydaniu przez deweloperów progamu zaczyna być użytkowany i wychodzą błędy które nie zostały wykryte podczas testów. Przykład: nie sądzę aby Plasma 5.7.0 była stabilniejsza od Plasma 5.6.5 (przynajmniej tak było do tej pory, owszem nowe wersje były stabilizowane względem starszej ale wprowadzały także nowe elementy które powodowały problemy) czy też Libreoffice 5.2.2 vs 5.1.4
Trzeba natomiast rozróżnić oznaczenie stabilny – tu kryje się błąd np. Ubuntu między wydaniami LTS oznaczone jest jako stabilne, ale w rzeczywistości tak nie należy jego traktować, to raczej blade edge w wersji skokowej. Dużo w tej kwestii napsuł Mandrake/Mandriva wydając wersje testowe pod oznaczeniem stabilne itd.
Co do dystrybucji rolling release to mogą być blade edge lub nie. Do tych pierwszy można zaliczyć np. Archlinuxa i Funtoo Linux, a do drugich PCLinuxOS czy Gentoo (z gałęzi stable).
Sam pomysł odseparowania oprogramowania od systemu i zamknięcie go w kontenerze jest bardzo dobry. Już dawno zauważyły do główne środowiska. Gnome, które rozwija flatpak jest w ten sposób dystrybuowane już od dłuższego czasu, teraz dołącza się KDE (jako że flatpak oparty jest o serwer wyświetlania wayland to jeszcze przez pewien czas nie ujrzymy stabilnej Plasmy czy programów ze stajni KDE ale prace idą pełną parą). Świetnie będzie mieć środowisko prosto od deweloperów, w najnowszej wersji, od razu po wydaniu i to niezależnie od bazy na której będzie stało (czy to archlinux, czy debian, czy fedora lub centos ewentualnie własny LFS 😉
“To był konflikt między autorem a Cannonicalem, które nie uwzględniło jego poprawek. Strzelił focha i zarzucił projekt…”
To chyba wystarczający dowód na to, że deweloperzy innych dystrybucji mają więcej oleju w głowie od tych z Canonicala i nie uzależniali się od takich wynalazków jak Compiz i jego rozhisteryzowany deweloper.
Zresztą Mark Shuttleworth jest tak samo rozhisteryzowany, dlatego nikt nie chce się uzależniać od jego fochów i nikt nie będzie traktował poważnie Unity, Mira, Upstarta czy teraz tego Snapy.
Być może brakuje mi wiedzy, ale
– przy dzisiejszych dyskach wielkość aplikacji ma drugorzędne znaczenie
– używam czasami aplikacji portable, zwłaszcza Steama, więc i snapy i mógłby się przyjąć
– widzę pewne problemy techniczne z tą wielkością, choć nie wiem jak to sprawdzić,
przy budowaniu portable
a) W Windzie pobierane są przy kompilacji tylko potrzebne funkcje,
pozatym tu też są zależności, tylko siedzą w systemie np. biblioteki C także nie rzuca się to.
b) W Linuchu pobierane są całe biblioteki, przez co efekt końcowy jest większy,
Pozatym czasami w dystrybucjach jest inna wersja glibc, wiec portable będzie wieksze.
Linux Torwalds miał podobno pracować na poprawą działania portable, więc może kiedyś zobaczymy
lepszy efekt końcowy, czas pokaże, a narazie jest jak jest.
nie wiem czemu piszesz tak nieprawdziwe informacje. Poziom redaktorów Fakt i niezależna.pl po prostu. Gdzie przeczytałeś, że system będzie zajmować 80GB miejsca na dysku po instalacji?
I jeszcze coś,
porównywając portable, a pakiet z zależnościami na Linuchu …
trzebaby się przyjrzeć ile niechcianych zależności instaluje nam pakiet.
Jak ktoś ma duży system, to prawdopodobnie nic,
ale jak ktoś ma odchudzony system, to pewnie też będzie sporo.
“- przy dzisiejszych dyskach wielkość aplikacji ma drugorzędne znaczenie”
Szczególnie w przypadku SSD 🙂
Samo miejsce na dysku to nie jeden problem. Bardziej istotne jest obciążenie łącza przy instalacji i aktualizacji kalkulatorków wielkości 100 MB i programów użytkowych po kilka GB każdy 😉
“trzebaby się przyjrzeć ile niechcianych zależności instaluje nam pakiet.”
I pewnie dlatego normalnemu Linuksowi wraz ze środowiskiem graficznym i oprogramowaniem wystarcza 4-6 GB na dysku, a taki Windows dzięki “oszczędnemu” nieużywaniu zależności potrzebuje jakieś 10x tyle miejsca 🙂
Nvidia wspiera tak samo waylanda jaki i mira. Natomiast bardzo szkoda upstarta – w debianie była “prawdziwa wojna” między zwolennikami upstarta a systemd. Trzeba zwrócić uwagę, że z upstarta korzysta także RHEL 6, a wielu jego użytkowników widzi przewagę między upstartem a systemd (tyle, że to już historia).
“Nvidia wspiera tak samo waylanda jaki i mira.”
Bo Mir to w zasadzie klon Waylanda. Ale to już temat na inna dyskusję.
A co na to Intel? 🙂
“w debianie była “prawdziwa wojna” między zwolennikami upstarta a systemd”
Głównie wśród wszelkiej maści internetowych trolli. Deweloperzy jednoznacznie (i to w kilku głosowaniach) spłukali Upstarta w toalecie.
“Trzeba zwrócić uwagę, że z upstarta korzysta także RHEL 6”
Musiał być z niego bardzo zadowolony skoro RH zaczął od podstaw tworzyć systemd 🙂
PS Coraz zabawniejsze te wywody wielbicieli Canonicla 🙂
“Głównie wśród wszelkiej maści internetowych trolli. Deweloperzy
jednoznacznie (i to w kilku głosowaniach) spłukali Upstarta w toalecie.” – no cóż ale mijasz się z prawdą. Komitet Techniczny wybrał systemd głosem jego przewodniczącego bo był remis. Proponuję przeczytać choćby https://dug.net.pl/news/568/
“Musiał być z niego bardzo zadowolony skoro RH zaczął od podstaw tworzyć systemd :)” jest zadowolony ale jednocześnie wspierał rozwiązanie konkurenta, który na polu serwerów coraz śmielej sobie poczynał i przejmował rynek. Cicha wojna między RH a Cannonicalem toczy się od blisko 10 lat, a zaczęło się od GTK. Systemd powstał w marcu 2010, a RHEL 6 wydano 10 października 2010. Gdyby im nie pasował to pozostaliby przy sprawdzonym system V, ale wtedy konkurencja by ich wyprzedziła i RHEL nie mógłby się chwalić, że jest firmą innowacyjną.
PS “Coraz zabawniejsze te wywody wielbicieli Canonicla :)” jeśli to do mnie to nie trafiłeś. Nie należę do wielbicieli jakiejkolwiek dystrybucji. Używałem wielu, prawdopodobnie większość z opisanych na distrowatch, a zaczynałem od Caldera Open Linux (https://en.wikipedia.org/wiki/Caldera_OpenLinux) w ubiegłym wieku 🙂
sam jeden libreoffice zajmuje 1,1G a mój obecny system z kompletem oprogramowania to niecałe 4G – ile to wszystko będzie zajmować w snapach? Oczywiście 80GB to trochę zgadywanka, ale żeby się nie okazało że będzie więcej…
” no cóż ale mijasz się z prawdą. Komitet Techniczny wybrał systemd głosem jego przewodniczącego bo był remis.”
W tamtym czasie Komitet Techniczny był zdominowany przez kretów z Canonical.
Głownie Ian Jackson, który był głównym prowodyrem całego wielomiesięcznego zamieszania:
““Ian Jackson previously worked for Canonical and was seen as a proponent
for Upstart. Ian was the one that last month called for the vote about
init system coupling.”
Na szczęście deweloperzy debiana jednoznacznie pokazali co myślą o jego pomysłach i zmienili skład Komitetu Technicznego.
https://vote.debian.org/~secretary/gr_initcoupling/results.txt
“Gdyby im nie pasował to pozostaliby przy sprawdzonym system V, ale wtedy konkurencja by ich wyprzedziła i RHEL nie mógłby się chwalić, że jest firmą innowacyjną.”
Po pierwsze SysVinit to była jedna wielka kupa, która nigdy się nie nadawała do poważnych zastosowań i stąd w ogóle powód powstania Upstarta i jego używania w RH i kilku innych projektach.
Po drugie RH to poważna firma na rynku i nie musi się niczym chwalić. To nie biznes pana Józka z Allegro czy jakiś inny bankrutujący Canonical 🙂
“Po pierwsze SysVinit to była jedna wielka kupa, która nigdy się nie
nadawała do poważnych zastosowań i stąd w ogóle powód powstania Upstarta..” – sysvinit był świetnym rozwiązaniem stosowanym powszechnie (obok skryptów w stylu bsd), wywodzącym się ze świata unix. Nigdy nie nazwał bym go kupą, choć z czasem zaczął miewać problemy. Skąd się wzięły opisano choćby tu https://dug.net.pl/news/15/
Dzisiejszym biznesem rządzi PR, czy to się nam podoba czy nie. RH zrobił swego czasu mistrzowskie posunięcie. Stworzył Fedorę, w której mógł testować wszystkie pojawiające się w świecie linuksa nowinki. Niestabilność tych rozwiązań nie obarczała bezpośrednio RHEL, bo oni brali przetestowane przez tysiące użytkowników rozwiązanie. Cannonical popełnił błąd udostępniając przejściowe wydania pod swoją marką, stąd zaniżenie wartości ich produktu. Po prostu testowali wszystko na żywym organizmie. Pozycję Ubuntu utrzymała akcja rozsyłania oryginalnych płyt instalacyjnych i to ich obroniło przed klęską. Zaistnieli w świadomości zbiorowej.
Jestem przekonany, że to się jeszcze zmieni, bo raczej nikt nie będzie chciał pobierać za każdym razem po 200MB danych by kalkulator zainstalować. Na razie to wygląda tak jakby hurtem były wrzucone wszelkie zależności, biblioteki i binaria do jednej paczki. Poza tym jak widzę po komentarzach, to cała histeria zarówno tu jak i na dobreprogramy jest tylko i wyłącznie dlatego, że to Canonical opracował snapy rękami swoich programistów, a tą firmę “polski światek kuców linuksowych” uważa za sprawcę całego zła i jednego procenta użytkowników na PC. Już nie daj Bóg wspomnieć o współpracy z MS w ich obecności. Gdyby to zrobili deweloperzy z Arch, Debiana czy Minta to nie byłoby żadnej histerii na taką skalę jaką widzę tu w komentarzach, tylko każdy by mówił “Paczka z libreoffice zajmuje 1,1GB. Sporo, ale to szybko naprawią. Wdrożono to przecież półtora miesiąca temu, nie ma co szarpać nerwów tylko zaczekajmy na spokojnie co się będzie działo.”
No to się można przyjrzeć. Nic trudnego. Bierzemy kod i… po chwili widzmy, że:
1. prawidlowo zbudowana paczka będzie miała w swoich metadanych informację o tym, że zależności to X, Y, Z (w odpowiednich, minimalnych, wersjach, a niekiedy i w maksymalnych),
2. podczas instalacji – menedżer plików – sprawdzi z tych X, Y, Z jest już zainstalowane w systemie, a czego brak – dociągnie to ostatnie tylko i wyłącznie,
3. jakikolwiek program pakowany jako JWA (jedna, wielka aplikacja) będzie miał dokładnie to samo co paczka, a nadto jeszcze wszystko to, co umożliwia mu w ogóle odpalenie się, w tym także te programy, które są już zainstalowane.
Cały ambaras z potrzebą istnienia wszelkiego rodzaju snapsów to działania niektórych dystrybucji, które wydają wersje “stable” utrzymując je przez wiele lat i niewprowadzając do nich nowych bibliotek, no bo to przecież “stabilne wydanie”. To jak stabilne, to inna sprawa. W ten sposób, wadliwie rozumiejąc stabilność systemu, dystrybucje te działają przeciwko rozwojowi oprogramowania. Stąd też gdy jakiś deweloper chce ulepszyć swój program i musi korzystać w tym celu z określonych funkcji umieszczonych w nowszych wydaniach ma do wyboru: albo wypuści dobry, dopracowany program, ale nie uda się go uruchomić na np. Ubuntu LTS, Debian Stable, Linux Mint itd., albo… musi wypuścić program gorszy, bez wszystkiego tego, co mógłby zawierać i jego twórca chciałby tam umieścić tylko i wyłącznie po to, by zapewnić możliwość pracy tego programu na najpopularniejszych – bądź co bądź – dystrybucjach. Tak, czy inaczej – efekty są opłakane. Oczywiście nic nie stoi na przeszkodzie w istnieniu aplikacji w kilku wersjach, tyle, że… na przeszkodzie stoi użytkownik, który z jednej strony ma wmówione, że wszelkie LTSy, Debian Stable itp. itd. (to jedynie przykłady, nie czepiam się ich) są najlepsze, bo “stabilne”, a wszystko inne “stabilnym” nie jest, a z drugiej strony chciałby mieć programy w najnowszych wersjach, bo tam są np. funkcje, których potrzebuje. Cóż jakoś nikt nie chce takiemu użytkownikowi wytłumaczyć, że jednak taka dystrybucja po prostu nie jest dla niego.
A Ubuntu nie ma innej drogi (podobnie jak kilka innych dystrybucji), jak tylko pakować część aplikacji w snappy itp. (choć akurat od snappy/snaps są lepsze rozwiązania), albowiem coraz częściej możliwość uruchomienia jakiejś nowej aplikacji będzie się bardzo rozchodzić od tego, co “w trawie” takiego LTS piszczy. Nadto – jeśli w ogóle Mir ujrzy światło dzienne – w ten sposób będzie mogło obchodzić pewne niekompatybilności oprogramowania z tym “serwerem”.
Fakt? Zadam proste pytanie: ilu dystrybucji typu rolling release używałeś? Ile z nich było “niestabilnych” (i co to w ogóle znaczy)?
Podany przez Ciebie przykład dotyczący Plasma jest natomiast zgoła wadliwy. Otóż Plasma 5.7.0 będzie “stabilnym” wydaniem. Podobnie jak “stabilnym” jest każde wydanie 5.6.x. “Niestabilne” wydanie będzie nosić (obecnie) numer 5.6.95. Podobnie z LO. Czy Plasma 5.7.0 okaże się stabilniejsza (w potocznym rozumieniu) od 5.6.5? Nie wiem. Wiem jedno – i tam odsyłam – że z lektury kodu źródłowego Plasmy, który ma zostać wprowadzony w 5.7.0 wynika, że deweloperzy czynią m.in. starania, by nowa jej wersja była stabilniesza od poprzedniej.
Podobnie też mylisz się poważnie nt. Arch Linuksa nazywając go “blade edge”. Prawdopodobnie nie używasz tej dystrybucji.
To nie chodzi o to, czy dane rozwiązanie pochodzi od X, czy Y. Coś jednak na rzeczy jest. Zobaczmy – spośród wymienionych wyżej LO wybierzmy wyłącznie te, które są zbliżone do “snaps”:
LibreOffice OS X Bundle: 201 MB
LibreOffice Flatpack: 156 MBs (tu jednak trzeba dodać nieco zależności, które muszą w systemie być)
LibreOffice AppImage: 246 MB
LibreOffice snap: 1.1 GB
Z porównania rozmiaru wynika, że jednak Canonical mocno przegiął ze swoim “standardem”. Jeśli “szybko to naprawią”, to… biorąc pod uwagę, że 16.04 jest LTS należało to wprowadzić wówczas, gdy zostanie odpowiednio dopracowane i zoptymalizowane. Obecnie strzelają sobie w kolano.
“Na razie to wygląda tak jakby hurtem były wrzucone wszelkie zależności, biblioteki i binaria do jednej paczki.”
Nie na razie, bo to o to chodzi w tych paczkach! Idea jest taka żeby w paczce były wszystkie zależności, i tak naprawdę są to swego rodzaju kontenery do uruchamiania aplikacji we własnym systemie… Ma to rozwiązać problem “dependency hell” gdzie program A wymaga liby L w wersji 1.5 a probram B wymaga aby ta liba była w wersji 1.9. To jest bardzo duży problem dla wszystkich dystrybucji, snapy mają go rozwiązać, ale nie uważam (moja opinia) aby to było najlepsze rozwiązanie. Poza tym nikt w Ubuntu chyba nie przemyślał kosztów tego rozwiązania – mam na myśli wad jakie to rozwiązanie wprowadza do świata Linuksowego.
Druga rzecz, Ubuntu jak zwykle wymyśla koło na nowo – bo tego rodzaju formaty już istnieją ale Ubuntu musi wymyślić swój bo nie daj boże musieli by dać trochę swojego kodu społeczności. Do tej społeczności od której 99% kodu ich Ubuntu pochodzi…
Tym razem się chwalą że snapy są kompatybilne z innymi dystrybucjami, co jest jakimś krokiem na w dobrą stronę, tyle że znając ich dotychczasowe poczynania zawsze mogą w którejś wersji wprowadzić takie “ulepszenia” że nie będzie działało poza Ubuntu.
Okazało się, że w tej paczce było parę “niepotrzebnych” rzeczy:
– The Ubuntu default install misses LibreOffice Base and Java unless you explicitly install them
– The Ubuntu default install misses debug symbols unless you install the package libreoffice-dbg too
i to powodowało rozepchanie tej paczki do monstrualnych rozmiarów. Teraz ten snap zajmuje 287MB.
Już było coś takiego jak Snapsy w PC-BSD a mianowicie pakiety PBI, tam LibreOffice ważył 741MB.
http://ftp.twaren.net/BSD/PCBSD/pbi/PBI/PBI/editors/libreoffice/9/x32/
Ale się jakoś nie sprawdziło. Niby instalka Windowsa też ma swoje zaleźności ale jest tego jak by mniej, plik PBI niby pod jeden system FreeBSD a też więcej te zależności zajmują niz na Windows. Wadą takiego rozwiązania jest to, że ostnio jak znaleźli lukę pod Linux nie tylko w jądrze ale i jakimś programie, pakiecie, to tylko aktualizowany jest ten pojedyńczy pakiet. Teraz pomyślcie sobie jak w systemie są różne paczki takich snapsów z róznymi zależnościami i pakietami które zawierają luki bezpieczeństwa niepołatane. Nie dość że długo zejdzie aby to załatać, to trzeba będzie cały snaps zmieniać i przebudowywać jego zależności.
Ale z drugiej strony jak by nie patrzeć to jest w fazie rozwoju. Snap LO 5.2 beta *ważył* aż 1 GB, ponieważ zawierał symbole debugowania.
Opiekun pakietu stworzył go na nowo bez tychże symboli i rozmiar paczki
zmalał do 287 MB.
https://skyfromme.wordpress.com/2016/06/16/a-third-of-a-libreoffice-snap/
“sysvinit był świetnym rozwiązaniem stosowanym powszechnie (obok skryptów
w stylu bsd), wywodzącym się ze świata unix. Nigdy nie nazwał bym go
kupą, choć z czasem zaczął miewać problemy”
Tak jak niemal wszystko w świecie unixa było świetne, ale 20-30 lat temu.
Potem to tylko prowizoryczne kombinowanie.
Wg Twojego linka nawet 10 lat temu, w i tak przestarzałym Debianie, były już z nim problemy, które ciągle narastały.
Otóż to. Snappy wbrew pozorom (bo od Canonicala) nie jest taki zły, a już na pewno jest bezpieczniejszy od appimage (odseparowanie programu od systemu) – podobnie jak flatpack. Dlaczego Snappy a nie Flatpack? Trudno powiedzieć, niech deweloperzy zadecydują, czego się im lepiej używa.
“Poza tym jak widzę po komentarzach, to cała histeria zarówno tu jak i na
dobreprogramy jest tylko i wyłącznie dlatego, że to Canonical opracował
snapy rękami swoich programistów, a tą firmę “polski światek kuców
linuksowych” uważa za sprawcę całego zła i jednego procenta użytkowników
na PC.”
Problemem nie jest jakaś twoja wyimaginowana histeria, a stek bzdur wypisywanych przez podobnych tobie głupio-mądrych komentujących.
Sam wasz guru Mark S wielokrotnie powtarzał, że Snap ma byc tylko dodatkowym narzędziem – obok apta – do dystrybucji dodatkowego (głównie komercyjnego) oprogramowania.
Nawet on w swoim pozornym szaleństwie doskonale sobie zdaje sprawę z realiów i pozycji Canonicala, wynikającej z braku jego zaangażowania w jakiekolwiek projekty społeczności i całkowitym braku wiarygodności.
Nie jest to koncepcja ani nowa, ani jakoś specjalnie wyrafinowana. Ba, jest wręcz prostacka w założeniach i wykonaniu. Istniały, istnieją i dalej są rozwijane inne różne podobne projekty i nikt poza oszołomami z pewnego środowiska nie robi z tych Snapów rewolucji.
LibreOffice Snappy: 286 MB (zobacz: http://people.canonical.com/~bjoern/snappy/)
Nie sądzę, żeby przy dyskach o pojemnościach rzędu TB już prawie na porządku dziennym jest sens rozwodzić się nad aplikacjami zajmującymi 100 i więcej MB – chociaż, kwestia kalkulatora ważącego aż tyle może być tu wyjątkiem…
Z tego co widziałem, to przy projekcie pracuje Polak, Zygmunt Krynicki – http://www.omgubuntu.co.uk/2016/04/ubuntu-16-04-lts-snap-packages polecam komentarze
” ilu dystrybucji typu rolling release używałeś?” – jeśli mnie pamięć nie myli to prawie wszystkich dostępnych.
Stabilność rozpatruję na dwa sposoby:
1. w potocznym rozumieniu – program się uruchamia, a zamyka go użytkownik a nie błędy, ewentualnie daje wyniki jakie się spodziewam a nie z kosmosu;
2. niezmienność bibliotek i narzędzi, na których programista może oprzeć swoje rozwiązanie i spodziewać się, że przez kilka lat ten stan się nie zmieni (bo wprowadzenie nowej funkcji “x” sprawi że funkcja “y” będzie działała inaczej lub że w nowej wersji będzie jeszcze funkcja “y”) – to powinna rozwiązać tzw. kompatybilność wsteczna ale jak ona wygląda w praktyce wie każdy kto dłużej używa oprogramowania.
Zwrotem “blade edge” Arch Linuksa określał jego twórca Judd Vinet. Uważasz, że się mylił? “Blade edge” według JV, to dystrybucja w której znajdują się najnowsze, oznaczone przez swoich deweloperów jako stabilne, wersje oprogramowania, najczęściej w kilka dni po ich wydaniu (czyli bez testów społecznościowych). Obecnie jedną z dystrybucji, które wykorzystuje to Manjaro oparte na ArchLinuksie. Służy mi głównie jako podgląd nowości w świecie linuxa. Jako “konia roboczego” używam jedną z dystrybucji LTS – mam pewność , że po upgrade min. drukarka będzie mi nadal działała. Z archem czy manjaro nie było tak różowo 😉
“Podobnie też mylisz się poważnie nt. Arch Linuksa nazywając go “blade edge”.”
Zapomniałem dopisać:
“Arch strives to stay bleeding edge, and typically offers
the latest stable versions of most software.” – to ze strony archlinux.org https://www.archlinux.org/about/
“Cały ambaras z potrzebą istnienia wszelkiego rodzaju snapsów to działania niektórych dystrybucji, które wydają wersje “stable” …” – ten ambaras wynika raczej z innych przesłanek. Według mnie chodzi o:
1. dostarczenie twórcom oprogramowania narzędzia, które pozwoli na dostarczenie ich produktu jak największej liczbie odbiorców niezależnie od dystrybucji z której korzystają,
2. sprawdzenie przez użytkownika nowych wersji oprogramowania bez ingerencji w system bazowy,
3. zwiększenie bezpieczeństwa poprzez zamknięcie najbardziej narażonych elementów systemu w “piaskownicy”,
4. używanie oprogramowania na systemach, które ze względu na swoją budowę na to by nie pozwalały przy wykorzystaniu obecnego modelu rozwoju dystrybucji (czyli to co Ty opisałeś).
Linuxa mam na 40gb ssd i ostatnie co zrobię, to zainteresuję się snapsami canonical’a.
Ja mam na ssd 256gb, ale na pewno nie po to żeby marnować to na takie rzeczy. Wolę tam mieć katalog użytkownika (poza kilkoma podkatalogami, które za bardzo się roztyły żeby siedzieć na ssd).
@Salvadhor: Jeśli zapytać by dowolną osobę o największą bolączkę Linuksa, to w
większości przypadków bez chwili zastanowienia otrzymamy odpowiedź: „Za
dużo dystrybucji”…
Nie do końca… Dla mnie największym problemem jest brak Corela pod Pingwina. To może być przyczynek do mojego rozwodu z wolnym oprogramowaniem. Próbowałem z Winem (CorelDraw 11), ale bezskutecznie.
Na Yotube jeden młody Portugalczyk pokazuje jak zainstalować X3 (https://www.youtube.com/watch?v=857UeYRKUuE), ale wstawia jakieś biblioteki mfc71u.dll, a ja nie wiem czy to jest legalne i w jaki sposób legalnie nabyć takie biblioteki. Potem Winetricks-em instaluje mfc42.. czy to jest zgodne z prawem?
Brak Google Sketchup-a też trochę doskwiera…
No cóż, tak to już jest na linuksie. Jeśli chcesz obsługi windowsowych aplikacji to pozostaje tobie CrossOver. Bodajże za 200 zł masz możliwość instalacji wielu programów z wiodącego systemu. Co do Corela https://www.codeweavers.com/compatibility/search?name=corel jak widać CorelDraw 11 jest obsługiwany dość dobrze 🙂
Dlatego wielu grafików przenosi się na Mac OS. Sporo profesjonalnych narzędzi jest tam dostępnych natywnie.
a nielepiej zamiast snapów. robić tak jak zrobili z krita3? appimage
ja tam wolał bym appimage
Dzięki bardzo K.
Właśnie sprawdziłem 11-tkę i dział na czystym Winie. Szczerze mówiąc szczęka mi opadła, bo tyle się nasłuchałem, że nie ma Corela pod Linuxa, że uwierzyłem w to bez sprawdzania, a mój stary CorelDraw leżał nieużywany w szufladzie… zresztą zobaczcie sami..
http://www.imagic.pl/files/view/20696/CorelDraw11_Linux.jpg
Reasumując mogę pozostać i pracować na Linuxie (czyli AOO, TB i CDraw). Czas pokaże, czy była to dobra decyzja.
Z tym bezpieczeństwem snappy znalazłem coś takiego:
1. http://snapcraft.io/#responsive-tab-content-4 – wygląda na to, że należy zrobić wyjątek dla SELinux, jeśli go stosujemy,
2. “Any Snap package you install is completely capable of copying all your private data to wherever it wants with very little difficulty.” (zob.: https://mjg59.dreamwidth.org/42320.html ).
Nie wiem, nie znam się, ale wychodzi na to, że raczej z bezpieczeństwem snappy nie ma wiele wspólnego.
Ups – winien Ci jestem przeprosiny. W opaczny sposób Cię zrozumiałem.
I nie chcąc wchodzić w wyższość jednych świąt nad innymi – tak na zupełnym marginesie. Z Debiana Stable – przed wielu laty – musiałem zrezygnować, albowiem po aktualizacji ukazało mi się 1/4 pulpitu na całym ekranie. Deweloperzy nie uznawali tego za błąd i jedna grupa odsyłała go do drugiej, a tamci ponownie do pierwszej itd. W Siduksie, Ubuntu – działało bez problemu z tymi samymi wersjami Xów i sterowników. Fakt – zdarza się to niezmiernie rzadko, ale jednak.
Na sterownik do mojej drukarki w Chakra, Manjaro, Arch napsioczyłem się ile wlezie, albowiem co jakieś 1-2 miesiące przestawał działać. Winnym okazał się wadliwie napisany skrypt PKGBUILD (i CCR, który go po prostu przepisywał).
W flatpaku, portable jest LOBase 🙂
Swoją drogą ciekaw jestem jak w przypadku LO-snappy działają te elementy w LO (np. rozszerzenia takie jak skądinąd świetne languagetool), które wymagają javy (oczywiście, gdy jest ona systemowo zainstalowana).
“Tym razem się chwalą że snapy są kompatybilne z innymi dystrybucjami, co jest jakimś krokiem na w dobrą stronę (…)”. Nie wspominają jednak (w swoich PR wystąpieniach), że snappy jest dostępne dla wielu systemów, pod warunkiem, że menedżerem usług jest tam SystemD 🙂 Szczególnie bawi mnie sposób uruchomienia w Gentoo: https://assets.ubuntu.com/v1/2235d892-gentoo.png 🙂
Nie ma sprawy 🙂
Jeśli CorelDraw 11 zadziałał na czystym wine, to byćmoże pójdzie też wspomniany przez Ciebie Google Sketchup. W CrossOver obsługiwany jest b.dobrze https://www.codeweavers.com/compatibility/search?name=sketchup
Pamiętaj o starej zasadzie: jeśli jakiś ważny program działa na wine to nie instaluj jego nowszej wersji. Sprawdź najpierw na systemie zapasowym. W przeszłości projekt wine miewał regresje co skutkowało brakiem możliwości uruchomienia aplikacji.
Jak dla mnie idealna sprawa. Nie musiałbym czekać z drżeniem serca, czy dany program albo inne aplikacje współdzielące z nim biblioteki, wstaną po aktualizacji bez problemu. Jak coś mi w nowej wersji nie zatrybi, to po prostu wrócę do wcześniejszej.
Bezpieczeństwo też byłoby większe, o ile udałoby się oddzielić te paczki od systemu w wystarczającym stopniu.
Jeśli chodzi o wielkość pakietów, to jak rozumiem jest problem wieku niemowlęcego. Z czasem pewnie paczki zostaną zoptymalizowane i będą większe powiedzmy tylko o 80% od pakietu deb czy rpm.
Patrząc z punktu widzenia osób stosujących Linuksa w codziennej pracy, rozwiązanie ma bardzo dużo zalet, zdecydowanie przeważających nad wadami:
– brak kolizji przy aktualizacjach
– zawsze najnowsza wersja, bez oglądania się na resztę środowiska
– odpadają problemy z zależnościami przy instalacji
– bezproblemowa deinstalacja
– separacja od innych aplikacji i systemu
– przenośność między różnymi dystrybucjami Linuxa, (multi-dystrybucyjność?! ;D )
Jeśli będzie trzeba to chętnie kupię większe dyski czy szybsze połączenie internetowe. I tak to pójdzie w koszta, alternatywą jest oddanie tej kasy skarbówce. Choć szczerze mówiąc dyski w firmowych komputerach zajęte są średnio w ok 25% a łącze jest 20 Mb, więc w moim wypadku nie widzę żadnych problemów. Potencjalnych korzyści natomiast całe mnóstwo.
A ciekawe jak wygląda Flatpak od RedHat’a, chwalą się że jest dużo dojrzalszy, oparty na starszych projektach. Z kompatybilnością z popularnymi dystrybucjami by design. Tak czy siak kolejna potyczka Canonical kontra reszta świata.
A co do zależności systemd… chyba taki świat nas czeka, że Linux == Systemd.
Mi się nie podoba to że jest to jeden wielki pakiet do wszystkiego… ale na chwilę obecną nie chciałbym używać systemu bez Systemd, bo nic innego nie stanowi sensownej alternatywy i nawet nie chodzi mi o sam init, a o resztę narzędzi, które dostarcza.
Wypróbuj sam: http://www.libreoffice.org/download/flatpak/ – dowiesz się.
Jeśli chodzi o systemd – tak masz rację. 90% obecnego linuksowego (i aktualnego) świata, korzysta z systemd. Problem leży jednak gdzie indziej. Czyli we wciskaniu się w systemd nawet wówczas, gdy nie jest to w żaden sposób potrzebne (skoro żadna alternatywa snapsów nie wymaga systemd, a tylko on tak, to usługa ta nie jest konieczna do pracy paczek zrobionych w taki, czy podobny sposób).
Nadto chodzi mi o coś innego. O zwykłą przyzwoitość. Canonical swoim zwyczajem rozpuszcza wici, że wymyślił coś cudownego (choć tym razem przynajmniej wprowadził). Nadto usiłuje wcisnąć za przeproszeniem ciemnotę, że jest to rozwiązanie najlepsze z dostępnych oraz że jest dostępne dla “wielu systemów”. I oprócz tego, że wymyślił i wprowadził u siebie nic tu nie jest prawdą. Zwróć uwagę, że “domyślna” (to pewne uproszczenie, proszę mi wybaczyć) instalacja Gentoo oparta jest o openrc. Opisany sposób instalacji w Gentoo tego ustrojstwa wymaga zamiany openrc, które jest tam chyba na większej ilości instalacji na systemd. Podobnie na wszystkich innych systemach, które nie korzystają z systemd. Dlaczego zatem Canonical zamiast wciskać ciemnotę nie powie: opracowaliśmy coś, co jest dobre (ich zdaniem) i będzie mogło być uruchamiane na systemach z systemd? Odpowiadałoby to prawdzie, gdyby nie to, że… rozwiązanie to nie startuje np. na Archu (wg informacji ma wsparcie, czyli… PKGBUILD uniemożliwiający jednak korzystanie z aplikacji), a w Fedorze wymaga ingerencji w bezpieczeństwo tego systemu.
Pomijam inne – niezbyt czyste – PRowskie zagrania.