Názory k článku
Vyšel Flatpak 1.0.0
-
anon (neregistrovaný)
Appimageupdate uz tu nakej ten patek je. Co vsechno flatpak neumi je zbytecny furt dokola opakovat, snad jen pripomenu ze vy red hataci jste ho propagovali jako super reseni uz v dobe kdy v nem vsechny aplikace bezeli s vychozim gtk tematem :D. A v te dobe uz byl appimage davno plne pouzitelny.
To ze od flatpaku odrazuji i velke gnome projekty (ktere ho maji povinne) mluvi samo za sebe.
-
Vím, že na trolly se nemá reagovat, ale...
Toto se týká Evolutionu a ano, Evolution ve Flatpaku nenabízí plnohodnotnou integraci, ale není to Flatpakem, ale sandboxingem a měl by takový problém v každém řešení, které se snaží o nějakou izolaci aplikace. Evolution je skrze backend evolution-data-server úzce provázaný s desktopem a dalšími aplikacemi (Contacts, Calendar, Bijiben, Tasks). e-d-s jde do Flatpaku bundlovat, ale potom člověk přijde o tu integraci se zbytkem. Taky by se dal v sandboxu udělat přístup k systémovému e-d-s, ale tam byl nebyla zaručená funkčnost, protože Evolution se spoléhá na to, že má k dispozici odpovídající verzi e-d-s (3.28<->3.28 atd).
Evolution a e-d-s je prostě software, jehož architektura se sandboxingem nikdy nepočítala a jediný problém Flatpaku je, že ho má, což mi tedy nepřijde jako něco špatného.
Mimochodem nevím, jak by toto řešil ten zázračný AppImage. Ten by buď bundloval e-d-s k Evolutionu a pak by přišel o integraci se zbytkem nebo by se snažil linkovat systémové e-d-s a pak by to znamenalo, že to nebude fungovat všem uživatelům, kteří zrovna nebudou mít stejnou verzi e-d-s, jako je verze Evolutionu, která je v tom AppImage. A instalovat stejnou verzi Evolutionu, jakou mám v distribuci, přes AppImage postrádá smysl.
-
anon (neregistrovaný)
Si tu flatpak sracku, kde nefungujou temata (na ty se teda dobastlil nedavno jeden velky polofunkcni workaround), konfigurace fontu, konfigurace renderovani fontu, kde mas v systemu 5 ruznejch verzi gnome, aplikace se spolu neumi poradne bavit, ktera ani nefunguje na vsech podporovanych velkych distribucicich, kdyz vymenis grafickou kartu nebo nainstalujes novejsi drivery tak se ti to cely rozsype, a ma radu dalsich problemu (o kterych se nesmi mluvit) klidne pouzivej (ale moc tomu neverim, ze to doopravdy pouzivas ;)).
A tohle vyvijej v RH od nuly a tvrde propaguji, kdyz uz tu je roky open-source projekt, ktery umozni poustet jednu binarku na ruznych distrech, a to overeny, funkcni a bez zadneho z vyse zminenych problemu.
Kdyz ale kouknu na github a vidim, ze na flatpaku dela jen jeden vyvojar, tak RH velice chapu, ze se jim vyplati investice s naklady limitne se blizici nule, aby se pokusili ziskat takovou moc nad linux desktopem (=ovladat distribucni kanal pro linux aplikace). Nedelal bych to jinak, resp. delal, nalil bych do toho vic penez a vyresil ty sileny bugy :).
-
Flatpak samotný je relativně jednoduchá věc. Jen to spojuje různé technologie do jednoho řešení (LXC, cgroups, OSTree,...), mnohem více práce je na tom toolingu kolem toho: sestavování aplikací, runtimy, distribuce a na tom dělá výrazně větší množství lidí a Red Hat tam už hraje spíš druhé až třetí housle. Tam je aktivnější Endless a CodeThink.
-
anon (neregistrovaný)
Ze sloganu flatpaku jako "future of application distrubition" apod. primo cisi snaha nahradit balickovaci system a to je vylozene mrveni na/pod urven windows.
Ale tady je potreba dodat, ze pro windows muzes dodat jednu binarku, ktera ti bude bezproblemove chodit na ruznych verzich 20 let zpatky. Flatpak nepodporuje ani RHEL6 a navic je nepouzitelny, protoze rozbiji integraci.
Nerekl bych, ze to je tedy snaha udelat z linuxu windows, ale zmrvit linux z nejlepsiho desktop OS pod uroven windows.
-
MK (neregistrovaný)
A jak AppImage řeší uvedené problémy? Např. výše zmíněnou nutnost mít v systému jednu konkrétní verzi eds, nebo třeba u těch témat vzhledu to, že GTK knihovna přibundlovaná v tom AppImage bude kompatibilní s tématem nainstalovaným v systému a vzhled nebude rozbitý?
Odpovím si sám, neřeší to vůbec. Jen doufá, že to shodou okolností bude fungovat. -
MK (neregistrovaný)
Nijak jsi mi neodpověděl na otázku.
Tak ještě jednou: mám systém, v kterém je systémová GTK třeba 3.10, mám tam nastavené téma, které je s touto verzí kompatibilní, přes AppImage si nainstaluju aplikaci, která vyžaduje novější GTK (dejme tomu 3.22), která je tam proto přibundlovaná. AppImage tomu GTK zpřístupní cestu k nainstalovanému tématu a to se ho pokusí načíst. Jak mi AppImage zajistí kompatibilitu mezi tím tématem a přibundlovanou GTK a že vzhled aplikace nebude rozbitý? Nijak.
Subsurface na RHEL 6 je jako příklad střela mimo. Subsurface je napsaný v Qt5, RHEL 6 Qt 5 ani nemá, nejsou tam v něm žádné aplikace a Subsurface tam tak nemá být s čím vzhledově jednotný. Že se to nainstaluje a jede to, je pěkné, ale bavíme se tady o integraci se systémem a ostatními aplikacemi. -
MK (neregistrovaný)
GTK 3.22 není sotva vypadá knihovna, ale 2 roky stará. Jestli to, že na ní vývojář závisí, znamená, že je krypl, tak je svět plný kryplů :) Opravdu nikdo, kdo píše novou aplikaci, nechce záviset na 8 let staré verzi GTK a ještě testovat, že je kompatibilní se všemi verzemi mezi tím a dneškem. Ale to je vcelku irelevantní. Uživatelé chtějí nové verze hned a vývojáři opravdu nemají potřebu řešit kompatibilitu s roky starou verzí knihovny a s ní kompatibilními tématy. A AppImage na to prostě nemá spolehlivou odpověď a pokud nebude, tak se neprosadí bez ohledu na to, jestli to vývojáři aplikací podle tebe dělají kryplovsky nebo ne.
-
anon (neregistrovaný)
Nabundlovat cely OS krome jadra (aspon ze linus chape dulezitost ABI kompatibility!) je mozne na serveru (i kdyz i tam to neni uplne pohadka), na desktop s tim prichazi obrovske mnozstvi problemu, ktere flatpak neumi resit a navic se o nich ani nesmi mluvit.
Jo a ukaz mi naky appimage a distro na kterem je ten problem o kterem mluvis, rad bych to videl v praxi.
-
j (neregistrovaný)
lol ... tak to jiste, on totiz vubec neni v kazdejch widlich unikatni set ruznych verzi ruznych dll ... (a mluvim o tech systemovych, jak jinak). A vubec se ti nestane, ze po (zcela libovolny) aktualizaci se libovolny API zacne chovat uplne jinak.
Pricemz (narozdil od tuxe) nemas zadnou moznsot jak nekde nejak rict, ze tvoje aplikace vyzaduje danou knihovnu ve verzi X az Y. Jediny co udelat muzes, ze si tam tu svoji verzi pribalis, a jeji instalaci trebas userovi rozbijes vsechno ostatni. Alternativne je tvoje aplikace 100x vetsi nez by byt musela a pouziva neaktualni a deravy verze vseho moznyho.
Krasa.
-
anon (neregistrovaný)
No rozhodne netvrdim ze ta kompatibilita ABI je 100%, ale rozhodne je radove radove lepsi nez u gtk/gnome. Kdyby melo gnome ABI kompatibilitu na urovni windows tak neni zadny appimage ani flatpak potreba.
Druha vec je absence balickovaciho systemu a spravy zavislosti na windows, tam to rozhodne stoji tezce za hovno, nelze nez souhlasit :).
-
anon (neregistrovaný)
Je to na hovno, ale je to bohuzel to nejlepsi co mame. Sracka co se neumi integrovat nikdy nijak je jeste horsi.
za vsechny tyhle sracku muzou prave ty kryplove co pul roku rozbijou ABI.
Doprdele, udelejte core standardni jeden runtime, a i ten flatpak bude pouzitelnej.
Ten priklad v praxi kdy se appimage rozbije me stale zajima.
-
MK (neregistrovaný)
No, já ti ten příklad hledat nebudu, ale je to natolik běžné, že to Flatpak ani Snap podporovat nechtějí. Kdyby chtěli, tak přimountovat adresář se systémovými tématy do sandboxu je to nejjednodušší. Flatpak to řeší asi u 10 nejpopulárnějších témat, ale výrazně spolehlivěji než AppImage.
-
anon (neregistrovaný)
Flatpak to resi zpusobem "pokud existuje tema se stejnym jmenem jako tvoej systemove temate pripravene jako extension do te konkretni runtime, kterou pouziva tato aplikace, ok, pouzijeme, jinak fuck off a mas hnusny default gtk tema", to je vse
S appimage jsem zatim nikdy problem nemel a vzdy se pouzilo moje systemove tema, proto jsem te pozadal at ukazes realny priklad kdy to s appimage nefunguje. Ja tu pisu o konkretnich problemech flatpaku (a klidne poslu screenshoty jak je to hnusny).
