Názory k článku
Ubuntu přestane nabízet Flatpak
-
O žádném takovém nezávislém srovnání nevím. Osobně se domnívám, že to není jednoznačné. Nespornou bezpečnostní výhodou Snapu patří možnost snadno instalovat citlivé software jako izolovaný sandbox, což u serverového software nebo obecně negrafických aplikací Flatpak neumožňuje. Příklady viz Nextcloud, Postgres, openHAB atd. Dále je izolace u Snapu těsnější, než u Flatpaku.
Naopak výhoda Flatpaku je, že umožňuje jemné nastavení oprávnění a sandboxu jednotlivých aplikací, což ve Snapu nejde. Navíc Flatpak umožňuje lepší a snažší kontrolu nad aktualizacemi jednotlivých balíků. Ve Snapu se aktualizace provédějí v podstatě samovolně a to může být problém.
Z hlediska funkčnosti pro uživatele má Flatpak nespornou výhodu v tom, že dovoluje i neprivilegovaným uživatelům, aby si instalovali vlatsní aplikace, a možnost "přenosných" instalací. Pro vývojáře a baliče mi zase snap připadá snažší, byť otravnější.
-
nejsem moc příznivcem snapu, vadí mi, že se chlubí bezpečností, přitom to je obal nad cgroups, apparmor a seccomp, řeší hlavně OS level isolation (jaký je český překlad) a neřeší izolaci HW, stejně tak neřeší co je obsahem samotného snapu nebo nepoužívá namespaces.
Vadí mi, že navozuje milný dojem a neřeší ty temnější části. Bere s sebou nevýhodu neprůhledných aktualizací a dalšího stromu závislostí, které je nutné někým udržovat.
Rozumím kam s tím Ubuntu míří, pro uživatele s desktopem to je pokrok, pro mě spíše překážka.
-
Já bych ještě doplnil, že v mnoha distribucích je sandbox Snapu úplně vypnutý, takže aplikace nejsou izolované nijak. Lidi z Canonicalu nám slibovali už před 5 lety, že to ve Fedoře vyřeší, a doteď to není a myslím si, že už asi ani nikdy nebude.
Navrhovali to jako distribuční formát pro Ubuntu, pak to z toho udělali multidistribuční formát, aby podpořili adopci vývojáři aplikací, to se moc nechytlo, tak teď to zase postupně směřuje k tomu, že to bude jen pro Ubuntu. -
aj, to je pěkný facepalm, vím, že snap podporuje i RH distribuce, ale naprosto jsem netušil, že vlastně jen na půl a všechna ta povídání v dokumentace kolem bezpečnosti tam nejedou.
Díky za info, to mě ani nenapadlo testovat. Naštěstí je zaměří primárně na uživatele a nás z headless serverů to nechává klidný.
-
mozna je to o tom ze Fedora ma specialni pozadavky, protoze treba na Arch Wiki: https://wiki.archlinux.org/title/Snap vidim:
Snaps can be confined using AppArmor which is now enabled in the default kernel. Consult relevant wiki pages to find steps for enabling AppArmor in your system.na https://wiki.archlinux.org/title/AppArmor pak:
Ubuntu, SUSE and a number of other distributions use it by default. RHEL (and its variants) use SELinux which requires good userspace integration to work properly. -
My nemáme speciální požadavky, my prostě používáme SELinux. Ale i to se dá řešit, lidi z Canonicalu nám předložili plán, jak to vyřešit, ale bohužel zůstalo jen u něj. Co jsem slyšel, tak v Snap týmu byly tyhle věci deprioritizované. Mají teď prostě jiné priority, než pracovat na tom, aby snap fungoval dobře v jiných distribucích. Nemám jim to za zlé, nakonec není to charita, ale byznys, který si na sebe musí vydělat.
-
Tak ono to není v "mnoha" distribucích, ono je to prostě v Red Hat distribucích, protože jak říkáte, ty používají SELinux a ne AppArmor. Na druhou stranu tady platí obecné pravidlo open source: když někdo něco chce, je na něm, aby se postaral, že se to implementuje. Neboli Red Hat klidně mohl podporu SELinuxu pro snap implementovat sám. Taky vám nijak nevytýkám, že jste to neudělali, máte jiné priority, ale je přece jenom licoměrné v tom případě vinit Canonical.
-
SELinux nepoužívají jenom naše distribuce. Pokud navrhuji multidistribuční formát, který má fungovat pokud možno všude, navrhnu ho tak, aby používal technologie, které jsou opravdu všude. My jsme si taky původně hráli s myšlenkou, že budeme ve Flatpaku používat SELinux, ale nepoužili jsme ho právě proto, že řada distribucí ho nepoužívá. BTW ono to nebylo jen o SELinuxu, několik let se čekalo i na to, až se dostanou patche pro AppArmor, které Snap vyžaduje, do mainline Linuxu.
Jinak máte pravdu, že je to primárně o motivaci, ale pokud chcete dostat něco do distribuce, tak je primárně na vás, abyste se přizpůsobil distribuci, ne distribuce vám. Snad nepovažujete za rozumné, aby distribuce kvůli jednomu novému balíčku kompletně změnila security model, který používá 20 let. Když jsme Flatpak dělali, tak jsme se my snažili, aby výborně fungoval v Ubuntu. Alex sám spravoval PPA s nejnovější verzí, přizpůsobovat se feedbacku, když to šlo v Debianu přes review, rozhodně jsme nečekali, že by pro nás ostatní distribuce dělaly zásadní ústupky v tom, jak věci dělají. -
S názorem, že se mají používat jenom funkcionality, které jsou opravdu všude, celkem nesouhlasím. Je to ta stará redukce na nejmenšího možného jmenovatele, která dlouho držela vývoj zpátky a ve velké míře ho stále ještě drží (i když už naštěstí aspoň není "zakázané" používat moderní featury linuxového jádra, a ne se nábožně držet POSIXu).
Jinak ale nikdo samozřejmě po Red Hatu nechce, aby změnil bezpečnostní model. Jde o to, že přizpůsobení snapu bezpečnostnímu modelu Red Hatu nemusel nutně dělat automaticky Canonical, mohl to udělat i Red Hat. Nemyslím si totiž, že Canonicalu někdy nějak kór šlo o to, aby snap fungoval i v ostatních distrech. Koneckonců jde o přidanou hodnotu jejich vlastní distribuce. Ale kdybyste to vy v Red Hatu byli implementovali, byl by to přínos pro uživatele vašich dister, protože by pak mohli snadno používat hodnotné software jako např. LXD, které se distribuuje formou snapu a oficiálně dneska na RH distribucích není podporované vůbec (neoficiálně/nepodporovaně to jde do jisté míry, ale je to hrozný opruz).
-
S názorem, že se mají používat jenom funkcionality, které jsou opravdu všude, celkem nesouhlasím.
No, s tím samozřejmě nemusíte souhlasit, ale to je realita multidistribučních řešení. Čím víc to postavíte na věcech, které nejsou samozřejmostí v každé aspoň trochu nové distribuci, tím větší problémy potom budete mít.
Ale kdybyste to vy v Red Hatu byli implementovali, byl by to přínos pro uživatele vašich dister, protože by pak mohli snadno používat hodnotné software jako např. LXD, které se distribuuje formou snapu a oficiálně dneska na RH distribucích není podporované vůbec
To je pěkné, ale my opravdu nemáme vývojáře, kteří jen čekají, až někdo s něčím dojde, aby s tím pohnuli a dostali to v požadované kvalitě do distra. Víte, kolik takových věcí dnes je? Kdybyste viděl naše issue trackery... Když kernel přešel na cgroups2, tak Docker šel (dočasně) z Fedory, protože prostě nemáme zdroje na to, abychom tomu projektu pomáhali je implementovat. A to Docker je významem úplně někde jinde než LXD. Realizovat můžeme tak 2 věci z 10, které by se nám líbilo udělat. A takhle to mají ve všech distribucích, práce je hromada. Nikde vás nečekají s otevřenou náručí, že to dodělají za vás. Buď to udělá sám autor nebo někdo z komunity, komu záleží na tom, aby to v distru bylo. U Snapu ve Fedoře nakonec neplatilo ani jedno.
Nemyslím si totiž, že Canonicalu někdy nějak kór šlo o to, aby snap fungoval i v ostatních distrech.
Původně jim o to nešlo. Pak ale zjistili, že pokud má Snap uspět, nemůže být Ubuntu only, a začali podporu napříč distribucemi hodně řešit. Objíždět konference, přesvědčovat, slibovat. Zjistili ale, že to udržování kvalitní podpory v jiných distribucích je dost obtížné, protože původní návrh na to moc nebral ohled, a taky celkově přijetí v linuxové komunitě bylo chladné kvůli věcem jako proprietární distribuční kanál a CLA, tak ta podpora ostatních distribucí šla na druhou kolej, což jak už jsem psal, jim nemám za zlé. Je to prostě byznys a teď se jim spíš vrátí prostředky, které vloží do snapu pro IoT přímo na Ubuntu.
-
Viz komentář ohledně podpory Flatpaku od zaměstnance Canonicalu a hlavního vývojáře nového GUI software store (které nejspíš časem nahradí GNOME Software / KDE Discover i v odnožích Ubuntu).
-
Doporučuji číst i mezi řádky.
Google Play, App store, Microsoft Store, Steam, Epic Games atd.
Všechno je to o určování pravidel, kontrolou nad ekosystémem a samozřejmě o tom nejdůležitějším ‒ zisku.
GNOME Software, KDE Discover, FlatHub, atd. jsou komunitní projekty, které nemají za cíl generovat zisk.
Subjektivně mi přijde např. Elementary appcenter jako něco akceptovatelného i s ohledem na placené aplikace, ač to tak vnímám možná z důvodu že je Elementary "outsider" na tomto poli.Každopádně Ubuntu chce prostě kontrolu jako každý hráč na trhu a to rozhodně není v dlouhodobém horizontu ve prospěch běžného uživatele.
23. 2. 2023, 18:27 editováno autorem komentáře
-
Používáte tady někdo tyto řešení (Flatpak, Snap, AppImage) i na domácím stroji pro bežné aplikace např. Firefox, Spotify, ...? Zkoušel jsem tyto 3 a přes všechny deklarované výhody mě to přijde horší než používat balíčkový systém distribuce (hlavně mnohem pomalejší). Opravte mě pokud se mýlím, ale nabyl jsem pocitu, že jsou tyhle řešení spíš výhodné pro distributory softvéru než pro uživatele.
-
Já mám tak tři, čtyři appky, které občas využiji jako Flatpak, protože nejsou ani v AUR. Jako AppImage jsem měl asi dvě appky, ale zjistil jsem nakonec, že je vlastně vůbec nepoužívám, tak jsem je smazal.
Ty co mám jako Flatpak, tak jsou i ve Snapu, ale Snap (když ještě byl nainstalovaný), tak se spouštěl se systémem jak daemon, v čemž vidím nevýhodu a zbytečnost, když Flatpak nic takového nepotřebuje. Možná kdybych ty apky používal často, tak bych začal porovnávat výhody a nevýhody...
-
v Xubuntu 22.04 na desktopu pouzivam:
Flatpak: Geary (autor prestal pred casem delat DEB (coz by stejne pri pozadavku na novejsi Gnome casti nestacilo), ale dela Flatpak)Snap: pouzival sem pro kernel-livepatch, ale presel na ubuntu-mainline-kernel kterej to nepodporuje, protoze vychozi kernel ma umele zablokovanou hibernaci s SecureBoot
AppImage: obcas pustim Etcher, nebo nejaky program co jen otestuju ci jednorazove pouziju a autor ma AppImage pripravenej
BTW: firefox co je by default v *buntu v snap sice pouzivam okrajove ale na primarnim sem kvuli nejakejm uz nevim jakejm drobnostech presel zpet na deb (nicmene problem nebyla rychlost startu)
-
Je to trochu ubíjející sledovat.
Dřív se velcí hráči snažili o vendor lock na úrovni HW a návazně SW. Když už to s HW tak dobře nešlo, protože nastoupila, jakž takž, standardizace a modulárnost, snažili se o lock na úrovni OS a následných aplikací. Když to, také významnou měrou nešlo udržet, také díky GNU, OSS a dalším, tak se vymyslel koncept kdejakých uzavřených ekosystémů "Store/repozitářů aplikací".
"Krucipůsk", jsme tu společně na jedné hroudě kamení letící vesmírem, což takhle postoupit dál, od konceptu soupeření mezi korporáty a vložit tu energii raději do nepředstírané spolupráce.
-
vidis to jednak cerne a druhak zaslepene ;-)
autori nejake distribuce muzou (a casto maji) nejake specialnejsi pozadavky, ktere nejake zazita(nebo vznikajici) komponenta, nedokaze (ci nechce) splnit, tezko pak budou si narokovat pridani do upstreamu neceho co by chteli jen oni, nebo naopak to rozbijelo neco co si preji/kam smeruji puvodni/hlavni autori te komponety...
takze je pak logicke ze se bud udela fork, nebo neco na zelene louce, stejne tak je logicke ze casem (z jakychkoliv duvodu) se to muze zmenit a prejde se ne neco "mainstreamove" se zachozenim toho sveho (viz napr. Unity, Mir u Canonicalu)
u snapd kterej byl od pocatku zamyslen na server, IoT atd (ale tvurce Canonical ho mohl dle sveho upravit i pro Desktop aby si to sjednotil), by asi tezko se zahodilo a preslo na flatpak, kterej byl od pocatku zamyslen pro Desktop (a pokud vim stale neumi bez Desktopu fungovat, takze nepouzitelne pro server, IoT, atd)
-
Flatpak byl navržený jen pro desktopové aplikace, protože v době, kdy vznikal, už široce rozšířené řešení pro serverové aplikace existovalo - Docker. Plýtvat energii na soupeření se zavedeným řešením místo toho, abychom ji věnovali zaměření na to, pro co jsme to vytvářeli primárně - desktop, nedávalo smysl. A to mi trochu přijde, že je problém Snapu, snaží se to být řešením na všechno, ale na nic pořádně. Minimálně na desktopu to tak vypadá.
Jinak Flatpak je sice jen pro desktop, ale snaží se držet co nejblíž ostatním kontejnerovým technologiím. Nakonec dá se i zabalit a distribuovat ve formátu OCI kontejneru a používat tak stejné repozitáře jako Docker/Podman. -
Pls, je mozme pomocou flatpacku mat viacero nezavyslych instancii tej istej aplikacie? Nieco ako ma Snap https://snapcraft.io/docs/parallel-installs ?
-
RE. Černě a zaslepeně:
Nevím, na kolik jsi se věnoval tématu multiplatformního nasazování aplikací, nebo jejich životnímu cyklu. Studoval jsem to, věnoval tomu část diplomové práce, od roku 1994 v pozici systémového administrátora pro několik společností to mám denně na talíři, učím o tom studenty.
Není to záruka, že to nevidím černě a zaslepeně, ale snad to z mé strany není jen hospodský žblept Neználka.Nejsem zastáncem "jediného správného řešení", mám rád diverzitu, když přináší nové pohledy a nová řešení. Zároveň jsem přesvědčen o tom, že nás stojí obrovské prostředky, když vázne spolupráce, nebo když se někdo snaží na vydělat pomocí vendor lock. Ten vendor lock vidím spíš v Google Play, App store, Steamu, Epic store,... Problematickou spolupráci vidím v oblasti apt / deb / rpm / snap / flatpack / emerge / pacman / pip / brew / gem / zypper / ... (a dalších > 60 technologií nasazení SW). a to nemluvím o tom, že si kdejaký SW řeší aktualizace sebe a případných addonů, pluginů, modů po svém.
Autoři distribucí, nebo celých OS, mohou mít speciální požadavky, to ale neznamená, že by tu neměl být standardizovaný základ, protože většina procesu nasazení aplikace v nějakém systému je stále o stejných úkonech.
IMHO ani server vs desktop nejsou v tomhle natolik odlišné světy, aby potřebovaly dva různé standardy pro stejnou věc.25. 2. 2023, 09:54 editováno autorem komentáře
-
Balíčkovací systémy – ono se to snadno řekne, ale provedení už není tak triviální. Dejme tomu, že bychom chtěli udělat nějaký společný základ. Vidím tu dvě možnosti:
a. Udělat nějaký standard, a k němu jednu implementaci. Tady řešíte, ve kterém jazyce to má být. Pro některé balíčkovací systémy byste asi neuspěl s ničím vyšším než C, případně možná Rust. Pro npm/pip/gem by to asi nějak šlo, ale muselo by tu být zatraceně dobře navržené API, aby do toho základu nepotřebovali vývojáři npm/pip/gem moc sahat.
b. Udělat nějaký standard, a k němu několik implementací v různých jazycích. Jednu v JS, jednu v C, jendu v Ruby, … Moment, tady už toho ale moc nešetříte, a ještě přidáváte overhead na vzájemnou domluvu – dejme tomu, že třeba vývojáři emerge budou chtít nějakou změnu kvůli use flags. Místo toho, aby si upravili svůj software, budou řešit schválení změn standardu s vývojáři, které use flags reálně nezajímají. Nakonec to použije Cargo, ale i tam ty use flags vypadají jinak.Dále když dva dělají totéž, často to není totéž. Představte si třeba situaci, kdy se v dependency graphu objeví dvě různé verze téhož balíčku. Nainstalovat obě? Nainstalovat tu novější? Vyhlásit konflikt? Rozhodnout se podle toho, jak moc se liší čísla verzí? Nemáte tu jediné správné řešení. A obávám se, že takovýchto rozdílů při troše hledání najdeme mraky. Reálně by tak společného základu možná až tolik nebylo. Možná servery nabízející balíčky by mohly být někdy stejné.
A nakonec, co z toho? Ušetřená práce na vývoji balíčků? Asi moc ne. Větší vzájemná kompatibilita? Asi taky ne, ani třeba u deb nemůžete použít ten stejný balík pro Ubuntu a Debian, nebo pro různé verze distribuce. Jednotné rozhraní? Možná trochu, ale totéž můžeme mít i v současném situaci – vizte třeba PackageKit. Nemám pocit, že by získal nějakou velkou popularitu.
Tím neříkám, že by nějaký společný základ udělat nešel, nebo že by nic nepřinesl. Spíše se obávám, že náročnost je neúměrně vysoká vzhledem k přínosu.
