So again… who does this benefit?

It benefits me because I can install 32 bit software as Flatpak without any troubles and without messing up my whole system with 32 bit libraries dependency hell.

It benefits the end-user.

People do not want to be in dependency resolution hell; where they have three programs that all use different versions of libssl and require them to install all of them properly and point each application to the correct one. Most users have no ability to resolve problems like that. By not bundling, the application developer is forcing them to either try anyway or just not install their software.

Bundling dependencies with Flatpak or Snap helps the end user at the cost of only a few extra megabytes of space, which most users have in abundance anyway.

It benefits both devs and end users.

Many people don’t have the time or resources to manage a broken application especially devs who have to deal with that on several Linux distributions simultaneously.

Many distros use different package install scripts and repos to suit their specific needs. If I were to use a Debian-based distro, I would need to use apt to grab from a Debian-compatible repo. If I somehow got apt to work on Fedora, then not only would the program I installed not work, it would likely annihilate many of the preexisting dependencies and possibly brick the system.

I personally use Arch Linux which uses pacman, my package manager of choice, and a lot of times I’ll find an application that doesn’t work on my system due to mismatched dependencies. Arch is incompatible with .deb and .rpm files and does not use the Debian repo and its derivatives. It uses the AUR and its own derivatives of that repo. I don’t have the time or skill to get a program to work with a newly updated dependency on one distro nevermind however many exist on the internet. Many devs do that for free after they’ve been working at their job for hours and/or taking college courses.

What a Flatpak or appimage (ignoring goofy aah snaps) really does is allow a developer to update dependencies for their application at their own pace without having to play catchup when something inevitably breaks due to an update. It allows for a more stable system. As a Debian Bro, you might not need that, but on rolling-release distros like Arch and funky distros like Manjaro that can be very much welcome.

Snaps benefit Canonical. They’re trying to build their own walled garden, and anyone else benefiting is not a consideration.

Flatpaks are different, because they aren’t purpose-built to benefit a single company. I wouldn’t use them to install most things, but there’s a few places where there’s benefits for at least some people. It’s a lot easier to maintain large projects like Firefox on older distro releases for example. You get sandboxing, so that say a bug in Firefox won’t let malicious javascript take over your system. It lets vendors release closed source software that would never be included in your distro’s repos. These are all things that may not benefit you, but in theory they’ll benefit enough people that it’s worth it.

I’ve also moved onto NixOS so don’t use either one anyways. I think Nix or something like it is the future, even if you’re running a more traditional distro, though that might just be misplaced optimism, see the success of worse is better.

As for Flatpaks: Me. It’s easier, simpler, cleaner, more secure and overall more convenient. It’s like on mobile, permission based. But without the shady corporations behind it.

About Snaps: some edge devs but more importantly: Canonical.

deleted by creator

deleted by creator

As a Steam Deck user I really like flatpak, because it allows me to install third party apps while my system remains exactly the same as every other Steam Deck on the same version.

That means just like other “consumer” devices and unlike most PCs, updates are simple and risk free. There is no risk of having an update break because I installed some app that broke system level stuff.

It helps distributing applications that don’t break left and right. Deepin is creating its own thing as well and they said they are gonna check host system first then supplement missing components if needed. This should result in maximum space saving, but allow developers to cherry pick dependencies.

How this is gonna play out remains to be seen.

I think it benefits the distro maintainers. They can vet and ship version 0.13.1 of some multi-player video game, and support that for two years without bothering to package multiple backward-incompatible releases from the game developers. People won’t come demanding that they break their distro’s stable version no major version upgrades rule because everyone actually playing the game can just use the snap/flatpak published by the developers.

Mainly software vendors.

The fact that you can build a package with all dependences built in etc. Means software vendors can release a product for Linux. Without worring about all the different versions of library’s out there.

This is useful for os when trying to support less common distress. As you are not rellying on the distro to package everything. Then destros that wish to may compile more efficient versions based on there own dependencies can. But other distros are supported if they do not want to compile. Without your team having to compile for every distress.

But it also allows commercial closed source vendors to package once and know every linux system (on the hardware they choose to support) will have the dependencies expected. No matter the distro choice or other software requirements. Removing the issue with supporting every distress. As this is a common reason commercial software avoids Linux. As 100s of different distress divided between a relatively small customer base. Means support is often not cost effective.

Users who want to have software accessible

Me. A flatpak Firefox means not adding a repo to install non-free codecs. A flatpak steam means not installing a hideous number of 32 bit libs. Can’t remember what software it is because I rarely use it, but another flatpak prevents me needing to build it from source.

The main benefit of Flatpaks for me as a user, is that I can upgrade my system without fear of anything breaking (I use Silverblue, which relies heavily on Flatpak to enable this).

I think you should look at the runtimes basically as a repository. There are a bunch of libraries in there, and you make sure that your application works with those versions. Except that now, these libraries and versions are consistent across distributions, so you can support multiple distributions in one go. Additionally, it’s the application developer, who knows the application well, who ensures this compatibility, rather than a packager. Which, again, benefits me as a user, in that I can use the app even if my distro doesn’t have someone to package it.

Snap is just up Canonical trying to build an AppStore that they control so they get a bit of every software sale on Linux. It’s straight up evil. They neither support third party repositories nor is their AppStore server Open Source. It’s build such that they retain all the control and only employs the minimum amount of Open Source to get away with it.

Flatpak is more tricky, I am not sure there is any company behind it actually controlling it directly. But it is very much build for KDE and Gnome apps. As a general Linux package manager it’s completely useless, as it has no dependency management, the only thing you can depend of are the KDE and Gnome runtimes, there is no separation of individual libraries and such. Support for more than one binary per package didn’t exist last time I checked, the support for command line in general is terrible and the whole thing is geared towards an Android’ish experience with simple monolithic apps you can click on. The fact that it runs on multiple distributions is great, but everything else about it is awful.

There is also Nix, this is by far the best package manager we currently have. Runs on all distros, completely reproducible builds, git repositories can themselves be treated as actual packages, everything is easily overridable and changable by the user and best of all it is all build on regular Unix tooling, i.e. just some symlinks and environment variables, very transparent and easy to understand, no weird container magic that hides what is going on.