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?
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á.