Názory k článku RPM, DEB, anebo něco zcela jiného – pár slov k nadcházející linuxové ®evoluci

"bezpečnost je pro mě třeba u darktable až druhořadá." - na prvním místě je snad vždy funkčnost, na druhém bezpečnost a na třetím všechno ostatní, ne? K čemu by byla bezpečná aplikace, když by nefungovala?

A k cemu je fungujici aplikace, ze ktere utikaji (citliva) data? 🤣

Nejsou takové všechny aplikace od Google, Meta, Microsoftu, OpenAI, Anthropicu a některé od Applu? Evidentně to nevadí ani uživatelům a asi ani NÚKIBu.

A co je horší, že ty aplikace občas ani nefungují.

1. 8. 2025, 07:42 editováno autorem komentáře

Mně to třeba vadí dost zásadně.

Spousta programu pracuje s volnymi daty. Treba je mi uplne jedno co nejaky hypoteticky zly editor kodu vytezi na zvolenem repozitari, protoze to pak stejne jde na verejny repozitar.

Jedno to neni, protoze na verejny repozitar typicky neposilate ruzne credentials pouzivane treba pro pristup do DB. Teda s vyjimkou mamlasu, co jsou schopni na git commitnout kod i s temi credentials... :-)

Tak credentials by se neměly posílat ani do soukromého repozitáře, ne? Ještě třeba přimhouřím oko nad tím, když je ten repozitář šifrovaný a to kam se tam ukládá přístup není nějak zvlášť důležité.
Jinak se ale credentials do verzovacího systému nedávají nikdy bez ohledu na to, jestli je repozitář veřejný nebo soukromý.

Otazka byla "K čemu by byla bezpečná aplikace, když by nefungovala?" Tys to rozporoval.
Ja jsem ti nasel alespon 1 priklad, kdy lze pouzivat program ze ktereho unikaji data. Zato nefunkcni ale bezpecny program je uplne, ale uplne zbytecny. A tedy nevim o co se tu jako snazis.

@David
nesuhlasim, za mna najlepsi je balickovaci system tcz a nasledne pkg od bsd

Proč neplýtvat místem - je ho přece dost. Proč programovat efektivní pracně optimalizované aplikace - výkon mají dnešní procáky nadbytečný. -> Windows

(jinak samozřejmě deb)

1. 8. 2025, 00:31 editováno autorem komentáře

Aj tak je najlepsie AppImage

Občas provozuji nějaký ten AppImage a dle mě je to nejlepší řešení, mám dojem že i velký Linus se někde vyjádřil, že AppImage je šikovné řešení, narozdíl od Flatpaku a Snapu.

Jinak mám vše v nativních balíčcích. Na začátku popisované „podivné“ závislosti mě vskutku pobavily, to je prostě problém distribuce, I use Arch BTW. K Flatpaku a Snapu mám zkrátka nějaký vnitřní odpor, jednou jsem z důvodu lenosti zkusil nainstalovat betaverzi Siril z Flatpaku. Potom co jsem ho odinstaloval i s celou tou vopičárnou okolo, jsem si napsal PKGBUILD.

Problém AppImage je v tom, že dovoluje libovolně linkovat na knihovny v systému. To zní jako super nápad, že? To nejlepší z obou světů. Co mi stačí ze systému, to použiju, co potřebuju jiné, to zabalím k aplikaci. Bohužel to vede k tomu, že vývojář udělá AppImage, který funguje u něj (typicky na nějakém Ubuntu), ale už ne na ostatních distribucích, protože ta knihovna, u které mu to v Ubuntu fungovalo i se systémovou verzí a proto se jí rozhodl použít, je v ostatních distribucích v nekompatibilní verzi.

Samozřejmě jde udělat AppImage, který bude spolehlivě fungovat všude, ale chce to dost zkušeností a opatrnosti. AppImagů, které byly na mém systému rozbité, jsem zažil v množství "větším než obrovském". Ten formát bohužel selhává v té nejpodstatnější úloze: zajistit, aby jedna instalačka fungovala všude.

Tohle nerozporuji, ale netvrdil bych, že je to bug, je to spíše vrozený rys AppImage. Pořád je to něco za něco, relativní jednoduchost vyžaduje více práce toho, kdo AppImage vytváří.

Osobně jsem narazil na na chybějící knihovnu u AppImage Prusasliceru, kdy mi chyběl gtkwebkit, který byl linkovaný, ale nebyl součástí obrazu. Důvodem bylo, že by pak AppImage byl asi o 200 MB větší, kdyby měl táhnout všechny závislosti. To že z Flatkapu mám tyhle závislosti nainstalované je sice pěkný, ale takového místa co mi to sežere, nedejbože ve více verzích...

Nejlepší je nativní balíček to mi nikdo nerozmluví. AppImage je šikovný, Flatpak a Snap podle mě zavádí systém v systému a to se mi prostě nelíbí.

1. 8. 2025, 09:11 editováno autorem komentáře

Jenže když chcete vytvořit něco, co bude spolehlivě fungovat napříč všemi distribucemi a jejich verzemi, tak vám nezbude nic jiného než vytvořit systém v systému. Ten společný jmenoval je hrozně malý. Běžný uživatel očekává, že po instalaci mu bude aplikace fungovat, ne, že bude řešit, jak a v jaké verzi doinstalovat webkitgtk.

Další věcí je pak samotná distribuce. Autor AppImage se nechal slyšet, že pro něj je vrchol distribuce aplikací doba Windows XP, kdy si lidi stahovali instalačky z webových stránek. Existuje sice AppImageHub, ale nevím, nakolik je to dělané s ním ve spolupráci a nakolik mu natruc, každopádně to je velká znouzecnost.

Na distribuci softwaru v Linuxu jsem vždycky považoval za jednoznačně lepší to, že uživatelé instalují software z jednoho, maximálně několika prověřených zdrojů. Opravdu bych se nechtěl dožít toho, aby se normou stalo to, že máti řeknu: "Vyhledej si ve vyhledávači GIMP, klikni na jeho stránky a stáhni si instalačku". Zvlášť v dnešní době, kdy je relativně jednoduché udělat phishingovou stránku gimp-app.org, která se v Googlu při vyhledávání GIMPu umístí nad gimp.org.

Chápu, že pro někoho, kdo se chce držet distribučních balíčků a jen občas udělat výjimku a kdo ví co dělá, to je jednoduché a lákavé, ale já tedy doufám, že se to jako formát pro distribuci aplikací v Linuxu příliš neprosadí, protože to je opravdu návrat do časů Win XP. A vývojáři dnes balíčky pro distribuce dělat nechtějí a je jim jedno, jestli tam jejich aplikace je nebo ne, takže z toho, co fungovalo na občasné výjimky, by se taky mohl stát majoritní způsob distribuce aplikací na Linuxu a v podobě, v jaké to je teď, by to opravdu bylo "velký špatný".

Na distribuci softwaru v Linuxu jsem vždycky považoval za jednoznačně lepší to, že uživatelé instalují software z jednoho, maximálně několika prověřených zdrojů. Opravdu bych se nechtěl dožít toho, aby se normou stalo to, že máti řeknu: "Vyhledej si ve vyhledávači GIMP, klikni na jeho stránky a stáhni si instalačku".

Přesně tak. Jinak problém s používáním dalšími zdrojů softwaru může klidně nastat i při použití nativního balíčkovacího systému a slepému přidávání repozitářů.

Typický scénář, kdy mě kontaktuje uživatel, že mu špatně fungují aktualizace v "tom" Linuxu a vypisuje to "nějaký" errory.
Po vzdáleném připojení do systému pak vidím jen nějaké neřešitelné závislosti nebo mrtvé vzdálené repozitáře.
- A jak se ti to tam dostalo?
- Ale potřeboval jsem XYZ, a tohle byl druhý blogpost, co mi našel Google. Tak jsem jen kopíroval řádky a spouštěl :)

Nebo je to může být i takové to klasické.
curl -sL https://blablbabla.github.io/thegreatapp/install.sh | sudo sh

Takže v porovnání s tím mi přijdou důveryhodné zdroje a Flatpak s těmi izolačními mechanismy jako velký posun.

A co izolacia? Ten GIMP nepustim na siet a na zapis dam mu iba jeden adresar napr '~/Picture/GIMP' a balickovac mu este prideli nejaky '~/.local/sha­re/gimp' pre zdielanie konfiguracie.
Potom sa radikalne zvacsi mnozstvo miest odkial mozem balik instalovat. System podobny ako ma Android. Izolacia aplikacii, nie ze kazda aplikaci vidi vsetko a moze si robit co chce. Viem ze sa to da nastavit ale skuste odizoval Chrome, to sa ani neda.

Podporovať 100 - 1 disturbácií je fuc7 ťažko riešiteľný problém.

- 1 ako Clear Linux

Pro uživatele rolling distribucí s bohatšími repozitáři Flatpak takový benefit nemá, možná mimo komerčních aplikací (typově Spotify, různé ElectronJS klienti atp.).
Nicméně pokud jedete na klasicky verzovaných distribucích, co mají třeba dvou, tříletý cyklus plus nějakou extended podporu, tak je to podle mě rozumný způsob jak mít v systému aktuální verze mnoha aplikací, které navíc často vydává a testuje přímo jejich autor.
AppImage je za mě zajímavý možná pro portable aplikace, co chcete spouštět bez dalších runtime, jinak ne. Nemá to, logicky, žádnou přímou integraci do systému, aktualizace (bez dalších služeb), žádné sdílení atp.

Jinak mi přijde, že to někteří lidé vnímají strašně fundamentalisticky. Takhle to má být, to je ta jediná správná "Linuxová" cesta. Naopak s troufám tvrdit, že většina uživatelů vnímá spíš benefit toho, že má dostupné aktuální verze aplikací, které může používat.
U pár lidí okolo mě to třeba byl jeden z důležitých aspektů vedoucích k tomu, že s Linuxem můžou pracovat většinu času jako s primárním desktopovým prostředím.

Pro vývojáře desktop aplikací, speciálně pokud jsou to jednotlivci nebo malé týmy, co dělají multiplatformní desktop aplikace, je tohle konečně způsob, jak přímo do pipeline dát jedno oficiální, univerzálně použitelné sestavení pro Linux, které můžou testovat, řešit vůči němu bugy bez toho, aby odhadovali, co s tím provede další balíčkář, vůči kterým knihovnám to sestaví atd.
Ano má to i své nevýhody (např. více zabraného místa, pro někoho to může být i bezpečnost v případě staších knihoven, ale to je obecný aspekt všech "kontejnerových" řešení). Nicméně i s nimi to může pro spousty lidí pořád být velmi rozumný způsob, jak přidávat aplikace, co nejsou v distribučních repozitářích, pokud zkombinují nativní balíčkovací systém a právě Flatpak.

Asi tak. Tyhle sandboxované balíky především strašně moc zjednodušily provozování LTS dister na desktopu, kdy si člověk jádro systému a důležité věci v userspacu může držet na stabilních verzích (takže neriskuje, že si updatem rozdrbe systém, případně v updatu bude nějaká výkonová regrese), ale desktop appky má aktuální a nehnijou mu tam na prastarých verzích.

Pamatuju si na doby, kdy jsem jel Debian 5 na ThinkPadu T30 a třeba dostat tam relativně aktuální LibreOffice byl strašnej porod. Dneska s Flatpakem nemám problém mít na notebooku LTS distro s aktuálníma appkama a vlastně vůbec nic řešit nemusím.

<trolling>
A proto je pořád nejlepší si stáhnout wokenní verzi a spustit ve Winu :-D Třeba u TNT simulátoru jsem to tak udělal, protože poslední Linuxová verze vyšla asi před 15 lety.
</trolling>

Jo a dopadne to jako Steam, pro každou gamesu wine (protonovej) kontejner, a po nějaké době to člověk celé radši stejně strčí na btrfs s deduplikací.

Este ma napadlo ze aj Linux ma Homebrew ako Apple. Pouzivat o to niekto a ake mate skusenosti?

Nefunguje to na AArch64, takže -1÷0

2. 8. 2025, 14:28 editováno autorem komentáře

- Základní důvod pro sdílení závislostí není šetření disku, ale šetřeni RAMky (sdílená knihovna může být v RAMce jen jednou pro víc různých aplikací). A velikost RAM sice taky narůstá, ale ne tak dramaticky jako SSD, plus velký rozmach neupgradovatelných pamětí v noteboocích atp. Takže toto je pořád věc, co má cenu optimalizovat.
- Megabalíčky typu flatpak často mají problém s včasnými bezpečnostními aktualizacemi závislostí. Plus to duplikuje práci, protože to musí řešit každý balíček sám za sebe.
- Přijde mi divné vypichovat "atomické a neměnné" jako protipól k balíčkům se závislostmi. To jsou dvě celkem ortogonální osy. Jenda je o tom, jak moc chceme dovolit modifikace systému mimo balíčkovací systém, druhá o tom, jakou máme granularitu balíčků (málo velkých vs hodně malých). Že jde relativně atomický systém s normálními závislostmi, viz třeba NiXOS (byť tam to není tak striktně enforcované, ale klidně by mohlo).

Plus to duplikuje práci, protože to musí řešit každý balíček sám za sebe.

To taky není úplně pravda. Flatpaky mají sdílené runtimy. Navíc v rámci Flathubu existují dál ještě sdílené moduly. U jejich aktualizace se sice musí aplikace rebuildovat, ale je to něco, co se dá automatizovat. Ve výsledku to množství závislostí, o které se musí správce aplikace starat, může být relativně malé. Na Flathubu třeba spravuju Datovku, která ke svému běhu potřebuje desítky závislostí včetně hromady Qt modulů, já se ale musím starat jen o tři z nich.

Sdílené knihovny jsou hezká teorie, ale v praxi se to moc neděje. https://drewdevault.com/dynlib.html

Výjimka jsou velké molochy typu Qt a GTK, ale ty (a některé další knihovny) jsou díky runtime sdílené i u Flatpaku.

Základní důvod pro sdílení závislostí není šetření disku, ale šetřeni RAMky (sdílená knihovna může být v RAMce jen jednou pro víc různých aplikací) … Megabalíčky typu flatpak často mají problém s včasnými bezpečnostními aktualizacemi závislostí. Plus to duplikuje práci, protože to musí řešit každý balíček sám za sebe.

A to je podle mne zcela zásadní důvod, proč je celá ta "moderní" koncepce úplně špatně. Když je podstatná bezpečnostní chyba v nějaké knihovně, kterou "používá (skoro) všechno", třeba OpenSSL, tak když vyjde distribuční balíček s opravou, vím, že to mám nainstalované (občas musím ještě restartovat pár běžících aplikací, přičemž mám nástroje, které mi řeknou, které to jsou). Kdybych používal ten "moderní" systém, budu muset hlídat, který z té hromady megabalíků už opravu má a který ještě ne. V podstatě je to jako návrat ke staticky linkovaným knihovnám, jen ještě s dalšími nevýhodami navíc.

Z nějakého důvodu si ta moderní koncepce myslí, že updaty v aplikacích jsou rychlejší, než v systému.
Na jedné straně to je pravda, zejména co se týče závislostí na ffmpeg & spol. Jenže pokud jde o bezpečnostní záplaty, tak majoritní distribuce OS vyhrávají na celé čáře!
(Ostatně, všimněte si, jak je - i tady - populární názor: hlavní je funkčnost, bezpečnost mi je vcelku ukradená.)

Z nějakého důvodu si ta moderní koncepce myslí, že updaty v aplikacích jsou rychlejší, než v systému.

Problém je v tom, že u některých to tak opravdu bude. U jiných to bude pomalejší. A pak se najdou i takové, které to neopraví nikdy - nebo přinejmenším ne dokud nevydají nový pack s novou verzí té své aplikace.

U bezpečnostních updatů bývá - dle mých zkušeností - rychlejší systém; v případě úpravy funkčnosti zase aplikace.

"Bezpečnost je mi ukradená" je celkem legitimní zkratka správně formulovaného "u velké části vulnerabilit v mém nasazení neexistuje realistický scénář, jak by jí mohl útočník zneužít k získání přístupu, který už nemá" (jasně, věci jako web browser popř. mail klient bude výjímkou, ale třeba riziko děravé komponenty Steamu, která se jinam než na Steam nepřipojuje je irelevantní, když Steam může nainstalovat breberku v rámci regulérního updatu)

Stejně tak mě třeba neuráží obráběcí linka řízená nějakým Win95...

Svět, kde je jedna knihovna a všichni na ni dynamicky linkují, je sice nádherný, ale z pohledu praxe utopistický. Svět se prostě vydal jiným směrem. Alternativou k flatpakům a snapům, které se tomu snaží dát alespoň nějakou štábní kulturu a přinášejí mechanismy, které bezpečnostní problémy mitigují, jsou instalačky se staticky slinkovanými bundly a random AppImage obrazy.
Aby si byl člověk jistý, že používá jen jednu opravenou knihovnu, musel by používat jen software z pomalu se tenčících (vůči celkovému objemu software) repozitářů a ani u nich by si nemohl být 100% jistý, protože pod tím povrchem pravidel a slibů se nachází realita plná kompromisů. Vzpomínám si, jak jsme dávali dohromady krypto v RHELu, kolik překvapení to přineslo. :)

Tak mimo to, že u flatpaku prostě updatuju runtime a update OpenSSL dostanou všechny balíky které ho používají, ty opravdu kontroluješ u všeho v systému jestli je to s knihovnama slinkované staticky, nebo dynamicky? Protože ani v tradičním balíku tu jistotu nemáš.

ty opravdu kontroluješ u všeho v systému jestli je to s knihovnama slinkované staticky, nebo dynamicky? Protože ani v tradičním balíku tu jistotu nemáš.

Nepoužívání staticky linkovaných knihoven je v pravidlech distribuce už dlouhé roky.

Tak to sa budes dost cudovat az zistis, co vsetko si take browsery nesu so sebou.

To je pěkná teorie. Praxe je taková, že se staticky linkované knihovny používají ve všech distribucích. I ve Fedoře jsme přiznali realitu a správci balíčků se aspoň žádají, ať to přiznají ve spec filu. Kolik z nich opravdu udělá? Nikdo neví. V RHELu vzhledem k tomu, že musíme podporovat i více než 10 let stará vydání, se v tomto ohledu musí dělat taky nepěkné kompromisy.

David Jezek: "instalují i hromady zcela obskurních balíčků"
Tiez David Jezek: "Diskový prostor zabraný Flatpaky prostě není v roce 2025 zásadním argumentem.

Ježkova práce je psát a vyplodit článek. Ne fušovat do logiky ;-)

Otazka vhodnosti pouziti, jako vzdy. Protoze kazda vec ma sve vyhody i nevyhody, a volime podle toho, k cemu a jak ji chceme pouzivat.

Na serverech chci minimalisticky OS ktery neumi "rozbit" klasickou aplikaci a jeji knihovny - volim balickovaci system OS + kontejnerizaci pro beh aplikace, pokud chci i vysokou dostupnost, tak to vse na virtualizaci typu proxmox/vmware s disky na SAN.

Mam novou "moderni" aplikaci, pak patrne muzu pouzit privatni/verejny cloud a kubernetes. Cokoliv pod tim kubernetes je pro mne infrastruktura, kterou chci jako sluzbu od dodavatele (a v public cloudu muzu mit i ty kubernetes jako sluzbu)

Mam workstation, pracuju s grafikou, hraju hry, grabuju videa, chci audio v hi-res a posledni verze user aplikaci - pak by pro mne asi flatpak mohl byt zajimavou moznosti, ale s ohledem na bezpecnost bych na tom PC nemel mit ucetnictvi. U flatpak na rozdil od kontejnerizace totiz obvykle nemohu "hodit" bezpecnost na dodavatele aplikace. Leda ze by se ten flatpak provozoval a sestavoval v ramci distribuce, ktere mam duvod verit.

Ale vždyť Flatpak uvnitř právě kontejnery používá. A umožňuje sandboxing.

Jenze oddelenim aplikaci do flatpack sandboxu komplikuje zivot, pokud maji spolupracovat.
Preba pouzivam keepass a keepass plugin v browseru. Na pocitaci kde zkousim flatpakove verze me to spolu nechodi. Zkusil jsem navod, neuspel, ale nevenoval jsem tomu vic nez 1/2h.

Ano, tym, ze aplikacie su v sandboxe tak nemaju pristup k nahodne roztrusenym socketom alebo suborom na systeme.

Dolezite je, ze sa postupne prichadza na jednotlive pripady a problem sa riesi. V niektorych pripadoch je to relativne jednoduche - ako napr. Kerberos pre pocitace v domene alebo spominany Native Messaging, V inych pripadoch je o dost tazsie - napr. taky PKCS#11 (smart cards), pretoze konfiguracia pozostava z cesty k lib.so kniznici, ktora moze mat (a mava) zavislosti na dalsich knizniciach na hostitelskom systeme.

Já teda moc nechápu tuhle hoňbu za poslední verzí. V čem tě omezuje půl roku stará verze co jávim darktable nebo gimpu? Nějaký ulítlý filtry používaj akorát hračičkové, normální člověk akorát ořízne, poladí kontrast, pro efekt trochu přisaturuje barvy a hotovo...
Podle mě je to jen mentální nastavení. Není problém psát v open officu z roku 2015, upravovat fotky ve dva roky starym gimpu, sám používám na fotky picasu z roku asi 2011, nic lepšího podle mě ještě nikdo nevymyslel (neinvazivní úpravy). Ještě pár týdnů zpátky jsem používal inkscape 0.něco...

Ale nešť, ať si každej pouští co libo. Mě osobně na těch flatpakách vadí dvě věci, že na starších strojích s pomalym ssd se to pouští pomalu a taky že to někdy dubluje aplikaci nainstalovanou z balíčků a né vždy je snadné rozlišit která z nich se právě spouští. Typicky firefox, gimp...

V čem tě omezuje půl roku stará verze co jávim darktable nebo gimpu?

Tak zrovna u GIMPu je mezi aktuální a půl roku starou verzí rozdíl asi 10 let vývoje. ;-)

Jinak obecně: uživatelé to prostě chtějí, chtějí to i vývojáři, protože když vydají nějaké nové funkce, dělají kolem toho nějaké promo, tak chtějí, aby k tomu uživatelé měli přístup hned a ne za půl roku nebo rok, až vyjde nová distribuce. Potřeby a preference uživatelů se mění a buď se jim Linux bude přizpůsobovat, nebo ho bude používat jen pár konzervativních lidí, kterým vyhovuje, jak to fungovalo před 20 lety.

Chcu to len vyvojari aby v jeden moment mohli povedat ze cez kupovania softu a update to nejde a treba predplatne...

1. 8. 2025, 10:18 editováno autorem komentáře

To možná jo, ale v čem tě to omezuje? To jako před půl rokem jsi fotky vyvolával jinak, nebo to nešlo?

Při běžném používání člověk na chyby téměř nenarazí, a kromě nějakých frikulínských filtrů a cojávim AI podpory, bez který ses posledních 10 let obešel tam není nic nového.

Ovládá se to stejně krpatě a jestli má průhledný meníčka nebo starej wokenní interfejs je úplně jedno.

Ano, ono to třeba nešlo. Protože nové foťáky a formáty RAWů.

Vážně? Jako fakt máte půl roku tak novej foťák, že raw z něho nešel před tim půl rokem nijak vyvolat a s poslední verzí nejednou jde? Podle mě kecy v klecy...

Občas jsou prostě momenty, kdy čekám vydání nové verze, která bude obsahovat to skvělou funkci, kterou strašně potřebuji...

Teď jsem na to narazil s FreeCAD-em. Na jednom stroji mám/měl jsem verzi 1.0.0 a na druhém 1.0.1. Otevřel jsem projekt ve starší verzi a ejhle, ono se to rozbilo... A ukázalo se, že verze 1.0.1 umí měřit délku oblouku, zatímco 1.0.0 ještě ne...

Zrovna u Firefoxu se dost casto bavime o zaplatovani bezpecnostnich der. Provozovat deravy prohlizec neni uplne stastny napad, zeano ;-)

Takže posledních třeba 10 let byly všechny prohlížeče děravý a nebezpečný ? A s nástupem snapu je to najednou sluníčkový?

Záplatovat se musí, ale to se děje přece i v balíčkovaných verzích, takže tohle tvrzení postrádá reálný základ.

Prohlížeče v distribucích jsou záplatované, protože distribuce úzce sledují upstream i za cenu toho, že se porušují základní pravidla: zákaz bundlování, zákaz rebasování v rámci jednoho vydání... A je to už opravdu na hraně. Firefox vychází každý měsíc, téměř vždy jsou tam opravy kritických bezpečnostních chyb, takže na vydání opravy máme pět pracovních dní a těch podporovaných streamů máme jen v RHELu kolem 20. Nemůžeme se dočkat dne, kdy budeme mít Firefox pro RHEL jen ve Flatpaku a budeme dělat jeden build místo 20.

Prohlížeče opravdu nefungují tak, ze vyjde Debian Stable a správci tam nechají hnít 3 roky stejnou verzi Firefoxu. Na backportování oprav nemá nikdo prostředky a kdyby to nechali 3 roky neopravené, byl by to pořádný bezpečnostní průšvih.

Přesně tak, ale to vysvětlujte výše danymu.

Za mě klidně budu používat distribuční verzi, pokud bude místo toho jenom ta ve flatpaku, je mi to celkem jedno, ale pokud bude start té flatpakové verze trvat 10 vteřin, zatímco distribuční naskočí za vteřinu, ta ve flatpaku se bude pakovat.

Zrovna u RawTherapee může být, že nějaký RAW začne podporovat rok po existenci foťáku. A pokud má člověk na distribuci čtvrt roku starou verzi, protože ta existovala při sestavování distribuce a nová major verze RawTherapee vznikla dva týdny po té, tak má smůlu a ještě minimálně půl roku na distru nová verze nebude, protože se často řeší jen bezpečnostní chyby, které jsou mi zrovna zde lhostejné.

A přesto jsem v openSUSE používal (vlastní) balíček darktable s podporou mého foťáku ještě dlouho předtím, než ho podporoval upstream release darktable i libraw. Právě díky tomu zastaralému systému RPM balíčků, kde mi stačilo udělat si linky ve vlastním OBS projektu, přidat pár patchů a přidat příslušný repozitář.

To umí minimum lidí. A navíc jste pak musel alespoň chvíli ten svůj fork udržovat. A mimochodem to samé jde udělat i s Flatpakem.

Používám flatpak když aplikaci nemůžu najít ve správci balíčků distribuce nebo když chci nějakou aplikaci jen otestovat nebo když je to moloch s mnoha závislostmi (např. KDE aplikace), jinak mi úplně stačí sudo apt install :-)
Edit: A ještě, kdybych potřebovala nejaktuálnější verzi aplikce, ale to se mi ještě nestalo :-D

1. 8. 2025, 10:10 editováno autorem komentáře

Osobně jsem našel ještě use-case, když člověk potřebuje přepínat mezi nativním Wayland během a během pod XWaylandem, kdy se u Flatpaků tohle dá na jedno kliknutí přehodit ve Flatsealu.

Mna hlavne prekvapuje ze autor ktory tu bezne pise o tom ako pouziva stare stroje preferuje flatpaky/snapy atd.

Snap má daleko větší overhead, protože připojuje komprimované image a pak je stackuje. Takže se ty aplikace skutečně spouští citelně pomaleji.
U Flatpaku to zdaleka tak hrozné není, ano resolvují se symlinky, je tam nějaká izolace, ale na většině strojů to reaguje v podstatě stejně jako nativní aplikace. A ano samozřejmě se případně natahuje další runtime, takže na strojích, co mají omezené množství RAM, tohle může být znát.
Nicméně i např. na mém nejstarším stroji, což je teď nějaká mobilní dvoujárdová i3 z r. 2013 ve zrecyklovaném ntb, je to subjektivně pořád úplně v pohodě v porovnání s aplikacemi z nativních balíčků.
Ale samozřejmě nevím, možná má autor ještě něco staršího :)

Ono se to nějak vylučuje? Nebo co je to za nesmyslnou úvahu? Jakože když taky používám staré stroje, nesmím použvat jádro vyšší než 5, v žádném případě AI a optimálně povinně CRT monitor?

Každému soudruhu co jeho jest. Z těch vyjmenovaných "výhod" mě nezaujala ani jedna a nevýhod je spousty. Čímž bych to zase pro sebe uzavřel.

Mozno trochu off topic ale pri citani clanku som si uvedomil ze som K3b nemal spusteny min. poslednych 6 rokov. Zjavne su teda diskove media definitivne mrtve. Aj ked teda planujem pouzitie mdiskov na dlhodobe zalohy klenotov typu rodinne fotky a videa.

1. 8. 2025, 11:34 editováno autorem komentáře

Základní problém vidím ve stylu vývoje - perou se tu dvě skupiny - tvůrci „knihoven“ a tvůrci „aplikací“. V uvozovkách je to proto, že teď nemyslím jen .so a spustitelnou binárku.

Aplikace, ty ať se vyvíjí, mění přidávají funkcionalitu, přeskládávají UI a cokoliv... A knihovny... Ty se musí vyvíjet taky. Ale s podstatně větším ohledem na ty aplikace. S ohledem na zachování zpětné kompatibility a dlouhodobou podporu. Pokud se ve své aplikaci potřebuji vázat na konkrétní verzi knihovny (a nemůžu jít k novější), tak je to špatně (teď nemyslím přechod typu kernel 2.2 -> 2.4 -> 2.6, GTK2->GTK3 atd, tam je to jasně dané).

Druhou stránkou věci je to, že aplikace dosáhly takové komplexity, že je strašně těžké udržet je funkční. Vývojáři pak nemají na to zkoušet ještě různé verze knihoven.

To vše nastoluje pár otázek - chceme takové aplikace, které vlastně fungují jen náhodou a jejich funkcionalita není jednoduše replikovatelná? Neměli bychom se zabývat i udržitelností vývoje - nejen s ohledem na svoji knihovnu, ale s ohledem na ty, kteří ji budou používat ve svých aplikacích? Flatpak, Snap i Appimage může mít své opodstatnění, ale takhle mi to přijde jen jako vytloukání klínu klínem, rovnák na vohejbák a ... Prostě jen zavírání očí nad skutečným problémem.

Tady někdo rád svítí petrolejkou místo aby si vzal moderní baterku která stojí hned vedle :)

Akorat ta baterka ma kazdy tyden jine ovladani, jine napajeni a jine vlastnosti svetla.
Typicky frikulinsti junior develove tohle nechapou stabilizaci u velkych projektu. I vyvojar by mel vybirat knihovnu podle stability rozhrani.
Zazil jsem ale ultrakonzervativni pristup u solarisu nebo prvnich debianu kde to bylo ke skode projektu. Baliky i 10-15 let stare :-P

1. 8. 2025, 12:56 editováno autorem komentáře

A proto se u mnoha projektů po letech rolling-release vývoje začínají zase objevovat LTS verze. Že...

Od baterky čekám, že bude svítit vždy, když potřebuji. A ne, ze pokaždé budu muset nainstalovat zcela jiné baterky a k nim hledat kompatibilní žárovku. V takovém případě je ta petrolejka stabilně funkční řešení. Kupodivu. (A taky, 95% lidí si neumí představit situaci, kdy je petrolejka prostě lepší řešení, než cokoliv elektrického. Přesto takové situace existují.)

Ale o tomto není příspěvek, na který reaguješ. Jsi ve své reakci zcela mimo mísu. Není to o tom co chci používat (baterka versus petrolejka), ale o tom, že vývojáři by měli myslet nejen na fíčury, ale i na stabilitu. Je super, že libKnihovna-2.3.4.so umí SqělouFíčuru, ale k čemu mi je, pokud zásadně rozbije kompatibilitu s verzí 2.3.3 a ve verzi 2.3.6 o půl roku později je tato fíčura zase odstraněna. Pak raději jako vývojář zůstanu na řadě 1.13, která je sice stará, ale mám jistotu, že s ní moje aplikace poběží i když někdo náhodou vydá opravnou verzi.

U baterky, co vam bude rok stat na polici se take muze stat, ze vam neposviti, kdyz ji zrovna budete fakt potrebovat... :D

Druhou stránkou věci je to, že aplikace dosáhly takové komplexity, že je strašně těžké udržet je funkční. Vývojáři pak nemají na to zkoušet ještě různé verze knihoven.

Jestli je vůbec o něco takového zájem. Hádám, že předplatné softwaru nese víc, než jednorázový prodej.

Navíc bohužel linuxový desktop ani Mac nemají stabilní ABI a udělat program, co funguje několik desítek let beze změny prakticky nejde :-/

Jak zmínil kolega s CADem. Ve chvíli, kdy člověk dané softwary využívá k práci (peněžní, či dobrovolné), jsou nové verze s opravou chyb a nových funkcí nutností. Windows kolegové nemají problém, já s Linuxem vždycky měl. Code mám v .deb oficiálně, na vše ostatní čék pokoutně lovil ppa a to jsem na distru, co ppa má, co mají říkat ostatní a i tam jsem závislý na tom, zda nějaký PPAista ještě chce podporovat daný SW a danou verzi distribuce. Flatpak je v tomhle vysvobození, se všemi neduhy co má, řeší problém, co předtím řešen nebyl.

Ono jaksi záleží na tom, jaké "softwary". 95 % toho, co na počítači dělám je práce a kdybych měl dva tři roky staré verze, ani bych si toho nevšiml. Tyhle řeči o "nutnosti" mě nikdy nepřestanou fascinovat. Jeden z hlavních problémů téhle doby fakt je neschopnost rozlišovat mezi chtěným a nutným. A dojem, že celý svět to má stejně jako já. Přičemž mi přijde, že z nějakého důvodu je těchhle lunatiků zrovna v IT nadprůměrně hodně.

Vtipné je, že kdyby software neměl vámi požadované funkce před těmi 2-3 lety, tak ho nepoužíváte a taktéž neřešíte jeho nové verze.

Hezký článek, díky za něj!

Doba holt pokročila a vývoj softwaru (i různých protokolů/API) zrychlil natolik, že na to již klasické repozitáře a jejich pomalejší styl vydávání aktualizací nestačí.

Větší problém pak spatřuji v samotných linuxových distribucích či minimálně v některých z nich. Nechvalným příkladem budiž třeba Ubuntu se svým "universe" repozitářem, do nějž se balíčky pouze "syncují" z Debianu v době vydání distribuce a následně, po dobu životnosti dané verze distribuce, již často bývají zcela bez aktualizací, a to včetně těch bezpečnostních. Důvodem je jednak fakt, že 99% těchto balíků nemá v Ubuntu žádného maintainera, krom toho je však samotný proces aktualizace balíků v Ubuntu většinou poměrně zdlouhavý, byrokratický a schvalovány bývají pouze menší patche. Výsledkem jsou neopravené high severity CVE u mnoha balíků v LTS verzích Ubuntu a arogantní reakce typu "it's in universe, let it rot" ze strany některých zaměstnanců Canonicalu. Tímto nechci Ubuntu ani Canonical hanit, velkou spoustu (jiných) věci dělají dobře.

Osobně je mi myšlenka oddělených systémových a aplikačních aktualizací (resp. zdrojů softwaru) rovněž poměrně blízká a dle mého názoru je to směr, jímž se budou muset mainstreamové distribuce dříve či později vydat, aby se desktopový Linux stal skutečně "blbuvzdorným" a použitelným i pro běžné uživatele. Jen je třeba najít tu správnou cestu, kterou se k tomuto cíli vydat, aniž by to poškodilo nynější uživatele, včetně těch více konzervativních.

Proč by na to nestačily? Stačí na to naprosto v pohodě. A "musí" člověk reálně jenom umřít. S blbuvzdorností to nijak nesouvisí; to už by jak Windows, tak macOS dávno neexistovaly.

Toto je moje dnešní zkušenost. 146 tisíc souborů z GitHubu, návod nefunguje a rozjet to nejde. Takže pouze nativní balíčky daného OS a kontejnery jen nspawn nebo jaily. Docker není potřeba.

Ja mám Aarch64, čo je to ten flatpak?

(Pán Ježek, nečakám odpoveď. Len podpora Aarch pre flatpak je slabá.)

"Len podpora Aarch pre flatpak je slabá"

?

Přiznám se, že úplně nevím, co myslíš. Flatpak jako technologie tě přeci v tomhle nijak nelimituje, to záleží na vydavateli konkrétních balíčků.

Na Flathubu (coby asi nejpoužívanějším veřejném repozitáři) mi to teď hlásí..
x86_64 - 3073 balíčků
aarch64 - 2573 balíčků
To se mi nezdá tak hrozné, i vzhledem k tomu jak minoritní architektura pro Linux desktop to teď reálně je.

Dá se to zadat jako kritérium i třeba ve webovém hledání.
https://flathub.org/apps/search

Vám sa to nezdá hrozné, ale tých chýbajúcich 500 projektov je dosť. Lebo sú to napríklad projekty, ktoré zrovna by som mal rád, ale nie je release na aarch64 flatpakom vyžadovaný. Na to narážam u Flatpaku, častejšie, než by som chcel.

Napríklad aj Linux je minoritný systém, táto argumentácia by sa dala aplikovať na všetko.

2. 8. 2025, 08:54 editováno autorem komentáře

A v com je slaba?

Ze neexistuje Chrome pre aarch64? Rovnaky problem je aj v deb.

V deb mám chromium. Keď mám chromium s widewine, nepotrebujem chrome.

Omlouvam se velice, ale toto mi prijde jako tak kolosalni hloupost, ze me to vyprovokovalo.

Kdyz si clovek vybira distribuci, musi aspon trochu chapat jaky ma release cyklus, jakou ma filozofii, na koho a na jaky ucel je zamerena. Prijde mi jako uplny nesmysl si vybrat jako distribuci Mageiu a pak na ni naplacat miliony flatpaku.

Jak je mozne soucasne argumentovat, ze extra misto na disku zabrane flatpaky nevadi, ale extra misto na disku zabrane dotazenymi (doporucenymi?) zavislostmi vadi?

Dalsi podobna nelogicnost, nejdriv dostaneme argument, ze vyhodou flatpacku je vyssi bezpecnost, nasledne nam autor napise, ze mu je bezpecnost vlastne ukradena. Mimochodem, pokud si pridam jako zdroj flatpaku nejakou treti stranu, tak pravdepodobnost, ze instalovana aplikace muze obsahovat treba keylogger je urcite vyssi a nejsem si jist, ze argument, ze to nema sanci ohrozit system je z hlediska bezpecnosti uzivatele relevantni.

Firefox ve flatpaku je neco jako Firefox ve snapu a co ja si pamatuju, tak z toho velke mnozstvi uzivatelu Ubuntu bylo velmi nestastnych. Z toho lze tak nejak usoudit, ze autoruv dojem, ze "to neni problem" je dost minoritni nazor. Mimochodem Mozilla udrzuje vlastni repozitare s aktualni verzi Firefoxu, takze mozno i tak...

Konstruktivni poznamka na konec, pred mnoha lety SUSE spustilo OBS https://openbuildservice.org. Naucte se balickovaci system svoji distribuce. Nebudete treba instalovat doporucene zavislosti, kdyz vam vadi, a na teto sluzbe si nechate sestavit balik se softwarem ve verzi a s patchi, ktere chcete, a muzete to sdilet mezi ruznymi stroji.

Ja vlastne uz celkem dlouho volam po tom, aby se system delil na knihovny a aplikace. Knihovny at maji stabilni API i ABI po celou dobu existence daneho release distribuce. Aplikace at si delaji updaty, jake chteji.

Takovy Firefox rezim. Tezko rict, jak toho dosahl, ale je to v podstate jedina aplikace, ktera zvladala i na uz vydanem Ubuntu pridavat novou funkcionalitu (do te doby nez ho zprznili snapem).

Kdyby v tomhle rezimu fungoval treba GIMP a Darktable, tak je mozne mit nejnovejsi verze bez kontejnerizace.

Firefox je snap balíček na Ubuntu.

Rozdelenie skor systemove sluzby a aplikacie. Taky wayland kompozitor alebo pipewire server prinesie system, klientske kniznice si uz ponesie aplikacia, v pripade casto pouzivanych kniznic zdielany runtime aplikacii, ako to robi flatpak.

Na to, aby system priniesol kniznice, ako je to dnes, je treba urobit snapshot stavu v urcitom case (slovnikom distribucii vyhlasit za stabilne) a potom tieto verzie podporovat urcity cas - 3 - 5 - 10 rokov. Popritom vsetky aplikacie v distribucii musia skonvergovat na tieto verzie, ktore uz v case vyhlasenia za stabilne maju nejaky vek, kludne aj 2 roky. Takze v priebehu zivotneho cyklu takejto distribucie nutite aplikacie, aby pouzivali kniznice 5-7-12 rokov stare. Ked sa k tomu pripoja pouzivatelia, ktori potom hlasia na upstream bugy opravene roky naspat, tak je jasne, ze upstream nebude mat pozitivny pristup k balickovanym verziam.

GIMP ani Darktable v spomninanom rezime fungovat nebudu, pretoze je to rezim narocny na pracnost a browsery su v podstate jedine balicky, ktore maju vynimky z mnohych balickovacich pravidiel, napriklad si prinasaju vlastne verzie kniznic, aj ked system pouziva ine. Keby podobne vynimky dostali aj ostatne balicky, tak uz by sa to prilis od flatpakov nelisilo.

> SSD stojí 500 Kč, 512GB stojí 750 Kč, 1TB stojí 1300 Kč a 2TB stojí 2500Kč to není validní argument.

Senzace a teď si popovídáme o UFS v telefonech. Koupím si do svého mobilu 2T místo mých 128G eMMC? Ne.

> Stejně tak nepovažuji za argument delší dobu spouštění takových aplikací.

Jasně, taky nepovažuju za hodnotné hrát si s Linuxem když si můžu koupit Mac... bože, tenhle článek je ale blbost...

Jestli si chtěl strhnout flamewar, dobrá práce! Škoda, že se do článku nevtěsnala nějaká hodnota.

Tak zrovna do (linuxového) telefonu se dle mého názoru nic jiného, než Flatpak, Snap či něco podobného nehodí.

Pane Ježku, nemá smysl to dlouze rozmazávat, anglicky neumíte. Když už chcete uvest kapitolu citátem ověřte si to, takhle to sráží jinak zajímavý članek. "Let's flame war begins" je neanglický nesmysl, zřejmě se mělo jednat o parafrázi římského "Let the games begin". V takovém případě zaměníte "games" za "flame war"...nikdy jinak. Zdar.

Právě stále prodávám 6x4TB NAS HDD a mám 4TB v NVMe + SSD a uvažuji o koupi NAS s 8x4TB NVMe, takže místo? Neznám :-)

Linuxovými desktopy, které spravuji, jsou obvykle starší stroje ve službách nenáročných uživatelů (dědečkové a babičky či školáci a jejich rodičové). Typický use case je starší notebook s několika základními aplikacemi k prohlížení internetu, přehrávání multimédií a nějaké komunikaci (e-mail, Signal...). Obvykle jsou na stroji dva aktivní uživatelské profily (dědeček+babička, sourozenci, rodiče+děti).
Větší administrátorské zásahy se konají několikrát do roka, u kafe, menší po telefonu nebo SSH.
Tyhle stroje uživatel ani administrátor nechce moc vylepšovat - a balíčkovací systém se elegantně postará o updaty, bezpečnostní záplaty systému i aplikací, případně mírný upgrade. Když se něco pokazí - zajdu na kafe.

Na několika strojích je i pár programů v kontejnerech (většinou snap, nějaký flatpack a jedna aplikace jako appimage). Zatímco o balíčcích v podstatě nevím, ty kontejnerové se co chvíli s něčím připomenou, nejčastěji se snahou o aktualizaci pod účtem, který na to nemá práva. (Ta appimageová sama detekuje update, stáhne si image pod uživatelský profil - a zhavaruje při pokusu o update. Po příštím spuštění nebo další den se to opakuje, a v adresáři se staženými soubory se dostává k e stovce stejných souborů... Ale uznávám, že tady je to především chyba pachatele aplikace.)
Snap, FlatPack, AppImage - to má smysl nejspíš zejména na jednouživatelských strojích, a spíš na těch, které si uživatel spravuje sám. Dokážu si to představi i ve firemním, centralisované řízeném prostředí, ale jakmile se na počítači střídá několik uživatelů, bude se to akorát plést pod ruce... (Zatím.)

V tomto je ešte horší homebrew na macOS - ten je doslova vytvorený s predpokladom, že ho bude používať 1 užívateľ

Neházel bych ty všechny zmíněné technologie do jednoho pytle a vyvozoval z toho obecné závěry.

AppImage je opravdu specifická věc. Jak už jsem tu psal, je to vhodné pro portable aplikace, protože se to dá spustit odkudkoliv bez dalších programů v systému - to je hlavní cíl a benefit ("Linux apps that run anywhere").
Nicméně to neřeší problémy, co můžou nastat při případném linkování na konkrétní verze systémových knihoven. Zároveň je to pouze standard pro formát, vytváření a sestavování těch obrazů. Nemá to žádnou formu sandboxování.
Není žádný standardní (oficiální) mechanismus, jak je automaticky aktualizovat, spravovat, integrovat do systému atp. - je to mimo rámec toho projektu na portable aplikace. Jsou možná nějaké horší či lepší utilitky třetích stran, co se o tohle snaží a například extrahují metadata, vytváří XDG desktop soubory (aka zástupce). Může tam být interní aktualizační mechanismus v zabaleném softwaru, co ale logicky nezafunguje, když je image na místě, kam uživatel nemůže zapisovat atp.

Použil bych to pouze pokud není žádná jiná alternativa (Flatpak, Snap, dist. balíček).
Kdyby to mělo popisovaný problém, řešil bych ty aktualizace sám pomocí nějakého skriptu (který má právo na zápis), anebo v případě jediné aplikace bych se tím vůbec nezabýval a normálně to rozkopíroval do všech profilů (~/.local/bin/), ať se to každému uživateli aktualizuje samo pomocí interního mechanismu.

Flatpak oproti AppImage řeší spousty dalších věcí, dá se říct, že to nejen formát a nástroje k sestavení, ale i komplet balíčkovací systém včetně uživatelských nástrojů, sandboxuje, drží se XDG standardů atp. Je tam jistá forma deduplikace pomocí linků. Sdílené runtime balíky šetří jak místo, tak velikosti stahování. atd.
Stran toho delegování administračních úkonů, např. aby běžný uživatel mohl aktualizovat také systémové flatpaky, tak dá vše systémově řešit pomocí PolicyKitu.
Jsou tam registrované všechny potřebné akce, takže stačí např. použít systémovou skupinu users, kde budou všichni uživatelé a napsat jednoduché pravidlo, co ty akce povolí.
Nebo založit novou (např. flatpak-adm), upravit pravidlo a přidat do konkrétní uživatele.

msmucr@msmucr-desktop:~> pkaction | grep -i flatpak
org.freedesktop.Flatpak.app-install
org.freedesktop.Flatpak.app-uninstall
org.freedesktop.Flatpak.app-update
org.freedesktop.Flatpak.appstream-update
org.freedesktop.Flatpak.configure
org.freedesktop.Flatpak.configure-remote
org.freedesktop.Flatpak.install-bundle
..
org.freedesktop.Flatpak.runtime-install
org.freedesktop.Flatpak.runtime-uninstall
org.freedesktop.Flatpak.runtime-update
org.freedesktop.Flatpak.update-remote

Snap řeší hodně podobných věcí jako Flatpak. Byť jsou tam samozřejmě funkční rozdíly.. a každý z obou může mít určité výhody proti tomu druhému.
Osobně mi přijde citelně pomalejší než Flatpak, a to jak na spouštění (komprimované image, inicializace služby po startu), tak i aktualizace (differenciální přenos - delty vyžadují jejich výpočet na klientu).
Navíc je to tak divně mezi - v Ubuntu se to používá jak na desktop aplikace, tak poslední dobou na některé systémové služby. Což mi přijde zbytečné.. specificky v situaci, kdy je jsou na služby zaběhnuté Dockery a OCI kontejnery s bambilionem nástrojů okolo. Podobně to má tvrdou vazbu na jediný repozitář (Snapcraft od Canonoicalu).
Za mě by bylo optimální, kdyby se s tím ještě chvíli vyblbli a pak se to přirozeně odložilo (podobně jako Mir, Upstart) :), aby se zbytečně nefragmentovaly používané formáty pro tyhle desktop kontejnery a zůstal opravdu jeden majoritní.
Koneckonců i na Ubuntu instalacích obvykle Snap deaktivuji a používám tam Flatpak.

Ta AppImage aplikace je opravdu jediná - a že se bude takhle nemravně chovat mne nenapadlo, dokud jsem neviděl, co napáchala. ;-) Vzhledem k tempu aktualisací to není problém, pokud nastane nutnost, lze to přes SSH srovnat do latě.
Snapu v Ubuntu jsou jak rakovina. Nic proti, ale - jak píšete - když to začalo metastázovat mezi systémové utility, stalo se to nanejvýš protivným.
FlatPacky nejsou špatné, osobně mi připadnou jako rozumná alternativa, ale přijde mi, že tak nějak předpokládají, že uživatelem je administrátor. Viz právě to přidělování práv. (IMHO se o tyhle věci uživatel starat nemá, natož abych mu musel delegovat práva.) Na jednouživatelském stroji bych jim asi dal šanci.

Celkově to opravdu na mne dělá dojem, že se tu (někdo) snaží řešit problém jak udělat nejlepší instalace na počítači pro jednoho uživatele, protože se pohybuje ve sociální bublině, kde pravidlo 1 počítač = 1 uživatel platí, kde jsou počítače opravdu osobní, stejně, jako mobily a tablety.
Proto ta snaha přiblížit instalace tomu, jak je to na mobilních platformách.
Jenže mezi prostým lidem tomu tak není - a PC/notebooků v rodinách spíš ubývá, přičemž zůstávají sdíleným prostředkem, pro situace, na které mobily či tablety nestačí nebo se nehodí.

FlatPacky nejsou špatné, osobně mi připadnou jako rozumná alternativa, ale přijde mi, že tak nějak předpokládají, že uživatelem je administrátor. Viz právě to přidělování práv. (IMHO se o tyhle věci uživatel starat nemá, natož abych mu musel delegovat práva.) Na jednouživatelském stroji bych jim asi dal šanci.

Takhle mi to nepřijde. Od začátku to právě počítá s více možnostmi používání a je to, podle mě, docela vymakané.

Můžete je instalovat jen pro všechny uživatele, a nedovolit normálnímu uživateli přidávat ani aktualizovat žádné aplikace. To je většinou i výchozí nastavení, třeba balíček flatpak na Suse, má polkit pravidla tak, že to povoluje jen uživatelům ve skupině wheel, ale můžete to dalšími pravidly upravit úplně dle libosti. Na Ubuntu je to zas skupina sudo.
Tohle je myslím asi to, co většina lidí očekává. Software spravují jen administrátoři, ale pokud je tam jen jediný přidaný účet v systému, má většinou také administrátorská práva.
Zároveň je na Suse připravený, ale neaktivní systemd timer, co spouští globálně: /usr/bin/flatpak --system update -y --noninteractive
Stačí ho zapnout a naplánovat podle potřeby.

Pokud pak chcete kombinaci, tzn. aby uživatelé měli k dispozici systémové (sdílené) aplikace, do kterých nemůžou sahat, ale zároveň si mohl nainstalovat něco jen pro sebe, tak to jde taky.
Jestliže uživatel používá příkaz flatpak z terminálu, mělo by stačit v shellu udělat alias, na flatpak, aby se to používalo s direktivou --user na konci. První pak přidat uživatelský repozitář na flathub přes flatpak remote-add. A pak už to normálně jede a všechno, co udělá, bude pouze u něj v profilu.
Samozřejmě pokud tam bude závislost na nějakém runtime, který už bude jednou nainstalovaný pro všechny, tak se nestahuje.
V případě, že pak používá např. GNOME software s pluginem pro flatpak, jde to taky, když se v u něj nastaví:
gsettings set org.gnome.software install-bundles-system-wide false (výchozí hodnota je true a chce to přihlášení, viz. to co jsem zmiňoval).
Všechny tyhle kroky se dají udělat samozřejmě udělat automaticky, když se vytváří nový profil nebo po nějaké jeho inicializaci.

Jo, něco takovýho jako /usr/bin/flatpak --system update -y --noninteractive jsem tam musel přidat do updatovacího scriptu. (Ono je to už pár měsíců, co jsem to potřeboval naposledy...)
Ale právě to, že na to člověk musí pamatovat, že se to neřeší v rámci běžného update-update, mi na tom vadilo.
(A taky to prvotní ladění souběhu apt + snapu + flatpacku v Ubuntu: doteď si nejsem jistý, že to mám úplně správně a že se něco samo nerozbije v budoucnosti po nějakém updatu.)

Já jsem právě pro tento use čase balíčky opustil. Zjistil jsem totiž, že uživatelé je neaktualizují. Došel jsem k nim po půl roce a měli třeba půl roku starý Firefox. Prostě i když stačí kliknout na notifikaci a potom na tlačítko Instalovat, nedělají to. A nemám koule jim to dělat na pozadí. V datech o pádech vidíme, že přepisování souborů za běhu programy pořád nemají rady a padají. U Flatpaku to problém není, protože nové soubory se načtou až po dalším spuštění programu, takže tam nemám obavu to dělat na pozadí automaticky.
Dalším důvodem je, že neměnný systém je prostě praktičtější, když se něco rozbije. Nestává se to často, ale občas prostě ano. A pak vysvětlujte po telefonu máti, která je 120 km daleko, jak si má downgradovat mesu, protože zrovna u jejího modelu GPU došlo k regresi. Takto jí řeknu, ať po startu počítače vybere druhou položku, čímž nabootuje do předchozího snapshotu, a používá ho, dokud se to neopraví. Vím, že dnes existuje díky Btrfs snapshotování i u balíčků, ale pořád to není tak přímočaré a univerzální jako ostree/bootc.

Já tu drzost nechat aktualizace na pozadí mám - byť uznávám, že je to částečně z mé nezkušenosti a z toho plynoucí nedostatečné opatrnosti. ;-D

Dědečka a babičky jsem naučil: Klikni na připojení k VPN, a počkej na telefonu. Zbytek přes SSH...
Občas je efektivnější povídat si se systémem, než s uživatelem.

U těch regresí v hardwarové podpoře je občas problém ten, že to ani do plného systému nenabootuje. A to je pak ještě těžší BFU vysvětlovat, jak nabootovat, připojit se k síti a VPN v nějakém failsafe módu.

A pak nastává čas na návštěvu na kafe... ;-D

(Nicméně variantu při startu honem vyber druhou volbu - předchozí verse - a pak se připoj... stařečkové už zvládli. Jen nesmím zapomenout jim na konci připomenout, že se mají zase vrátit na první řádek, jinak zůstanou na té předchozí versi věčně.)

Ja si myslym, ze toto je otazka stretu dvoch odlisnych svetov.

Pre server/enterpri­se/datacenter svet sa hodi viac klasicky pristup s balickovacim systemom. Vydavatel distra ma overeny set kniznic a aplikacii, ktore spolu funguju. Update kniznice sa aplikuje na cely system a ostatne zavisle kniznice a appky pouzivaju novu. Vydavatel systemu by to mal mat otestovane. Dostupne aplikacie v repe su obmedzne na vyber vydavatela distra (lebo jeho schopnost udrziavat repo a testovat kompatibilitu je obmedzena).

Pre user/consumer/des­ktop svet sa viac hodi pristup flatpackov (ala Windows pristup nezavislych aplikacii). Jadro systemu s core kniznicami si handluje vydavatel systemu. Ostatne appky si instaluje uzivatel od roznych nezavyslych dodavatelov. V tomto pripade je lepsie ked appku updatuje jej vydavatel. Je lepsie ked appka funguje a robi co ma so starsou kniznicou ako ked po update na novu kniznicu prestane fungovat. Mnozstvo dostupnych appiek je obrovske a vydavatel systemu nema sancu zabezpecovat kompatibilitu vsetkych appiek s roznymi kniznicami. Preto je to na vydavatelovi appky.

Ještě přidám svoji vtipnou zkušenost s Ubuntu a Snap: Na mém retro PC nejde Ubuntu nainstalovat, protože grafický instalátor v mobilové a webové technologii Flutter prostě nefunguje (ani ve VirtualBoxu, po čase zamrzne - nevím jak dnes, bylo rok zpět). Obešel jsem to serverovou verzí + následně doinstalování grafického desktopu. Jenže v poslední verzi (test před rokem) i GNOME byl zabalen ve Snapu. Takže i konzolový instalátor skončil na tom, že kopírování/roz­balování GNOME.snap vytimeoutovalo, protože rychlost optické mechaniky a plotnového disku * velikost balíku GNOME překročila ručně zvolený timeout natvrdo v kódu instalátoru (USB porty odpálil blesk a na přídavné PCI kartě z nich neumí bootovat BIOS). Workaround: starší verze Ubuntu Server, kde GNOME nebyl ve Snapu, pak upgrade.

4. 8. 2025, 16:26 editováno autorem komentáře

Prosím napište zde parametry toho PC.

Ono to není o těch parametrech. Jen o tom, že kopírování a rozbalování těch snapů je zdá se asynchronní task (jak je dnes moderní), takže nemá přehled o průběhu a testuje jen natvrdo zvolený timeout. Jinak to retro PC je Xeon 6jádro od prvního Core i (tj. hned první po Core 2), 16 GB RAM (jeden slot se upekl, takže jedu už jen 2 paměťové kanály ze tří), dGPU AMD z o něco novější doby (ale instalátor jedu v textové konzoli). Jak jsem psal, musím instalovat z CD mechaniky, protože USB porty na základní desce jsou odpálené bleskem a z těch na přídavné PCI kartě BIOS neumí bootovat. Pro zajímavost, Windows 11 na tom jede (testoval jsem), protože je to první CPU, co má vyžadovaný SSE4.2. S těmi instrukcemi je Win11 zkompilovaný. TPM je potřeba jen pro systémové šifrování, a to nepotřebuju. Tento PC si nechávám i proto, že tam mám nativně XPčka (samozřejmě s GPU 3D akcelerací a ostatními ovladači) a další staré verze Windows a OS.

4. 8. 2025, 21:37 editováno autorem komentáře

Tak tohle je snad opravdu už masochismus ne? To i já uznám. :-)

Prevádzkovať hacknuté win 11 bez TPM na poloupečenom stroji ... Ehhh, brekeke.

Idem asi hladať studený spoj na raspberry pi 1, je to krám. Iba 13 rokov má a prestalo mi fungovať. Pritom som sa k tomu zle správal a naviac to bolo lacné.

TPM neni potreba jen pro system. Je potreba i pro bezpecne brouznani na Internetu,
Viz technologie Passkey a DBSC(Device Bound Session Credentials).

PS: Drive jsem byl nastvany, ze Windows vyzaduje novy HW, dneska uz chapu ze je to krok v pred - sam ale Windows nepouzivam.

To jsou všechno volitelné technologie a ani nejsou zapnuté by default. A jinak nejde o hack OS, jen vypnutí kontroly v instalátoru.

Na Passkey TPM potreba neni. Externi token v tomhle smeru udela lepsi sluzbu - aneb muzete se bezpecne prihlasovat na vicero zarizenich a soucasne nemusi byt vsecha natvrdo pridratovana k tem sluzbam.

Jistě. Krok vpřed je odjakživa vytvářet vendor lock a pak ještě nutit kromě softwaru kupovat i nový hardware. Obávám se, že jste hlavně úplně nepochopil důvody, proč s tím má tolik lidí problém.

Procházející uživatel Gentoo pokrčí rameny nad starostmi lidi s RPM a pod. a polituje je. /smh

...presne, DLL hell je zlo...jo aha, to jsem jinde, tak pardooon.

Prosim dejte mi nekdo strucnou odpoved na nasledujici otazku:
Daji se na Linuxove Immutable distribuci instalovat komercni aplikace typu: MATLAB, Maple, Python, Julia, Java + vyvojove prostredi Gnu-GCC + Gfortran + Ruby, a dalsi vyvojarske aplikace a knihovny pro numericke vypocty (OpenMP, MPI, atd.) tak, aby to vsechno dohromady fungovalo jako na klasicke balickove distribuci? Jak je to s pristupem na sitove disky (NFS)? Jak je to s licencnimi servery pro komercni aplikace? Atd. atd.

Resp. jinak:
Je tahle "nova" cesta uz OPRAVDU prakticky pouzitelna a spolehliva v oblasti profesionalniho nasazeni?

Osobne se obavam, ze specialne u komercnich aplikaci, ktere na serveru pouziva vice uzivatelu najednou a data, aplikce resp. knihovny musi byt dostupna i po siti a to v korporatnim prostredi se striktnimi bezpecnostnimi politikami ... asi nebude schudna zalezitost. Navic dritiva vetsina modernich komernich aplikaci pro analyzu dat a numercke vypocty obecne vubec nepodporuje technologie snapd, flatpak a pod.

Tak pro koho to teda vlastne je vhodne ?

14. 8. 2025, 14:57 editováno autorem komentáře