In the previous article in this series, we looked at how to get started with Fedora Flatpaks and how to use it. This article compares and contrasts between the Fedora Flatpaks remote and the Flathub remote. Flathub is the de-facto standard Flatpak remote, whereas Fedora Flatpaks is the Fedora Project’s Flatpak remote. The things that differ between the remotes include but are not limited to their policies, their ways of distribution, and their implementation.
Goals and motivation
Fedora Flatpaks and Flathub share the same goals but differ in motivation. The goal is to make applications accessible in their respective field, maximize convenience and minimize maintenance.
Fedora Flatpaks’s motivation is to push RPMs that come directly from the Fedora Project and make them accessible throughout Fedora Linux regardless of the versions, spin, etc. So, in theory, it would be possible to get the latest and greatest applications from the Fedora Project without needing to upgrade to the latest version of Fedora Linux. Of course, it’s always advisable to keep everything up-to-date.
Flathub’s motivation is to simply make applications and tools as accessible as possible regardless of the distribution in use. Hence, all tools are available on GitHub. Filing issues for applications provided by Flathub is the same as filing issues on any project on GitHub.
Packages
Fedora Flatpaks and Flathub create Flatpak applications differently. First and foremost, Fedora Flatpaks literally converts existing RPMs to Flatpak-compatible files where developers can then easily bundle as Flatpak and redistribute them. Flathub, on the other hand, is more open when it comes to how developers bundle applications.
Types of packages published
Fedora Flatpaks only publishes free and open source software, whereas Flathub publishes free and open source software as well as proprietary software. However, Flathub plans to separate proprietary applications from free and open source applications, as stated by a recent blog post from GNOME.
Sources
Flathub is open with what source a Flatpak application (re)uses, whereas Fedora Flatpaks strictly reuses the RPM format.
As such, Flathub has tons of applications that reuse other package formats. For example, the Chrome Flatpak reuses the .deb package, the UnityHub Flatpak reuses the AppImage, the Spotify Flatpak reuses the Snap package, the Android Studio Flatpak uses a tar.gz archive, etc.
Alternatively, Flathub also compiles directly from source. Sometimes from a source archive, from running git clone, etc.
Number of applications
Fedora Flatpaks has fewer applications than Flathub. To list the applications available from a remote, run flatpak remote-ls --app $REMOTE. You can go one step further and get the number of applications by piping to wc -l:
[Terminal ~]$ flatpak remote-ls --app fedora | wc -l 86 [Terminal ~]$ flatpak remote-ls --app flathub | wc -l 1518
Here, at the time of writing this article, we can see that Flathub has 1518 applications available, whereas Fedora Flatpaks has only 86.
OSTree and OCI formats
Implementations are quite different too. Both Fedora Flatpaks and Flathub use Flatpak to help you install, remove, and manage applications. However, in terms of how these applications are published, they fundamentally work differently. Flathub uses the OSTree format to publish applications, whereas Fedora Flatpaks uses the OCI format.
OSTree format
OSTree (or libostree) is a tool to keep track of system binaries. Developers consider OSTree as “Git for binaries” because it is conceptually analogous to git. The OSTree format is the default format for Flatpak, which Flathub uses to publish packages and updates.
When downloading an application, OSTree checks the differences between the installed application (if installed) and the updated application, and intelligently downloads and changes the differences while keeping everything else unchanged, which reduces bandwith. We call this process delta updates.
OCI format
Open Container Initiative (OCI) is an initiative by several organizations to standardize certain elements of containers. Fedora Flatpaks uses the OCI format to publish applications.
This format is similar to how Docker works, which makes it fairly easy to understand for developers who are already familiar with Docker. Furthermore, the OCI format allows the Fedora Project to extend the Fedora Registry, the Fedora Project’s Docker registry, by creating Flatpak applications as Docker images and publishing them to a Docker registry.
This avoids the burden and complications of having to use additional tools to maintain an additional infrastructure just to maintain a Flatpak remote. Instead, the Fedora Project simply reuses the Fedora Registry, to make maintenance much easier and manageable.
Runtimes
Flatpak runtimes are core dependencies where applications reuse these dependencies without duplicating data, also known as “deduplication”. Runtimes may be based on top of other runtimes, or built independently.
Flathub decentralizes these runtimes, meaning runtimes are only available for specific types of applications. For example GTK applications use the GNOME runtime (org.gnome.Platform), Qt applications use the KDE runtime (org.kde.Platform), almost everything else uses the freedesktop.org runtime (org.freedesktop.Platform). The respective organizations maintain these runtimes, and publish them on Flathub. Both the GNOME and KDE runtimes are built on top of the freedesktop.org runtime.
Fedora Flatpaks, on the other hand, uses one runtime for everything, regardless the size of the application. This means, installing one application from Fedora Flatpaks will download and install the whole Fedora runtime (org.fedoraproject.Platform).
Conclusion
In conclusion, we can see that there are several philosophical and technical differences between Fedora Flatpaks and Flathub.
Fedora Flatpaks focuses on fully taking advantage of the existing infrastructure by providing more to an average user without using more resources. In contrast, Flathub strives to make distributing/publishing applications and using them as painless as possible for the developers and for users.
Both remotes are quite impressive with how rapid they improved in very little time. We hope both remotes get better and better, and become the standard across the majority of desktop Linux distributions.
GroovieMan
I do not use both of them. RPM is my preffered source and i am very happy to see that most of the supplier also provide for proffessional rpm packages like Citrix!
To my mind flatpak/hubs are unsafe like a software distribution with fat-executables (statically linked libs). If the distributor does not take care of his (also) shipped with 3rd patry libraries, then you may still use a vurnable functionality while rpm distributed software get a sec-fix on a update of a depended library package for a couple of apps.
Flatpack/hubs is the software distributors modern art of the eyewash. Flatpack might lower the incompatibilities between linux distributions, but it sholder up the burden of responsibility to the distributor for the software that he is delivering now.
From the user perspective flatpak may be right for games, but for any other software i rely on, it is counterproductive to see a later version of a software on my desktop, that i can’t rely on.
TheEvilSkeleton
Fedora Flatpaks works similarly to RPMs. Everything is in the Fedora runtime; and everything is built from Fedora RPMs, so applications (and dependencies) are regularly updated.
Vincent Chernin
Great to see a nice article about these 2 remotes!
Keep in mind this also includes Flatpaks which refs have the
prefix. These include runtimes, SDKs, extensions, GTK themes etc. These are not necessarily “apps” in the usual sense (e.g. not user-visible on flathub.org), so it might make sense to not count them.
To see the list of “apps” you can grep for the
prefix:
86
$ flatpak remote-ls flathub --columns=ref | grep "app/" | wc -l
1518
TheEvilSkeleton
Thanks! I was actually supposed to list apps, but I completely forgot about it and listed all packages available.
Also, you can simply use –app instead. So:
Anyway, thanks for letting me know! I’ve edited the article and listed the numbers of applications, and not the numbers of packages.
ivanhoe1024
Nice comparison, thank you! Quick question: on a system where both Flathub and fedora remotes are added, is there deduplication between the Fedora runtime and the others from Flathub? I assume there is not, and this is a pity since many things could surely be shared among these runtimes…
TheEvilSkeleton
Unfortunately they are not deduplicated. Since they use slightly different builds, e.g. patches, versions, and thus have different hashes, they cannot be deduplicated.
Aaron
Does Red Hat and/or Gnome intend to abandon the traditional RPM format entirely in favor of Flatpaks at some point in the future?
TheEvilSkeleton
I’m not affiliated with Red Hat, nor am I deeply involved internally, so take it if you will. I highly doubt they are going to abandon RPM because it’s literally impossible to have a Flatpak-only system. However, that doesn’t stop them from using another format like deb, PKGBUILDs or others. But I still doubt that will ever happen soon.
edier88
Very good article. I have learned a lot! Thank you!
TheEvilSkeleton
Thanks!
laolux
Thanks for the great explanation about the differences between flathub and fedora flatpaks. It is interesting to know that fedora flatpaks are created from the regular rpms. Now it would be interesting to know how exactly that is done.
TheEvilSkeleton
I was thinking or writing an article about it, but I have to do a lot of research on it. In the meantime, you can watch this video to learn how to make Flatpak apps using RPMs: https://www.youtube.com/watch?v=IuxHidCdbPo
laolux
Thanks, thats quite interesting. I am sure you will make a great article out of it 🙂 Thanks in advance!
Akarshan Biswas
I prefer the flathub one because it uses ostree with delta updates.
TheEvilSkeleton
Fedora Flatpaks does delta updates too, so there shouldn’t be a difference when you update.
DipQ
Thanks for the great explanation! It was a bit puzzling in my mind why would they use different runtimes, but this makes it much clearer, and with a link to a very interesting docker repo to boot, thanks
Scott Dowdle
I can tell you aren’t a Red Hatter because you used the word “Docker” rather than “Container”. As you probably know, Red Hat’s alternative to Docker is Podman and rather than trying to call things a “Podman This” and “Podman That”, they prefer the more neutral term of “Container This” and “Container That”. For example, Fedora doesn’t have a Docker Registry nor does it have a Podman Registry, but it has a Container Registry. See how that works? 🙂
I find the use of the term “remote” to be confusing… as for the traditional package manager, we call a remote store of packages and associated metadata, a “software repository” or simply “repo”. Why the need for a different term? Flatpak repository… and if you have a local copy… I guess it would be a local Flatpak repository… but if it is not stored somewhere on your LAN/WAN then it’d be a remote Flatpak repository. Flatpak remote makes me think of a remoting protocol or a device I use to turn on a TV with.
Ryan Gonzalez
“Remote” here comes from OSTree, which in turn based the terminology on Git: since Flatpak maintains its own local OSTree repos to store the actual app, it makes sense to have a distinction where the repos you actually download from are “remotes”.
Scott Dowdle
Thanks for the background… but the same local vs remote pertains to package manager repos too… and they don’t feel the need to differentiate… but given time I’m sure it’ll become the new mental normal.
Narendra Utpala
Is there a place to request for Fedora flatpak apps? I would love to have app such as MuseScore through Fedora flatpak, as the Flathub version has issues on Fedora 35.
TheEvilSkeleton
You’ll have to open an issue on the Bugzilla. To do so, head over to https://bugzilla.redhat.com/, press “File a Bug”. Create an account if you haven’t. Then, press “Fedora”, press “Fedora” again. In the Component section, type “mscore” (MuseScore package). And finally you can write everything you can to request a Flatpak application.
Narendra Utpala
Alright I’ve opened the issue there. Thanks for your help!
Michael Montoya
I really like the flatpak idea, but it’s very hard to find good remotes. You can try flathub-remotes , but i don’t know how stable they are or what problems you might have with them.
condor
I was unaware of https://registry.fedoraproject.org/ before reading this article. BTW, this article can easily be expanding into a Fedora package management white paper, but then in the dialog that followed part one of this series, didn’t the author state there were no plans for a followup article? This is not only a big topic, it is a topic at the center Fedora’s evolution.
Since the first article in this series was published I went back and examined my use of video editing software and how I install it. The Flathub provided video editor I raved about, in my comments for the first article in this series, was broken. I guess, I get carried away in my desire to be a technology futurist and need to curb my enthusiasm when standing in front of the classroom. There is no Fedora Flatpak for either my preferred video editor or the several of its competitors I keep an eye on, and if the Fedora Flatpak installation were at least as reliable as the rpm installation then I wouldn’t have to hedge my enthusiasm.