After after adding the Flathub repository, in the store several apps are available both in Flatpak and in Package (.deb?) format.
I was wondering if there was a reason to choose one or the other in such cases.
The only difference I am able to observe is the download size, of course Flatpak is bigger, but beyond that is anyone able to list the pros and cons of the two solutions?
The only scale that tips for me is how many clicks you have to go through to install something.
Theyāre even
Flatpak is an attempt to provide some sandboxing over applications, so that they have less access to the system. The GNOME team seems very supportive of Flatpaks.
Here is my opinion.
- Flatpak Pros
- Sandboxed
- Direct access to uploads on Flathub means quicker access to newer software
- If proprietary software is needed, Flatpaks of the software might limit its ability to spy
- Flatpaks seem to make targeting different Linux distributions easier. Donāt have to worry about .deb or .rpm as long as you have Flatpak installed
- Flatpak Cons
- Access to newer software sometimes means getting updates that break things. It is not as curated as package repositories.
- Might inadvertently install proprietary software, because it is available from Flathub
- Larger filesizes
I am a fan of Flatpaks, though, and try to use them where possible.
I admit if you are new to Linux this can be confusing.
Deb is the native packaging scheme for programs and applications on Debian. It is, as such, used in all Debian derivatives (Ubuntu being the big one there).
It is like downloading the install file for a Windows or Mac system. It includes usually just the files specific to the program.
A flatpak is a containerized system, that allows developers to package their program along with everything it needs into a flatpak. This is why it is larger. It provides some sandboxing, and compatibility is the main benefit. You donāt need to worry about missing software because the flatpak will have everything it needs.
So deb packages are smaller, but might not install properly if you donāt have the dependencies necessary for it.
Flatpaks will always install, and you donāt need to worry about dependencies, etc. They also auto update, etc.
Deb packages are more efficient, but both run the same, once installed. Flatpaks allow you to not ābloatā up your system with dependencies.They take up more space, but donāt clutter up your system.
There is no right or wrong answer on using them.
If you worry about dependencies, then flatpaks are great. They generally are not updated as fast as the deb repos are. If you understand how to install linux software then debs will use less space, but do not have any native sandboxing or auto updating going on.
Donāt .deb packages run faster?
Another con: flatpaks ignore dependencies, so if you have something special adjusted to your system, thereās a good chance flatpaks will be oblivious. For the L5 it matters because our GTK is patched to work better on a phone. It puts me between a rock and a hard place now because Iād like to fix some text input deficiencies, but if I break compatibility, flatpaks are going to be degraded.
In general it also matters when the upstream is unable or unwilling to make improvements. Thankfully GTK is mostly aligned with us.
This can be a point for Flatpak: Flatpaked Qt apps work on the old amber-phone distribution, native donāt.
Marginally, due to sharing the same shared libraries as the rest of the system.
I use Fedora Silverblue as my daily driver and flatpaks are basically the default way of getting software. Without getting into why I think Silverblue is so awesome, using flatpaks allows the system to update or even upgrade without any worry about breaking compatibility with any software (since theyāre self-contained packages that donāt depend on the system packages). Just from a security standpoint I think itās worth using flatpaks whenever possible*; but like I said earlier, it does allow for some really cool stuff like Fedora Silverblue, which is a dream to use once you get used to the new way of managing your system.
- I know not all flatpaks are equal in this area, but itās still pretty early in itās adoption and a step in the right direction. Itās only a matter of time.
Thereās another argument in the opposite direction (I assume youāre talking about sandboxing): flatpaks make it easy to use outdated libraries, if the flatpak author canāt keep up. Distributions are usually quick about security updates.
@dcz
Thatās a very good and fair point.
I know the app versions for flatpak tend to stay ahead of the system package versions, but obviously that doesnāt mean the dependencies bundled in the flatpak are the most up to date. Luckily if the sandboxing does itās job, the only thing that should be at risk is the app itself, which hopefully motivates the developer to keep up with things or risk being overtaken by a competing app. Your points stands though, there is definitely a give and take there.
I believe I read somewhere, or maybe Iām wrong, and Iām new to Linux, so I could be mistaken, but I thought one of the objectives of PureOS is to sandbox all apps to block/limit their access to the OS? So then flatpaks sandbox in addition to this?
Iām not sure if itās the explicit goal of PureOS to sandbox all apps, but as I understand it, Flatpak is the main way to achieve this.
One other advantage of flatpak or snaps is that they make installing software easier. Provided you have your software catalog set up for flatpaks, they are usually served from a central repo. (you can find some elsewhere of course) One of the main reasons for snaps, was to provide a single repo with everything in it.
One of the most annoying things about learning Linux is how to add a repo so you get the software you want or need.
For your information, you can run snaps on any Debian based system as well. They have some advantages and disadvantages to flatpaks.
I wouldnāt really say that. One way or another, you either have to count on a repo having it, or on a file you download. The ease of installation is slightly better for Flatpaks, because they donāt need root (unless weāre comparing to Nix).
Maybe if you change your distros a lot, flatpaks have advantage: you can use the same flatpak distro regardless of OS distro.
My love for Flatpak was indeed fostered in part by distro-hopping. The other advantage I found was that since they are self-contained, I could install them all to my home partition. With separate root and home partitions, I could constantly change OSes on the root partition and still have pretty much everything I want/need from my home partition without even needing to reinstall things.
As a developer, being able to create one package for release is pretty nice.
Even as a user of one of the major package formats (RPM), there are times when the only official release is a deb (or similar), which means you either compile your own or use something like alien to create an rpm from the deb. You could also add someone elseās repo that has it, but I usually try to avoid that since thatās one more piece of the puzzle you have to trust.
the future is a combination of 2/3 native to OS packaging method + 1/3 independent .AppImage āappsā (for those few youād NOT care to have tight integration in the OS).
youād still need to be careful about what you make executable on your system and why ā¦
OK, thank you all very much.
From the foregoing I get the insight that, in principle, flatpaks are a better choice.
But while looking at Passwordsafe (for instance) it got me wondering if there may be exceptions: this package has an installed size of 911 kB, the flatpak is 57 MB. This makes me think that almost everything it needs to run is already there. Isnāt a good enough reason to choose the standard package?
Iād say there are some apps that you want to have native packages and some that you can have as flatpacks - and then there are those that fall in between depending on what you prefer and need. Anything fast, small, simple and benefits from being up to date plus comes from a reputable (open) source VS. special apps that canāt be installed otherwise and wouldnāt be published to linux otherwise, apps that donāt interact with the system that much, apps that ājust need to workā for one thing while probably never getting updated (but somehow doesnāt matter), apps that either donāt need to be lightning fast or there is extra system resources to compensate fore cpu/memory/storage needs. I donāt think they exclude oneanother but drawing a line on which to emphasize will fluctuate between users, usecases and in the future.