The Future of Flatpak

Desktop is not a large market for Red Hat. Even their employees mostly use Fedora.

The only place I really see RHEL workstations is in special purpose applications, and in most of those the users either have a separate Windows box, or they Citrix/RDP into the corporate Windows environment to do normal office productivity things anyway.

Given the target of RHEL, I can’t say that I disagree with their decision to not package those applications for RHEL 10. RHEL isn’t really designed to be a user desktop. Ever since RH split out workstation and server versions of the OS, RHEL has always been targeted for servers. I don’t think the lack of an office suite will really be that impactful towards users.

This is just made all the more true if there is an alternative source for these tools, like Flathub.

> There's just one problem: they don't integrate with desktop without an additional application

Their biggest problem is that they're not actually truly portable between distributions. They're a gamble of what they're compiled and bundled against, and it's possible for two distributions to not have binary compatibility with each other due to user space differences (different versions, compile flags etc). The kernel developers may not break userspace between updates, but userspace developers certainly have no qualms about breaking userspace.

When you head out of Ubuntu/Debian where developers often build AppImages on (because Linux is a neglected platform and when they think Linux they think Ubuntu), they often fail to run or have errors (e.g. on Fedora). There's more problems such as the terrible practice of encouraging people to set the execute flag on binaries they download off the web.

Flatpak avoids the dependency problem entirely because it's uses runtimes and namespace to ensure reproducible and stable runtime environments.

For desktop integration you can use Gear Lever https://github.com/mijorus/gearlever. It can also update AppImages with some configuration changes.

I disagree. Flatpak pros:

- installing: easy to locate, install and has centralized management for updates.

- flatpaks are also persistent. User-installs are in the home dir.

- sandboxing built-in.

Can't comment on other stuff. Haven't had issues.

on Ubuntu you can integrate Appimages with AppImageLauncher.

https://www.omgubuntu.co.uk/2022/10/appimagelauncher-install...

I've found AppImages less universally functioning, though. Some segfault on start or have some other weird problems later, while presumably they work great on the author's system.

They seem to work on my current systems, though, and I use a few, but flatpak has always worked on any system, and I expect it has higher chance of working as it delivers more of the system.

> I find Appimage to be better alternative to Flatpak

Me too.

But there is a "bigger picture" view of this which I think is important and relevant:

• AppImage encapsulates apps' requirements using the app bundle format from the ROX desktop: https://rox.sourceforge.net/desktop/

• ROX borrowed the idea of app bundles from Acorn's RISC OS, which is still around and is FOSS now: https://www.riscosopen.org/content/

• The RISC OS desktop treats folders whose names begin with a pling (`!`, an exclamation mark) specially. It expects a structure inside with an icon, a launcher script, etc.

• RISC OS also had an "icon bar", a forerunner of the Windows taskbar

• One of the Acorn engineers who worked on RISC OS was head-hunted to NeXT Computer in California. He took his Archimedes with him.

Source: an interview I arranged: https://www.theregister.com/2022/06/23/how_risc_os_happened/

• About a year later, Steve Jobs demonstrated NeXTstep 0.8 with a Dock

• NeXTstep also has app bundles, demarked by a folder called $NAME.app instead of !$NAME

This is a pervasive and influential idea. It's how macOS apps work and that can be traced to RISC OS.

NeXT style bundles are available and work on Linux if you have GNUstep. There are 2 extant GNUstep desktops:

https://onflapp.github.io/gs-desktop/index.html

https://github.com/trunkmaster/nextspace

But there is a distro which takes this idea much further and packages the _entire Linux OS_ in app-bundle directories:

https://gobolinux.org/

I think the makers of Flatpak, Nix, Guix, and Spack -- https://spack.io/ -- all really ought to take a deep look at ROX, AppImage, and GoboLinux.

What all of these do can be done better, in a more human-readable way, if you throw away ancient UNIX assumptions about filesystem directory hierarchies.

This was mostly not designed and was in historical fact accidental anyway:

https://lists.busybox.net/pipermail/busybox/2010-December/07...

Even for apps that don't use one of the native toolkits like GTK or Qt, where this has been a solved problem for decades, they should at least respond to a dark/light mode flag if they can. Flatpaks mostly don't.

They don't even have the same cursor as the system a lot of the time. It's especially cool when running display scaling when some apps shrink the cursor to a minuscule size too because of poor system integration.

I believe it doesn't work for me to open a directory of HTML files in Firefox: it just opens one file, and that's it, so style sheets and links are missed.

I've worked around by running a local web server for that content, but I'd rather if it just worked. The problem is also in some apps that open web browser for their documentation by invoking them directly.

If the apps inside need to be specifically coded for it, then why is it "marketed" as a way to sandbox currently existing apps?

Ubuntu's Snaps depend heavily on AppArmor which is not present in many of the other top-tier distros which use SELinux, so it's not an alternative.

Different answers for different problems, but basically two reasons.

First, library/software/data versions inside the flatpak can and will be different from the ones outside. So a flatpak might as "what is the current Qt5 theme", and get the answer "don't know about Qt5, but the Qt6 theme is cute-cats-qt6" which it cannot interpret. Things like themes might not even be available inside the flatpak, so even if the answer were parseable, cute-cats-qt6 might just not be available on the inside.

Second, flatpaks are sandboxed, so things will be filtered. This means that a query might not get through, an answer might not get through, both might be altered. Or maybe an answer might be useless because "you can get the theme at /usr/share/themes/cute-cats-qt6" points to a path that the flatpak is not allowed to access.

I don't actually know but I guess the issue is that the theme/gui libraries are sandboxed too

I think that because a lot of gtk apps use gvfs[0]. And most kde apps use kio[1]. But if you want files access through the standard syscall. You have to use the standard mount program or fuse.

0: https://en.wikipedia.org/wiki/GVfs

1: https://en.wikipedia.org/wiki/KIO

Thanks for answering.

The threat model for a programmer is likely much more complicated than for a regular user, but not related to sandboxing.

Regarding the "server facing the internet is real", I am not sure I get your point. Could you elaborate?

The point you make about portals and how the support exists but neither Flatpack/IOS or Android ecosystems get it right is very revealing: when nobody gets it right then it likely means the design is broken. Even Fuscia failed and it was an OS built from scratch to focus on userspace isolation and contracts for IPC and syscall.

Anyway it is very unfair to the users when designs supplant existing ones breaking things that used to work. Again we are talking about very basic computer usage patterns that have existed for several decades.

> I think Flatpak can do this, but almost no one does it.

Flatpak can do it poorly. What I see is opening a file for read once gives the sandboxed app write access to that path name forever.

> That is the problem, though. It was never yours. It belonged to app developers, some of them potentially nefarious.

But it has been mine for decades and nefarious developers somehow weren't a real issue in my distro's repositories for this whole time. It's a self-inflicted problem.

Only fedora can put stuff in their flatpak repository presumably. That makes them a gatekeeper. Why is a repository needed? If it was the same, Mozilla would be able to put a flatpak file for Firefox on their website and it would be the preferred way to install Firefox.

Of course everybody (including Mozilla) can create their own repository and then you can install from any repository you like. But how is that different than just downloading whatever and installing that? And that's more of a hypothetical. Mozilla doesn't do that and doing such things is not common.

What Apple and MS enforce via signatures is that what you install and run was produced by somebody with a valid certificate that passed their screening.

The problem flatpak hasn't solved is that the likes of Mozilla still have no good way to distribute the most recent version of their application to all Linux users. So they put a tar ball on their website instead.

> Package maintainers aren't born that way, they become that way by volunteering, just like most everything in Linux.

I feel like there's a constant tug of war on this issue. If you leave it up to app developers then they have to package their app for N distros. If you leave it up to the distro maintainers then they have to compile N apps for their distro. I don't envy either group given how different distros are and how varied apps are in quality, methodology, etc.

I look at Podman. In my opinion it could be (could have been?) a huge disruptor, but its RedHat (or Fedora or CentOS or whatever the hell those guys do now) versions are way higher than versions for other distributions, which creates for me (just a home user) an interoperability problem between all my different Linux boxes. RedHat if anybody has the resources to fix this but I guess they'd rather try to use it as a way to force adoption of their distro? I don't even know.

Both the apps and the distros are volunteer-heavy. App packaging is a big job for either side. I'm still hopeful that Flatpak can help that job

That's a massive waste of resources and time.

If you are unwilling to use tools like Flatpak, then that limits what distros you can make. e.g., in a world without Flatpak, only distros with X users can exist. In a world with Flatpak, distros with X/10 users can exist.

Another way to think about it: if you want to make/use your own distro, then using Flatpak will cut down the amount of work you have to do by some large multiple. You're free to not use it, just like you're free to install custom electrical sockets in your house and make custom adaptors for every single appliance you buy.

Standardization/centralization exists for a reason.

> distros should package for themselves. You just distribute your sources.

Is Devault basically saying that the application developer should just throw their source code over the wall and hope that other parties notice and figure out how to build it correctly? I would find that model of software distribution unsatisfying as a developer because merely distributing a source tarball and leaving the rest to middlemen makes it difficult for me to predict how my users will experience the final product. Even if my product is fully open source and free to fork, it's my reputation on the line when things don't work as intended. I would prefer to establish a more direct relationship with my users; to personally build and test my software in all environments that I support; and to hear directly from users whenever they experience problems.

> distros should package for themselves. You just distribute your sources.

That's how you ended up with Erlang being split into 20+ packages on Ubuntu/Debian in the past. Because it was packaged by people who know little about erlang, and had too much time on their hands probably.

And that is the main issue: you want distro maintainers to compile and package every single pieces of software under the sun, but they can't possibly know every piece of software, how it works, or how it's supposed to work. Times that by the number of distros.

Flathub is not unvetted. Every submission goes through human review. If a piece of software requires an unnecessary permission (i.e. if someone submits an alarm clock program that requires home folder access and internet access), it will get rejected. If a developer updates their software and changes the required permissions, the update won't get pushed to users until it goes through human review.

Besides this, for open source packages, the code gets built on Flathub's build servers without internet access. The source code associated with a given Flathub package version must be either a specific Git commit (verified with a commit hash) or a release tarball (verified with a sha256 hash). This means that it's always possible to verify that the code a developer publishes corresponds to the binaries being shipped to users. Closed source packages get a big warning on their Flathub pages saying that the program's code is proprietary and not auditable.

With the traditional distro packaging model, the requirements to become a maintainer are stringent and there's human review when a package is added, but there's typically no review after that point. If you'd like a recent example of the drawbacks of this system, see here: https://security.opensuse.org/2025/05/07/deepin-desktop-remo... . After the OpenSUSE security team rejected certain components of the Deepin DE for containing major security problems (including multiple root privilege escalation vulnerabilities), the Deepin maintainer smuggled them in anyway through an innocuous looking package called "deepin-feature-enable" and nobody in the security team noticed for several years. I'm not trying to call out the OpenSUSE security team here, I'm sure they don't have the resources to vet random packages. I'm saying that expecting maintainers to never ship malicious code because they went through the process to become a maintainer is a weakness of the traditional distro packaging model.

Distro package maintainers are not security researchers, they don't audit the code they maintain.

> Now I can run my latest user softwares on a stable distribution. That’s pretty cool.

I'm at a bit of a loss. Isn't the entire point of a stable distribution _not_ having cutting edge userspace? It's an inherently double edged sword.

If you just wanted to mix and match you were always able to run (for example) a debian testing chroot under debian stable. Something like Nix is the more extreme version of that. The point of something like Flatpak then is either sandboxing or the distribution model (ie getting software from the original author).

But those are even worse from this point of view, I have no control over which apps can access my camera, or microphone.

I'm personally disappointed that sandboxing isn't easier in Linux. I hoped it would move past Windows and Mac, imagine a world where the majority of libraries are sandboxed too, we only let compression and decompression libraries read one stream and write to another, this would improve security. This has been done by both Google (in Android) and Apple (in iOS and Mac OS X), but hasn't seen general acceptance in Linux (as far as I can tell).

if they were working fine there would be not need for flatpak

Many Ubuntu or Debian users still use Flatpak, don't they? Even though there's already apt-get.

>Flatpack is a weird extra layer on top of Linux

My brother in christ, systemd, x11 and even GNU are weird extra layers on top of Linux. Linux is just the kernel. This is exactly what "redefining Linux so it's never responsible for 99% you need to put on top of Linux to have a functional modern OS" is about.

There sort of is, but you can't do anything with it, because you essentially have no user space utilities?

For all of the crap that people gave the term "GNU/Linux" it's even more true today considering there are Linux-based operating systems that don't use GNU utilities.

gjsman-1000 talks about "design flaws" in Linux above, but Linux is just the kernel. There is no "Linux" operating system, despite everyone, and even Linus probably? using that term.

If you call booting init and getting a black screen "an operating system," well... that's cool I guess.

I doubt Linus ever talks to the GTK people in any meaningful way, or any other desktop environment authors. So, what design flaws?

Do you call a ladder a badly designed scaffold because it doesn't have a horizontal platform? No, it's just something entirely different all together.

Why does that matter? Copies of a few libraries is just not a problem.

This isn't a bug. Kmcaster is unmaintained and has been removed from flathub.

[0] https://flathub.org/apps/com.whitemagicsoftware.kmcaster

It comes up as dry because the package is marked as unmaintained

https://flathub.org/apps/com.whitemagicsoftware.kmcaster

https://github.com/flathub/com.whitemagicsoftware.kmcaster/p...