Vlákno názorů k článku
OBS Studio smírně vyřešilo problémy s Fedorou kvůli flatpaku od Curaj - Kdyz jsem Fedoru testoval tak jsem to smazal...

Kdyz jsem Fedoru testoval tak jsem to smazal a pouzival ciste Flathub. Na internetu clovek najde dost stiznosti na nizkou kvalitu flatpaku od Fedory obecne, nejen OBS. Vi nekdo, proc ten Fedora flatpak remote vubec existuje?

25. 2. 2025, 11:24 editováno autorem komentáře

Tak bych tipoval, že to bude souviset hlavně s Fedorou Silverblue, kde je to primární způsob přidávání aplikací nad ten úplný základ. Ty flatpaky jsou pak většinou generované z normálních rpm balíčků, co jsou ve Fedoře.
Taky je tam pár technických odlišností. Např. OSTree vs OCI formát, jinak poskládané runtimy (a závislosti na nich).
https://fedoramagazine.org/comparison-of-fedora-flatpaks-and-flathub-remotes/
Také nad tím mají samozřejmě větší kontrolu, pokud by chtěli něco měnit. Navíc jim nepřestane úplně fungovat software v distribuci, když by byl jakýkoliv problém s Flathubem.

Hodně uživatelských stížností, co jsem zaznamenal, pak jde spíš za tím, že ty Flatpaky mají stejné restrikce jako normální balíčky z Fedory. Tzn. žádné patentované nebo sporné fíčury (kodeky atp.), což třeba u spousty různých multimediálních věcí činí ty flatpaky prakticky dost nepoužitelnými.

25. 2. 2025, 11:45 editováno autorem komentáře

flathub je userspace debianu, nebo mozna dokonce ubuntu - ale obecne se flat vyhybam, je to pomale, ma to omezeni na disky (asi jde nakonfiguropvat) a kupu balastu k tomu - to uz radeji appimage a nejradeji apka v OS, RPM je pro me v pohode a nedela to bordel ala windows - kazdy soubopr je z balicku a tak jde upgeradovat nebo odebrat

Nemýlite si to so SNAPom?

Jelikož Flatpak má runtime dle výběru autora, tak asi plete.

A RPM fungují dobře jen do chvíle, než člověk potřebuje míchat stabilní verzi systému s nejnovější verzí aplikace.

AppImage zase nemají sandbox (takže je potřeba dost důvěřovat zdroji) a automatické aktualizace.

Tak to úplně není.
Flathub jeden z veřejných repozitářů a největší server na publikování.
To, co máte nejspíš na mysli, jsou ty runtimy, které jsou pak většinou základní závislosti těch jednotlivých flatpaků s aplikacemi.
Jejich id začíná na org.freedesktop­.Platform
Branche (verze) mají sice podobné číslování jako Ubuntu - yy.mm.point-release
ale není to Ubuntu. Je to projekt zastřešený Freedesktopem
https://freedesktop-sdk.gitlab.io/
Používají pak nástroj Buildstream, aby to složili z jednotlivých komponent.
Nad tím jsou pak další runtimy, např. s KDE nebo GNOME s různými branchi.
Viz. seznam těch nejpoužívanějších..
https://docs.flatpak.org/en/latest/available-runtimes.html

Jak jste zmínil tu instalaci jinam, je to docela hezky vyřešené. Deklarujete si v prostě další umístění configem v /etc/flatpak/in­stallation.d/
Pak se k němu odkážete při instalaci pomocí parametru např. --installation=druhy-disk
https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-installation

AppImage je podle mě dost nesrovnatelný. Neumí téměř nic bez dalších nástrojů okolo, nemá vůbec žádný sandboxing, jedna spustitelná binárka obsahuje vše, tzn. nedají se vůbec sdílet závislosti. Osobně mi to přijde vhodné jen na portable aplikace.
Jasně RPM (nebo jakýkoliv distribuční formát balíčku DEB, AUR) má samozřejmě výhody a je to preferované. Na stranu druhou, Flatpak, Snap nebo AppImage je řešení pro situace, kdy ty balíčky nemáte. Chcete např. spustit novější verzi, než je v distribuci příp. nechcete řešit všechny další závislosti. Příp. komerční software (jako Spotify klient).
Zároveň dost často ty flatpaky na Flathub publikují přímo vývojáři z těch projektů a je to součástí jejich pipeline. Takže je to spolehlivější než nějaké dobrovolnické repo s rpm, kde můžete mít dvě verze, než to někoho za půl roku přestane bavit.

Rychlost flatpaků mi přijde subjektivně nejrychlejší v porovnání s AppImage i snapy. A v podstatě srovnatelná s nativními balíčky na standardních počítačích s SSD. AppImage i snap používají komprimované squashfs image, kdežto flatpak to má po souborech standardně na disku, byť tam je zas hromada linků, které mají ale relativně minimální overhead. Snap se tu úvodní prodlevu snaží zmenšit tak, že ty image připojuje po startu systému přes snapd, což ale zas prodlouží start a vypínání systému, plus je tam samozřejmě připojená tuna loop blok. zařízení po celou dobu (což mě samotnému trochu vadí).
Osobně jsem si vyhodnotil Flatpak jako nejlepší. AppImage jen jako portable.
Snap se sice u Canonicalu používá i na služby (démony), ale to mi přijde trochu k ničemu, když máme OCI, Docker, Podman atd.

Díky za hezké shrnutí a souhlasím, ze tří dostupných možností je Flatpak i dle mě nejlepší.

Klasické balíčky pořád vnímám jako lepší, akorát developerům mnohých appek se to již nechce balit pro každý systém APT/RPM/... zvlášť a tak často nic než Flatpak bohužel k dispozici není.

AppImage je na houby, protože umožňuje libovolně linkovat na systémové binárky. To musíte být zkušený vývojář, abyste tak udělal instalačku, která bude fungovat opravdu na všech relevantních distribucích. Proto jsem zatím narazil snad na víc rozbitých než funkčních AppImagů. Lidi to dělají stylem: na mém Ubuntu to funguje, ven s tim. Tohle Flatpak nebo i Snap nedopustí.

Jinak jak už někdo psal, flatpak runtimy se dnes buildní ze zdrojáků, nemají s Debianem nic společného. To možná platilo v úplném začátku.

Jo jste přesně pojmenoval další problém. Např. takhle jsem měl portable Audacity, které chodilo na Ubuntu, ale už nešlo spustit na SUSE, právě kvůli vazbě na specifickou knihovnou PortAudio.

O Debianu moc nevím, možná na úplném začátku, to jsem to moc nesledoval, ale předtím než přešli na zmíněný BuildStream, tak na ty runtimy měli tooling a balíčky z Yocto Linuxu, který se obecně spíš používá na embedded a průmyslové věci.

Repozitář s Fedora flatpaky existuje primárně kvůli předinstalovaným aplikacím v Silverblue a spol. Fedora totiž nedovoluje, aby instalace obsahovala software odjinud. Je to také kvůli RHELu, kde děláme také vlastní flatpaky, protože řada zákazníků odmítá z bezpečnostních a certifikačních důvodů používat daný software od někoho jiného, než je Red Hat. Nicméně chytla se toho komunita a začala do flatpaků překlápět i aplikace, u kterých to ani není potřeba: nejsou předinstalované a jsou k dispozici na Flathubu.

Zakázat jim to nemůžeme, ale měla by se tomu nastavit nějaká pravidla. Např. flatpak by mohl vytvořit jen ten, kdo spravuje také RPM balíček dané aplikace. Často totiž někdo vytvoří flatpak, ač o to správce původního balíčku nemá zájem nebo si to přímo nepřeje. Jenže správce flatpaku je na těch balíčcích závislý. Jakoukoliv větší změnu lze udělat jen skrze ně. A když jejich správce nespolupracuje, nemá možnost, jak opravit něco, co je rozbité.

Díky za upřesnění a vysvětlení. Sice sám používám hlavně Flathub a nemám Silverblue, ale dává to smysl :)

Aha. Tak teď už to chápu. Používám Kinoite a měl jsem problém, že vestavěný Firefox a VLC prostě nepřehrají videa (nejde obraz). Kodeky, samozřejmě. No a tak jsem začal používat verze z Flathubu a OK. Nešlo by u těchto dvou aplikací dát Flathub výchozí? Tím, že jsou bez podpory videa jsou prakticky nepoužitelné. Ale chápu, že nad tím potom nemůžete držet záruku. Ale chtělo by to hned po prvním spuštění dát uživatelům na výběr.

Jinak si Kinoite užívám, nerozbitnost je super. Vždycky bootuju do funkční instalace. U klientů se mi párkrát stalo, že během aktualizací došla v ntb baterie (třeba) a vše se rozbilo. Ti, kterým jsem dal Immutable distro (ať už Silverblue nebo Kinoite) toto už neřeší.

Nešlo, protože Fedora nemůže obsahovat patentově chráněný software. A Firefox z Flathubu dělá to, že si při instalaci vyžádá ještě instalaci runtime extension s ffmpeg, který je plný patentově chráněného softwaru. Kdybychom to mohli použít, dáme to přímo do Fireroxu ve Fedoře a ten z Flathubu není potřeba, ale nemůžeme. Je to problém, který nemá technické řešení.

Jinak by mé zajímalo, co za video kodek vám ve Firefoxu nefungoval. Máme tam podporu pro H.264, VP8, VP9, AV1... To pokrývá prakticky vše, co se dnes v online videu používá. H.265 doteď Firefox neuměl tak jako tak.

Bez ffmpeg-freeworld a podobných mi nejela půlka YouTube ani třeba obrázkové pozadí v Google Meet. Nezkoumal jsem, který kodek to byl, ale rpmfusion to spravil.

Na Silverblue taky po ciste instalaci ve Firefoxu nejelo video z youtube (zkusil jsem jedno nahodne). Firefox z flathubu bez problemu.

Prakticky vzato nejede Youtube. Vůbec. Černé obdélníky. Verze Firefoxu z Flathubu jede normálně.

Problém s Firefoxem ve flatpaku je ten, že zatím chybí portál pro propojení s jinými aplikacemi. Konkrétně KeePassXC. Jak jsou z flatpaku oba, neumí se propojit.