This post isn’t a problem report or request for assistance. Rather, it’s an attempt to discuss flatpaks vs. rpm package management and the applicability/viability of each on various types of Fedora installs.
As a long-time user of Fedora, I’ve watched, with interest, the growth of immutable Fedora systems (Atomic). Flatpaks seem to make sense on atomic installs, as they’re simpler to install/manage than RPMs (which need to be ‘layered’ on top of the installed image).
However, I don’t really see the value in using flatpaks (unless the underlying software is unavailable as an RPM) on (for lack of a better term) ‘mutable’ installs. For such systems, flatpaks seem to be an additional area of management and troubleshooting on top of the DNF/RPM package management platform.
Is that really the case, or am I missing something important here? What preferences do you (the general ‘you’) have around rpms vs. flatpaks, as well as ‘mutable’ vs. ‘immutable’ installs?
Availability is most certainly the elephant in the room.
There is versioning within the flatpak system extending general availability by facilitating dependency chain isolation allowing different apps to use different versions of the same libraries without wrecking one another or the host system.
System friendly in that flatpaks are installed in a “containerized” environment and not the host “core” system (root file system) reducing risk to system stability and normal ops.
One use-case for flatpaks is where a geographically diverse collection of users with different distros/releases (some typically working for large enterprises that only allow one linux distro and differ in schedules for new releases) need to minimize differences due to distro packaged versions/configurations.
Fedora flatpaks are built from the same sources as rpms, distributed by Fedora. So that statement is only true for flatpaks from flathub or other 3rd party repos.
My experience with Flatpaks is from a Fedora Atomic desktop user perspective, so I might be biased, but here are some reasons in favor of Flatpaks:
Higher availability of apps (already mentioned). There are certain non-specialized apps that make the general desktop usage experience richer, but are only available as Flatpaks from Flathub. A couple of such GNOME apps would be a task manager, a simple app for annotating screenshots, an RSS reader maybe, etc;
Apps are often built by the app’s maintainer/developer (some users might prefer that);
Faster access to apps’ latest version;
Sandboxing (when applied properly);
Better communication on issue reporting, since both the reporter and the developer are accessing the same (latest) version of the app in the same environment (i.e. using the same runtimes).
Note that the above reasons apply to Flatpak apps from Flathub, since Fedora Flatpaks are built from their corresponding RPMs.
From a strategic perspective, there are also arguments for decoupling the base system from GUI applications, also given the usual shortage of maintainer resources.
From a strategic perspective, “decoupling” means distributions don’t distribute anything but the base “immutable” system and anything else at the user level is distributed by somebody else, via the “store”. Where did I see that already?
The answer to the above question is “none”.
Flatpaks don’t have ANY advantage over “native” packages, and/or the advantages aren’t on the user side. Actually it is some sort of “copying” solutions from the usual “big firms” like the “setup.exe” and it is the same answer to the same question, which again is not on the user side.
I would also add that the “sandboxing” is both a lie (because it isn’t enforced from above, it is self-applied) and useless (because ideally the immutable system, which is the main reason for this thing, is read-only). Oh, then it is not “the developer” it is somebody who owns a channel on the “store”. Same as extensions with the same issues.
Not every software can be shipped as RPM in the default repository: because it is too niche, for licensing reasons, because it uses obsolete libraries, etc.
In some cases you may add an external repository, which tends to end with a broken system or a catastrophic failing when upgrading. In other cases, you may compile the code yourself, or use appimage, or install scripts. Neither of these is better than flatpak.
Flatpak also allows an isolation that rpm packages does not. I.e. I feel much more reassured when running a random app from the internet if it is in flatpak form, because I can block it from accessing my filesystem.
Also, nobody is forcing you to use flatpak, there is no service running when you’re not using it, the base installation uses less than 10MB, and you can even uninstall it if you want. I really do not see why it would be such a problem
I would correct this in “not everybody wants or can distribute software as RPM”.
For example Mozilla recently opened repositories to distribute Firefox as APT and RPM and it was needed because “snap” and “flatpak” do not solve the “how to distribute to the masses” issue while adding several other issues with the integration of the browser in the system.
So now the question becomes "what should I install on my regular distribution, the “snap” or “flatpak” Firefox or the APT and RPM Firefox? My answer is there isn’t ANY need for the “snap” or “flatpak” packages besides the “immutable systems”. Frome the user’s perspective, given she/he is not using an “immutable system”, the “native” packages are BETTER from any point of view.
Yes, there are software that aren’t included in the distribution repositories and you can get only from somebody else as “snap” or “flatpak”. That is not “better”, it is the less evil. Which should be reduced to the minimum, not advertised.
Just for completeness: there also exist Nix and Guix package managers. They add several advantages to stock distribution package managers:
coexistence with distribution’s packages (Nix/Guix use their own unique installation path outside standard system directories)
because each package has unique path there can be installed many different versions and even flavors of same package at same time
transactional updates using “profiles” (set of links to “active” packages) that can be easily switched - providing installation history and safe rollbacks).
multiple profiles can exist (multiple set of symlinks) - so you can have open several shells with different sets/versions of packages - without conflict.
no container overhead
Disadvantages of Guix/Nix:
weakens SELinux (or AppArmor) protections due way how these packages are installed
same (lack of) protection as with regular package manager - no additional isolation
have to be careful running simultaneously multiple versions of packages that have lot of stateful data in HOME (Firefox, etc…)
Personally I use Guix package manager to install packages that are missing in stock distribution, e.g., keepass …
If RPM CoW ever gets finished, one advantage that RPMs will have over Flatpaks is Packed Object Repositories. Essentially, your typical “dnf update” command will work more like rsync and it will only have to download the parts of the RPM packages that have changed. There should be (much) less to download whenever you need to apply updates. This means system updates will be faster and there will be less wear on your SSD since there is less data being duplicated.
I don’t know why the “sandboxing” is always brought as a big thing. It is not. The problem is the sandbox makes sense when there is some external mechanism that cannot be touched and defines the boundaries for the software that sits inside the sandbox. In our case there isn’t any enforcing from outside, it is the same self-contained package that brings its own permissions. That means the good software will come with nice and fair permissions and stay confined in the sandbox, hostile software will come with settings to escape the sanbox. Yes, I install some softare with the “good software” permissions, then something happens from inside the said software, maybe it stays confined (like, I don’t know, a browser with remote code execution). It does not work when I install “cool app xyz” from the “store” and it is designed to access my data (like any malware).
Another big misconception is the “immutable” system is “safe”. It is provided as read-only image, so it will always work regardless the changes the user (willing or not) applies. Problem is the system is going to boot but anything the user can read and write can be accessed, overwritten and deleted and in my opinion that is the opposite of what I need since I don’t mind to re-install the system if needed but I can’t afford to loose my own files, it is not the system that should be safe, it is the user.
So on one side we don’t need anything “immutable”, we need backups, on the other side the “immutable” systems do have one single user-case that is the corporate environment where they need to deploy several workstations and “the user” is never “the admin” of the same machine.
In other user-cases, when “the user” is also “the admin”, both immutable systems and snap, flatpak and alike, do not have any advantage while bringing several disadvantages. I have already written about the change in philosophy from “distribution” that distribute lots of packages at any level and “distribution” of the sealed system when anything “user” comes from a third party store. And, of course, the same consequences we got in Windows since ever, meaning “the developer” distributing software (and making changes to the system, accessing user data) without anybody in between.
Taking a different perspective, a developer may prefer flatpak because they will run on a wide variety of distributions. Some niche applications may only be available in flatpak for Fedora.
In addition flatpaks are run in a container which offers better security.
It is true that some packages will be duplicated across multiple applications, the upside is that there can’t be a conflict with regard to the version of the package needed for the app to run, it comes with what it needs to run..
I believe there are some tangible benefits to flatpak: one being the permissions system (more on that later) and the choice (when enabled) to access a large 3rd party repository like flathub…if you need ‘non-free’ codecs a number of apps come with those without needing to add them in manually (the steam flatpak being an exception).
If you are using KDE, you have the permissions system baked into the desktop, so you can see and manage exactly what the software has access to on the system. On Gnome though you will need the flatseal flatpak to control these toggles. Use example: many apps default to internet functionality being turned on without much user control over when these connections are made or how often. With just checkbox on KDE I can turn that on/off without much trouble at all. With RPMs, imagine opening up 5-7 different apps and all of them are making internet connections on startup or throughout use that you did not ask for and did not need, not my cup of tea. You can also choose to manually limit folder access through portal permissions (Example: add ‘xdg-documents’ to the permission system to limit an app’s access to only your documents folder).
Something else to consider: If your app crashes it is much less likely to take something from the system down with it - if it is a flatpak. You are not relying on the system for runtimes…let’s say an rpm (perhaps third-party) app does not play well with a certain system runtime after a system update. You either have to rollback some stuff or wait for these to play nice with each other sometime in the future. With a verified third-party flatpak, the included runtimes are what the developer specified to ensure functionality of the software and that version stays until the developers are ready to update it = fewer system vs app conflicts.
For me personally running fedora workstation. Flatpaks when used appropriately in combination with RPM packages provides a far more stable, and in some ways a cleaner system in a sort of round about way. As well as aiding me greatly with overall system management, while also providing a bit of added security. The way i personally manage my system currently is that i only install rpm packages when the application has a legitamate need to directly interface with the core filesystem. Ie the applications that need hardware acceleration like obs studio or video editing software, or cli tools or if the application just performs poorly in a flatpak like steam or is only available via rpm. For everything else i use a flatpak. In my view this provides me with a more stable system that is far less likely to break during an upgrade because i dont need to ultilize very many third party repos which can and often will cause problems during an upgrade to a new version of fedora and possibly even break your system completely. Im also at a refuced risk of a bad update pushed by a developer of breaking my system and with the latest supply chain attacks im at a lower risk of a developer inadvertantly pushing a tainted package directly to my core filesystem. Utilizing flatpaks for basically of the random little apps i want or want to try out helps to provide a bit of extra security with the sandboxing as long as i manage my flatpak permissions well which i do and i also dont install software via flatpak that gives itself extra permissions the software doesnt need to function properly. If a flatpak gets pushed a poor update it breaks only the flatpak and i can simply just unistall it and use an alternative software. It also aids in system management because i dont have to grep through an inordinate number of packages and dependencies when going through my system. I can simply just run flatpak list and have a short concise list of all the random little apps i have installed and due to the small number of rpms i have i just know what i have installed via rpm for the reasons i listed above earlier. In my experience most flatpaks are also updated more frequently with users usually getting the latest software version via flatpak before it hits official repos. Tldr I like flatpaks because they provide a bit of extra security, keep my system segregated and easier to manage and make my system more stable during major upgrades as ive learned the hard way in the past having a lot of third party repos installed at some point generally leads to needing a fresh install and i have not had that issue since switching to my new method of system management utilizing flatpaks appropriatelt in combination with rpm packages when appropriate.
While Flatpak apps do include their own dependencies, labeling them as inherently wasteful is inaccurate. The system uses shared “runtimes” and smart de-duplication. While they bypass the host’s system libraries, they intelligently share resources with other Flatpak apps. While there is a slight, initial storage overhead when you transition to your first few Flatpaks, the footprint Amortizes significantly as you install more software. Because multiple versions of different runtimes can accumulate and cause unnecessary storage bloat, you can easily reclaim disk space by routinely running flatpak uninstall --unused in your terminal.
Whether it’s Flatpak, or containers run with Toolbox, Distrobox or Podman Desktop, I like the separation from the main system.
I can install and then remove a Flatpak, and the impact to the base system is minimal. If I want to use LaTeX for a while, I can either add a few hundred packages, or have it all contained within the Flatpak and easy to nuke at any time.
It’s the same (for me anyway) with programming runtimes and compilers. It can be a lot of packages. I do it in a Distrobox, and I can easily just toss that container and start over with any distribution I wish.
This is the way in atomic systems, but it’s not a horrible way to do it in a traditional Linux system.
Flatpaks improve stability by sandboxing apps. So, as a rule, only install a .rpm app on the host system if that app can’t be made to work in a container (e.g. a Distrobox). Such are usually driver apps and a few utility-type apps. That precaution provides a level of isolation equavalent to Flatpaks.
Atomic distros do one more level of stability by guaranteeing that .rpm apps that you must “layer” on the host OS won’t destabilize its file system. Their penalty for self-managing “layered” .rpm apps is that you must reboot to enable the app. So, the penalty is a few seconds, unless the device is older.