A co je na flatpaku humus? To, ze vytvori separatne namespace pre aplikaciu? Alebo to, ze kniznice vovnutri mozu byt ine ako v systeme? Za mna je to prudke pozitivum, ze aplikacie nie su viazane natvrdo na system a oba si mozu ist svojim tempom; uz ziadne praveke verzie v repozitaroch, lebo cely svet musi skonvergovat na jednej konkretnej verzii kazdej kniznice.
V krajnich pripadech i to je lepsi nez si tahat do systemu flatpak humus s pulkou binarek kterou uz v systemu mam nejasneho obsahu a puvodu o kterem nic nevim.
A pokud si to do systemu pritahnu tak nechci jednu po druhe analyzovat,scannovat a znova to cely opakovat po update.
Jinak co linuxoveho desktopu tyce. I ve widlich musite obcas delat oplne stejne skopiciny.
"Rock prasackych progrosu".
Proste aby nam ten entrprajz solusn bezel u Fsech (letici flus na stul od PM...) zakosu kde jediny schopnejsi admin je mrtvy brouk v racku.
Na linux, resp. typických linuxových distribucích, je hezké to, že se pro instalaci programů používají repozitáře s balíčky, u kterých se dá alespoň do určité míry předpokládat, že procházejí nějakým testováním a kontrolou. U nějakého humusu z flatpaků sotva - nejsem si jist, jestli se tímto chceme přibližovat stavu panujícímu na windows, kde kdokoliv instaluje cokoliv, co kdekoliv najde (ne že by to technicky byl problém flatpaku, ale jeho zacílení a způsob použití si o to prostě říká).
Vyvíjel jste nějaký komplexnější software, který by se pak distribuoval přes repozitáře?
Jako vývojář nemáte prakticky kontrolu nad ničím. Pokud chcete aby měli uživatelé aktuální verzi, musíte si dělat balíky sám. Takže s každým release balíky pro Ubuntu/Debian/Fedoru a možná i další. Nikoho v distribuci nezajímá, že jste vydal novou verzi. Do repozitáře se dostane až s další verzí distribuce. Takže uživatel může klidně dva roky čekat na novou verzi. Pokud se aplikace týká věcí, které se často mění, jsou uživatelé v pasti. Flatpak je požehnání. Jeden balíček, X distribucí. Dokud sám nechcete, nemění se podvozek. Aplikace prostě funguje a máte čas udělat v klidu upgrade na novější verzi runtime.
Ano, pokud je aplikace hodně populární, balíčky udělá někdo jiný a taky se o ně do jisté míry zvládne starat. Pokud vyvíjíte něco méně populárního, je vše na vás jako vývojáři. Z vlastní zkušenosti mohu říct, že je to dost náročné.
To je feature, nie bug.
Za systemove kniznice si je zodpovedny system, za aplikacne aplikacia. Tym padom system moze byt minimalny, nemusi obsahovat kazdu jednu kniznicu pod slnkom a aplikacia podobne, tiez len to co potrebuje. A to, ze sa nemusia zhodnut na verzii znamena, ze ani jeden nie je obmedzovany tym druhym. Nenastavaju dnes bezne situacie, ze aplikacia na Linuxe nemoze nieco pouzit, lebo nejaky LTS system udrziava 7 rokov staru verziu a nema nove ficury, ktore pouzivatelia ziadaju.
Ano, nicméně ona appka tu knihovnu asi potřebuje v nějaké verzi.
Samozřejmně, můžete být purista a říct že když ta appka potřebuje děravou knihovnu, nebudete používat tu appku.
Otázka je kolik pak strávíte smysluplnou prací a kolik migracemi mezi software (protože autor nemá zrovna čas se zabývat upgradem).
To že u close-source nepochodíte vůbec Vám je přepokládám jasné.
A prakticky ve světě go, rustu, nodejs, javy, php a dalších jazyků které mají svůj package managment jste asi skončil (protože to sebou "tahá" všechny knihovny (jsou prostě prikompilovaný)).
To je sice teoreticky pekne, ze su symlinky (ktore sluzia na zlinkovanie pri buildovani, resp. soname -> real file name), ale:
1) neriesi to transitivne zavislosti, len priame. Ked sa nazbiera poziadavka mat v ramci procesu rozlicne verzie kniznic, tak to je dost problem. Preto to baliky v ramci distribucie nerobia a konverguju na jednu verziu.
2) neriesi to konflikty v assetoch jednotlivych verzii kniznic (kniznica pouziva pre svoj subor v /usr/share/foo/bar vo verzii 1 format X a vo verzii 2 nekompatibilny format Y)
3) neriesi to problem, ze aplikacia vyzaduje vyrazne novsiu kniznicu, nez je pribalena k distribucii (lebo do LTS novsie verzie z principu nedavame, vsak, to si setrime o 5 rokov neskor).
Toto je skutocny problem; ono casto trva 5-10 rokov, kym nieco, co Fedora a Arch uz davno maju, prebubla do Ubuntu / Debianu / RHEL (aj ked v10 je uz celkom fajn). Plus potom niektori vyvojari si tiez davaju na cas, ved kym nieco nie je odstranene, tak neriesime ze je to deprecated niekolko rokov, ved LTS distibucie tu s nami budu este dlho... a potom su prekvapeni, ked sa deprecated naozaj odstrani, ved to "potrebuju". Napriklad, kolko rokov tu mame pipewire (ktory riesi aj x11!), ze sa nema grabovat x11 root window a kolki pouzivatelia sa stazuju, ze vo waylande im nejde zdielat obrazovka?
ad 3: https://www.reddit.com/r/linux_gaming/comments/1h1lz4n/easy_setup_of_gamescope_on_steam_flatpak/
Sice nie velmi user friendly, ale (vraj) funguje.