Earlier this year, we talked about a peculiar oddity concerning Flatpaks and Fedora: unlike just about any other distribution, Fedora maintains its own Flatpak repository, while everyone else just defaults to Flathub. While there’s a few technical differences between Fedora Flatpaks and Flathub Flatpaks, the main gist is that the Fedora ones are built using Fedora’s own RPMs, while Flathub’s are built using different means.
This is an odd situation, since it does not reflect what users really want – users seem to greatly prefer Flatpaks from Flathub, since they have fewer bugs, are packaged by the applications’ creators, and bugs in Flathub Flatpaks can be reported to the actual developers, whereas bugs in Fedora Flatpaks generally cannot. As such, Fedora users are often surprised to learn that the Flatpak they installed came from Fedora instead of Flathub.
Now, since Fedora’s long-term goal is to make their immutable, Flatpak-focused variants the default, this situation needs to be addressed. As such, Fedora and GNOME developer Michael Catanzaro has published an incredibly detailed article outlining all the issues and possible solutions and courses of action. The basic gist is that before Fedora can consider switching from its own Flatpak repository to Flathub, a number of shortcomings in Flathub must be addressed:
↫ Michael Catanzaro
- Open source software must be built from source on trusted infrastructure.
- Applications must not depend on end-of-life runtimes.
- Applications must use flatpak-external-data-checker to monitor bundled dependencies wherever possible.
- Sandbox holes must be phased out, except where this is fundamentally technically infeasible.
Some of these points are fairly obvious, but let’s go over them anyway. A lot of binaries on Flathub are pre-built in that they are not built using Flathub’s infrastructure, and as such, you don’t know if anything has been done to the code between, say, the code’s release on GitHub and the Flatpak you install on your computer. This obviously needs to change, and ideally, all Flatpaks on Flathub should be reproducible.
End-of-life runtimes should obviously also not be a thing, for entirely obvious reasons. Currently, a little under a third of applications on Flathub use end-of-life runtimes, meaning the runtimes they use are not receiving any security updates. The same applies to external dependencies packaged inside Flatpaks; they can be outdated too, but many Flatpaks do not use the designated tool to deal with this issue. Obviously, holes in the Flatpak sandbox should not exist either, again for entirely obvious reasons.
Catanzaro proposes a number of solutions to all of these problems, which require work from both Fedora and Flathub to be implemented. On top of that, even once these issues are satisfactorily addressed, there’s a debate to be had over the exact way in which both the traditional and immutable variants of Fedora move on over to Flathub – the variant I personally like the most is where the core applications installed by default remain in control of Fedora, while everything else gets installed from Flathub.
Of course, this is not of much relevance to people who prefer plain, traditional RPMs – such as myself – to whom Flatpaks are more of a “if all else fails” option than a default. While the immutable, Flatpak-based variants of Fedora are definitely on their way to become the default option, the traditional RPM variants will not be going anywhere, and will remain an option as well. I think defaulting new users to the immutable variants is the way to go, even if I personally won’t be using them.
Well, this may not be popular but…I disagree.
To grow into a mainstream OS, Linux needs to be a platform. I need to be able to publish an app for Linux and have it work on all Linux systems.
[Two pages of content removed because it was just way too long.
– we need a Linux appstore, even for paid apps
– it has to be an attractive place to publish
– rather than hard rules, we should have flags. Fedora and users can select restrict their choices if they want
– in particular, allowing old runtimes and even dependencies is absolutely essential
]
We need Flathub to provide the experience that Windows users enjoy. If I get an app from Flathub, it will work on my system. We need to leverage the power that containers bring us on Linux. Debian users can stay on their ancient software versions but still get software that requires newer runtimes via Flathub. And Arch users can use Flathub to get more stability in critical apps they depend on. And all of us should still be able to use that one proprietary app that we use every day that the author stopped publishing 15 years ago.
Fedora was always its own thing, catering to people who like complete build reproducibility and removal of every feature that could be liable to a patent lawsuit (it’s the reason they dropped GPU video decoding). But for every other distro, I agree.
> We need Flathub to provide the experience that Windows users enjoy.
That’s exactly what they’ll get:
unauditable systems running outdated libraries; no respect for global themes and configuration, with each app doing its own thing; making it difficult for the end user to swap out an underlying library and replace with a custom fork (as required by the LGPL3).
Flathub is a displacement of trust from the distribution to individual software authors, who pinky swear that they’ll play the role of a distribution team and keep track of bugs in their dependencies.
One thing flathub does orders of magnitude better is isolation, I’d love to see that in some form for natively installed software.
Well, this is what most people want: They want to get a piece of software from the author just like they buy a thing from the store, they don’t want middlemen “repackaging” things (with all the delays and non-support for old LTSes this brings) or even worse removing things from the application (some distros remove libdvdcss from VLC for example). It’s up to the author to update dependencies, not the OS vendor.
Even application stores like the Play Store, App Store, and Steam give authors the freedom to upload binaries: they don’t demand access to source code and don’t repackage anything (they scan the binaries automatically for malware, which is the equivalent of running physical goods through an X-ray scanner, but that’s it).
kurkosdr,
I agree with this. In general it should not be necessary for 3rd parties to change the author’s software. Of course there are pros to centrally managed repos, like synchronizing dependencies. But it takes a lot of effort and doesn’t scale well. Users often end up stuck on old versions because of dependency issues and having to wait for repos to do the work to update their end after the authors do. It’s better that authors be the only party responsible for updating software.
That’s not to say 3rd parties don’t have important roles to play. They are very useful for search/directory services and vouching for cryptographic identities. Centralized parties shouldn’t have unique privileges at the OS level. Users should be able to switch them like switching search providers. As for the software distribution itself, I’d prefer something decentralized like bittorrent over centralized provider like flathub.
TBH they aren’t ideal either. I’d like to see us get away from centralized repos/app stores. Decentralized software distribution is more ideal and much more robust against things like lock in, censorship, walled gardens, etc.
About UI consistency, this problem had been solved by OS themes. Using Qt4, you could create an app that used the native APIs of each OS and hence used the OS’s native theming engine (from Windows 2000 to Windows Vista and from Solaris running CDE to Ubuntu running GNOME), but then the cool kids of Silicon Valley decided that native APIs are passe and everything should be an HTML webpage or an XML layout it should look the same everywhere. This happened around the smartphone boom era, when lack of multitasking by iOS (and weak multitasking by Android) meant the application had the entire screen to itself for extended periods of time. This is also when large platforms like Deliveroo and Uber started to appear and they wanted their brand to be the same everywhere. So, it wasn’t long until this trend started appearing on desktop apps too (first with Electron apps, then with native apps), because modern tech is about copying ideas without understanding why. The fact themes are handled at the app library level is insane.
Do you remember Nero burning rom? Avast 4 [2] ? This started looong before the iphone. Everyone wants to be special.
And once you say “UI is in the OS” , the “release once, run everywhere” requirement is dead, because different versions will have different widgets available. (I wrote UI for MacOs in swift for a few years. Availability is per OS version)
[2] https://news-cdn.softpedia.com/images/news2/Avast-Antivirus-Updated-Download-Included-2.png
On top of that…
Native random chat application: few MBs of RAM, snappy.
Electron random chat application: few GBs of RAM, lags on typing, constant high CPU background usage god knows why.
> Fedora needs to embrace Flathub
I would be extremely wary about allowing flathub such a central position for software distribution.
On a side note: what’s up with such projects being cute about what entity manages them? Click on the “about” page and it’s all about “the team”, “the community”, and such meaningless babble, with no mention of what sort of entity one is ultimately dealing with. For all I can see, it could be microsoft or, worse, gnome pulling the strings behind the scenes.
It 100% is GNOME. You can see that the “app of the day” is always some libadwaita GTK4 Gnomeshit. That’s because the Flathub “guidelines” to be a featured app are essentially to follow the GNOME guidelines.
If Flathub ever starts taking payments for apps, this will just encourage developers to develop only for GNOME so that their apps get featured. It’s got the potential to be another EEE project from GNOME.
I would actually like Flathub to succeed as the main Linux “app store”, but it must not be controlled by GNOME or Red Hat.
@j0scher
Red Hat is already pulling the strings. This is all just sheep herding.
I am ok with it though. The primary pathway to Red Hat dominance is contributing code. Works for me.
And, I would benefit greatly if Linux was a more successful platform (even though I use a very off-beat distro). So, I want a Linux App Store to succeed. I do not like most of the choices made in the freedesktop platform (the Flatpak runtime) but standardizing on the most popular and successful parts of the Linux ecosystem makes lots of sense. If that means GNOME apps, I am ok with it (even though I do not run GNOME as a DE).
Will the world write commercial apps in libadwaita and GTK though? Qt seems more popular with paid apps today. Electron is used a lot. If Adobe were to release Photoshop as a flatpak, would it be written in GTK? I would like to find out.
@Mote
The are being cute because “the community” is a critical part of the corporate strategy. Remember, Fedora was created by Red Hat precisely so that they could go full commercial with RHEL. Red Hat has controlled Fedora since inception via “community” contributors that work for them. And the strategy has worked brilliantly given all the concern we see about “Red Hat taking Fedora commercial”. This shows that people believe that Fedora is completely independent and do not understand how Fedora and Red Hat work together at all.
Who is the number one contributor to GNOME? The number one contributor to Flatpak? That would be Red Hat and Red Hat.
This goes to show that Linux fragmentation problem has as much technical as political underpinnings. Owning the voluntary work of packagers (by making it not directly applicable by customers to competitors products and maintainers) is part of how distribution companies define their equity to investors. It’s a sort of commons that they fence.