Vývojář KDE Markus Slopiank se na svém blogu zaměřil na podporu Flatpaku a Snapu v současných linuxových distribucích Arch Linux, Debian, Fedora, Gentoo, Mageia, openSUSE, RHEL/CentOS a Ubuntu. Vypadá to, že Snap je dobře podporován jen v Ubuntu, zatímco Flatpak v Arch, Debian, Fedora, openSUSE a dokonce i v Ubuntu.
(zdroj: phoronix)
Může mi někdo prosím vysvětlit v kostce v čem přesně spočívá přínos Flatpaku nebo Snapu?
Pokud jem pochopil správně funkcionalitu tak si sebou bude aplikace nosit i některé knihovny na kterých je závislá.
Není to plýtvání místem když se může použít knihovna systémová?
Není to trochu proti Unixové filozofii? "Dělej jenom jednu věc a dělej ji dobře?"
Nevzikne tak v linuxu podobný problém jako ve win kde občas bývá chaos s dll?
Jak můžu vědět, že se v nějáké přibalené knihovně neskrývá nějáký malware?
To budou repozitáře Flatpak/Snap aplikací obsahovat odkaz nebo dokonce i zdrojáky použitých knihoven?
Je to sracka kde nefunguje ani IME ... tzn nepouzitelny pro pulku sveta.
Vyznam flatpaku je ze to aspon zamestna nekolik gnome taky-vyvojaru a nemaji pak cas vic nicit gnome :).
Flatpack nebo Snap řeší situaci, kdy potřebuju v systému mít dvě různé verze knihoven, protože 2 programy, které chci pouštět vyžadují každý jinou verzi. Také umožňují uzavřít aplikaci do kontejneru a zvýšit tak bezpečnost.
> Není to plýtvání místem když se může použít knihovna systémová?
Což je cena, kterou jsou uživatelé ochotní zaplatit za to, že jim to pojede.
> Není to trochu proti Unixové filozofii? "Dělej jenom jednu věc a dělej ji dobře?"
A když se ty malé věci, co dělají jednu věc dobře poskládají do větší, tak máme linuxový desktop, který dělá spoustu věcí (a někdy i dobře :-) ). Nebo máme Flatpack či Snap
> Nevzikne tak v linuxu podobný problém jako ve win kde občas bývá chaos s dll?
Systém má svou knihovnu a aplikace taky svou
> Jak můžu vědět, že se v nějáké přibalené knihovně neskrývá nějáký malware?
:-) stejně jako u jiného software
> To budou repozitáře Flatpak/Snap aplikací obsahovat odkaz nebo dokonce i zdrojáky použitých knihoven?
Imho můžou používat sdílené knihovny z OS nebo své vlastní.
no daleko podstatnejsi problem kterej ot resi tvari v tvar tem srackam co dnes linux je je moznost mit (teoreticky) v necem stabilnim (tozn x let starem se sarymi sle znamymi bugy) aplikace ktere jsou dnesni soucasne, tozn roling updates ale jen pro vyjimky ne pro cely system; teoreticky
Já myslím, že problém může být s bezpečností. Pokud si aplikace s sebou táhne nějaké knihovny, tak by to měly být opravdu jen ty obskurtní a pro ni specifické, ne běžné. Nerad bych měl v systému třeba 50x knihovny pro SSL, z toho 45 jich zastaralých a nezáplatovaných (protože vývojář už to dávno zabalil).
Tento problém se řeší izolací aplikace do kontejneru.
Imho může dost dobře fungovat kombinace klasického systému s jednou nebo několika málo aplikacemi ze snapu nebo flatpacku.
V případě, že bude 50 aplikací používat trochu jinou verzi knihovny, tak to opravdu může vypadat tak jak píše Kamui. Záleží hodně na vývojářích dotyčných aplikací jestli udržují svou aplikaci aktualizovanou a bezpečnou pro své uživatele. Imho je třeba si umět vybrat, které aplikace chcete ze snapu nebo z flatpacku.
Ano, ano, ano.
Jenze flatpack ted RH tlaci vsude? Na jeden dve aplikace do systemu, u kterych nevyzaduji integraci (vystacim si s evropskymi jazyky a netrapi me dalsi omezeni) je to fajn.
Tlacit to vsude pod heslem "the future of application distribution" ve stylu https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks je bud totalni hovadstvi nebo umyslna snaha poskodit linux desktop.
Red Hat to netlačí všude. Red Hat (přesněji desktopový tým, rozhodně ne celý Red Hat) to tlačí ve Fedoře. Fedora nemá třeba takový Flathub ani přednastavený. Takový Endless je Flatpak-only, Linux Mint a Solus mají Flathub přednastavený. V Debianu se podpora výrazně zlepšila díky Collaboře... Tam Red Hat nikoho do ničeho netlačí. Řekl bych, že Red Hat dnes není ani hlavní vývojářská síla za Flatpakem. Věnují se mu u nás tak 1-2 lidi. Endless tím, že má Flatpak-only systém, do něj investuje výrazně víc.
Prakticky nevyhnutelnost je to u immutable OS, kde se na systém nesahá a tudíž se do něj ani nic neinstaluje. Z pohledu upstreamového vývojáře je to někdy dar z nebes, protože má kontrolu nad tím, jaké knihovny jeho aplikace bude používat, a tedy nad tím, jak to bude u uživatele funkční a stabilní. Člověk se až diví, co se dokáže stát, když aplikace v distribucích funguje s jinými verzemi knihoven, jinými buildovacími volbami atd.
"Není to plýtvání místem když se může použít knihovna systémová?"
Náročnější na místo to je, ale paměť a místo na disku jsou dneska levná záležitost, takže to není takové negativum jako dřív.
"Není to trochu proti Unixové filozofii? "Dělej jenom jednu věc a dělej ji dobře?"
Nevím, co má toto společného s unixovou filozofií. Když má aplikace přibundlovanou knihovnu, tak nemůže dělat jednu a dobře? Mimochodem ve světě BSD se takto bundluje, co já pamatuji.
"Nevzikne tak v linuxu podobný problém jako ve win kde občas bývá chaos s dll?"
Windows už víc jak 10 let na počítači nemám, takže se moc nechytám. Jako že by vznikaly konflikty? To u Flatpaku nehrozí. Že tam těch knihoven bude víc? To je podstata bundlování. Nicméně Flatpak to alespoň částečně řeší sdílenými runtimy.
"Jak můžu vědět, že se v nějáké přibalené knihovně neskrývá nějáký malware?"
A jak to můžeme vědět u softwaru třeba v RPM balíčku? Ten nijak nebrání bundlování a aplikace třetích stran často v balíčku bundlují téměř všechno, aby to fungovalo na různých distribucích. V tomto mezi těmi technologiemi není principiální rozdíl. Rozdíl je v tom, že Flatpak umožňuje dynamicky linkovat jenom na runtime, RPM balíček prakticky na cokoliv v systému. Výhoda Flatpaku je, že každá aplikace běží ve svém vlastním namespacovém sandboxu, takže dosah škodlivého software je omezený. Navíc Flatpak k instalaci nevyžaduje na rozdíl od správce balíčků práva roota.
"To budou repozitáře Flatpak/Snap aplikací obsahovat odkaz nebo dokonce i zdrojáky použitých knihoven?"
Tak třeba Flathub buildí ze zdrojáků podle manifestu, který je veřejně k dispozici a v kterém je uvedeno, z jakého zdroje a z jaké verze se jednotlivé komponenty buildí. Prošel jsem review jak třeba ve Fedoře, tak na Flathubu a ta míra kontroly je tam podobná.
Jinak prostě nejde říct, jestli jsou lepší balíčkovací systémy a dynamické linkování, nebo Flatpak/snap a bundlování. Obojí má své výhody a nevýhody a které převažují záleží na tom, kdo a kde to používá.
libGL funguje uz davno, pre Nvidiu je extension s ich proprietarnym driverom, mesu obsahuje rovno runtime, aktualne 18.0, co je novsia verzia ako maju niektore distribucie.
Problem bugu #1 flatpaku je, ze je v nespravnom repozitari, takze ho nikto nezatvoril.
Na flathube je flatpak pre Steam. Hry zo Steamu pod tym bezia ;)
Flatpak runtime pouziva vlastne verzie driverov, tie co su instalovane v systeme ani nevidi, kedze ma sandboxovany /.
Pri Nvidii je dolezite, aby kernel driver nebol novsi ako ten, co je vo flatpaku, co sa moze stat, ked user updatne jeden, ale nie druhy (nvidia driver pre flatpak je extension, ktora vychadza zhruba rovnako ako nvidia vydava svoje binarky). Pri AMD a Inteli som este nezaznamenal konflikt medzi kernel a userspace driverom.
Takze z pohledu *uzivatele* ... z niceho nic prestanou fungovat nektere aplikace. Pozdeji zjisti, ze ty instalovane pres flatpak, ktere pouzivaji libGL. Pak stravi pul dne debugovanim, aby zistil, ze se to stalo, protoze se mu zupdatovali drivery ke grafice v distru a doinstaluje si prislusnou verzi do flatpaku.
Jinymy slovy, ne, stale flatpak nefunguje s libGL.
Nedej boze kdyz nekdo vymeni treba amd grafiku za nvidii.
Je to dost skoda, protoze to neni tak davno co linux desktop fungoval celkem dobre.
Z pohladu pouzivatela to bude fungovat, bez toho, aby sa musel zaoberat nejakymi drivermi.
Aplikacia zabalena vo flatpaku je otestovana voci driverom, ktore si nesie runtime, nie voci nahodnej verzii, ktoru bude mat pouzivatel v systeme. Pre developerov je to dar z nebies, lebo vedia, voci comu maju testovat.
Ale kludne si opakujte co len chcete, akurat na rozdiel od vas su tu ludia, co maju s flatpakom prakticke skusenosti.
Co ty mas za problem, Flatpak ti prebral frajerku alebo co?
Pokial si pouzivatel nainstaluje hocico, co pouziva OpenGL a ma nvidiu, dotiahnu sa mu aj drivery k jeho karte. Ako budu pribudat verzie, budu sa mu dotahovat aj jednotlive verzie extensions. Svojho casu som Nvidiu mal a nebol najmensi problem.
Nehovoriac o tom, ze tento "problem" je len s Nvidiou. Majitelia AMD a Intelu su uplne vysmiati.
> Pre developerov je to dar z nebies, lebo vedia, voci comu maju testovat.
Tohle chapu. Taky-developer otestuje proti jedne verze runtime(s) a je z obliga. Ze to i pres to nebude fungovat je mu bud u zadku a nebo nema dostatecnou mozkovou kapacitu aby vubec dokazal pochopit jak to funguje.
Mimochodem, s dynamicky linkovanym libGL by to prave chodilo protoze budes ti bude sedet verze knihovny s verzi driveru v jadre.
> Ze to i pres to nebude fungovat je mu bud u zadku a nebo nema dostatecnou mozkovou kapacitu aby vubec dokazal pochopit jak to funguje.
> Mimochodem, s dynamicky linkovanym libGL by to prave chodilo protoze budes ti bude sedet verze knihovny s verzi driveru v jadre.
Toto moze napisat iba clovek, co nikdy neriesil obskurne bugy v implementacii OpenGL nahodneho vendora.
Tady má ale kolega anon2 pravdu. Fakt nevím, jaký důvod autoři flathub runtimů měli pro tento způsob integrace libGL. Používat systémovou libGL je IMHO bezpečnější než bundlovat devadesát verzí mesy či nvidia-utils a doufat, že to nebude s tím, co je náhodou nainstalováno v systému kolidovat. Protože ovladače hardwaru jsou v jádře, nikde není zaručeno, že nějaká aplikace s danou verzí mesy bude skutečně fungovat všude stejně, v případě nVidie bych to čekal ještě horší.
Flatpak je sandbox. On zo systemu nevidi nic, /usr namontovane do flatpaku je samostatna distribucia, napr. Freedesktop 1.6 je defacto Yocto.
Tym padom, ze zo systemu nevidi nic, nevie pouzit systemovu libGL.so, ktora by mohla byt linkovana s dalsimi systemovymi kniznicami, az by nakoniec zo sandboxu neostalo nic. Samotny ovladac pre OpenGL je v libGL, resp. v moduloch, co si libGL dolinkuje a s jadrom (nie, tam nie je ovladac, tam je iba cast, ktora alokuje pamat, robi presuny bufferov, a scheduluje command buffery) komunikuje cez /dev/dri resp. /dev/nvidia. Ano, pri nvidiach treba davat pozor na zhodu medzi jadrom a userlandom, a presne to riesia nvidiove extensions. Pri mese to problem nie je, pretoze jadro, mesa a libdrm maju samostatne release schedule a jedna cast nikdy nevie, s akou verziou druhej casti budu komunikovat v danej distribucii, preto maju komunikaciu medzi rozdielnymi verziami osetrenu.
V pripade, ze je naozaj treba specificka verzia mesy, tak sa to samozrejme da osetrit presne tym istym mechanizmom, ktory pouziva nvidia, ale zatial to nebolo potrebne pre software urceny koncovym pouzivatelom. Je to akurat fajn pre vyvojarov, aby skusili ine verzie, nez tie, ktore su v runtime.
pacon/gnome-software updatuje vsetky zdroje sw naraz, teda aj dnf/apt a flatpak. Pokial pouzivatel pojde do command line a updatne jedno a druhe nie, tak ano, urobi si problem kym ich neupdatne obe. Bezny BFU vsak toto robit nebude.
Pri zmene hw treba doinstalovat extension nvidie, a ano, je to vnimane ako user-unfriendly a predmet na zlepsenie.
Za tych par mesiacov, co som pouzival nvidiu, som nikdy nemal problem, ze by nvidia driver nebol zabaleny pre flatpak. Zvycajne byval o par hodin skor, ako rpm balik.
Sam moc dobre vis, ze updatovanim flatpaku a dnf/apt zaroveni nezaruci ze bude jak systemovym driver i runtime flatpaku ve stejne verzi.
To ze dokazes tvrdit, ze kdyz si nekdo sam pusti apt rucne, tak si za to, ze mu prestanou fungovat aplikace ve flatpaku, muze sam ... tim bych tu diskusi asi ukoncil.
Ale jste teda doudam, ze duvod proc si tech par mesicu nemel problem je jasny - ten driveru se proste neupdatoval. Vzdyt jsou toho plne "github issues" flatpaku jak s tim lidem zapasi.
Pretoze bezny user rucne apt nepusta. User, ktory vie rucne spustit apt, si vie dat pozor na rozlicne verzie.
Beznemu userovi raz za tyzden vybehne notifikacia, ze su k dispozicii nove verzie, casom na nu klikne (v pripade userov ktorych poznam, to trva dalsi tyzden), spusti sa mu Gnome Software alebo KDE Discovery a ma 99,999% sancu, ze verzie budu sediet.
A zase opakujem, ze je to zalezitost iba Nvidie, nie ostatnych, a to len preto, ze ich driver stack je pod takou licenciou akou je.
A samozrejme, ze som updatoval. Pretoze ked viem spustit v mojom pripade dnf, tak si viem pozriet, ake verzie kde mam. Nanestastie (alebo nastastie?) medzi rpm a flatpak nie su zavislosti, takze update jedneho nevie vynutit/zablokovat update druheho.
AppImage nerieši ani jedno. Updaty súhlasím by bolo "nice to have". Sandboxing je podporovaný cez firejail. https://firejail.wordpress.com/documentation-2/appimage-support/
Za mňa ideálna kombinácia.
Updaty jsou celkem zásadní, jinak to dopadne jako na Windows – každá aplikace si to bude řešit po svém, některá vůbec, některá pouze při spuštění (takže spustíte zastaralou aplikaci a teprve pak se aktualizuje) a některé (jako Chrome) skrze daemona. Pak místo jednoho (nebo několika málo) daemona jich najednou budete mít spoustu, podle počtu aplikací. V tom výhodu nevidím.
Ad řešení sandboxu po svém – ano, to ale nastaví pár lidí, nehledě na to, že zrovna firejail je poněkud slabý sandbox.
Takže shrnuto podtrženo, logicky nelíp na tom je kolébka Snapu Ubuntu a obří komunitou podpořený na kontinuálních aktualizacích založený bláznivý Arch (ten mám já). Nejhůře logicky konzervativní RHEL/CentOS (a Mageia, nu, nemá tak velkou komunitu, dá se tomu rozumět). Zbytek je řekněme takový běžný standard, průměr, jako se všemi ostatními novinkami.
Vlastně nic nového novinka nepřináší, ale je zajímavé, že se ten svět Linuxu zas tak moc nemění.
Nechapem preco si sefovia velkych distier raz za rok spolu nesadnu a nevydaju specifikaciu napr. Linux 2019 kde bude zoznam 100 najbeznejsich kniznic s presnymi verziami a uzivatelovi aj developerovi moze byt jedno na akom distre ta apka pobezi. Staci aby distro podporovalo standard Linux 2019 a hotovo.
Když se zasníme a budeme předpokládat, že se ty desítky distribucí dohodnou, jak to budou dělat distribuce s dlouhodobou podporou? RHEL je podporovaný 10 let, to 10x za svůj životní cyklus změní uživatelům API/ABI, aby byl kompatibilní s verzí "Linuxu" pro daný rok? Nebo by měl RHEL vycházet každý rok a Red Hat a vývojáři aplikací pro něj budou muset podporovat 10 různých verzí RHELu, respektive "Linuxu" naráz? To je ten ideální svět? :-)
Pro centos/redhat je k dispozici https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/ - nezkoušel jsem.
