There is one specific way in which the non-corporate open source projects typically document how their infrastructure work: not at all, and Flathub is no different. The full picture likely lives only in my brain, and while it could be sorted out by anyone (especially in this LLM age, yay or nay), why should it only be me thinking at night about all the single points of failure?
Like any system that evolved naturally, it’s all over the place. It’s tempting to tell its history chronologically, but even then, it’s difficult to find a good entry point. Instead, this post focuses on what happens when users call
↫ Bart Piotrowskiflatpak install; later entries will cover the website and, finally, the build infrastructure. Buckle up!
As time goes by and more and more issues with Flatpak are addressed, I feel my attitude towards the technology change somewhat. I’m still very much a traditional package manager type of person, and will opt for my distribution’s repository if the versions they have are up-to-date, but I’m no longer audibly groaning if an application I want is only really available as a Flatpak. For the increasing number of normal, average users switching to Linux, Flatpak is probably the right way to go, especially since it can easily coexist with your traditional package manager.
The only part of the linked article that made me raise my eyebrow was the reliance on Fastly, which seems to form an important linchpin of the whole Flathub stack. Fastly is an American company, and while they support Flathub entirely for free, the state of the world does have me wonder if this couldn’t evolve into a problem in a myriad of ways, perhaps through questionable people acquiring Fastly or through pressures from the clown car US administration.
I’m sure it’s all fine, but it’s hard not to think of these things in this day and age.
The article says that they currently rely on Fastly. It does not say that they *have* to rely on Fastly in the future. But yes, interested minds wonder how prepared they are for a migration to a different CDN vendor, should the need arise.
Massive downloads. These formats are wasteful, costly, and contradict the original efficiency philosophy that Linux was partly about. People are on fixed download quotas. Who wants to waste 5g of that on a few editors and a messaging app?
Shifu,
You’re absolutely right, yet despite those drawbacks for flatpak/appimage/etc, 3rd party software on linux isn’t well served by centrally managed repos. If linux ought to support 3rd party software, then self contained application bundles like flatpak help address longstanding problems with the centralized repo model. Steam came in with their own proprietary installer for their game catalogue and it works well, but it’s proprietary and doesn’t solve the problem for 3rd party applications more generally. Some linux software publishers took the idea of using application installers from windows, but frankly that’s a poor practice and it’s an antiquated practice that should be discouraged even on windows.
So even though I agree with your points, flatpak is still useful for distributing software that’s not covered by the distro’s centralized repos.
Just a minor nitpick:
Flatpak isn’t fully self-contained; the Flatpak base infrastructure is set up after downloading your first app through the service, then a lot of that infrastructure is reused for future downloads’ dependencies. It’s actually pretty efficient for a bundle-based system, but it’s not truly self-contained in the sense that you can’t just randomly download and execute a Flatpak bundle without that infrastructure in place. Still, there really is a lot of extra support stuff that is duplicated within each Flatpak bundle, making every download bloated compared to native packages.
Contrast to AppImage, which is a truly self-contained application bundle; on pretty much any distro you don’t have to install anything beforehand, just download the bundle, mark it executable, and launch it. This has the obvious downside of even larger bundles than Flatpak, and a lot more duplication of support libraries and other files for similar applications; they can’t share each other’s bundled libraries. Still, it’s even easier to use than Flatpak and is a good backup for a Flatpak user whose favorite software hasn’t made it onto Flathub yet.
Honestly I’m with Thom on all of this; the distro’s repository should always be one’s primary source of software as it is tested and vetted to work on the distro. With that said, when I ran Void Linux I relied on Flatpak for Pinta, because no one packaged it for Void (likely due to the nightmare that is Mono development) and I’m not experienced enough to package it myself and submit it. Thankfully OpenBSD has Pinta available as a package, and even better, it’s the older version before the GTK4 rewrite.
Morgan,
Yeah, perhaps calling it self-contained was problematic. You need the standard base dependencies to be satisfied, but any additional dependencies are bundled. It’s a lot like android or steam where there’s a standard base system and other dependencies get bundled.
AppImage packages are also dependent on some platform dependencies, such as gimp’s appimage requiring debian 13 or above, earlier versions of debian don’t have the dependencies that the gimp appimage was designed for. Although now this makes me curious how big the difference is between these different formats in practice. It would be interesting to investigate this further.
I tried looking up other posts about this and found sources with different conclusions, haha. I believe they’re all looking at the install size and not the package sizes though, in which case obviously flatpak will loose because files are uncompressed at install.
computingforgeeks.com/snap-vs-flatpak-vs-appimage/
phoenixnap.com/kb/flatpak-vs-snap-vs-appimage
baeldung.com/linux/snaps-flatpak-appimage
I haven’t tested runtime performance and I’m curious which would generally launch fastest from a fresh boot.
It’s not that I oppose using the repos, but they fall short when you need things that aren’t in them and I’ve grown tired of building 3rd party software and dependencies for myself. So I increasingly use flatpak and appimage versions of software when I need to run software/versions that aren’t in the repo. It’s often the easiest and fasted way to get what I want. For example VLC on debian was intentionally scrubbed of some RTSP library that I need to access my security cameras over licensing issues. The upstream version of VLC works as expected. Installing the flatpak version of VLC was a quick fix without the headaches of doing it manually. Another time I installed a CANBUS packet analyzing program that wanted several bleeding edge dependencies that just weren’t in debian stable. The appimage version of it bundles the needed dependencies and just works with no fuss.
They’re not perfect. but they do save so much time over having to do things the old way.
When I ran Debian in the past I always ran Sid for access to newer software and libraries, is that not an option for you? I know Sid is the “unstable” branch but it was always extremely stable in practice for me. That was many years ago though, I haven’t ran Debian or a Debian-based distro as my main in over a decade, apart from Raspberry Pi devices here and there.
Morgan,
Possibly, although given that I oversee production environments, there’s a reason we use stable. It’s technically possible to Frankenstein a solution whereby Debian Sid packages get installed into Debian Stable. However the result can be even less stable than Debian Sid – not that it’s Debian’s fault. It would be pretty cool if this configuration worked reliably and apt could manage it better than it does. Containers like docker (or indeed flatpack) are probably the most robust way to get different versions of software running with the least effort.
Lately it seems my posts are more likely to be auto-moderated even when I remove links.. Is there a way to tune the sensitivity down for long term users?
I haven’t had this issue in a while here, but yes it would be nice if any accounts with, say, a year or more lifespan and at least a dozen or so posts aren’t auto-moderated, links or no.
This one’s new. Where are people getting their Linux philosophy from?
Sorry but that’s nonsense.
You don’t have to download “5g (sic) of that on a few editors and a messaging app”.
First: nobody forces you to use it if you don’t want or can’t.
Second: thanks to compression, shared runtimes and delta updates you don’t have to do a full download on every update.
(Unlike most traditional package managers, delta updates seem to be a sore spot for them)
My only quirk is the amount it leaves behind. At some point, I wanted to upgrade my Librem 5 and had only 1GB free. Even after removing all flatpak apps I still couldnt free up space. Nuking it from orbit freed 8GB. A lot of unused stuff that stayed even after the application that required it got upgraded or removed.
🙁
I don’t use many flatpak apps but my regular routine includes `sudo flatpak uninstall –unused`
Note: I use `sudo` cause I always install flatpaks on system level, I don’t like to have applications in my home folder.
I prefer native packages, then Flatpak, then AppImage, then Snap as an absolute last resort. Unless I’m in a hurry, I’ll try building from source before re-enabling the Snap service.