Flatpak - bezpečnostní noční můra

Diskusi vyvolala stránka Flatpak - bezpečnostní noční můra (flatkill.org) popisující bezpečnostní problémy technologie Flatpak [reddit, Hacker News].

10.10.2018 08:55 | Ladislav Hagara | Komunita

Komentáře

[Kate]

Ten reddit :D

>While I appreciate the clever domain name, it is difficult for me to take a computer security vulnerability seriously in 2018 if it doesn't include a logo.

[disorder]

"The way we package and distribute desktop applications on Linux surely needs to be rethinked"

vie mi niekto poskytnut tl;dr preco? nejak ma tato tema obchadzala.

[ehm]

dependency hell 3d-party aplikací

[sc]

No ve finale ma stejny problem aji docker a podbne tooly na kontejnerizaci. Presunul se problem aktualizaci o level vys, coz z pohledu vyvoje techto nastroju je ok tim ze se problem presunul jinam. ale pro uzivatele je to vetsi hrozba, protoze nema jistotu ze jsou ty veci aktualizovane uvnitr, tzn u distribuci se to resi relativne promtne, za cenu, ze se neco s novou verzi muze rozbit, tady je verze zafixovana, takze tool funguje, ale muze obsahovat ruzne zranitelnosti

+ jeste to, ze nektere aplikace maji zbytecne velka privilegia, aniz by je potrebovaly at jiz castecne aby usnadnili praci uzivatelum, tak i mozna z lenosti.

[disorder]

myslim preco je debian repo zle na instalovanie balickov, mne to uz vyse 15 rokov vyhovuje

[kralyk z abclinuxu]

No, tak si představ situaci, že jsi právě naprogramoval program. Co musíš udělat, aby si ho lidi mohli nainstalovat z Debian repo? + k tomu to samé pro další distra...

(Tím samozřejmě nechci říct, že Flatpak je řešení.)

[Kate]

K tomu bych přidala situaci kdy autor použije nějaké novější verze např. Qt, které v určité podmnožině stable distribucí nejsou.

[disorder]

program sa da zabalickovat aj s vlastnymi verziami kniznic, ak sa nedaju doinstalovat z backportov, testingu, unstable alebo poskytnut vlastne balicky zavislosti. u roznych proprietarnych produktov taketo obsiahle /opt instalacie nie su ani nevidane.

osobne preferujem radsej nepodporovat stable v takom pripade. na desktope urcite nie je probolem pridat backports, testing, unstable. casto ide iba o jednotlive balicky a nie pol systemu.

[Kate]

Ano, dá se. Ale není v tu chvíli sandboxovaný install do Flatpaku lepší alternativa než rozbalení aplikace do /opt se všemi závislostmi? Ten flatpak a podobné alespoň umožňují použít nějaký udržovaný a updatovaný runtime (teď odhlédněme od porodních bolestí, jde mi o princip technologie)

Poskytování vlastních balíčků závislostí je pak už v případě one man projektu úplně nereálné, pokud to má obsáhnout opravdu všechny distribuce.

[disorder]

autor balicku si voli ake zavislosti pyta od systemu, moze zobrat zo systemu vsetko okrem jednej kniznice ked chce ("tej, ktora nie je v stable").

spravit distribuciu si vyzaduje vela ludi a vela prace, ale vysledok za to stoji. preto ak nejaky alternativny system vznikne, bude musiet byt rovnako rozsiahly a narocny na pracu.

pragmaticke riesenie je spravit deb, ktory pokryje majoritu pouzivatelov. potom ak je problem so stable:

1) komu na tom velmi zalezi, moze poskytnut backportnute kniznice - casto sa to da spravit trivialnym rebuildom balickov z testingu/unstable, dokonca aj balicky z ubuntu su v 99.9% pripadov uplne kompatibilne. a dokonca aj bez rebuildu.

2) ubuntu vychadza dvakrat za rok, debian testing ma rolling updates a najpopularnejsie veci su v backportoch aj pre stable. staci dat ruky prec od podpory starsich systemov. aj to je validne riesenie.

3) ak ide o vyznamnu aplikaciu, tak to niekto casto spravi pre vlastnu potrebu - mozno aj v oficialnom repe.

maloktory program je asi tak bleeding edge a tak rozsiahly, ze by sa ho tykalo obmedzenie "debian stable" a bolo by nemyslitelne ho poriadne zabalickovat pre majoritu pouzivatelov. vacsi problem je ak nie su zabalickovane nejake obskurne veci z perlu, pythonu, javy, node a pod.

[MadCatX]

Obávám se, že jsi v těch třech bodech přesně popsal „ten problém“, kvůli kterému vyžadují uživatelské aplikace na Linuxu aspoň nějakou údržbu, aby dlouhodoběji fungovaly a menším týmům se proto do podpory Linuxu moc nechce. Deb balíček, co by pokryl „majoritu“ uživatelů bych chtěl vidět. Třeba OpenSSL, které právě kvůli bezpečnosti asi budeš chtít mít systémové nemá stabilní ABI. Vyfakovat uživatele nepodporou staších distribucí, zatímco i dnes pod VS2017 lze při troše snahy psát programy, které se v pohodě spustí na XP SP3 taky není řešení. Co napr. takový CentOS 7 nebo SLE? To vlastně mainstreamové distribuce s komerční podporou ale leckterý software je tam ve skoro archaických verzích (třeba GCC 4.8 na CentOS 7). Backportovat si potřebné knihovny a spol. je dost práce, která navíc vyžaduje dost dobrou znalost těch knihoven ze nitř.

Tenhle hejt na všechno RedHatí (PA, Wayland, systemd, Flatpak, PipeWire bude následovat) je fakt úžasný. Nemám nic proti racionálnímu poukazování na chyby a nedostatky ale fakt mi není jasné, jak by si kdo představoval „lepší Flatpak“. Jistě, není to ultimátní řešení distribuce aplikaci na Linux ale ten koncept mi přijde životaschopný. Když nic jiného, může to pomoci vývojářům, kteří by se na Linux jinak vybodli distribuovat něco, co nebudou muset buildit pro deset distribucí každých pár měsíců kontrolovat, zda to pořád funguje.

[kralyk z abclinuxu]

Co napr. takový CentOS 7 nebo SLE? To vlastně mainstreamové distribuce s komerční podporou ale leckterý software je tam ve skoro archaických verzích (třeba GCC 4.8 na CentOS 7).

+1, tohle je důvod, proč jsem před časem u jednoho sw vyhodnotil balíček pro CentOS jako unfeasible... :-/

[Jan Kundrát (jkt)]

Zrovna tohle je trivialni pres [devtoolset](https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/). Nase interni CI servery, ktere kompiluji kod pouzivajici C++17, maji GCC 7.2 a Clang 6 na CentOS7.

[kralyk z abclinuxu]

Co musí udělat uživatel CentOSu, aby mu takto sestavený SW fungoval?

[MadCatX]

Že se to dá před devtoolset doinstalovat je jedna věc (sám to používám kvůli GCC 7 a Pythonu 3.6) a je to fajn ale aplikace sestavená tímto způsobem na standardním CentOSu 7 dost pravděpodobně chodit nebude. User by si IMHO musel minimálně doinstalovat příslušný devtoolset a aplikaci spouštět z environmentu nastaveného pomocí scl enable devtoolset-7.

[kralyk z abclinuxu]

Hmm, tak to jsme tam, kde jsme byli :-/

[ed]

Realne? Nepouzivat CentOS. To je bohuzial take korporatne a nepostihuje to len Linux, ale podobne, alebo este horsie na tom bol Tru64 (GCC 2.95) a onoho casu aj HP-UX.

Zaroven si nemyslim, ze by konkretne Flatpak nejako zasadne riesil pritomnost novsej verzie kniznice na systeme, kde v repozitaroch standardne nie je. Taku kniznicu bud ide trivialne nainstalovat ako obycajny balicek, alebo je tam niekde nejaky strasny zadrhel a ten nevyriesi ani flatpak. Ak sa budeme bavit o molochoch ako Qt a pod. a Historickej vykopavke ako CentOS, tak si najskor nabijeme usta na tom, ze nejake sebenovsie Qtcka vynucuju pouzitie C++11, ktore GCC 4.8 nepodporuje uplne. A to je asi dost neriesitelny problem, pretoze ABI sa medzi GCC 4 a 5 prave z titulu C++11 zmenilo. Takze starym prekladacom to nedam ani do Flatpaku ani nikam inam a novym prekladacom riskujem, ze to nebude stabilne.

[MadCatX]

Realne? Nepouzivat CentOS. To je bohuzial take korporatne a nepostihuje to len Linux, ale podobne, alebo este horsie na tom bol Tru64 (GCC 2.95) a onoho casu aj HP-UX.

Takze starym prekladacom to nedam ani do Flatpaku ani nikam inam a novym prekladacom riskujem, ze to nebude stabilne.

S Flatpakovým SDKčkem dostaneš i kompilátor. V runtimu verze 1.6 bylo GCC 6.2, s podporou novějších jazykových standardů problém není. Trochu drhnout by možná mohly nějaké špeky z C++17.

[AsciiWolf]

+1

[Bystroushaak]

K tomu bych přidala situaci kdy autor použije nějaké novější verze např. Qt, které v určité podmnožině stable distribucí nejsou.

Zábavnější je to když použije starší. Zrovna před měsícem jsem si užil portování kusů PyQt4 do nového Mintu, kde už je všude Qt5 a stálo mě to asi 6 hodin práce, s tím že před pár lety bych na tom naprosto vyhořel.

[Petr Tomášek]

A to je právě špatně! To si má nechat pro -future větev...

[disorder]

spravit balicek nie je zrovna komplikovana vec a ked uz sa stretnem s programom mimo oficialneho repozitara, tak najcastejsie to byva vo formate deb balicku (hoci pre ubuntu, tak 100% kompatibilne). stiahnem a nainstalujem.

cize toto je problemom pre non-debian distra, ano? tak vdaka ubuntu aspon za takyto monopol, vobec nepocitujem ziadny problem v tejto oblasti.

[Peter]

"spravit balicek nie je zrovna komplikovana vec a ked uz sa stretnem s programom mimo oficialneho repozitara, tak najcastejsie to byva vo formate deb balicku (hoci pre ubuntu, tak 100% kompatibilne). stiahnem a nainstalujem."

Ano, protože ten balíček s největší pravděpodobností dělá přesně to, co ty Flatpaky: bundluje si závislosti, ale na rozdíl od Flatpaku není ta aplikace vůbec v žádném sandboxu.

[Kate]

Ne tak docela. Připraví se tím o možnost vycházet z nějakého runtime. Vyčítaný problém ve Flatpaku ve formě suid bitu je tam pochopitelně také, jen je to narozdíl od Flatpaku který to opravil řeštitelné dost obtížně.

[disorder]

okrem proprietarnych veci som snad este nevidel, ze by niekto bundloval co tam nepatri. netvrdim, ze to tak niekto nerobi, ale asi nie som cielovka takych programov.

[kralyk z abclinuxu]

spravit balicek nie je zrovna komplikovana vec

Spravit balíček vyžaduje udělat si přehled o tom, jestli v daném distru jsou potřebné dependence a v potřebných verziích/variantách, dále pak u těch, co nejsou, vymyslet, jak to řešit. A je celkem jedno, jestli pro Debian-family nebo RH-family nebo jiná distra.

Jinak ano, žádný z těch úkolů jednotlivě není rocket science a dá se, ale dohromady je to vopruz, násobený počtem podporovaných dister.

Fajn by bylo, kdyby existovala nějaká meta-definice, ze které by se daly např. tvořit balíčky pro více dister a třeba i bundly jako AppImage nebo Flatpak. Otázka je, jestli by ta definice mohla být dostatečně obecná, aniž by byla šíleně složitá.

[PetrHL]

Kolik jste tech balicku realne udrzoval a jak dlouho? Delat baliky je peklo! Debian si v pohode zmeni nazev balicku, udelate balicek pro Ubuntu, ten ale funguje spatne v Minutu. Udelate DEB, ktery funguje v unstable ale ve stable uz ne a v Ubuntu taky ne. Peklo na zemi. Pak ruzne verze vyvojovych aplikaci ktere kod kompiluji. Neda se spolehnout naprosto na nic, teda ano, da se spolehnout na to, ze to nebude jednoduche ani omylem. Delam baliky pro svuj program uz X let a jsem z toho cim dal zoufalejsi.

Navic kdyz uz se balik dostane konecne do stable, je aktualni verze uplne jinde a kdyz je v te stare verzi bug, tezko jej budu opravovat kdyz je aktualni upstream uplne jinde.

Vytvorite balik a zacne kolecko. Ve VirtualBoxu mam Debian, Ubuntu, Mint v nekolika verzich a pokazde musim otestovat instalaci a upgrade :(. Vydat novou verzi je peklo na nekolik hodin. Des a posledni dobou na to fakt nemam naladu.

AppImage mi uz skoro funguje, pak bude nasledovat flatpack a asi se na DEB vykaslu. RPM baliky pro Fedoru mi nastesti dela nekdo jiny, jestli funguji v openSuse nemam tuseni a odmitam to resit. Odmitat mohu, ale kdyz mi uzivatele reportuji problem, nemohu je poslat do mist, kde slunce nesviti. Drtiva vetsina z nich kompilaci nezvladne. Mam se na ne vykaslat?

[Martin Tůma]

Mam se na ne vykaslat?

Ne, bohatě stačí začít používat OBS...

[Peter]

Problém je v tom, že nejvíc práce s udržováním balíčků pro x distribucí je v testování a kontrolování, že s měnícími se závislostmi v té dané distribuci ta aplikace pořád perfektně funguje. A tady mi OBS opravdu nepomůže. Flatpak dává vývojáři kontrolu nad běhovým prostředím aplikace. Runtime má pořád stejný bez ohledu na distribuci, na novější verzi runtimu může přejít, až si je jistý, že je na to připravený, nemá to tempo diktované distribucemi. Takže ne, začít používat OBS bohatě nestačí. OBS nemusí být špatný způsob, jak flatpaky vytvářet. Zvolím si jednu distribuci, proti které budu testovat a z jejichž balíčků skládat obsah flatpaku, a ten flatpak pak budu distribuovat pro další distribuce, aniž bych musel řešit, jestli je s nimi aplikace kompatibilní. Myslím, že OBS už to umí pro AppImage.

[Martin Tůma]

Tak jistě, pokuď někdo píše SW "pro vývojáře" a ne "pro uživatele", tzn. závisí na tisíci různých "cool" knihovnách, jejichž API se mění 2x do měsíce a jednou týdně vyjde rozbitá verze, tak tady opravdu OBS nepomůže. Pokuď se ale SW už píše s tím, že by měl fungovat v běžných "mainstrem" prostředích, tak tady odvede OBS 99% práce.

V zásadě pak stačí pouze vyzkoušet balíček (který se vyrobí zaškrtnutím jednoho checkboxu) pro novou verzi distribuce v okamžiku, kdy je distribuce přidána do OBS. A to se zas tak často neděje - Ubuntu vychází 2x ročně, Fedora a OpenSUSE jednou, Debian jednou za dva roky a RHEL jednou za 5 let.

[MadCatX]

Dejme tomu, že bych chtěl OBS vykoušet aspoň pro balíčkování na skutečně mainstream distra. Jak je řešena kontrola závislostí? Dozvím se nějakým automatizovaným způsobem, že nějaký z mých balíčků potřebuje rebuild nebo musím čekat, než mi někdo nahlásí bug? Lze automatizovaně sestavovat i balíčky včetně závislostí? Mám-li nějaký backend ve formě knihovny a k němu frontend, budu je chtít zabalit odděleně ale zároveň najednou, protože změna v backendu si může vynutit úpravu frontendu, obráceně to tak být nemusí.

[Martin Tůma]

Při změnách závislostí OBS balíčky automaticky rebuilduje.

[Peter]

Už jen to, abych měl nainstalovaných x distribucí, abych na nich zkoušel funkčnost nových balíčků, je rozhodně víc než 1 % práce. Mimochodem Fedora vychází dvakrát ročně. openSUSE už má rolling release verzi, kde bych musel testovat prakticky pořád, to samé u Archu. A to se nebavím o tom, že se člověk musí občas hádat se správci svých závislostí v distribucích, protože ty závislosti často buildí s různými flagy, takže i stejné verze se občas chovají jinak. Když toto člověk řekne někomu, kdo dělá svůj software i pro ostatní systémy a Linux je pro něj pár procent uživatelské základy, tak řekne: dejme mi něco jako Flatpak nebo Snap, protože takové šílenství absolvovat nehodlám.

[snajpa]

No, Nix jde nainstalovat na vetsine distribuci a je to vcelku suckless zpusob popisu kompilace + zavislosti [/nix-propaganda]

[Martin Tůma]

Jak už jsem psal - je to o stylu vývoje. Pkuď si do projektu zatáhnete závislosti na nějakých obskurních knihovnách, které se verzi od verze (build od buildu v různých distrech) chovají jinak a mají tendenci dělat závislý SW nefunkčním, nezbude vám opravdu nic jiného, než použít bastly typu flatpak nebo appimage.

Při dostatečně "defenzivním" stylu vývoje takové problémy - z vlastní zkušenosti - nenastávají, nebo alespoň o několik řádů méně často, než bugy v samotném projektu. Takže "testování" se dá nechat na uživatelích a řešit až případný, zcela ojedinělý, bugreport (řízení jaderného reaktoru ve flatpaku jsem ještě neviděl a doufám, že ani neuvidím...).

[kralyk z abclinuxu]

Jak už jsem psal - je to o stylu vývoje. Pkuď si do projektu zatáhnete závislosti na nějakých obskurních knihovnách, které se verzi od verze (build od buildu v různých distrech) chovají jinak a mají tendenci dělat závislý SW nefunkčním

Jasně, např. libstdc++, openssl nebo libcurl jsou vyloženě obskurní :-/

[PetrHL]

+ 1

Pripad openssl je super. Zmena minor verze a rozbiti api. Fakt slast.

[Martin Tůma]

Docela by mě zajímalo, v jaké (ne-rolling updates, tam samozřejmě z principu v průběhu času velké změny občas nastanou) distribuci se v rámci jedné verze změnilo libstdc++ nebo OpenSSL tak, že rozbilo závisející balíčky...

Ale uznávám, že tahle debata je pro mě předem prohraný boj - vždy se dá najít nekonečné množství důvodů, proč něco nejde.

[Martin Tůma]

Zvlášť by mě to zajímalo v případě libstdc++, protože moje zkušenosti jsou zcela jiné. Do loňska jsem se několik let účastnil projektu, kde jsme několikrát denně distribuovali dynamicky linkovaný kód pro RHEL, SLES a Debian (od RHEL6 po nejnovější verze), kompilovaný oproti libstdc++ z RHEL6 a NIKDY se nestalo, že by to neprošlo testama z důvodů nekompatibility libstdc++...

[kralyk z abclinuxu]

kompilovaný oproti libstdc++ z RHEL6

No, tak v takovém případě jsi v pohodě, protože libstdc++ z RHEL6 bude nejspíše tak prastará vykopávka, že ji sestavoval ještě Ježíš s učedníky a prakticky se ti nestane, že by někdo měl starší. Naproti tomu když chceš sestavovat na Debianu, tak musíš downgradovat, aby pak ten sw nastartoval i na RHELu, CentOSu apod., anebo změnit distro právě na RHEL nebo CentOS. To se tu řešilo v jiném vlákně.

Jinak nejde ani tak o to, že by aktualizace nutně rozbila balíčky (resp. to se možná i u toho OpenSSL stalo, už se přesně nevzpomínám), ale už to, že jsou ty balíčky ve znatelně jiných verzích je komplikace. Ten libcurl jsem zmínil proto, že např. v nějaké verzi přidali nějakou fíčuru, kterou potřebuju, ale starší Debian, CentOS apod. mají starou verzi, takže je potřeba napsat na tu fíčuru workaround nebo ji backportovat a dále také psát na to všelijaké feature testy. Takže musí někdo udělat tu práci, aby zjistil, kde jaké fíčury v kde jaké knihovně jsou nebo nejsou na kdejaké distribuci a následně napsal a udržoval ty backporty/workaroundy a feature testy. To jsou šílený hladový zdi. Na to se vyplácají celé člověkodny práce, které mohly být naplněny nečím mnohem smysluplnějším.

[debian+]

Kolik jste tech balicku realne udrzoval a jak dlouho? Delat baliky je peklo! Debian si v pohode zmeni nazev balicku, udelate balicek pro Ubuntu, ten ale funguje spatne v Minutu. Udelate DEB, ktery funguje v unstable ale ve stable uz ne a v Ubuntu taky ne. Peklo na zemi. Pak ruzne verze vyvojovych aplikaci ktere kod kompiluji. Neda se spolehnout naprosto na nic, teda ano, da se spolehnout na to, ze to nebude jednoduche ani omylem. Delam baliky pro svuj program uz X let a jsem z toho cim dal zoufalejsi.

Navic kdyz uz se balik dostane konecne do stable, je aktualni verze uplne jinde a kdyz je v te stare verzi bug, tezko jej budu opravovat kdyz je aktualni upstream uplne jinde.

Vytvorite balik a zacne kolecko. Ve VirtualBoxu mam Debian, Ubuntu, Mint v nekolika verzich a pokazde musim otestovat instalaci a upgrade :(. Vydat novou verzi je peklo na nekolik hodin. Des a posledni dobou na to fakt nemam naladu.

AppImage mi uz skoro funguje, pak bude nasledovat flatpack a asi se na DEB vykaslu. RPM baliky pro Fedoru mi nastesti dela nekdo jiny, jestli funguji v openSuse nemam tuseni a odmitam to resit. Odmitat mohu, ale kdyz mi uzivatele reportuji problem, nemohu je poslat do mist, kde slunce nesviti. Drtiva vetsina z nich kompilaci nezvladne. Mam se na ne vykaslat?

Preto je aj dost zvyk, ze kodery len davaju zdrojaky a niekto dalsi (z distra alebo distro-fanus) spravi uz balicek pre distribuciu

[debian+]

Byva skor standart: 1.) .deb 2.) .bin.tgz 3.) .rpm

[Bedňa]

Spravím z toho Appimage a nie sračky ako lezú z RedHat a Canonicalu, ja to ani nespustím.

[AsciiWolf]

A sandbox si budeš zprovozňovat přes Firejail. Jo, skvělé BFU-friendly řešení. (Navíc to bude méně bezpečné, než ten Flatpak.)

[Bedňa]

A to už RedHat v kontajneroch nemá heslá v plain texte, tak tlieskam

Myslím, že mi Flatpak nefungoval kvôli absencií systemd, teda u Snapy si to pamätám určite. Ten ehm systemd nemá žiadne závislosti, to majú súdruhovia pravdu, akurát sračkoidné distribúcie na ňom stavujú svoj celý enviroment.

Keby všetci frčali na antiX/Debian unstable, nepotrebujú riešiť ptákoviny. Mám najnovšie knižnice od všetkého okolo a žiadny vývojár, určite až na nejakého uvrešťaného čo sa tu zachvíľu ozve, si nemôže sťažovať. Aj Arch už nestíha s dychom, takže čochvíľa z neho bude ďalšie zbytočné distro. Môžeme si pomerať ePenisy a určite vyhrám

[MadCatX]

Jojo, kdyby všichni používali distro jako já, DE jako já, konfiguraci jako já, to bych to měl jednoduché... Je fór, že to říkáš zrovna ty, známý odpůrce jakéhokoliv technického řešení, které není aspoň deset let staré.

[Bedňa]

To bol taký chaby pokus o flame vrámci srandy.

odpůrce jakéhokoliv technického řešení, které není aspoň deset let staré.

Heh toto píšu všetci čo pretlačujú šmejďárny namiesto poctivej práce. Áno už sa teším kedy spravíte z Linux Enviroment MS sračku bez konceptu. To už ale ja budem na dôchodku, všetko mi bude šumák a budem vás všade chodiť za to jebať na plný úväzok.

[AsciiWolf]

Myslím, že mi Flatpak nefungoval kvôli absencií systemd, teda u Snapy si to pamätám určite.

Flatpak již nějakou dobu na systemd nezávisí.

[Bedňa]

To je fajn posun, takže si predsa nechali pootvorené dvierka. MS si tiež myslel že sú najmúdrejší a za posledný rok sa to myslenie otočilo. Žeby to nariekanie po fórach, bugzillach atď. nebolo zbytočné ako tu väčšina tvrdila?

[Petr Tomášek]

Základem je, aby se program dal zkompilovat pomocí ./configure --prefix=/usr --sysconfdir=/etc && make && make install. Pak stačí jednoduše vytvořit pár souborů k zabalení jako balíček pro .deb, nejlépe k tomu ještě .spec pro RPM. Pokud je program dobře naprogramovaný a nepoužívá prasárny, je pak možné jej překompilovat víceméně automaticky pro kdeco.

[MadCatX]

Problém ale není s kompilací, resp. nastat může tehdy, když na nějakém distru nejsou k dispozici potřebné knihovny buď vůbec nebo v potřebné verzi. Problém je hlavně s testováním a udržováním těch balíčků pro větší množství distribucí. Spravovat třeba RPMka pro Fedoru, která má novou verzi každý půlrok, k větším změnám občas dojde i v rámci jedné verze a podporovat je nutné aspoň tak tři verze dozadu musí být fakt job snů. Dále si různá distra na "svoje" verze nějakého SW aplikují dle libovůle maintainerů různé out-of-tree patche, takže co funguje na F28 nemusí fungovat na Ubuntu 18.04 apod. Tohle jsou přesně ty záludné a těžko předvídatelné problémy, které mohou některé vývojáře odrazovat od toho, aby brali Linux vážně a třeba Flatpak se tuto situaci snaží aspoň nějak řešit.

[trekker.dk]

Spravovat třeba RPMka pro Fedoru, která má novou verzi každý půlrok, k větším změnám občas dojde i v rámci jedné verze a podporovat je nutné aspoň tak tři verze dozadu musí být fakt job snů.

Od toho jsou správci balíků.

Flatpak se tuto situaci snaží aspoň nějak řešit.

Jo, přidáváním dalších hoven do té hromady hnoje, kterou je IT obor.

[MadCatX]

Spravovat třeba RPMka pro Fedoru, která má novou verzi každý půlrok, k větším změnám občas dojde i v rámci jedné verze a podporovat je nutné aspoň tak tři verze dozadu musí být fakt job snů.

Od toho jsou správci balíků.

Pokud hodlám distribuovat svůj vlastní software pro Linux, jsem tím správcem balíčků já. Představa, že švihnu kód někam na GitHub a někdo jiný to za mě zabalí je přinejmenším dost optimistická. Pro jednotlivce nebo malé týmy představuje konstantní údržba linuxových balíčků značnou zátěž, kterou je ne každý ochotný podstupovat. Tím spíše, když třeba na Windows stačí rozumně napsaný kód zkompilovat jednou a šance, že bude fungovat na všem od XPček pod desítky a ještě dál je dost vysoká.

[Peter]

Nehledě na to, že lidí, kteří jsou ochotní spravovat balíčky v distribuci, je málo. Rozdíl v množství softwaru, který je k dispozici pro Linux a který je zabalíčkovaný v distribucích, je čím dál větší.

[Peter]

Problém není v kontejnerech, problém je v tom, jak se do nich dostává ten obsah. Můžu mít Docker kontejner plný ručně zkompilovaného neaktualizovaného bordelu a můžu mít kontejner, který je sestavený z balíčků nějaké distribuce a pravidelně z ní dostává aktualizace. To samé platí u Flatpaku. Myslím, že Fedora nedávno začala podporovat buildování Flatpaků z balíčků v distribuci. Pak tyto Flatpaky budou dostávat aktualizace stejně jako balíčky v distribuci.

[olin]

Do kontejneru se ale nesmí cpát průběžné aktualizace, to je v rozporu s reprodukovatelným otestovaným buildem...

[Peter]

To dost záleží na povaze těch aktualizací. Pokud je to založené třeba na RHEL/CentOS, kde se alespoň na úrovni základního systému drží API/ABI kompatibilita, neviděl bych v tom problém.

[debian+]

Aky problem pred aktualizaciou zaarchivovat kontainer?

[snajpa]

LOL? LOL! LOL. Looooool. Tohle je jakoze myslene fakt vazne? A do tohohle vtipu jde nekdo jakoze dobrovolne? Ani nevim, ktera cast tohohle vyjadreni mne nadzvedla vic. Asi snad kazdy jednotlivy slovo. Jakoze fakt seriozne myslena hlaska? Nebo jenom vtipna jednovetna glosa na cely stav hipsterceni ohledne par namespaces, kterym se ted honosne rika kontejnery? :D Lololo. Kontejner, nesmi, prubezne, aktualizace, rozpor, reprodukovatelny, otestovany, build. LOL! Takze spis: kontejner = nahodna michanice namespaces/cgroup bez tvaru; nesmi = nedaji protoze dopr*any design; prubezne = tyyyjo vlhky, nedosazitelny sen, na ktery mame trapny workaround prohlaseny za feature (proste ten zamalwarovany stav zahodime a pak si pockame na novy malware...); aktualizace = viz predchozi keyword, tohle nevime, co je, mame workaround; rozpor = pratele, cele to, co delate, je rozpor se zdravym rozumem; reprodukovatelny = znelo to cool, vsichni to chteji, ale nevime, co to znamena; otestovany = detto; buildem = nahodnou slepeninou, ktera zrovna dosedla a spustila se. Ship it! :D LOL.

[Chytrex]

+1

Smutné je že tvůj comment je dnešní realita.:(

[snajpa]

Jenom pro poradek. Bezici kontejner se aktualizovat za behu *da* a delat se to *ma*. Ze si vy borci vymyslite 3+ zpusoby lepeni Bash spaget a prohlasite to za reprodukovatelny, z toho nic reprodukovatelnyho ani naaaahodou nedela. Kdyz smrdi tooling vc. podkladovyho distra, lezou pak z lidi takovyhle vtipny hlasky. Na vsechno ostatni je tu nix-build, nix-copy-closure a nixos-rebuild Doporucuju si precist tuto uz dvanact let starou akademickou praci a prestat vypoustet do sveta bludy, co vsechno se neda. Aneb, svet se posunul a paralelne k vsem tem “devops” bandam hipsteru funguji borci tady s Nixem, kteri chodi a stavi jeden reprodukovatelny aktualizovatelny deployment za druhym. I nas vpsAdminOS je aktualizovatelny i ve stavu, kdyz bezi jako live OS... a kdybyste nekdo chtel videt konkretni priklad, jak ma vypadat reprodukovatelna aktualizovatelna infrastruktura...

[trekker.dk]

Ceterum censeo Carthaginem esse delendam

[snajpa]

Je tak, budu si hrat na trolla a tlacit to horem spodem, dokud mi nekdo nevpali do ksichtu, ze existuji uz i jeste lepsi reseni... (napr. v Nixu se da udelat infinite loop, coz muze taky smrdet). Ale dokud bude v kurzu Docker, Flatpak a podobny hackish gulase, bude jeste srandy dost A taky, koho tahat z prusvihu a od koho si za funkcni reseni v normalne lidsky nestihatelnych deadlines nechat poradne zaplatit

[trekker.dk]

Na LinuxDays o tomhle chtěl někdo přednášet, ale podle všeho to nikoho nezajímalo. I když bych teda ani nevylučoval tu možnost, že lidi z Red Hatu hlasovali víckrát.

[snajpa]

Za to na prednase o NixOSu bylo plno az do konce... :)

[trekker.dk]

Ceterum censeo Carthaginem esse delendam

[Roman]

Nemam rad a nepouzivam Flatpack od zacatku. Lidi by se opravdu meli zpamatovat. A vyvojari knihoven a interpretu by meli vic myslet na zpetnou kompatibilitu.

Cele tohle kontainerizovani je zlo (dobry sluha, zly pan). Melo by se pouzivat jen okrajove a podstive. Ovsem lenost lidi vitezi. Taky se casto bezproblemu spousti spatne nastavene Docker obrazy nejisteho puvodu. A mnohokrat je v kontaineru root user ackoliv tam moh byt unprivileged. Hlavne ze mame obrazy se vsim....

Nemam rad a nepouzivam Flatpack od zacatku. Lidi by se opravdu meli zpamatovat.

Když už hejtujete, tak alespoň napište správně název.

Cele tohle kontainerizovani je zlo (dobry sluha, zly pan). Melo by se pouzivat jen okrajove a podstive. Ovsem lenost lidi vitezi.

Co třeba Qubes OS? Rovněž vám připadá jako zlo?

[HOCIKTO]

Jó, na Flatpack se to nadává, ale aurkill.com nikde nevidim.... přitom v tom není tak velký rozdíl

+1; případně ta hromada third-party PPA pro Ubuntu, které často dokáží systém dokonale rozbít.

[tejpek]

tyvole srovnávat AUR a PPAs je fakt kokotina vůbec srovnávat Flatpak s AUR je dementní nápad Flatpak jde nainstalovat kliknutím na odkaz na webu. AKA 0 nutnost něco vědět, zvládne každá sekretářka. PPAs jde přidat taky ultra snadno, ale už to chce alespoň skill lvl 1. AUR zkompilovat a nainstalovat bez AUR helpers už přeci jenom hodně vyžaduje aby uživatel něco věděl. Navíc musel předtím ten Arch nainstalovat, což taky neni ultra easy. Kolem a kolem člověk co používá AUR ví do čeho jde.

[lertimir]

No je zde principielní rozdíl v tom, kdo se zaručuje za co. AUR z podstaty jasně říká, opravdu chceš instalovat soft, který je neprověřený? A pak je to na uživateli a jeho znalostech a zodpovědnosti. Flatpack se snaží tvářit, že vše je OK a že je to prostředí, které blbosti nebo špatné záměry udrží v nějakém rámci. A tím dávají uživateli pocit falešné bezpečnosti.

[MadCatX]

Uživatel, který úskalím instalace aplikací z AURu nebo různých soukromých repozitářů rozumí ty repozitáře v principu nepotřebuje, protože by si příslušné balíčky dovedl sestavit sám. Naopak napsat yaourt -S nějaký_bordel_z_AURu se dovede naučit i ten BFU, který si tak může nepříjemně nabořit systém. Úplně stačí situace, kdy se maintainer nějakého AUŘího pseudobalíčku na jeho údržbu vybodne a on jako na potvoru vyjde update, který naruší závislosti. V ten moment BFU nemůže aktualizovat nic, takže se k němu nemusí dostat ani případné kritické záplaty. Flatpak poskytuje aspoň nějakou míru izolace a vnitřní konzistence a i v případě nějaké závažnější chyby to neodnese celý systém.

[Jacob]

BFU se to naučit nedovede. Neviděl jsem jediného, který by to zvládl. Ve chvíli, kdy BFU začne psát příkazy typu yaourt -Ss cohledam a yaourt -S cochcinainstalovat, už to podle mě není BFU. A upřímně, jestli si BFU před tím sám nainstaluje Arch, tak to už vůbec není BFU.

[mankind_boost]

instalace arch je jen copy paste z wiki, nevyzaduje zadne znalosti ci schopnosti

[MadCatX]

Pokud nepřekládáš BFU jako "totální trotl na hranici svéprávnosti neschopný porozumět psanému textu a jednoznačným instrukcím" veř mi, že se to naučí. Postačí k tomu nevypnout při obsluze počítače selský rozum - což je přesně to, co někteří ÜberBFU dělají. Jednomu "běžnému člověku" jsem kdysi nainstaloval na tehdá fungl nový notebook Arch, protože podpora Sandy Bridgů stála tehdy v mainstreamových distrech dost za bačkoru. Dnes - více než po 6 letech - ho tam pořád má jako jediný OS a jediné problémy, co řeší jsou kolize při aktualizacích, protože to má zasrágorované spoustou ptákovin z AURu.

(Když jsme načali téma BFU vs software, který se nedá ovládat čtyřmi kliknutími mě napadá jedna nedávná histoka z práce. Někdy na jaře jsem zgruntu přepsal jeden výpočetní nástroj. Původně mělo samozřejmě jít o velkolepý projekt, kterým si to všechno vypočítáme a nasimulujeme a vůbec na tom postavíme úžasnou science. Počáteční drive velmi rychle zvadl a když jsem přišel s tím, že prototyp je hotový a připravený k ostrému testování, najednou nikdo nevěděl, co na tom budeme počítat. Vida, kam celý projekt míří jsem prohlásil, že nehodlám trávit stovky hodin lepením GUI k něčemu, po čem pak neštěkne ani kočka. Malý úkol, na který se nový simulátor hodil se nakonec objevil ale napsat GUI by znamenalo daleko víc práce, než kdybych měl každou simulaci osobně pustit ručně. Abych nebyl za úplného vola, zbastlil jsem na to kolegyni v Pythonu jednoduchý CLI frontend, který byl přece jen o něco šikovnější než syrové předávání parametrů do příkazové řádky. Napsané jsem to měl zhruba za dvě hodiny. Z představy, že budu někomu vysvětlovat, jak se PuTTynou naSSHčkovat do serveru, pustit tmux a z něj příslušný startovací skript se mi sice mlžilo před očima ale výsledek mě fest překvapil. Když se na poslední schůzi nadhodilo, kdy že k tomu bude nějaké to GUI (stará verze simulátoru ho totiž má), označila to kolegyne za zbytečnost s tím, že ten primitivní CLI wizard v klidu stačí. Dlužno dodat, že naučit se šest příkazů pro yaourt je oproti tomuto naprostá banalita. Tolik asi k tomu, co dokáže zvládnout i BFU.)

[Jacob]

Rozdíl v tom teda je, AUR nikdo nikde neprotlačuje jako RH Flatpack a nikdo se nesnaží z toho udělat univerzální systém pro distribuci softwaru v Linuxu. AUR je volitelný repozitář Archu a nic víc.

[Michal]

Tyhle veci postupne zabijou linuxovy desktop. Dneska jsem preinstalovaval 2 laptopy z ubuntu (implicitni os na desktopech ve firme) na windows. Protoze VLC instalivany pres software center neumi prehrat videa z cifs mountu kvuli nejakemu zkurvenemu sandboxu. BFU nesmi byt nucen resit takove problemy. Vim, ze bych jim mohl nainstalovat vlc z balicku a na kolenou uprosit aby tomu jeste dali sanci. Ale delat to nebudu, nebudu riskovat ze takovy kostlivec zase vypadne ze skrine.

[Petr Ježek]

Kdeže, každé distro má svůj balíčkovací systém a vlastní balíčky, leckdy pouze přebalené z jiného distra. V Archu si to, co není v repozitářích, může zabalit pomocí ABS každý dle své vůle. Žádný flatpak není potřeba, avláště tam, kde je již tak více možností, jak si balíčky sám vytvořit a jak je to se závislostmi, které jsou u některých dister opravdu pekelné...

[bibri]

To jste si teda pomohl! Kromě toho jsem to teď vyzkoušel a no problem, takže potíž bude asi jinde než v Ubuntu.

[lertimir]

A tak je to správně, Nefunguje tak přeinstalovat. Nemyslím si, že linuxový destop tohle zabije. Už mnoho let si drží podíl cca 1,5-2,5% v závislo na tom kdo to měří. A také souhlasím, že BFU nesmí být nucen řešit takovéto problémy. BFU se ani nemá snažit rozumět jak věci fungují. Pro útočníky ideální prostředí.

[pavele]

Opravdu rozumíš, jak přesně funguje linux a tvá distribuce?

Tak to gratuluji.

Dnes nikoho nezajímá, na jakém systému běží xxx. Uživatel chce xxx používat a ne být nadšený z toho, že právě teď se mu podařilo, aby xxx fungovalo.

[pepazdepa]

A ja myslel, ze linuxaci instaluji softver pres:

curl ${url} | bash

Hmmm.

[kralyk z abclinuxu]

Takhle se instaluje software na Windows ne? Teda ne doslova takhle, ale pokud vim, v zásadě to funguje tak, že stáhneš binárku a spustíš...