TLDR at bottom.
On most linux forums, it seems that everyone is trash talking flatpaks, snaps, docker, and other containerized packages with the statement that they are “pre-compiled”. Is there a real-world affect that this has with performance and/or security, and does this have to do with canonical and/or redhat leaving a bad taste in people’s mouths due to previous scandals?
Also, it is easier for the developer to maintain only one version of the package for every user. All of the dependencies come with the package meaning that there aren’t distro-specific problems and everything “just works” out of the box.
I understand that this also makes the flatpaks larger, but there is deduplication that shrinks them as you install more by re-using libraries. Do the drawbacks of a slightly larger initial disk usage really outweigh all of its advantages?
I have heard that flatpaks are slower than distro-specific compiled binaries but haven’t seen a case where this affects performance in the real world.
TLDR: In most forums linux users tend to take the side of distro-specific packages without an explanation as to why.
There are a few obvious security implications with the rise of containerized packaging. One of the first is the move away from true centralized, least trust packaging. With traditional packages, you are trusting your distro maintainer (be it Debian, Canonical, RedHat, Arch, SUSE, etc.) To provide patched versions of software from their trusted repository mirrors to your computer. This does a few things like limiting the amount of places that you need to download software binaries from, as well as having other potential benefits like checksum validation on downloaded packages.
Most containerized package platforms including Docker, Snap, Flatpak tend to have a centralized set of repository mirrors, but anyone may compile and publish their own software to it. Flatpak is kind of the exception to this. Some distros (i.e. Fedora) publish their own sets of repos with flatpak packages. This is because Flatpak allows for more than one source repo for packages. I do believe Docker, Podman allow for the same as well. Snap infamously doesn’t allow any repos other than Canonical’s proprietary community repo.
Most of these containerized packages solutions also offer varying levels of sandboxing, which is a good set of security features that could benefit individual hosts from potentially vulnerable software. One could argue that flatpaking Firefox or other browsers and jailing them to limited capabilities and filesystem access is a good thing given the potential for malware propagation through such applications.
In particular though, most containerized solutions aren’t generally hated by online user communities except Snap, which has both been among the most restrictive as well as furthest behind in features, performance parity, and general user experience. Snap was for the longest time significantly far behind Flatpak for user land applications and still wouldn’t be my first choice for server applications compared to Podman or Docker due to just not being nearly as flexible as the other two.
The performance of the platforms can vary compared to native. For the desktop-oriented platforms (Snap, Flatpak) they generally perform insignificantly different from native packages, although Snap packages that are built compressed have had horrific IO performance for the loading of package files (leading to atrociously slow startup times of applications in the past). This is supposedly better now, though I have no intention of installing Snapd to find out.
As a note for culture, people particularly also dislike Snap because of how badly Ubuntu (Canonical’s Linux distro) is depending on it, including having Snap automatically reinstall after removal and dropping many packages from apt only to throw redirects in to pull the snap package when requested from apt. This is why de-snapped derivatives of Ubuntu are also popular.
As for package sizes, they tend to be a bit bigger than native, as well as the added cost of a second set of libraries. Many users online don’t get the ‘why’ when their first package from Flatpak is nearly a 3 GiB download, despite the following packages will hardly be any different in size from native packages. In a way, these packaging solutions do remove an advantage of the singular set of libraries. If you use netbooks, SBCs, IoT devices, or other similar minimal storage devices, you might feel this impact. However most systems will only have a marginal increase of storage utilization overall from a second set of libraries being installed.
Why should the GUI application be a system package? Why shouldn’t we have the good permission system that Android has? Why is the distro packaging every piece of software out there a good thing? Why is a couple of packages using more space a big deal to you?
I never can understand those people who are just against the idea of flatpaks. On the other hand, I can see why you’d be against it for the state in which it is right now.
Let’s all use snaps then!
“No, I didn’t mean Snaps, I meant Flatpak”
Annnnd we are back at square one. flatpak is just another distro, with the limitations of a distro. You are basically asking for a unique distro to rule them all.
First, most of the people I saw discussing it support flatpak, not packages. They support flatpak like they support a football team. example here: “Mostly because they’re uneducated fools”.
It’s all about reputation. There are people I trust, like Steam and there are perfect strangers from the internet. Who do you trust the most between “debian VS mastakilla_51”?
Wake me up when a flatpak app is thought with clear boundaries and doesn’t just request access to my whole home directory. Until then I much prefer to have a team of packager maintaining a reputation, dedicated to their job and producing fine, reliable apps.
The Audacity fiasco was a perfect example of that. The apps was bought by someone, then telemetry was introduced into the flatpak and no one saw it. Instead, the distro maintainers noticed it and deactivated the telemetry. This is how we saw the thing.
Be very careful of what you lose when you say goodbye to distro packages, don’t take it for granted. If you walk the flatpak way you will have access to a mountain of unverified software built by a random person of the internet having access to your full homedir. It’s like installing freewares on Windows, you end up with a lot of crap on your computer. A packages repo is not like freewares for Windows.
Yes, I know, you think flatpaks come with sandboxing. It does not, because most of these packages use /home as the sandbox anyway and people click yes. Pick some flatpaks and see the access level their require. Most of the time it’s /home. This is a terrible trend and I wished more of the flatpak supporters mentioned it when they praise the tool. Some people don’t care. I do.
Cryptocurrency does nothing to help you since it gives a very strong incentive to criminal to scan your homedir. Scammers will use shiny software, flatpak it, add their “secret sauce” and publish it. If you had to install a cryptowallet, would you install the one from the debian repo of the one from mastakilla_51?
Until this whole jungle is sorted out: thanks, but no thanks.
https://github.com/obsproject/obs-studio/pull/2868
This is a good example of this kind of evangelism for the hot new packaging standard gone wrong.
A pull request was made for a half-baked appImage version of OBS by appImage creators.
They refused to support it, and the OBS developers refused to merge it because they have no appImage knowledge.
Drama ensued.I do like how nixOS is tackling this issue, but I don’t really care enough to switch away from Arch.