Názory k článku
Pro Flatpak už můžete nainstalovat témata vzhledu
-
luv (neregistrovaný)
Cely ten jejich pristup je "jeden krok vpred, pet kroku vzad" ale to prece ani po letech vyvoje (kdy stale resi takoveto zakladni problemy ... a to dost neuspesne) nemuzou priznat.
Flatpak is the next-generation technology for building and installing desktop applications. It has the power to revolutionize the Linux desktop ecosystem.
Sakra, vzdyt ja kdyz si instaluju aplikaci mimo system SAM PRO SEBE tak si pohlidam integraci na mnohem vetsi urovni (pouziti stejneho tema je ten nejzakladnejsi zaklad).
-
luv (neregistrovaný)
A pritom kdyby jejich cilem nebylo rozbit zabezpeceni na linuxu* tak by to slo vyresit celkem elegantne.
Ty runtimes jsou vubec dobra sranda - to se zacnou runtimes menit vyvojarum cilovych aplikaci pod rukama stejne (ne-li hur!) jako ted distribuce ... takze to vlastne nebyl "jeden krok vpred, pet kroku vzad" ale "jeden krok stranou, pet kroku vzad".
* (ted kdyz se zverejneni nejaka bezpecnostni chyba, tak je oprava behem par dnu) - kdyz bude potreba updatovat kazdy flatpak balicek/runtime tak se uzivatele nedockaji a bude se na aplikace na linux dat utocit stejne jako na windows
-
"to se zacnou runtimes menit vyvojarum cilovych aplikaci pod rukama stejne (ne-li hur!) jako ted distribuce"
Proč by se ty runtimy měly měnit pod rukama? Autor aplikace si klidně bude moct vybrat nějaký LTS, třeba založený na CentOS, který se nebude měnit 10 let. Nebo naopak takový, který má podporu 6 měsíců, ale má tam to nejnovější. Výhodou je to, že nemusí cílit na 10 různých platforem, ale pouze na jednu.
"kdyz bude potreba updatovat kazdy flatpak balicek/runtime tak se uzivatele nedockaji a bude se na aplikace na linux dat utocit stejne jako na windows"
Runtimy jsou založené na určité distribuci, normálně sestavované z balíčků. Je v některém z použitých balíčků opravená bezpečnostní chyba? Tak se automaticky spustí rebuild runtimu a pushne se aktualizace. Oprava tak k uživatelům dorazí prakticky stejně rychle jako ta v balíčku skrz distribuční repozitář.
-
luv (neregistrovaný)
automaticky se spusti rebuild runtimu a pushne se aktualizace ... ale zadny runtime se pod rukama menit nebude ;)
Fakt by bylo lepsi se vratit se do bodu 0 a zamyslet se nad tim jak to udelat spravne, kdyz uz mate ty zkusenosti z tohoto pokusu (libGL vam tam stale nefunguje ze).
Pro srovnani .. ve svem prefixu si resim i takove veci aby mi skoro nejnovejsi freetype renderoval stejne jako ten v RHEL6.
-
luv (neregistrovaný)
> Oprava tak k uživatelům dorazí prakticky stejně rychle jako ta v balíčku skrz distribuční repozitář.
Dobre, pro aplikaci 1.
Ale pro aplikaci 2, kde se vyvojar rozhodl pouzit jiny runtime dorazi oprava pro tu stejnou chybu kdy?
A pro aplikaci 3, kde se vyvojar rozhodl runtime nepouzit, protoze chce mit jistotu, ze se ta aplikace vsude alespon spusti (teda pokud nepouziva napr. OpenGL), dorazi oprava pro tu stejnou chybu kdy?
A pro aplikaci 4, ktera je zalozena na runtime odvozenem treba na tom CentOS, kde se ta bezpecnostni chyba v distribuci neprojevila (prtz se projevila az v novejsi verzi te ktere knihovny), ale vyvojar aplikace tam ma knihovnu nabundlovanou v novejsi verzi (ktera tu chybu obsahuje), dorazi oprava pro tu stejnou chybu kdy?
-
Proč proboha píšete reakci do tří komentářů? To je nějaká hra na co největší počet komentářů napsaných na Rootu?
2) to je zodpovědnost autora aplikace, aby vybral runtime, který dostává bezpečnostní aktualizace. Momentálně vzniká centrální repozitář Flathub, kde budou jen runtimy, které mají garantovanou podporu a dostávají včas bezpečnostní aktualizace. A aplikace, které tam uživatel najde, budou smět používat jen tyto runtimy.
3) ve Flatpaku musí aplikace nějaký runtime použít, i kdyby to měl být nějaký minimalistický jako třeba FreeDesktop.
4) co si vývojář přibundluje k aplikaci, je jeho zodpovědnost. Za bezpečnost samotné aplikace (a přibundlovaný software je prostě součástí aplikace) si nese zodpovědnost autor nebo její správce. To ostatně platí i v případě balíčků v distribucích.
Jinak jestli považujete vydání bezpečnostní opravy v RHELu/CentOS za měnění platformy pod rukama, tak to potom jo... Garantovaná stabilita API/ABI vám nic neříká? Můžu vás ubezpečit, že na to spoléhají aplikace ve výrazně kritičtějším nasazení, než jsou ty desktopové.
-
luv (neregistrovaný)
> Momentálně vzniká centrální repozitář Flathub, kde budou jen runtimy, které mají garantovanou podporu a dostávají včas bezpečnostní aktualizace. A aplikace, které tam uživatel najde, budou smět používat jen tyto runtimy.
A v momente kdy ten runtime/distro z ktereho je odvozeny prestane dostavat vcas bezpecnostni aktualizace se teda vyhodi z flathubu i se vsemi aplikaci co na nem zavisi ... a uzivatelum se ty aplikace odinstaluji?
-
Petr (neregistrovaný)
Flatpak je z dílen Red Hatu a jde stále o vývojovou verzi (0.9.x). Red Hat jak známo se přímo angažuje na vývoji Gnome - proto byl do Gnome jako závislost přidán i systemd, který se pak coby závislost Gnome dostal i do dalších distribucí.
To že ve vývojové verzi programu z dílny Red Hatu nikdo (zatím) moc neřeší KDE/Qt přece není nic překvapivého - počkejme na finální verzi, pak uvidíme, jestli jde zase o politický záměr (jako u systemd), nebo ne. -
"Red Hat jak známo se přímo angažuje na vývoji Gnome - proto byl do Gnome jako závislost přidán i systemd, který se pak coby závislost Gnome dostal i do dalších distribucí."
Kvůli tomuto to opravdu nebylo :) Prostě jen začali vývojáři využívat věci (session management, offline updates,...), které už umí systemd, tak proč je implementovat znovu a udržovat? Nikdy to ale nebyly nepřekonatelné závislosti a myslím, že doteď existuje v rámci GNOME skupina, která GNOME portuje na BSD a bez systemd se musí objetí. A projekt to vítá. Mimochodem mám pocit, že tu iniciativu, která přinesla závislost na systemd, vedl Frederic Peters, který pro Red Hat nepracuje a přispívá do Debianu.
"To že ve vývojové verzi programu z dílny Red Hatu nikdo (zatím) moc neřeší KDE/Qt přece není nic překvapivého - počkejme na finální verzi, pak uvidíme, jestli jde zase o politický záměr (jako u systemd), nebo ne."
Toto taky není pravda. Samozřejmě, že řešíme Flatpak i v KDE/Qt. Spolupracujeme s BlueSystems na vytvoření oficiálního KDE runtimu, pomáháme portovat KDE/Qt aplikace na Flatpak, implementovali jsme portály pro Qt, implementovali jsme podporu pro Flatpak v KDE Discover a budeme pracovat i na podpoře Qt témat ve Flatpaku.
-
Co myslíte emailovým portálem? Normálně předání mailto? To by měl umět URI portál a to je divné, protože já používám Telegram ve Flatpaku, ten používá právě KDE runtime a např. odkazy mi jdou otvírat bez problémů. Pokud něco nefunguje nebo není implementované, tak prosím nahlásit. Funkční parita s portály pro GTK jsou pro nás rozhodně priorita.
-
Petr (neregistrovaný)
OK, díky za vysvětlení.
Ještě se zeptám - řešíte ve Flatpaku i podporu alternativních init systémů (např. OpenRC), nebo počítáte do budoucna natvrdo se systemd jako s jediným podporovaným init systémem u univerzálně instalovaných aplikací ? Používám Archlinux a ten má u Flatpaku systemd jako tvrdou závislost... -
Flatpak není závislý na systemd, takže může bezvadně fungovat i v distribuci bez něj. Do verze 0.6.10 tam závislost byla, protože Flatpak používal systemd na nastavování cgroups, ale byla odstraněná. Nevím, proč v Archlinuxu systemd vyžadují, je fakt, že ve Fedoře je taky pořád jako buildtime závislost. Možná, že jen neaktualizovali seznam závislostí, nebo to buildí tak, že to systemd vyžaduje, upstream jej ale nevyžaduje: http://flatpak.org/faq.html#Is_Flatpak_tied_to_systemd_
-
Adam KaliszStříbrný podporovatelZajímalo by mě, jestli Flatpack do budoucna počítá i s headless/ server nasazením aby v tom ohledu dorovnal snap?
OpenBSD má docela problém s tím, že GNOME používá čím dál více že systemd. Uvažují o nějakém wrapperu, pokud vím, ale nelíbí se jim to.
