Jeden den s Flatpakem (diskuse)

[Jardik]

Tak kvuli qt aplikaci je potreba kde sdk, tj mnohem vetsi moloch nez je skutecne treba. Pak stejne musis bundlovat svoje verze knihoven, protoze ty v sdk padaj. No a pak kazda aplikace pro jinou verzi sdk ... co kdyz autor apku nezaktualizuje, to budu muset mit sdk plnebezpecnostnich a funkcionalnich chyb? No potes ...

[MadCatX]

Na tu molochoviost runtimů se můžeš dívat různě. Kdyby existovaly nějaké menší varianty (qt, qt-noqtquick, qt-minimal apod.), velmi rychle by ses dostal do stavu, kdy by každá aplikace chtěla vlastní runtime. To by byl ve výsledku větší zmatek než mít jeden masivní runtime, který pokryje závislosti daleko více aplikací. V rámci možností binární kompatibility by měly dostávat aktualizace i ty runtimy, takže bezpečnostní aktualizace se k uživatelům (snad) dostanou. To je velká výhoda oproti statickým buildům. Nějaký abandonware se stane rizikem dříve či později tak jako tak. Ke snížení bezpečnostních rizik má Flatpak sandbox.

[Rosta]

Takze zhorsime bezpecnost starymi zavislostmi s argumentem, ze sandbox ji zase zvysi. :D A ja si naivne myslel, ze ta izolace sandboxu je dalsi dodatecna uroven zabezpeceni... :)

[MadCatX]

Takhle ten argument ale přece nezní. Sandbox je tam hlavně proto, aby bylo možné relativně bezpečně instalovat aplikace z nedůvěryhodných zdrojů. Navíc závislosti staré být nemusí, pokud bude uživatel udržovat aktuální ten runtime. Ideální to není ale v rámci možných kompromisů mi to přijde přijatelné.

[Petr]

Tomuhle nerozumim. Pokud moznosti aplikace v ramci sandboxu definuji primo v tom flatpakovym balicku, jak to zvysi bezpecnosti spousteni z neznamych zdroju? Jako malware creator bych asi nastavil minimalni omezeni pro sandbox, nebo se pletu v necem a muzu nejakym snadnym zpusobem definovat nekde ze pro flatpak aplikaze ze zdroje x pouzij maximalni bezpecnost sandboxu?

[MadCatX]

Nastavení sandboxu se dají nastavit buď jednorázově (flatpak run --nofilesystem=home MyApp) nebo trvale (flatpak override --nofilesystem=home MyApp). Práva v manifestu jsou jen default, který si může uživatel upravit dle potřeby.

[Ravise]

Což stejně bude muset dělat ten na konci řetězu a pro každý flatpak zvlášť. Spíš bych si představoval nějaké varování, že "App chce přistupovat k ... [povolit jednou] [povolit vždy] [zakázat]"

[Petr]

Bfu to delat nebude, povoli vse...

[Luboš Doležel (Doli)]

Což o to, kompletní Qt runtime by mi nevadil, ale řekl bych, že většina Qt aplikací fakt KDE runtime nepotřebuje. Navíc existují oficiální buildy Qt, které by stačilo převést do formátu Flatpaku.

[RB]

Lze použít FreeDesktop runtime, který je fakt malý. Nicméně pak by si člověk musel bundlovat Qt. Jako nikdo nebrání tomu, aby se udělal malý Qt runtime. Flatpak podporuje také rozšíření runtimů, takže ten KDE runtime by šel udělat menší a třeba KDE Frameworks by se dalo dát do rozšíření, o jehož instalaci by si aplikace mohla říct, pokud by něco z něj potřebovala.

[Want]

To by jeden blil. Ještě že existuje mnohem jednodušší a efektivnější způsob jak vyrobit standardní binární balík: Použiju overlay, normálně to nainstaluju, pak z ramdisku vykopíruji obsah který chci zabalit, vyhodím co tam nechci. V případě nutnosti dopíšu postinstalační skript, přidám soubor s popisem balíku a použiju standardní distribuční nástroj k vytvoření binárního balíku.

[dumblob]

To preci jiz dlouho existuje plne automatizovane. A tesi se velke oblibe:

https://github.com/jordansissel/fpm

[MadCatX]

Podobně by se dalo použít i třeba OBS od SUSE, které má teda menší rozsah podporovaných formátů. Problém s distribucí nativních balíčků pro různá distra je ten, že je třeba je udržovat a v případě potřeby přebuildovat vůči novým (či naopak starým) závislostem. Pokud není v týmu aspoň jeden člověk, co by aplikaci X na distru Y aktivně používal, musí to IMHO dřív nebo později skončit tím, že se aspoň jeden balíček rozbije.

[smazáno]

.. a uplne stejne ti tvuj balicek rozbije update "runtime"

[MadCatX]

Jak? Pokud ty runtimy nebude spravovat nějaký pitomec, měla by být jedna řada runtimu pořád binárně kompatibilní.

[smazáno]

uplne to stejne plati o distrech

[MadCatX]

I o distrech jako Fedora, Debian-(unstable,testing), Arch etc.?

[smazáno]

naopak, i "stable" distra co slibuji ABI kompatibilitu se z "nepochopitelnych" duvodu rozbijeji

a to stejne se bude dit s temi runtimes

[MadCatX]

Promiň ale citation needed.

[smazáno]

Jasne, napriklad par dnu stare kompletni rozbiti kernel driveru v LTS ubuntu ... https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1750937

[MadCatX]

Kernel ABI != userspace ABI a já se hlavně ptal na případy, kdy něco rozbil update flatpakového runtime.

[smazáno]

Kernel ABI != userspace ABI

Ve smyslu, ze "stable" distra neslibuji stabilni kernel ABI ale jen userspace ABI?

Tohle je priklad, na ktery jsem narazil zrovna vcera, kdy slib stabilniho ABI nic neznamena.

Pripady, kdy se neco podobneho povedlo klukum z flatpaku si budes muset najit sam (maji bugzillu pro runtimes?).

[smazáno]

treba https://github.com/flatpak/flatpak/issues/1359 ?

[smazáno]

https://github.com/flatpak/flatpak/issues/1276 taky dobry

[RB]

To je pěkné, ale když se něco takového stane, tak ten problém řeším s jedním runtimem. Ne s RHELem, SLESem, Debianem, Ubuntu LTS... a to jmenuju jen distra s dlouhou podporou. Ano, i runtime ve Flatpaku může rozbít ABI, ale rozdíl oproti distribuci přes balíčky v distribucích je v tom, že mám jednu platformu, pro kterou vyvíjím a proti které musím testovat, a pořád můžu zasáhnout desítky distribucí.

[smazáno]

To zni rozumne, jenze pokud kvuli Flatpaku prestanes RHEL, Suse, Debian a Ubuntu podporovat, tak o hodne uzivatelu/zakazniku prijdes.

[MadCatX]

Na mainstream distrech je Flatpak k dispozici taky, o žádné uživatele v principu přijít nemusíš.

[smazáno]

Treba ubuntu 14.04 je stale podporovane, ale flatpak pro nej neni.

Navic dost uzivatelum, zvlast na linuxu, bude ten bloat a velice problemove integrovani do systemu (krome temat, fontu, napr. firemni CA) vadit.

[MadCatX]

Záleží na aplikaci. Integrace do systému mi nepřijde až tak špatná - aspoň z pohledu BFUčka - a předpokládám, že každý vývojár si udělá analýzu přínosů a omezení. Kdybych měl k ruce člověka, co by se o ten packaging na Linux staral, nativní balíčky pro pár nejprofláklejších dister bych asi připravil. Protože musím dělat všechno od návrhu, výpočetních knihoven až po UI a testování sám a celé to je v podstatě takový vedlejší produkt, nemám na mrcasení se s každou libBrokenDependency.so.66.6 čas a sáhnu tedy po něčem jako Flatpak. Tak jako se vším je o to o nalezení vhodného kompromisu.

[smazáno]

To vcelku souhlasim, je to vlastne o neco lepsi (a v necem horsi) nez vytvorit tarball, ktery si bude tahat vsechny zavislosti se sebou. Pokud by byl flatpak takto propagovan, tak je vse v poradku, ale "the future of application distribution"? To nemuzou myslet vazne prece...

Me hodne zajima ta integrace - co tam funguje prosimte? Zatim jsem se dozvedel, ze si to umi nekdy precist jake ma system (nebo uzivatel?) nastavene GTK tema a nainstalovat, pokud je podporovane, tema se stejnym nazvem.

Clanek je samozrejme super. :)

[MadCatX]

Nějak marketovat to přece musí;)

Jak moc dobře se flatpakové aplikace integrují do systému můžu vyzkoušet pořádněji, zatím jsem se omezil na „dá se to jednoduše zbuildit, vím jak na to a zdá se to funkční”. Minimálně adaptace na systémový GUI make-up vypadá OK. Možná by z toho mohl být další zápisek...

[smazáno]

• pouziva se ve flatpaku stejny font jako v systemu?
• .. kdyz zmenim nastaveni fontu v systemu, zmeni se bez resetu aplikace i ve flatpak aplikacich (pripadne aspon po resetu)?
• .. co kdyz font, ktery pouzivam v systemu, neni ve flatpaku
• nastaveni renderovani fontu - pro zacatek vypnuti antialiasingu
• pouziva flatpak stejne tema jako v systemu?
• .. kdyz zmenim tema v systemu, zmeni se bez resetu aplikace i ve flatpak aplikacich (pripadne aspon po resetu)?
• .. co kdyz tema, ktery pouzivam v systemu, neni ve flatpaku (!!)
• .. jak se flatpak chova pokud dva uzivatele na stejnem systemu pouzivaji ruzna temata?
• .. ^^ minimalne pro GTK a QT
• integrace libGL a knihoven k driverum .. Je hw akcelerace oficialne podporovana pro flatpak aplikace? Co kdyz vyhodim ze systemu nvidia GPU a vymenim za AMD? Resp. vzdyt je potreba aby knihovny a drivery byly ve stejne verzi(!!) .. jak se tohle resi?
• budou flatpak aplikace respektovat moje systemove nastaveni CJK IME ??
• Firemni CA pridana v /etc/ssl/certs a nastaveni /etc/ca-cerficates.conf
• Bude flatpak respektovat nastaveni proxy v systemu?
• Pokud aplikace potrebuje poslouchat na nejakem portu? To se resi predpokladam pres DNAT? I na ipv6?
• Pokud by byl soucasti aplikace treba skriptik do /etc/cron.daily nebo systemd timer, kam se nainstaluje?
• Pokud se ma aplikace spoustet po startu/ovladat pres init skripty, jak je toto vyreseno?

[MadCatX]

Tohle zní jako rozumné požadavky na dostatečně integrovanou aplikaci. Zkusím si někdy během příštích pár týdnů udělat čas a v rámci možností to vyzkoušet. Co se ovladačů GPU týče, ty pokud vím nejsou součástí žádného flatpakového runtimu a vždy se použijí ty systémové, proto je taky přístup k 3D hardwaru nutné odsandboxovat přes --device=dri (doufám, že nekecám).

[smazáno]

Soucasti ovladacu jsou krome modulu do jadra i knihovny jako libGL. Knihovny a driver v jadre musi byt ve stejne verze.

[MadCatX]

Však jo. Pokud vím, Mesa ani žádná její část ve Flatpakových runtimech není.

[smazáno]

Ja se prave divam ze se tam snazi zabalickovat vsechny verze knihoven k nvidia driverum.

[AsciiWolf]

Pokud se ma aplikace spoustet po startu/ovladat pres init skripty, jak je toto vyreseno?

Není vyřešeno. Pro takové aplikace není Flatpak určen.

[AsciiWolf]

Tedy, abych byl přesnější - spouštění po přihlášení (přes desktop soubor v ~/.config/autostart/) není problém; spouštění a ovládání přes init scripty/systemd unity by teoreticky šlo, ale pro takové věci prostě Flatpak není určen. Je určen pro uživatelské (primárně GUI) aplikace, ne pro démony.

[smazáno]

GUI aplikace, jejiz soucasti je i nejaky demon, ktery by se mel poustet pri bootu/loginu, me uplne scifi neprijde - typicky node a penezenka v jednom pro ruzne coiny. Nakonec, systemd to podporuje.

[AsciiWolf]

Tohle by mělo jít přes xdg portály/dbus. Nicméně ten démon musí být distribuovaný samostatně, ne jako součást Flatpak balíčku.

[Petr]

Jak je to s bezpecnosti flatpaku ve smyslu treba digitalniho podpisu?

[MadCatX]

Podepisování pomocí GPG klíčů by mělo být podporované ale nezkoušel jsem to.

[Petr]

A to jsem si rikal, ze bastleni rpm nebo deb je nekdy pakarna... chapu vyhodu flatpaku, ale taky vidim jaky bordel to nese sebou. Kdyz to dovedu do extremu, tak diky nejake prilozene ssl library misto pouziti sdilene mam v systemu diru dokud ji autor flatpak aplikace nefixne. 10 autoru, 10 dir. zatimco u rpm proste aktualizuji fixnutou ssl library a 10 aplikaci patrne bude fungovat dale.

[Adolf Kernel]

rovno nech sa distribuuju komplet paravirtualizacne kontajnery - k tomu ten flatpack speje...

[RB]

No, díru v systému mít nebudeš. Budeš ji mít v té konkrétní sandboxované aplikaci. Aplikace, které jsou "dobří občani open-source ekosystému", používají standardní knihovny, které jsou v runtimu (včetně té tebou zmiňované SSL). Runtimy jsou sdílené a udržované větším projektem, takže podobné distribucím. Aplikace, typicky ty 3rd party, které si bundlují prakticky všechno, už to dávno dělají v RPM a DEB a popravdě, raději na takové aplikace použiju Flatpak, kde jim nemusím dávat během instalace práva roota, neinstalují mi soubory libovolně do systému a neběží mi ve stejném namespacu jako zbytek systému.

[trekker.dk]

Takže místo runtime z distra bude potřeba hlídat kompatibilitu se sdíleným runtime. A nebo si ten runtime balit k aplikaci. To první má stejný problém jako vývoj proti distru (= flatpak je zbytečný), to druhé má bezpečnostní problémy (= flatpak je nebezpečný)

[MadCatX]

Jenomže dister jsou stovky, sdílený flatpakový runtime jen jeden. Proti tomu se hlídá kompatibilita daleko snáze.

[smazáno]

To urcite usetri praci ... ale nebude pak muset mit uzivatel nainstalovano 10 ruznych runtime (z toho 9 neudrzovanych a deravych), protoze ruzne aplikace budou vyzadovat runtime ruznych verzich?

[MadCatX]

Zodpovědný vývojář bude doufám vyvíjet pro nějakému z „oficiálních“ runtimů s dobrou podporou. Podobné peklo s potenciální záplavou exotických a nepodporovaných závislostí může snadno vzniknout např. na Archu instalováním balíčků z AURu. Jde IMHO o problém „kulturní“ který nemá vyloženě technické řešení...

[trekker.dk]

Samozřejmě že ne, s příchodem flatpaku prasata vývojáři s nevelkým rozhledem procitnou, přestanou vyvíjet bez ohledu na okolní svět, zavládne všeobecný mír a ráj na zemi. No nic, zpátky do reality...

[MadCatX]

I kdyby to byla pravda, klidně ať se tak stane. Vzhledem k tomu, jak je Flatpak od zbytku systému izolovaný ti libolovný bazmek nemůže příliš ublížit. Mít nainstalovaných několik runtimů najednou není šikovné ale v mometně, kdy by mi to začalo vadit může beztrestně odinstalovat, co nepotřebuji nebo klidně wipenout celý /var/lib/flatpak. To je daleko lepší situace než typické dilema AURisty, kdy WeirdAppA chce knihovnu libLegacyB která teď začala kolidovat s libNewVersionB, na které jako na potvoru závisí dalších patnáct balíčků a dokud to někdo nějak nevyřeší, nemohu instalovat aktualizace.

[Grunt]

Nejsem ani Archista ani AURista, ale zrovna AUR se mi docela líbí a použil bych ho jako protipříklad k Flatpaku. Nedá se natvrdo zalinkovat libLegacyB (přecejen je to kompilace) oproti WeirdAppA? Když si instaluju v binárních distrech věci ručně, jednoduše si připravím adresář /opt/WeirdAppA a svoje verze knihoven si do ní zakompiluju a pak nahardlinkuju proti samotné aplikaci. Něco takového v Archu možné není?

[MadCatX]

V tom případě by sestavení závislostí a samotné aplikace musel řešit PKGBUILD oné WeirdAppA a dále zde máme opět problém statického linkování a argumentu, že všechny knihovny by měly být sdílené. Za třetí i ta libLegacyB může mít nějakou system-wide závislost, která by se mohla časem rozbít a vyžadovat rebuild.

Pokud si něco sestavuješ ručně včetně závislostí, děláš vlastně úplně totéž co ve finále Flatpak, akorát bez sandboxu a centralizované správy. Na tom samozřejmě není nic špatného a bude se to (možná) o něco lépe integrovat se zbytkem systému ale rozhodně to není instalační postup, který můžeš chtít po BFU.

[Kate]

Nejen bez sandboxu a centralizované správy, ale pořád přijde o updaty runtime, které flatpak zajistit umí.

[trekker.dk]

Jo, protože stejné knihovněy převzaté ze stejných zdrojáků přibližně ve stejné době se od sebe v různých distribucích naprosto zásadně liší tak, že v tom je problém a prostě to uhlídat nejde, což je důvod, proč vznikl flatpak. Jasně...

[MadCatX]

Tohle přece není pravda. Ubuntu 16.04 bude mít o dost jiné verze knihoven než třeba RHEL 7, Fedora 27 nebo aktuální Arch. Některé distribuce si nedělají velkou hlavu klidně i s major aktualizací nějaké knihovny v rámci jedné verze, jiné se to snaží hlídat. Pokud nemáš člověka, co by releasy na Linux spravoval, nemáš šanci podporovat víc než hrstku distribucí a i tak to bude vyžadovat pravidelnou kontrolu, že je všechno stále OK.

[trekker.dk]

Přičemž ty jiné verze se od sebe budou lišit tak zásadně, že to vlastně bude úplně jiná knihovna...

[MadCatX]

O to přece nejde. I kdyby API zůstalo stejné, pořád se může změnit ABI což může paradoxně být i horší problém. Jen ABI MPFR se za poslední rok změnilo asi 3x. Zkus podobné změny uhlídat ručně pro všechny závislosti na všech distrech, které chceš nativně podporovat a vždy včas poskytnout aktualizované balíky.

[Adolf Kernel]

v jednoduchosti je krása. flatpak nevyzera byt jednoduchy...

[Albert Einstein]

Everything should be made as simple as possible, but no simpler.

[Albert Einstein]

Věci mají být jednoduché jak jen to jde. Ale ne jednodušší.

[smazáno]

Uz flatpak respektuje systemove fonty (vcetne nastaveni renderovani) a temata?

[MadCatX]

Systémová témata ano, nastavení renderování těžko říct kvůli rozdílům v knihovně freetype2.

[smazáno]

Ty systemova temata furt tim hackem ze si musis do flatpaku (runtimu?) rucne nainstalovat a nastavit to ktere pouzivas (pokud pro flatpak vubec je)? Tzn. integrace jako takova zadna?

Pokud se pouziva uzivatelska/systemova konfigurace ... jak se resi rozdily v konfiguraci mezi ruznyma verzema toho tematu (a to i takove ze s configem z jine verze muze padat) ?

[MadCatX]

Mně to fungovalo úplně bezúdržbově na všech čtyřech systémech, kde jsem to zkoušel. Možná jsi to z textu článku nezaregistroval ale já nejsem žádný flatpakový evangelista ani guru. Přišlo mi zajímavé podělit se o své zkušenosti a případně to konfrontovat s jinými možnostmi. Pochopil jsem, že se ti koncept flatpaku nelíbí, okay, jak bys to tedy řešil ty?

[smazáno]

A pouzivas vlastni temata (nebo vzdy vychozi systemove)?

Zminuju/ptam se na konkretni problemy - az vsechny ty problemy, ktere sebou flatpak prinasi, vyresi, tak to muze byt zajimava technologie.

[smazáno]

Pochopil jsem, že se ti koncept flatpaku nelíbí, okay, jak bys to tedy řešil ty?

Dodrzovat ABI kompatibilitu. Pokud by mi abclinuxu nevracelo "413 Request Entity Too Large", tak bych vlozil jako prilohu build vimu, ktery pouziva dynamicke linkovani a bude fungovat na vsech normalnich distribucich od rhel5 po Ubuntu 17.10 - to znamena na vetsim mnozstvim distribuci nez flatpak. Navic diky tomu ze ma dynamicky linkovane libtinfo se i lepe integruje do systemu.

Je mi jasne, ze to takto nefunguje pro gtk aplikace, protoze gnome "vyvojari" (narozdil od core knihoven) na to totalne kaslou.

Sam mam takovou prihodu, kdy jsem resil velice neprijemny bug s gsettings v ubuntu. Resetovalo se nastaveni klavesovych zkratek po restartu. Tento bug tam vydrzel pres dva roky a minimalne jeden ubuntu maintainer o nem vedel, nastavil si workaround a neresil; po dvou letech me to nastvalo tak, ze jsem stravil tri dny v gdb a fixnul to za ne, ale ocenuji, ze pak aspon patch bez kecu prijali (na zaklade predchozich zkusenosti jsem patch ani nezkousel dostat do upstreamu gnome - to by proste vyhnilo v bugzille). Je mi jasne, ze naucit vyvojare s takovymto pristupem nerozbijet ABI je mimo realitu. Na druhou stranu, jine opravdove reseni neexistuje. Flatpak apod. jsou takove workaroundy, kde se povazuje za uspech, ze se aplikace povede spustit.

[RB]

Ne, minimálně pro Flathub to je vyřešené tak, že do něj lze přidávat témata jako rozšíření runtimu. Minimálně, co se týče GTK, tak jsou tam ta nejrozšířenější. Pokud ho má uživatel nastavené v systému, automaticky se nainstaluje pro Flatpak a uživatel nemusí nic dělat. Libovolně témata ze systému to přebírat nebude, protože v runtimu je zpravidla jiná verze GTK než v systému a nikdo nezaručí, že to téma ze systému bude bezproblémově fungovat i s GTK z runtimu.

[smazáno]

Ne, minimálně pro Flathub to je vyřešené tak, že do něj lze přidávat témata jako rozšíření runtimu.

Jo to je presne ten "hack", ktery myslim, tzn. integrace nulova. Takze se nic nezmenilo, diky za info.

[smazáno]

Ale jo, to ze se to aktualni tema nacte z konfigurace systemu a automaticky nainstaluje a nastavi je fajn. Tohle se deje vlastne kdy?

[smazáno]

freetype2 ti bude navic se stejnym configem v ruznych verzich renderovat znatelne jinak

[PetrHL]

Díky za sdílení zkušenosti.

Mám aplikaci napsanou ve FreePascalu/Lazarusu a chtěl jsem ji zkusit distribuovat jako flatpack. Rychle mě to přešlo, bylo by to šíleně komplikované. Objevil jsem počin jménem AppImage. Pro mne, jako autora aplikace, mnohem pohodlnější a předvídatelnější.

[Luboš Doležel (Doli)]

Navíc mám pocit, že AppImage je na rozdíl od Flatpaku opravdu používaný. Zatímco Flatpak jsem ještě nikdy neviděl, aplikací v AppImage mám stažených hned několik.

[kolega]

Jestli jsi se s flatpakem nesetkal, tak jdi na flathub

[Ravise]

Když to, co hledám, není v systémových repozitářích, jdu hledat na stránky toho kterého projektu a jdu tam, kam mě pošlou.

Náš administrátor shledal tento komentář závadným.

NSFW píseň skupiny Masturbace

Zobrazit komentář

[AsciiWolf]

Flatpak je běžně používaný např. na Linux Mintu či Fedoře a některé distribuce, např. Endless OS či Fedora Atomic Workstation, jsou na něm dokonce postaveny. Další distribuce se pomalu přidávají k jeho podpoře ve výchozí instalaci (krom Ubuntu, které má svůj vlastní Snap).

[Rezza]

Zase u AppImage je to takove "na kolene" - uz jsem zazil takove, kde jela az xta verze po nahlaseni bugu, protoze autor zabundloval minimum knihoven, takze tu chybelo tohle, tu bylo tohle v jine verzi atd. U Flatpaku by tohle mel resit runtime.

[RB]

Přesně, u AppImage si autor může volně linkovat mimo ten bundle, což je cesta do pekel. Bude to lavírovat mezi: funguje to na systému autora, funguje to na systému lidí, kteří hlásí bugy atd. Nějaká záruka portovatelnosti tam není.

[smazáno]

Za to kdyz se aplikace bunduluje s kompletnim OS (to rovnou muzou bundlovat i s vlastnim hardware), tak to je uplne ale uplne bezproblemovy ....

[RB]

Nic není nikdy úplně bezproblémové, ale jinak ano, Flatpak je v tomto ohledu výrazně méně problémový než AppImage.

[smazáno]

A kdybyste bundlovali s kazdou aplikaci i vlastni hardware tak je to uplne bezproblemovy :P.

[Rezza]

Neni - takovych Hw/SW kombinaci zname dost a stejne nefunguji :). Ale jde o to, kde mame tu hranici, kde je to jeste akceptovatelne a kde uz ne.

[smazáno]

Aplikace, kde mi nefunguje klavesnice (resp. IME), protoze si sebou bundluje cely OS, je urcite za tou hranici.

Na druhou stranu, kdyz gnome "vyvojari" maji potrebuju rozbijet ABI i API kazdych 6 mesicu, tak si aplikace cely gnome sebou bundlovat musi.

[ehm]

Článek je pěkný (a díky za něj), ta technologie už tolik ne. Zatím rozmýšlím, jestli je za tím víc konzervativnost, nebo racionální důvody. V současných balíčkovacích systémech vidím nedostatky, ale nevím, jestli tohle bude celkově vzato lepší.

Mimochodem, to klonování masteru mě fakt děsí. Nedá se tam naspecifikovat alespoň ID posledního commitu? U souboru to chce checksum, tak proč u Gitu se to spokojí s názvem větve? Takhle je to naprosto nezreplikovatelné, každý, kdo to vybuildí, může dostat úplně jiný program.

[MadCatX]

Flatpak se IMHO nesnaží být "lepší balíčkovacím systémem" jako spíš rozumně kompromisní alternativou k nativním balíčkům. Jsem zvědavý, zda a kam se možnosti Flatpaku posunou.

Co se klonování z gitu týče, jde uvést branch, tag i konkrétní commit, který se má použít.

[trevor12]

tento prispevek by si zaslouzil placeny clanek na root.cz

[Petr]

Rekneme si to na rovinu, flatpak umoznuje bez nejake vyrazneho testovani dostat aplikaci na xx dister misto 2-3 s testovanim. Autor usetri cas, ale tak nejak to shazuje unix pristup ze knihovny jsou sdilene a aplikace pouzivaji to co uz je v systemu misto aby si tahali sebou vsechen bordel. Flatpak mi pripomina takovy zip pro windows ve kterem jsou vsechny dllka a aplikace, bez ohledu na to ze vsechny dllka mam uz v systemu a v 10ti dalsich adresarich ruznych aplikaci.

[Agent]

Já být vývojář distribuující si sám své výtvory do světa, tak udělám balíčky na 2 max. 3 nejpoužívanější balíčkovací systémy a ostatní buď ať se přizpůsobí a začnou používat jeden z těch balíčkovačů, nebo ať si trhnou. Variabilita a možnost výběru může být dobrá věc, ale co je moc, je moc.

[RB]

A aby to fungovalo na rozumném počtu distribucí, tak budeš bundlovat jak o život. Bez sandboxu, ve stejném namespacu...

[Petr]

Nic ve zlym, ale pokud je cely flatpak postaveny na tom, ze v manifestu jako autor aplikace urcis omezeni (rozumi se malware se nebude omezovat) anebo cekas ze si uzivatel udela nejaky override tak ta security je nastavena spatne.

[RB]

To, že to tak funguje nyní a sandboxing není vynucovaný, neznamená, že to tak bude fungovat i v budoucnu. Běží to v kontejneru, má to definované API na nejběžnější komunikaci mimo sandbox, takže základy pro účinný sandboxing na rozdíl klasických balíčků tam jsou.

[Petr]

Naprosty souhlas. Misto toho aby se linuxovy svet nejak zjednocoval, tak open source zpusobuje to, ze nekomu se nelibi neco, vznikne dalsi distribuce. A pak tady mame urpmi, rpm, apt, flatpaka miliony dalsich balickovacu ktere se obcas v nicem nelisi, obcas se zasadne lisi. Delat komercni soft pro linux? Rpm, deb, pkg a ostatni me nezajima. Delat soft jako one man show? Flatpak.

[RB]

Nevím, jestli to je Unix přístup, protože ve světě unixů (např. BSD) se jedou aplikační bundly už drahně let.

[Petr]

Neco jako treba:

# for LINE in $(rpm -qR httpd);do rpm -q --whatprovides $LINE; done | sort | uniq | grep -v "no package provides"

apr-1.2.7-11.el5_6.5
apr-util-1.2.7-11.el5_5.2
bash-3.2-32.el5
chkconfig-1.3.30.2-2.el5
coreutils-5.97-34.0.1.el5_8.1
db4-4.3.29-10.el5_5.2
expat-1.95.8-11.el5_8
file-4.17-28
findutils-4.2.27-6.el5
gawk-3.1.5-16.el5
glibc-2.5-107
httpd-2.2.3-76.0.1.el5_9
initscripts-8.45.42-1.0.3.el5_8.1
libselinux-1.33.4-5.7.el5
mailcap-2.1.23-1.fc6
mktemp-1.5-24.el5
openldap-2.3.43-25.el5_8.1
openssl-0.9.8e-26.el5_9.1
pcre-6.6-6.el5_6.1
shadow-utils-4.0.17-21.el5
zlib-1.2.3-7.el5

Jsem si nevsiml ze by si to tahlo vsechny zavislosti sebou. A httpd je takova obvykla unixova aplikace pokud se nepletu. Instalace pres rpm/deb mi proste prijde k systemu cistejsi a obecne vzato i bezpecnejsi.

[Vantomas]

httpd běží asi tak na 100 milionů zařízení, kdežto tady jeho PeakMaster asi tak na 100 zařízeních? To je pak jasný, že se maintaineří jen hrnou. A pro každou distribuci celé zástupy!

Osobně u obskurní aplikace dám radši přednost Flatpaku, než vlastní kompilaci ze zdrojáků. To je k systému ještě méně čistější a obecně vzato i bezpečnější.

[ehm]

Co se klonování z gitu týče, jde uvést branch, tag i konkrétní commit, který se má použít.

Aspoň, že tak.

Flatpak se IMHO nesnaží být "lepší balíčkovacím systémem" jako spíš rozumně kompromisní alternativou k nativním balíčkům. Jsem zvědavý, zda a kam se možnosti Flatpaku posunou.

Obávám se, že nativní balíky budou postupně mizet. Tady je totiž problém v tom, že vytvořit správně balík třeba pro Debian není vůbec jednoduché a dostat ho do oficiálních repozitářů jakbysmet. Vývojáři ani uživatelé nechtějí čekat.

Dnes se proto lze často setkat s „oficiálními“ upstream repozitáři (ať už provozovaných na vlastním serveru, nebo třeba jako PPA). To na první pohled vypadá jako dobré řešení, dokud není třeba řešit závislosti napříč těmito repozitáři. Balík foo z jednoho repozitáře může záviset na balíku bar z jiného repozitáře, který uživatel nemá přidaný. Konflikt pak musí vyřešit ručně on sám (v tomto případě nalezením a přidáním repozitáře, který obsahuje patřičný balík). V dlouhodobém horizontu se také můžou objevovat problémy se zanikajícími repozitáři.

Nabízí se myšlenka, jestli by závislost neměla být specifikována jen jménem balíku, ale ještě zdrojem. To ovšem neřeší ty případné zanikající repozitáře.

Nakonec by tedy asi bylo nejlepší něco jako IPFS, kdy balík bude specifikován jménem, verzí (viz dále) a nějakým podpisem – klasický checksum nelze použít, protože každá verze bude mít jiný.

Co se týká verzí, bylo by ideální pevně odlišit verzi API od verze softwaru, nebo striktně dodržovat konvence. V praxi nevím, jaký konsenzus v případě schéma <major>.<minor>.<patch> panuje ohledně situací, kdy v rámci (security) bugfixu je nutné rozbít zpětnou kompatibilitu. Inkrementuje se jen patch a mávne se nad tím rukou s tím, že „správně napsané programy by to rozbít nemělo“?

Takže by existoval jen jediný decentralizovaný repozitář (provozovaný např. na IPFS). Závislost by byla určená jménem balíku, podpisem, co nejméně restriktivní verzí (např. 1.2.*, pokud je garantováno, že API je stejné; alternativně lze také zavést další kvalifikátory, např. že patch musí být větší nebo roven nějaké hodnotě apod.) a dále referenční verzí, se kterou byl daný program původně testován.

Pokud by v systémech existovalo cachování balíků (nebo způsob jak je rekonstruovat z instalovaných souborů a minimálních dat držených v cachi package manageru), šlo by za předpokladu, že by systémy byly do IPFS běžně zapojeny zajistit, že dokud lidé budou libovolný balík dané verze používat, bude k dispozici i ostatním.

Referenční verze má spíše dokumentační význam: Pokud po upgradu nějaké knihovny přestane program fungovat, uživatel tuší, na jakou verzi by měl zkusit downgradovat (i třeba za cenu, že bude riskovat bezpečnostní zranitelnost – to už je jeho volba). Balíčkovací systém by s tímto případně mohl i automatizovaně pomoci.

Prerekvizitou samozřejmě je, že balíčkovací systém bude umět držet více verzí stejně pojmenovaného balíku. Ostatně, v systému, který naznačuji, by název měl rovněž spíše dokumentační význam než cokoliv jiného. Závazný je spíše nějaký ten podpis.

IPFS zmiňuji jen jako příklad, možná se na toto použití ani nehodí. Podstatná je ta myšlenka jednoho decentralizovaného depozitáře, ne konkrétní technické provedení.

[dumblob]

Některé z těchto myšlenek jsou implementovány v nejpokročilejším (a přitom jednoduchém) mně známém balíčkovacím systému GNU Guix.

[Petr]

A nekdo ho pouziva?

[dumblob]

No jistě. To by jinak v těch repozitářích nebyly tisíce aktuálních (!) balíčků (přes 7100 jich je aktuálně zahrnuto v continuous integration).

Jinak Guix můžete používat i v jakémkoliv jiném distru - funguje všude (paralelně k distro-specific "nativnímu" balíčkovači). Docela se hodí, že Guix umí instalovat jakékoliv množství různých verzí téhož, což právě většina nativních balíčkovačů absolutně nezvládá.

[Petr]

Dekuji, podivam se na to..

[Grunt]

Jen tak pro zajímavost:

     215 text files.
     215 unique files.                                          
       6 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.70 s (301.2 files/s, 26595.5 lines/s)
-----------------------------------------------------------------------------------
Language                         files          blank        comment           code
-----------------------------------------------------------------------------------
C++                                 88           2307            134           8636
C/C++ Header                       100           1103             70           3633
Qt                                  20              0              0           2313
Prolog                               1             22              0            270
Markdown                             1             18              0             55
Windows Resource File                1             19             23             28
-----------------------------------------------------------------------------------
SUM:                               211           3469            227          14935
-----------------------------------------------------------------------------------

Takže kvůli cca 9k řádkům v C++ (dodám že to je počet který by Gentoo emerglo jedním příkazem snad dřív než by se ten Flatpak nainstaloval) bude sebou aplikace tahat co? Qwt, QT5, LEMNG, … GNUGMP? Pokrok prostě nezastavíš. Ještě by mě zajímalo kolik má kB vlastní binárka toho PeakMasteru a kolik vlastní balíček ve Flatpaku. Jako pro nějaké velké aplikace typu LibreOffice, GIMP (i když i ten mám přeložený svůj v několika verzích a přitom naprosto bez problémů) budiž, ale tohle kvůli nějakému grafickému bindingu na pár knihoven který by se hodil spíš do nějakého AppStoru?

[MadCatX]

Flatpakovový balíček má cca 1.5 MB, Release verze binárky PM cca 800 kB (bez závislostí). Zbytek toho příspěvku nechápu. PM je GUI frontend pro výpočetní engine a všechno má nějaké závislosti, které se logicky musí nainstalovat. AppStoru? Kdyby bylo možné PM distribuovat přímo třeba skrze flathub, fungovalo by to skoro jako nějaký AppStore. Přiznám se, že mi vůbec není jasné, co jsi chtěl říct.

[chrono]

Chcel povedať to, že kvôli megabajtovej aplikácii sa nainštalovali desiatky megabajtov rôznych knižníc (navyše, ktorých väčšinu už aj tak bude mať, v aktuálnej a udržiavanej verzii, nainštalovanú v systéme).

[Grunt]

ECHMETCoreLibs a LEMNG jsou nezbytné součásti vlastní grafické aplikace a vzhledem k tomu že jsou vyvíjený tamtéž jako samotná grafická aplikace, nejspíš nebudou běžnou součástí žádného běžného systému a Grunt to prostě zapomněl přidat do výčtu. Ale samozřejmě to neznamená že tahle situace nemůže nastat.

[lizbee]

love this site so much! electrolysis memphis