Fedora, FFmpeg, Firefox, Flatpak, and Fusion
FFmpeg and Firefox
At the beginning of June, Otto Urpelainen posted
(on the Fedora development list)
about some surprising behavior he had observed on his system. Initially,
the Firefox browser was able to play the videos he wanted to watch.
Installing Fedora's ffmpeg-free package, though, caused those
videos to fail to play. As Urpelainen noted: "This is unexpected,
because one would expect that installing any variant of ffmpeg would
improve video support, not degrade it
".
As Kevin Kofler pointed out, this behavior looks like a bug in Firefox, which is unable to find the OpenH264 variant of the H.264 decoder found in the ffmpeg-free package. But it was not lost on anybody that this problem does not occur if the version of FFmpeg shipped by RPM Fusion is installed instead, and that the H.264 codec found there doesn't require the various convolutions required to get OpenH264 onto Fedora. The H.264 support in RPM Fusion is thought by some to work better as well. For this reason, Vitaly Zaitsev said that the proper solution is for users just to enable RPM Fusion.
Michael Catanzaro took issue with that advice:
Vitaly, your suggestions to enable rpmfusion are not helpful for inexperienced Fedora users, who expect multimedia to work out-of-the-box. Common multimedia needs like "play a video" absolutely need to work without rpmfusion, and we need Fedora developers testing this to make sure it works.
But Kofler replied that "It
is common knowledge that Fedora is/was effectively useless for anything
remotely related to multimedia without RPM Fusion packages
". Zaitsev
doubled
down later by saying that Fedora should simply preload the RPM Fusion
repository so that users need not go through the process of learning that
they need it and figuring out how to enable it themselves.
That is the process that is required now; a new Fedora installation will not be set up to obtain packages from RPM Fusion and will not help users understand that, sooner or later, they will have to configure that repository. But fixing that problem still does not appear to be in the works; one of the constraints placed on the Fedora project is that it cannot help users find repositories containing code that, for example, might have patent problems in some jurisdictions. This "pretend it's not there" approach has led to a certain amount of frustration over the years.
Enter Flatpak
More recently, though, there has been a development on a related front. In June 2021, the project adopted a proposal to set up the Flathub repository by default on Fedora systems. Flathub is, like RPM Fusion, an independent repository (run by the GNOME Foundation) and, again like RPM Fusion, it contains software that Fedora cannot distribute, but it distributes packages in the Flatpak format rather than using RPM. There is a push within Fedora to ship applications as flatpaks rather than as RPMs. Flatpak makes dependency management easier and, in theory at least, can run applications within secure sandboxes, but many developers see the format as inferior and would prefer to avoid it.
The Flathub repository was set up in a "filtered" mode, meaning that only applications that were acceptable to Fedora would be available (by default), but that still left room for proprietary flatpaks like Zoom, Microsoft Teams, and Minecraft. Last April, though, the situation changed: permission had been received to drop the filtering and present the full Flathub repository to users. Fedora developers are currently working on enabling this change for the upcoming Fedora 37 release. Catanzaro welcomed this news:
Er, so everything from Flathub is fine now, no restrictions? Seriously great news. In this case, I'd say priority one is to stop shipping Fedora's Firefox and Totem altogether, and default to getting them from Flathub instead.
Not everybody was so joyful, especially given that the plan is to have the system select a flatpak package over a traditional RPM package when both are available. Deferring to an outside repository for important packages like Firefox is also not universally accepted as ideal. But the idea that Fedora can now freely set up access to an external repository with software that Fedora cannot ship itself is generally welcome. It could be a solution to Fedora's longstanding limitations with regard to problematic media formats.
Why not RPM Fusion?
Since that decision was made, developers have been asking if access to RPM Fusion could be preloaded in Fedora as well, always to be told that it is not possible. The question came up again in this conversation as well; Catanzaro responded:
For avoidance of doubt, Fedora Legal has decided we may use flathub but not rpmfusion. As I explained to you previously, they have also decided not to share their reasoning for this.
Fedora project leader Matthew Miller answered with a pointer to this explanation:
Flathub is a third-party repository which provides software for various Linux distributions. It doesn't shape what software it carries around what Fedora does not. It fundamentally exists to solve a problem with Linux app distribution to which our policies around licensing, software freedom, and etc., are incidental. This makes it a different case.
It is fair to say that not everybody finds this explanation convincing.
Kofler described
it as "an absolutely ridiculous double standard
". "Maxwell G" called it "a
pretty flimsy argument
". Petr Pisar tried
to explain the difference: RPM Fusion specifically targets Fedora, while
Flathub is not Fedora-specific, and that somehow makes a difference.
The logic behind this policy surely makes sense to somebody in Red Hat's
legal department, but it may have some unfortunate consequences in the
Fedora user community. It is not hard to imagine that it could be causing
a lack of morale among the RPM Fusion developers, who have worked for many
years to address a key shortcoming in Fedora systems. If Fedora pushes its
users toward the Flathub solution, RPM Fusion may eventually just give up,
leaving no alternative to Flathub, which is a less-appealing repository for
many. It is not at all clear that Fedora and its user community would be
better off in that world.
Posted Jun 16, 2022 15:32 UTC (Thu)
by amacater (subscriber, #790)
[Link] (4 responses)
Every distribution has different policies: there might be scope for sitting down and agreeing a common policy between several distributions so as to avoid users distro-hopping just because "Distro A provides XYZ and distro B doesn't."
Posted Jun 16, 2022 22:19 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (3 responses)
Posted Jun 23, 2022 15:56 UTC (Thu)
by kpfleming (subscriber, #23250)
[Link]
Posted Jun 23, 2022 20:13 UTC (Thu)
by pebolle (guest, #35204)
[Link] (1 responses)
The whole point of distributions, or better their cause, appears to be the narcissism of small differences. (Perhaps that's one of the few worthwhile contributions of Freud?)
I find the deb versus rpm, KDE versus GNOME, systemd versus the fossils, and whatever other splits very depressing. I almost have sympathy for Google here: Android has been a take-it-or-leave-it offering from the get go. (Yes, it helps if you make a few billions every month. It helps even more that your market share is not below the rounding error of measurement.)
Posted Jun 30, 2022 12:59 UTC (Thu)
by callegar (guest, #16148)
[Link]
Posted Jun 16, 2022 16:18 UTC (Thu)
by bferrell (subscriber, #624)
[Link] (1 responses)
No one wants to adopt a tool that may or may not work with every update. There are other distros doing this too... All wanting to be FB "move fast! Break things!"
There is even question rising among the kernel devs if things might not be moving too fast now.
Posted Jun 16, 2022 16:40 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Part of the problem is that people do want things to move fast. But they also want things to not move; if things work as they're happy with, then those things should not change, while things that don't work well need to move fast to newer versions. And as the set of things that some people are happy with overlaps the set of things that some people think don't work well, we have a tension to resolve.
Fedora's resolution is to basically trust that upstream's pace is acceptable; RHEL's resolution is to try and hold on very stable versions for a long time.
Posted Jun 16, 2022 16:36 UTC (Thu)
by lobachevsky (subscriber, #121871)
[Link] (5 responses)
Nothing making this unsuable and definitely better than an outdated Firefox, but I'd be wary of deploying this to users on a large scale yet.
[1] https://github.com/flatpak/flatpak/issues/4571
Posted Jun 17, 2022 12:43 UTC (Fri)
by daenzer (subscriber, #7050)
[Link] (1 responses)
Posted Jun 18, 2022 10:20 UTC (Sat)
by lobachevsky (subscriber, #121871)
[Link]
Posted Jun 19, 2022 7:18 UTC (Sun)
by gspr (guest, #91542)
[Link]
Posted Jun 23, 2022 15:58 UTC (Thu)
by kpfleming (subscriber, #23250)
[Link]
There have also been ongoing problems with CUPS access from the Flatpak Firefox, so much so that I gave up trying to directly print from the browser and instead Save to PDF then open that PDF and print it.
Posted Jun 30, 2022 13:08 UTC (Thu)
by callegar (guest, #16148)
[Link]
Posted Jun 16, 2022 16:54 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link]
Posted Jun 16, 2022 16:55 UTC (Thu)
by cyperpunks (subscriber, #39406)
[Link] (12 responses)
Moving this success story to new formats as Flatpaks and Snap are very risky business.
Packaging of software is a very complex topic, moving to new formats don't make that problem go away, there are no free lunch.
Posted Jun 17, 2022 8:49 UTC (Fri)
by taladar (subscriber, #68407)
[Link] (9 responses)
Posted Jun 17, 2022 17:04 UTC (Fri)
by WolfWings (subscriber, #56790)
[Link] (8 responses)
Instead of waiting for your distro to ship an updated OpenSSL... now you need to wait for every containerized package to ship an updated image entirely.
Posted Jun 17, 2022 18:36 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (7 responses)
At least in the case of Flatpak, that's a false statement - you should be using OpenSSL from a runtime, like org.freedesktop.Platform, and as soon as that runtime is updated, you've got an updated OpenSSL in all Flatpaks using the runtime.
The difference between Flatpak and a normal distro is the granularity of dependencies; with Flatpak, my dependencies come in coarse-grained lumps (the runtime I choose, and any runtime extensions I add), rather than in the fine-grained set a distro gives you. And I'm expected to bundle dependencies that aren't in a runtime.
Posted Jun 17, 2022 20:10 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (6 responses)
Is that so? Don't flatpak applications "bind" to the specific runtime version/hash they were built against, so that the resulting rootfs is immutable?
Posted Jun 17, 2022 22:37 UTC (Fri)
by dbnichol (subscriber, #39622)
[Link] (5 responses)
Posted Jun 21, 2022 1:32 UTC (Tue)
by WolfWings (subscriber, #56790)
[Link] (4 responses)
It moves the version-tracking load to the SysAdmin much more heavily having to know about everything instead of just updating the actual vulnerable package once and done, which is literally the entire point of ABIs and APIs that don't wildly change.
Posted Jun 21, 2022 1:58 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Jun 21, 2022 9:50 UTC (Tue)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Of course, it's affects your reproducibility, since the image as run might not exactly match the image if you built it again. But if you're careful with the updates this should work quite well.
This article has raised my appreciation of Flatpak somewhat, which wasn't what I expected.
Posted Jun 21, 2022 16:57 UTC (Tue)
by dbnichol (subscriber, #39622)
[Link]
https://gitlab.com/freedesktop-sdk/freedesktop-sdk
Posted Jun 21, 2022 9:35 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
No - you update the runtime that contains OpenSSL to a new patch version, and all Flatpaks that depend on that runtime pick up the update automatically when they're next restarted. This is exactly the same level of complexity as updating OpenSSL by updating a single .deb, but with the proviso that the amount of data to transfer could be larger (since you're updating a whole runtime, and therefore picking up other fixes, not just targeting an OpenSSL fix).
You still face the problem of applications that are tied to runtimes that no longer get security updates - but that's a similar level of admin burden as handling applications that only link against unsupported OpenSSL versions, where you need to backport a fix from the version of OpenSSL in Debian Buster to the version that shipped with Debian Potato, or update the application to a newer version that runs on a newer runtime, or remove the application.
Posted Jun 17, 2022 17:03 UTC (Fri)
by WolfWings (subscriber, #56790)
[Link] (1 responses)
Posted Jun 18, 2022 21:55 UTC (Sat)
by alsuren (subscriber, #62141)
[Link]
The situation on MacOS used to be very fragmented, with macports, fink, and a few others. It now seems to have settled down to everyone using homebrew. It's a manual step to set up that non-technical users wouldn't be expected to do, but I would be willing to bet that there are more users of homebrew than users of any one package manager under desktop linux (I might just need to get out of my bubble. How would I find that out?).
I think that flatpak represents an opportunity for desktop linux to leapfrog the other platforms in terms user experience again. The sandboxing capabilities of modern linux have already unlocked a developer experience (in the form of docker, devops and more recently vscode devcontainers) that I never thought was possible when I started my first dev job at Collabora, a decade ago. We can do the same thing for desktop user experience too, and I'm glad to see it progressing so well. Maybe it will make me switch back.
Posted Jun 16, 2022 21:01 UTC (Thu)
by Seq (guest, #110060)
[Link]
Packages installed from there modify the system, and work as dependencies for other software. There may be concerns about timeliness of security updates. There have also been scenarios where rpm fusion hasn't been ready to go in-sync with Fedora version upgrades, thus either failing the upgrade or causing breakage. I've dealt with these issues in the past, but I made an informed decision to use and enable rpmfusion. Applying this to users with a mere checkbox (or by default?) and without the knowledge/ability to fix issues would be a concern. Granted, rpmfusion has improved on the timeliness issue a lot in recent years, possibly due to using similar infrastructure to Fedora now (Koji, etc).
Flathub, by comparison, are just bolt-ons that won't break the system itself.
(This doesn't address any legal concern, which is slightly more iffy. I haven't made up my mind on that).
Posted Jun 16, 2022 23:31 UTC (Thu)
by willy (subscriber, #9762)
[Link]
Posted Jun 17, 2022 8:47 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (3 responses)
There is an annoying bug in pdf rendering in the Ubuntu snap which doesn't occur in the apt-based firefox-trunk (including older versions). It looks maybe as if the snap is not able to find system fonts, analogous to the H.264 codec issue in the article. I wonder if a flatpak firefox on fedora will have its own issues.
Posted Jun 19, 2022 9:58 UTC (Sun)
by fredrik (subscriber, #232)
[Link]
https://launchpad.net/~mozillateam
It is also still possible to remove snap/snapd entirely from Ubuntu 22.04. In case you do not like such newfangled contraptions on your computer.
https://haydenjames.io/remove-snap-ubuntu-22-04-lts/
I hope this will continue to be possible for years to come, both options are entirely to my taste.
Posted Jun 23, 2022 12:39 UTC (Thu)
by mcatanzaro (subscriber, #93033)
[Link]
It's very likely that we'll switch *everything* to use Flatpak sooner rather than later, but they would still be built by Fedora and not have access to any multimedia goodness beyond what's already available in Fedora.
Posted Jun 27, 2022 8:44 UTC (Mon)
by danielthompson (subscriber, #97243)
[Link]
I don't think this is right. flatpak is useful to Fedora to convenience reasons. That is the difference (compared to rpmfusion) that allows them to include it. Having useful not-a-legal-workaround purpose to providing flatpak support in the distro is enough to change the legal reasoning about whether to include it by default. The same legal reasoning cannot be applied to rpmfusion because this repo arguably only exists for legal reasons.
Posted Jun 17, 2022 15:05 UTC (Fri)
by eru (subscriber, #2753)
[Link] (1 responses)
Posted Jun 17, 2022 15:14 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Not with Flatpak - the org.freedesktop.Platform runtime provides media codecs using FFmpeg, and if you need more than the "standard" set, you can add the org.freedesktop.Platform.ffmpeg-full runtime extension to get all codecs FFmpeg supports.
Posted Jun 18, 2022 23:56 UTC (Sat)
by elagost (guest, #159111)
[Link] (1 responses)
I have used exclusively Fedora for years and strongly prefer it for many reasons, but I would go elsewhere immediately if RPMFusion's repos were no longer available. They are essential for my desktop and servers.
Posted Jun 20, 2022 10:46 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
It makes sense in terms of legal risk: there are a variety of mechanisms you can use as a plaintiff to persuade a court that an apparently independent legal entity is in fact the defendant using a second entity at arm's length to escape liability. It appears that Red Hat's legal team think that defending the idea that RPM Fusion is separate to the Fedora Project would become too challenging for the level of resource they're willing to spend on Fedora, but that defending the idea that FlatHub is separate to the Fedora Project would not.
We can all speculate on why RH Legal think this way - I think the cross-distro nature of FlatHub, as compared to the tight dependencies from RPM Fusion on Fedora is a big component, personally - but for as long as the Fedora Project is a "A Red Hat-Sponsored Community Project", Red Hat Legal's willingness to take that risk is going to matter.
Posted Jun 18, 2022 23:57 UTC (Sat)
by bojan (subscriber, #14302)
[Link]
Posted Jun 19, 2022 7:31 UTC (Sun)
by gfernandes (subscriber, #119910)
[Link] (6 responses)
But one should be wary of this approach.
Flatpak advertised itself as a distribution *agnostic* packaging solution. The only way this can be possible is to do the *very* thing Windows installable have been doing for ages - bundle all dependencies in each installable.
This is the *very* thing Linux users prided themselves on - our shared library model that allowed all users of the same dependency, to *not* need to bundle that dependency in their installable bundle.
Given that Flatpak runtimes _can_ be shared, but does anyone know how many actually *are*?
Posted Jun 19, 2022 17:10 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link] (5 responses)
You mention runtimes, which means you're aware that this is not the only way this can be possible - most common dependencies exist in the runtimes and aren't bundled with apps.
Posted Jun 19, 2022 22:14 UTC (Sun)
by gfernandes (subscriber, #119910)
[Link] (4 responses)
The _ability_ to share does not automatically translate into reality.
Posted Jun 19, 2022 22:22 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link] (3 responses)
Posted Jun 20, 2022 6:35 UTC (Mon)
by gfernandes (subscriber, #119910)
[Link] (2 responses)
What you have said makes it sound like a fair option.
Posted Jun 21, 2022 17:26 UTC (Tue)
by dbnichol (subscriber, #39622)
[Link]
Posted Jun 23, 2022 12:49 UTC (Thu)
by mcatanzaro (subscriber, #93033)
[Link]
Posted Jun 19, 2022 16:28 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (2 responses)
What front-end(s) is this preference implemented in? I had a (too) brief look at the page linked and saw a reference to some obscure "GNOME software". What about "dnf" for instance?
Posted Jun 20, 2022 9:16 UTC (Mon)
by seyman (subscriber, #1172)
[Link] (1 responses)
"GNOME software" is Gnome Software.
As for dnf, the only type of package it knows about is rpm. It has no idea what flatpaks are and cannot install them.
Posted Jun 23, 2022 15:55 UTC (Thu)
by kpfleming (subscriber, #23250)
[Link]
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Having more users means more support cost, so it is not always a positive.
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
... but Android has at least as many variants as Linux desktops do: One UI, MIUI, EMUI... just to mention a few. All with different feature sets (e.g. in MIUI you cannot pin apps, so giving a phone to a kid to play gcompris is a huge issue). It is almost impossible to "switch" phone brand for many users without getting utterly confused.
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
[2] https://github.com/flatpak/flatpak/issues/4525
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
I have tried the "snap" version of firefox in the latest ubuntu and I must say that everything works amazingly well... apart from those things that don't work and fail in incredibly irritating ways: like broken grouping in the plasma task bar, poor fonts, firefox not starting if you try to start it from the cli from a directory it does not like, inability to access stuff that lives out of your home or media (it is not that you cannot access them by default... there is nothing you can do to allow such access), inability to customize things like mime types, broken extensions (markdown viewer), ecc.
Glad there is still a PPA with a non snap version of firefox. I hope that the flatpack version provides a better experience.
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
https://www.buildstream.build/
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora seems to be going the flatpak route for legal reasons; meanwhile Ubuntu went for a snap-only Firefox for convenience reasons (and supposedly because Mozilla too preferred to support a snap).
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
https://balintreczey.hu/blog/firefox-on-ubuntu-22-04-from...
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
> snap-only Firefox for convenience reasons (and supposedly because Mozilla too preferred
> to support a snap).
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
If a fresh install can obtain both the aforementioned programs as well as Nvidia Drivers and Google Chrome, then there's no reason not to bake in RPMFusion - even if just the free repo and opt-in; free/non-free are separated. ffmpeg is ffmpeg, regardless of if it's in /usr/bin or /var/lib/flatpak.
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion
Fedora, FFmpeg, Firefox, Flatpak, and Fusion