abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 18:33 | IT novinky Ladislav Hagara | Komentářů: 0
    dnes 13:11 | Nová verze

    Byla vydána nová verze 2.53.18.2 svobodného multiplatformního balíku internetových aplikací SeaMonkey (Wikipedie). Přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    dnes 00:22 | Zajímavý článek

    Na blogu programovacího jazyka Swift byl publikován příspěvek Psaní aplikací pro GNOME v programovacím jazyce Swift. Používá se Adwaita pro Swift.

    Ladislav Hagara | Komentářů: 4
    včera 17:44 | Zajímavý software

    egui je GUI knihovna pro programovací jazyk Rust běžící na webu i nativně. Vydána byla verze 0.27.0.

    Ladislav Hagara | Komentářů: 0
    včera 16:22 | Nová verze

    Byla vydána nová verze 6.1 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.13. Thunderbird na verzi 115.9.0.

    Ladislav Hagara | Komentářů: 0
    včera 14:44 | IT novinky

    Linka STOPonline.cz v roce 2023 přijala 3700 hlášení závadného obsahu na internetu, 22 bylo předáno PČR, 23 bylo předáno ISP a 944 závadových domén zobrazujících dětskou nahotu či pornografii bylo nahráno do mezinárodního systému ICCAM, který je spravován asociací INHOPE.

    Ladislav Hagara | Komentářů: 6
    26.3. 20:44 | Zajímavý článek

    Byla publikována podrobná analýza v upstreamu již opravené bezpečnostní chyby CVE-2024-1086 v Linuxu v nf_tables.

    Ladislav Hagara | Komentářů: 0
    26.3. 18:44 | Nová verze

    Byla vydána nová verze 4.1 svobodného 3D softwaru Blender. Přehled novinek i s náhledy a videi v obsáhlých poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    26.3. 18:22 | Nová verze

    Úkolníček Taskwarrior (Wikipedie) pro správu úkolů z příkazového řádku byl vydán ve verzi 3.0.0.

    Ladislav Hagara | Komentářů: 0
    26.3. 16:33 | IT novinky

    Společnost Canva stojící za stejnojmenným webovým grafickým editorem koupila společnost Serif stojící za grafickým editorem Affinity.

    Ladislav Hagara | Komentářů: 10
    Steam
     (24%)
     (29%)
     (14%)
     (9%)
     (24%)
    Celkem 382 hlasů
     Komentářů: 10, poslední dnes 17:31
    Rozcestník

    Nicholas Fraser: Flatpak není budoucnost

    Nicholas Fraser v obšírném článku Flatpak Is Not the Future (Flatpak není budoucnost) poukazuje na problémy flatpaku.

    23.11.2021 23:00 | Ladislav Hagara | Zajímavý článek


    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Diskuse byla administrátory uzamčena

    23.11.2021 23:21 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Tenhle přístup fakt nemam rád. Ne, že by čistě fakticky neměl pravdu, Flatpak, AppImage atd. fakt nejsou žádný technologický skvosty, ale ten člověk víceméně pouze kritizuje a nenabízí žádné použitelné řešení, resp. jeho "řešení" je:
    For developers, yes, this may be harder than making an AppImage. There will still be occasional bugs that crop up between library versions. There will still be occasional differences between distributions. These are things you can work around. It may be painful at first but it will be worth it: you will provide a much superior user experience by working around the issues with your users’ libraries rather than attempting to replace them.
    ... no takže TL;DR si to maj vyžrat vývojáři, kteří mají investovat čas, energii a mentální zdraví do nekonečné série různých velmi zábavných nekompatibilit a chyb mezi X různými distribucemi, a když to neudělají, budou pranýřováni za technologicky "nečistý" přístup.

    IMO dokud bude tenhle přístup přetrvávat, nic se k lepšímu nezmění a FlatPaků, AppImagí atd. bude čím dál víc, i přesto že jsou to technicky hnusná řešení.
    24.11.2021 00:10 Klid
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    ten člověk víceméně pouze kritizuje a nenabízí žádné použitelné řešení
    Neni za to placeny, pokud kritizuje neco v cem ma pravdu je pro vyvojare velmi cenne ovsem pokud se toho vhodne chopi. Neco podobneho udelal nedavno Linus a treba vyvojari KDE se toho chopili tak ze se snazili osetrit aby neslo pres Discovery odebrat pudu pod nohama. Ale mas pravdu je to jen o tom jestli si vyvojar dokaze sypat popel na svou hlavu, pokud by k tomu byl prokazatelny duvod. Nekdo treba nekdy prispel do nejakeho projektu a za to by pozdeji dostal horsi produkt nez mel, myslis ze pak mel duvod prispet znova? to by musel byt vul nebo fanatik;-)
    24.11.2021 22:33 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    IMO to není o sypání popele, myslim si, že je nekonstruktivní v tomhle pojetí operovat (tj. v z většiny emoce). IMO to je prostě jen o zdrojích, o tom, co je/není ekonomické, co škáluje/neškáluje.

    IMO vývojáři desktop aplikací obecně/průměrně nemají cykly/sílu/energii/čas/peníze na testování a přizpůsobování svého SW (vč. build systému, stromu závislostí etc.) bambiliónu velmi různě nakonfigurovaných (a velmi různě rozbitých) distribucí a na tomhle žádné množství nasypaného popela ani rozhořčených blogů prostě nic nezmění...
    Neco podobneho udelal nedavno Linus a treba vyvojari KDE se toho chopili tak ze se snazili osetrit aby neslo pres Discovery odebrat pudu pod nohama.
    Tak zrovna Linus má na téma zprávičky podobný názor ...
    24.11.2021 23:28 Pavel Píša | skóre: 18 | blog: logic
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Já Linusovo prohlášení spíš chápu tak, že upozorňuje stejně jako Nicholas Fraser na problémy a snaží se přesvědčit tvůrce distribucí, aby (dopřednou) binární kompatibilitu udržovali. Dokonce někdy i za cenu zachování odlišného chování od standardu. Podle mě je v dnešní době problém složitost řešení a nutnost pro dosažení požadovaného výkonu využívat heterogenního výpočetního modelu, GPU, driverů atd. takže těch standardů a ad hoc vzniklých ABI je příliš mnoho. Před 10, 15 lety bylo rozumně binárně dostupné jen Gtk a binární aplikace jako Adobe Reader a další v zásadě běžely na všech distribucích stejně (i na Slackware, který se od mainline knihovních balíků odlišoval asi nejméně). Dnes je těch optimalizací a závislostí příliš mnoho a není místo, kde udělat řez. Když si nedonesu svoje Qt, tak je možné, že na úrovni C++ Qt ABI bude rozdíl, i když C++ ABI díky Intelu a Itaniu, stejně jako ELF dostalo dobrá vodítka, jak má vypadat a být přenositelné. Ale dnes na úrovni Qt ABI budou problémy, zkusíme jít na úroveň X ABI, jenže od toho se upouští a vlastně se již nepoužívá, používají se vlastně jen jeho extensions pro získání GPU výkonu a přesouvání bitmap dále. Přitom tato ABI a jejich využití v Qt se snaží sledovat aktuálně nejvýkonnější konstelaci. Takže donést Qt a vzít systémové X knihovny nemusí být dobrá cesta. Ale když si doneseme i X knihovny, tak nemusí sedět proti stau akcelerací v jádře a driverech. Když se přidá závislost na integrovaném Python interpretru, tak se objeví další kartézský součin. Rozumná rovina řezu neexistuje. Lze doufat, že pro běžné aplikace bude časem systém poskytovat dostatek možností a požadavky se ustabilizují a třeba třeba se opět dočkáme období rozumné kompatibility mezi distribucemi. Uživatelé by měli hledět na čistotu řešení více než často pro vlastní odvedenou práci aplikace zbytné efekty atd.... a oceňovaná by měla být ta často ne přímo ditelná práce na stabilitě a kvalitě knihoven, kódu, ekosystému. Jenže často to co není na povrchu vidět nikdo nezaplatí...
    25.11.2021 08:38 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    V tomto jsem skeptický: Pro autory desktopových prostředí a jejich grafických toolkitů je změna smysl života. Místo aby rozvíjeli X11, tak si vyvinou Wayland. Že v něm nefunguje polovina úkonů od schránky přes dekorace oken, čtení obsahu obrazovky po vzdálenou relaci je v nejmenším netrápí. Místo aby udělali grafické rozhraní pro ALSA nebo rozvinuli jakýkoliv tehdejší zvukový démon, tak si raději napíšou PulseAudio, které trpí tolika chybami, že jej raději nahradí PipeWire, který je ještě horší. Stejná situace je správce přihlašování: SDDM je chudý příbuzný KDM, ale bez GLX vůbec nefunguje. GDM pro změnu je otesánek, který uvnitř má vlastní instanci GnomeShellu. Že by některý z nich správně implementoval PAM, aby fungovalo přihlašování např. čipovými kartami, je úloha z říše fantazie. Já si myslím, že Flatpak a jemu podobné technologie nejsou příčinou, ale důsledkem přístupu autorů desktopů za posledních deset let. Tahounem standardizace nikdy nebyl desktop, ale podnikové distribuce, pro něž desktop byl vždy okrajová záležitost.
    25.11.2021 10:55 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Tahounem standardizace nikdy nebyl desktop, ale podnikové distribuce, pro něž desktop byl vždy okrajová záležitost.
    Ano, protože desktop, narozdíl od podnikových dister, nikdo nezaplatí.
    25.11.2021 11:39 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Takže donést Qt a vzít systémové X knihovny nemusí být dobrá cesta. Ale když si doneseme i X knihovny, tak nemusí sedět proti stau akcelerací v jádře a driverech. Když se přidá závislost na integrovaném Python interpretru, tak se objeví další kartézský součin. Rozumná rovina řezu neexistuje.
    No jo no. Řešení by mohla být sada knihoven (což asi +- implikuje i balíčkovací systém) přenosná mezi distribucemi. Pak by stačilo tu integraci s distribucí vyřešit jednou a X aplikací by proti tomu mohlo linkovat etc. a nemusel by to řešit každej projekt samostatně.

    Něco takového tak trochu už dnes poskytuje balíčkovač Nix, tj. docela velkou sadu balíčků instalovatelnou na různých distrech, bohužel ale nemá vyřešenu tu integraci (a aplikace vyžadující GPU apod. jsou problém) a nevim, jak je na tom se zpětnou kompatibilitou. Takže možná by stačilo vzít Nix a vyřešit tyhle dvě věci.
    26.11.2021 09:35 PetrHL | skóre: 17 | blog: petr_h | Neratovice
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    No jo no. Řešení by mohla být sada knihoven (což asi +- implikuje i balíčkovací systém) přenosná mezi distribucemi. Pak by stačilo tu integraci s distribucí vyřešit jednou a X aplikací by proti tomu mohlo linkovat etc. a nemusel by to řešit každej projekt samostatně.
    Není to právě vlastnost Flatpaku a jeho runtime, který se aktualizuje pravidelně? Z něj pak mohu vycházet a na novější se přepnu až budu mít aplikaci odladěnou.
    "Do, or do not. There is no 'try.'" -- Jedi Master Yoda | CQRLOG | CQRPROP | HamQTH | Domů
    24.11.2021 01:28
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    ten člověk víceméně pouze kritizuje a nenabízí žádné použitelné řešení
    +1
    jsou to technicky hnusná řešení
    To je Tvůj názor.
    24.11.2021 10:16 PetrHL | skóre: 17 | blog: petr_h | Neratovice
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Přesně tak. Už jsem na ty kecy kolem nečistého přístupu alergický. Jestli má čas instalovat si X distribucí, testovat instalaci na čisté verzi a instalaci na upgradované verzi, tak ať si to užije. Já ten čas nemám a vydávám nové verze velice málo. Raději bych sobotu strávil něčím jiným než řešením závislostí pro balíky. Ubuntu 18.04, Ubuntu 20.04, 21.04, 21.10 má každá trochu jiné závislosti. Pak si balík vezmou do debianu a chodí mi, že balík vyřadí z distribude kvůli tomu, že se rozhodli přejmenovat balík, na které program závisí, ať si to prý opravím. Kašlu na ně. Nevadí mi si program kompilovat ze zdrojáků, uživatelé mají smůlu. Balíčků se dočkají jednou za čas. Flatpak jsem zatím neudělal, nemám energii. Můj program spolupracuje s dalšími programy v systému a nevím, jak bych je z flatpaku volal.

    Vývoj letí zuřivým tempem, nezvládám držet krok. Nedělám to fulltime. Program taky není jen hello world nebo něco, co nepotřebuje vůbec GUI.
    "Do, or do not. There is no 'try.'" -- Jedi Master Yoda | CQRLOG | CQRPROP | HamQTH | Domů
    24.11.2021 16:51 Martin Tůma | skóre: 39 | blog: RTFM | Praha
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Pak si balík vezmou do debianu a chodí mi, že balík vyřadí z distribude kvůli tomu, že se rozhodli přejmenovat balík, na které program závisí, ať si to prý opravím.

    Od lidí z Debianu lze sice očekávat cokoliv (spousta z nich stále žije v roce 2000 s přístupem: "my jsme Debian, a ty si před náma sedni na prdel"), ale pokud tam máš nějaké (jmenné?) závyslosti, které by dávalo smysl řešit správně už v upstreamu, tak co jiného mají ty lidi dělat, než to do toho upstreamu reportovat? Většinou (s výjimkou Debianu, přirozeně) jsou lidé od distribucí celkem rozumní a jejich bugreporty mívají hlavu a patu.

    Nevadí mi si program kompilovat ze zdrojáků, uživatelé mají smůlu. Balíčků se dočkají jednou za čas.

    Tenhle přístup si můžeš dovolit buď pokud jsi a) totální autista, nebo b) pokud děláš SW pro úzkou skupinu geeků. Ham radio asi spadá pod b), ale i tak si i v kladných recenzích lidi stěžujou, že jim to na jejich strojích nešlo rozběhat. O "jednohvězdičkových" recenzích ani nemluvě...

    Každý má právo na můj názor!
    24.11.2021 17:49 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Překlad: pán se pokusil dostat balík do Debianu a čekal, že si Debian sedne na prdel před ním.
    Quando omni flunkus moritati
    24.11.2021 20:27 Martin Tůma | skóre: 39 | blog: RTFM | Praha
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Tak samozřejmě, dá se na to koukat i takto a v Debianu to tak asi i vidí. Ale fakt je ten, že žádná jiná z asi dvaceti Linux, BSD nebo OS X distribucí, kde ten SW je se takto nechová...
    Každý má právo na můj názor!
    24.11.2021 22:53 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Tak samozřejmě, dá se na to koukat i takto a v Debianu to tak asi i vidí.
    Nemyslim si... to mi přijde jako takové romantické vnímání, nejspíš na to prostě neměli čas...
    24.11.2021 23:39 Martin Tůma | skóre: 39 | blog: RTFM | Praha
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost

    Tak naposledy rozhodně měli čas na spoustu byrokratických požadavků, včetně nutnosti reakce člověka, co měsíce nereaguje na maily. Nebo požadavku na změnu .desktop souboru, co by rozbil buildy pro jiné distribuce, kde ten program roky funguje.

    A to radši ani nezmiňuju, co si v Debianu navymejšleli při prvním pokusu, o kterej se tady trekker otírá...

    Každý má právo na můj názor!
    24.11.2021 23:55 Klid
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    To bych nerekl, spis to vidim tak ze udelal chybu ze tam necim prispival. Oni pravo meli a on smulu. To je druha mince "Zřeknutí se odpovědnosti" jak to byva u kazdeho linuxoveho programu, tentokrat na to doplatil vyvojar pohledem hlavnich vyvojaru ale uzivatel (nebo podradny vyvojar);-)
    24.11.2021 15:29 j
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Hele, reseni je prece jednoduchy a davno znamy ... dlouholeta (30+) binarni kompatabilita knihoven. Jenze to je fujkyfuj prozmenu z pohledu tech co delaj ty knihovny, protoze zrovna vcera prisli s naprosto bozi funcionalitou, ktera to samozrejme cely rozbije, a zejtra ji uz nebudou podporovat, protoze je to prestalo bavit.

    Mimochodem, tvaris se jako by na widlich vyvojar nemusel setrvale a neustale resit, ze mu neco prestalo fungovat prostoze M$ vydal nejakej uzasnej patch, a pak musi zaridit, aby ta jeho vec fungovala na asi tak desitce tisicovek variant ruznych patchsetu, pokud nechce, aby ho zakaznici poslali dorite.

    Pokud totiz nekdo tvrdi, ze widle sou kompatabilni, tak jedine proto, ze nikdy nic nevytvarel.

    Tech srackometu bude pribyvat jen do okamziku, kdy se nekde provali nejakej poradnej pruser s nejakou neaktualizovanou knihovnou. Pak si vsichni pridaji do internich pravidel, ze neco takovyho jim do infrastruktury vubec nesmi.

    ---

    Dete s tim guuglem dopice!
    24.11.2021 15:30 Meh
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Vyvojari by hlavne nemeli byt prasata a nepsat kod, ktery zavisi na knihovne presne X.Y.Z., protoze jen v tehle verzi uz je opravene O, ale jeste neni rozbite R. Kdyz ma software takovych zavislosti 5, tak to samozrejme nejde zkompilovat uz vubec nikde, krome jedne distribuce v konkretnim stavu (ne)aktualizace.
    24.11.2021 16:26 xxx
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Takhlen rozbite knihovny snad nikdo nepouziva. Realny problem je, ze treba Ubuntu 18.04 melo Qt 5.9, 20.04 5.11, a v progresivnejsich distribucich bylo neco jako 5.14. (Nebo tak nejak).

    Uplne super je pak resit, ze nejaka metoda z Qt 5.14 neni jeste v 5.9. Stejne super je taky trefovani verze OpenSSL.
    24.11.2021 22:34 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Takhlen rozbite knihovny snad nikdo nepouziva.
    boost je docela používaná knihovna...
    25.11.2021 08:12 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    To je ovšem volba autora, že se rozhodne pro knihovnu, která s každou verzí mění ABI.
    25.11.2021 11:31 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    To je ovšem volba autora, že se rozhodne pro knihovnu, která s každou verzí mění ABI.
    Tím jsi asi chtěl říct, že máš rozepsanou knihovnu poskytující stejné fíčury, ale s lepší zpětnou kompatibilitou, a s ní pak půjdeš za tím autorem a navrhneš mu, že ji může použít, že? To je super, autor bude rád.
    25.11.2021 12:50 _
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    tyhle kecy boomeru co v roce 2021 pouzivaji C++ me vzdycky dojmou
    26.11.2021 10:08 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Nepoužívám C++ a ten problém není specifickej pro C++.
    25.11.2021 19:00 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Tím jsem chtěl říct, že každý (autor) je svého štěstí (přenositelná binárka) strůjcem (vyhne se knihovnám, které nedrží ABI).
    25.11.2021 19:10 billgates | skóre: 27
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Alebo proste vsetko kompilovat staticky, co je zjavne buducnost, ku ktorej smerujeme.
    25.11.2021 20:29 j
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Takze tvrdis, ze pro autora je jednodussi do 10 knihoven backportovat stovky oprav mesicne, nez upravit zdrojak svyho vytvoru tak, aby fungoval s aktualne pouzivanyma verzema knihoven ... tak to jiste.

    A chtel bych videt nekoho, jak v realnym provozu pouziva cokoli, co se neda aktualizovat.

    ---

    Dete s tim guuglem dopice!
    25.11.2021 22:12 billgates | skóre: 27
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Nie, presne naopak. Developer si udrzuje potrebne aktualne kniznice a ako sa roluje API kniznic, tak priebezne upravuje projekt. Nerobi to samozrejme rucne, ale vsetko je to zaintegrovane do continuous integration systemu, kde len udrzuje recepty. Vzdy, ked sa ide buildovat novy release aplikacie pre verejnost alebo pre testy, tak sa vysklada cely build system od spodu podla receptov, pocnuc kompilatorom, kniznicami a vsetkym dalsim softverom. Tymto sposobom je kazdy build replikovatelny, zdokumentovany a vzdy sa k nemu da vratit.

    Cize kazdy novy release odovzdany zakaznikom prichadza vzdy s aktualnymi verziami kniznic a vsetko sa deje pekne automaticky, replikovatelne a riadne zdokumentovane.
    25.11.2021 22:24 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    To je teoreticky hezké, ale prakticky to má problém, že autor vydá novou verzi, až když chce on. Kdežto uživatelé chtějí mít opravené knihovny nejlépe hned.
    26.11.2021 10:40 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    To je teoreticky hezké, ale prakticky to má problém, že autor vydá novou verzi, až když chce on. Kdežto uživatelé chtějí mít opravené knihovny nejlépe hned.
    Tohle je mýtus.

    Důvod, proč tohle distribuce můžou udělat, není ani tak shared linkování, ale hlavně to, že distribuce má 1) strojově čitelně specifikovaný dependence a 2) automatizovaný recept na sestavení toho SW.

    Tohle ale s moderními hipsterskými staticky linkovanými jazyky (typu Go, Rust) máš typicky už z v upstreamu, protože mají oficiální způsob, jak strojově čitelně specifikovat dependence (narozdíl od C/C++, který tohle ca. 2021 furt ještě nemá). Takže v případě FOSS softwaru můžeš mít poměrně hodně automatizovaný proces, který zareaguje na notifikaci o (kompatibilní) bezpečnostní aktualizaci depenendence a ten software sestaví, i když jeho autor zrovna spí nebo je někde na pláži...

    Další věc je, že ten shared-linking proces nefunguje moc pro věci, které se z podstaty shared-linkovat moc nedají, tj. např. silně generické knihovny (což je např. část toho zmiňovanýho boostu).
    26.11.2021 19:24 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost

    Tvůj mýtus ti vyvracet nebudu. Moje zkušenosti o tom, co je možné, co se skutečně dělá a proč se to dělá, říkají něco jiného.

    K tvému snu o automatickém procesu: Kdyby závislost měla stabilní rozhraní, tak se především nic automaticky sestavovat nemusí, protože se ta závislost opraví jen jednou. A ne ve všech programech znovu a znovu.

    Hipsterské staticky linkované jazyky vyrostli na skutečnosti, že z open source se stala komodita. Kdyby museli řešit kompatibilitu s proprietárními knihovnami tak, jako to bylo v případě Céčka před padesáti lety, tak po nich neštěkne ani pes, nebo budou umět dynamicky linkovat. Nejsou první, kdo má automatické sestavování. Perl ho měl dávno před nimi. Staticky linkované jazyky se používají především kvůli možnosti zamknout se konkrétní verzi závislosti. Automatický překlad je tomu nutnou podmínkou, protože najednou autor je si distribucí sám sobě.

    Statické linkování je něco jako dockerový obraz. Akorát linkovaní je pod úrovní programu, kdežto obraz roste nad úroveň programu. Nebo se na to můžeš dívat tak, že statické linkování bundluje jen binární knihovny, kdežto obraz všechny soubory. Oboje v podstatě je o tom, kdo a jak to chce používat. Autor programu řekne, že statické linkování mu řeší jeho potřebu zamykat se na konkrétních verzích závislostí, co je uvnitř, nikoho nemá zajímat, a co je mimo jeho program, naopak nezajímá jeho. Autor dockerového obrazu zase bude tvrdit, že to řeší jeho potřebu zamykat se na konkrétních verzích programů uvnitř kontejneru, že co je uvnitř, nikdo nemá řešit, a obdobně že ho nezajímá, co je mimo jeho kontejner. Distribuce naopak pojímají všechny programy a knihovny jako koherentní celek, který prostě v dané verzi distribuce nemění rozhraní a komu se to nelíbí, ať použije jinou verzi distribuce.

    Pro distribuce je dynamické linkování nutnost. Ony nemohou posílat uživateli s každou aktualizací stovky gigabajtů znovu a znovu. Povím ti vtipnou historku: Poslední dobou se při překladu statických molochů typu webový prohlížeč objevují problémy s překladem na 32bitových architekturách. Důvod je ten, že při linkování se všelijakými optimalizacemi a ladicími údaji nestačí 32bitový adresní prostor.

    26.11.2021 22:16 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Kdyby závislost měla stabilní rozhraní, tak se především nic automaticky sestavovat nemusí, protože se ta závislost opraví jen jednou.
    Tohle funguje celkem dobře u něčeho jako libpng nebo nějaká taková knihovna, na který závisí každej a jeho babička.

    Jakmile to je ale něco míň profláklýho, tak se třeba taky stane, že aktuální verzi tý knihovny má Arch, RPM distra mají nějakou starou s aktualizací jednou za uherskej rok a Debian/Ubuntu to nevedou vůbec (nebo obráceně, to je jedno) ... no a pak celej tenhle model skřípe...

    Dynamický a statický linkování se nevylučuje, můžeš třeba nalinkovat libpng dynamicky a tu druhou knihovnu staticky.
    Nejsou první, kdo má automatické sestavování. Perl ho měl dávno před nimi.
    RIP
    Autor programu řekne, že statické linkování mu řeší jeho potřebu zamykat se na konkrétních verzích závislostí, co je uvnitř, nikoho nemá zajímat
    To je nepochopení. Zamknutí verze slouží k tomu, abys měl možnost sestavit program přesně stejným způsobem, jako to udělal autor/jeho build systém, je to takový certifikát "s timhle a timhle jsem to sestavil", ale nijak ti nebrání povýšit verzi kterýkoli závislosti na kompatibilní novější verzi a mělo by to fungovat (pokud autor knihovny není prase a nerozbil API v rozporu se SemVer nebo nějakým takovým standardem). Proto taky je lockfile typicky oddělěný od specifikace dependence. Oproti dynamickému linkování není o nic větší důvod, proč by tě nemělo zajímat, co je uvnitř, od toho to je open source a od toho jsou ty dependence čitelně specifikované...

    Mně naopak přijde, že ta transparence je lepší než u "tradičních" C/C++ věcí, tam kolikrát zjistit, na čem ta věc sakra závisí, je náročný; je to třeba napsané někde ve volném textu, místo verzí tam je třeba něco jako "fairly recent version of libfoo"... Sorry, ale to je hrůza. (Doufám, že mi teď někdo neřekne, že se mam podívat do distrobuce - na tyhle problémy jsem narážel např. právě když jsem se pro něco snažil vyrobit balíček.)
    Pro distribuce je dynamické linkování nutnost. Ony nemohou posílat uživateli s každou aktualizací stovky gigabajtů znovu a znovu.
    Meh, jako jo, sice ty binárky jsou velký, ale stovky GB to fakt nejsou... A jak říkám, ty druhy linkování se dají kombinovat.
    Povím ti vtipnou historku: Poslední dobou se při překladu statických molochů typu webový prohlížeč objevují problémy s překladem na 32bitových architekturách. Důvod je ten, že při linkování se všelijakými optimalizacemi a ladicími údaji nestačí 32bitový adresní prostor.
    Binárky pro 32b systému se dnes typicky cross-kompilují. (Ale souhlasim, že ty nároky na paměť jsou kolikrát celkem brutální.)
    27.11.2021 10:11 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Pro distribuce je dynamické linkování nutnost. Ony nemohou posílat uživateli s každou aktualizací stovky gigabajtů znovu a znovu.
    Meh, jako jo, sice ty binárky jsou velký, ale stovky GB to fakt nejsou... A jak říkám, ty druhy linkování se dají kombinovat.
    Ještě k tomuhle, ona taky ta "úspora" dynamickým linkováním může být záporná. Příklad: pandoc. Když u sebe zkusim nainstalovat pandoc, balíčkovací systém chce nasintalovat 131 balíčků haskell knihoven v celkové velikosti 430 MB. Staticky nalinkovaná binárka má 67MB.

    Jasně, možná když pak nainstaluju pár dalších Haskell prográmů, tak by se to začlo vyplácet - tohle říká tradiční filosofie. Jenže otázka je, kolik bych jich musel nainstalovat a jestli to fakt udělám - myslim si, že nejspíš ne. Zkusil jsem pokusně nainstalovat ten dynamicky linkovanej pandoc a pak zkusit nainstalovat stack - sice to chce nainstalovat miň věcí než bez toho pandocu, ale i tak to chce dalších skoro 90 balíků a 100MB na disku. Dobře, nainstaluju stack a zkusim nainstalovat xmonad - chce dalších 5 balílů a 200MB na disku. To jsem na nějakejch 800MB. To je šílený.

    V sumě; sdílený knihovny se vyplatí - z hlediska místa na disku, bezpečnosti i byrokracie / maintainer režie - až když tu knihovnu používá větší část SW.
    26.11.2021 22:18 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Distribuce naopak pojímají všechny programy a knihovny jako koherentní celek, který prostě v dané verzi distribuce nemění rozhraní a komu se to nelíbí, ať použije jinou verzi distribuce.
    To zní jako Apple ekosystém :-D
    26.11.2021 08:50 j
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    To skoro vypada, ze si nikdy nenapsal ani helo world ... kdyz se zmeni api knihovny, tak se rozhodne nic samo nepredela, velmi casto to znamena kompletne prekopat i zasadni casti aplikace.

    A viz predrecnik, ja rozhodne nehodlam cekat, az mi autor za 1/2 roku doda opravenou verzi jak reseto deravy knihovny. Kterouzto navic nedoda vubec, protoze zkusenost veli, ze autor bude pouzivat verzi knihovny starou nejmin 2 roky. Kupodivu z presne toho duvodu kterej uvadim o odstavec vejs.

    ---

    Dete s tim guuglem dopice!
    26.11.2021 12:26 sid
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Skor absolvent skolenia CI super guru za 1 den aj s obedom a kavou. Staci zobrat vacsi java projekt a aj taka "bezpecna" zmena google guava dokaze nenapadne rozbit projekt vdaka tomu ze dalsi projekt nevie spracovat jednu z novo pridanych metod. Pri troche smoly to dokaze aj prejst cez testy pretoze sa to prejavi az pri spravnej kombinacii parametrov v exporte. Tento automaticky sposob povysovania verzii inac svojho casu propagovali javascript "vyvojari" ktori potom "nechapali" ze ako je mozne ze je tu cosi rozbite. Peitom stacilo, ze projekt xyz zvysil verziu z 1.5.2 na 1.5.3. "Semver" v praxi.
    26.11.2021 14:49 billgates | skóre: 27
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    So srackami typu javascript alebo java nemame ziadne skusenosti, takze tu sa neviem vyjadrit. U nas robime v C a C++ a pouzivame dokopy nejakych 10 kniznic, spomeniem konkretne openssl, boost a potom nejake mensie ako fmt, google test na testy a podobne. Okrem nekompatibilit v API kniznic sme este za zivot projektu povysovali aj standard z C++11 cez C++14 na momentalne C++17 a coskoro budeme prechadzat na C++20. Projekt ma len jednu rolling vetvu, takze tym je to o nieco jednoduchsie. Nemame totiz u nas psychopatov, ktorych jediny zmysel zivota je menit s kazdou verziou poziciu ikoniek, takze z hladiska UI/UX sme velmi konzervativni. Zakaznici sa nemusia bat updatovat.

    Pri kazdom novom vydani verzie kniznice alebo kompilatora pripravi zodpovedny clovek nove recepty a robi sa novy build, ktory po testoch ide normalne k zakaznikom, aj ked sa v hlavnom zdrojaku vobec nic nezmenilo a povysila sa len niektora z kniznic.

    Je pravda, ze stale do toho zasahuje aj ludsky faktor, lebo ked ide o build, ktory len fixuje nejaky bug v niektorej z kniznic, tak prebehne len zakladny set testov. Ak sa robia zmeny v hlavnom kode, tak sa robi ovela viac testov, vratane field testov, ktore mozu zabrat az okolo mesiaca. O tom, aku mnozinu testov bude treba urobit rozhoduje clovek, ktory upravuje recept a ten je teda zodpovedny za to, aby si poriadne prestudoval diffy a rozhodol o rozsahu testovania.

    Takto si predstavujem, ze to funguje v kazdej firme, ktora vyraba komercny softver a robi pre neho podporu.
    26.11.2021 18:49 sid
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Kedze s vacsinou toho som robil je zjavne, ze nehovorite uplne pravdu respektive ani mozno netusite co vsetko sa musi riesit. Povysovanie boostu znamena casto prepisanie kodu a to aj v tak beznych castiach ako asio. Nehovoriac o probleme ked vas soft bezi okrem windows linux aj na nejakom arm so storocnym prekladacom ako niektore moxy. Vas prvotny nazor bol, ze sa vsetko krasne automaticky da dokopy co v svete boost neplati ani omylom. Nehovoriac napr v8 engine. Tiez udrzat rozne prekladace(windows, arm linux, linux, distrbucie pokope je pre c++ peklo. Niekto ma starsiu verziu openssl niekto novsiu. Cmake pomaha ale tiez jeho vyhladavanie kniznic ma svoje skryte nastrahy. Vzdy sme nakoniec skoncili v kombinacii static + dynamic model. Tj boost plus dalsie veci staticky. Openssl dynamicky.

    Ps:napisat ze pouzivam c++ a java je sracka znamena nejaku mentalnu disfunkciu? Gradle ci maven su proti peklu c++ prekladu neuveritelne inteligentne buildovacie tooly
    26.11.2021 22:17 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Gradle ci maven su proti peklu c++ prekladu neuveritelne inteligentne buildovacie tooly
    +1, Javu sice fakt nemusim, ale je náročné být v téhle oblasti tak špatný jako C/C++ ...
    26.11.2021 23:13 billgates | skóre: 27
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Z boostu pouzivame len dost maly subset funkcii, takze vela nas minulo. Najvacsie zasahy do kodu, ak nepocitam skocenie z C++14 na C++17, boli kvoli OpenSSL, no aj tam len kvoli implementacii featur.

    Mozno to bude zniet smiesne, ale na buildenie pouzivame Buildroot, ktory je nahooknuty na git repozitare, ktore inak udrziavame v atlassianskom Bitbuckete. Vysledok sa nasledne cez API eviduje v Jire a Confluence. Vyhodou je, ze kazdy vyvojar si moze vlastny buildroot deploynut u seba a pracovat lokalne. Recepty su teda vo forme Makefilov pre buildroot. Skusali sme v minulosti este nad to posadit TeamCity, nech mame peknu klikacku k tomu a somariny, ale usudili sme, ze je to len jedna dalsia zbytocna vrstva naviac. Vsetko vyriesi jednoducha sada skriptov v pythone + dobre udrziavane a tagovane repozitare v gite.

    Urcite by to islo urobit aj inak, ale pre nase produkty je toto idealna cesta. Robil som jeden cas vo firme, kde mali zmaknute TeamCity a robilo im to dost sialene namakane veci. Tiez islo o C++ kody. Cize ono to urcite ide, len asi treba od zaciatku mat nejaky plan a hlavne nepisat hovnokod.
    29.11.2021 09:22 sid
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    ano vsetko ide vid napr mozilla a podobne velke projekty. Lenze ide o to kolko ludi riesilo/riesi aby sa to cele dalo dokopy na rozne platformy/kniznice atd. Ked pouzivam cosi na urovni cisteho C++ (neriesim rozne architektury, OS) bez nejakych super novych funkcii a k tomu z kniznice pouzijem tak jednu stotinu a aj to bezpecnu nebudem to zobecnovat ake je to easy a ako to ide automaticky celkovo. Lebo nejde. A to este stale musim povedat, ze to co som pisal je este celkom ok pretoze kedysi pri priemyselnych pocitacoch a ich "cross compilacii" to bolo skutocne peklo. prekladac ktory snad pamatal vyhynutie dinosaurov plus sialene obchadzanie veci ktore nepodporoval alebo sice "podporoval" ale snad by bolo lepsie keby nie.
    25.11.2021 00:35 Klid
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Kdyz ctu jeden starsi clanek od J. Eischmanna, tak tam zrejme ten s tou kalkulackou neudelal nebo nechtel udelat ty diry s pravidly aby tam nemusel mit i to co uz v systemu ma a proto to taha vsechno. Nebo je clanek od J. Eishmanna zavadejici ale to by mohl rict nekdo kdo tomu rozumi;-)
    25.11.2021 23:52 Hněv
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Eischmann to je ten nácek?
    27.11.2021 09:43 hm
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    -1 za provokaci

    // tenhle komentář je soustavně mazán adminem bude však opět napsán znovu a znovu dokud se admin (ještír) nevyléčí ze svých psychických problémů anebo diskusi neuzamkne :)
    24.11.2021 01:33 Pavel Píša | skóre: 18 | blog: logic
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost

    Také jsem toho názoru, že je potřeba udržet vývoj distribucí a je nutné mít i možnost provést bezpečnostní opravu knihovny pod aplikací bez update všechno, co na ní záleží. Docker je v pořádku pro distribuovaný runner z GitLabu, ale pro desktop je to buď jen prodloužení odkládání potřebných úprav na později nebo naopak způsob, jak předběhnout standardní výbavu distribucí a netestovat na nich.

    Co se týče bezpečnosti, tak se mi také nelíbí sdílet svůj domovský adresář s nedůvěryhodnými aplikacemi jako je od počátku pandemie u nás na ČVUT nařízené sledování Temsů. Základní shlédnutí komentářů naštěstí chodí i pod Chromiem, ale i tak ta obluda mohla k mnoha mým datům, osobním, školním, firemním. Takže stejně jako autor, si myslím, že je potřeba takové aplikace a weby odstínit. Protože se zabývám spíš embedded tak jsem zvolil řešení, které podporovalo již PMDS-85 na jehož terminálech jsme se okolo roku 1988 hodně vyřádili.

    Unixové systémy pro ochranu osobních údajů používají UID a oddělené domovské adresáře. Takže mám konto se samostatným přihlášením pro kritické bankovní operace a naopak další konta pro podřízené a nebezpečné aplikace, jako je Teams a i binárně stažený Telegram (k tomu sice zdrojový kód je, ale o zaručeném third party review stahovaného blobu nevím).

    Aplikace spouštím přes tdesu, každý si jistě vybere správný ekvivalent pro svojí distribuci - gksudo, xdg-su, gksu, gnomesu, kdesu or beesu.

    Založím pro uživatele "uziv" konto "uziv_res" pro omezený přístup. Do /etc/pam.d/su přidám řádky +# Allow user uziv to substitute by user uziv_res
    +auth [success=ignore default=1] pam_succeed_if.so user = uziv_res
    +auth sufficient pam_succeed_if.so use_uid user = uziv
    a mám lepší pocit, že obludě nenabízím vše. Má to nevýhodu, že pak soubory ke sdílení musím kopírovat do složky na příslušné konto, ale složku mám s takovými právy, aby k ní hlavní uživatel mohl. Zjednodušit si to lze symbolickými linkami ze svého účtu. Ještě to chce omezeným uživatelům přiřadit skupiny, aby nemohli koukat moc jinam a ohlídat, že můj adresář omezenému vstup nedovolí.

    Ano, vím, že pokud zatím používám Xka, tak obludy mohou kdykoliv na klávesnici a udělat si screenshot jiného okénka, číst schránku atd... Ale toto oddělení nezabírá paměť duplikovanými sdílenými knihovnami a většinu blobů lze plně rozběhat proti nativním knihovnám. Doufám, že na to poslední vývojáři kvůli rádoby řešením s Flatpacky a Nixem a dalšími runtime duplikujícími technologiemi nezačnou zapomínat. (u Nixu si umím představit reálné usecase nebo jeho použití jako jednotnou distribuci)

    24.11.2021 01:40
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Aplikace spouštím přes tdesu, každý si jistě vybere správný ekvivalent pro svojí distribuci - gksudo, xdg-su, gksu, gnomesu, kdesu or beesu.
    Nebylo by pohodlnější použít Firejail?
    Ano, vím, že pokud zatím používám Xka, tak obludy mohou kdykoliv na klávesnici a udělat si screenshot jiného okénka, číst schránku atd... Ale toto oddělení nezabírá paměť duplikovanými sdílenými knihovnami a většinu blobů lze plně rozběhat proti nativním knihovnám. Doufám, že na to poslední vývojáři kvůli rádoby řešením s Flatpacky a Nixem a dalšími runtime duplikujícími technologiemi nezačnou zapomínat.
    Je to Flatpak, nikoliv Flatpack a neboj, vývojáři Flatpaků na to nezapomínají (X11 je u Flatpaku od začátku považován za legacy a insecure záležitost). ;-)
    24.11.2021 01:49 Pavel Píša | skóre: 18 | blog: logic
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Firejail, díky za připomenutí. namespace na omezení přístupu na síť pro některé aplikace jsem si v době, kdy o nich vycházely články na LWN hrál a asi jsem již i ten Firejail viděl, ale tenkrát zůstal u toho starého řešení na technologii ze sedmdesátých let. Třeba upgrade provedu, pro ostatní to stojí za zvážení a nejspíš je to lepší.
    24.11.2021 13:55 Integral | blog: devnull
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Nebo treba i AppArmor by se mohl hodit.
    24.11.2021 01:44 Pavel Píša | skóre: 18 | blog: logic
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost

    Ještě k tomu jak psát aplikace, trochu to opravdu bolí, ale i díky Suse to jde již celkem snadno https://build.opensuse.org/package/show/home:ppisa/qtmips. Ubuntu máme pod Launchpadem abychom pro jinou komerční firmu nezatěžovali Suse.

    V současné době i za pomoci našich studentů máme v devel podporu i pro Qt6, s tím, že je udržená kompatibilita i pro Qt5 ve staré verzi na Ubuntu 18.

    Myslím, že to je přístup, o kterém Nicholas Fraser hovoří.

    24.11.2021 10:24 Honz
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Pro mě třeba před lety jedna z nejdlůžežitějších věcí, proč zkoušet linux, byl balíčkovací systém. Ten ústup od přísně vedené a zabezpečené databáze k různým Flatpakům a podobným bordelům je návrat k Uindousům...
    24.11.2021 10:40 Fluttershy, yay! | skóre: 92 | blog:
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Mně se pro změnu líbil ten přístup MacOS (tehdy OS X), kde instalace aplikace spočívala v přesunu souboru aplikace do adresáře. (Na Windows mi nejvíc vyhovovaly „portable apps“.) Ale zase se musí přiznat, že Apple měl plnou kontrolu nad systémovými knihovnami/API, takže většina toho bordelu, na který si OP stěžuje, tam ani nemohla být. Projekty jako GNOME OS k tomu směřují, ale ani to se mi nelíbí…
    🇵🇸Touch grass🇺🇦 ✊ no gods, no masters
    24.11.2021 22:21 Vojta
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Správný linuxák neinstaluje ale kompiluje
    25.11.2021 00:10 Klid
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Ani to ti nepomuze pokud pouzijes uz rozbite zdroje ale to ty predem nemuzes vedet, jedine ze by sis ty zdroje od zacatku napsal sam, nekdy bys musel i kernel. Pak bys byl teprve spravny linuxak.
    26.11.2021 15:50 Smudla
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    A zpusob jaky pouziva NIXOS? Me prijde trochu prehnany ale zase ucelny. Teda mluvim o trochu jinem pristupu instalace do nestandardnich cest. Poprvy jsem neco podobneho videl ze zdejsi zpravicky u Gobo linuxu. Neni to teda o zadnych kontejnerech nebo sandboxech.
    24.11.2021 19:02 X
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Byla by na to zajimava anketa.
    29.11.2021 14:33 lyon
    Rozbalit Rozbalit vše Re: Nicholas Fraser: Flatpak není budoucnost
    Tam, kde je to pro uživatele komplikace namísto přínosu, je kontejnerizace zlo. Když jsem zjišťoval, proč mi po ugradu Ubuntu na pracovním notesu najednou Chromium startuje 10x dýl, letěl do koše nejdřív snap, a později celé Ubuntu. A když do snapu cpou už i jednoduché pythoní scripty, jako se to stalo s certbotem pro Let's Encrypt, tak je něco sakra špatně.

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.