As a user, the best way to handle applications is a central repository where interoperability is guaranteed. Something like what Debian does with the base repos. I just run an install and it's all taken care of for me. What's more, I don't deal with unnecessary bloat from dozens of different versions of the same library according to the needs of each separate dev/team.
So the self-contained packages must be primarily of benefit to the devs, right? Except I was just reading through how flatpak handles dependencies: runtimes, base apps, and bundling. Runtimes and base apps supply dependencies to the whole system, so they only ever get installed once... but the documentation explicitly mentions that there are only few of both meaning that most devs will either have to do what repo devs do—ensure their app works with the standard libraries—or opt for bundling.
Devs being human—and humans being animals—this means the overall average tendency will be to bundle, because that's easier for them. Which means that I, the end user, now have more bloat, which incentivizes me to retreat to the disk-saving havens of repos, which incentivizes the devs to release on a repo anyway...
So again... who does this benefit? Or am I just completely misunderstanding the costs and benefits?
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.
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.
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.
this is just my opinion but if you aren't after the sandboxing benefits then don't bother with them. if you want to avoid dependency hell go with nix, if you are worried about storage space use your standard package manager, and if you want higher security without the knowledge/effort to manually do it, go with flatpak or snaps (although many flatpaks need to be further hardened via Flatseal as the dev gets to configure the sandboxing. I'm unsure how this operates under snap as I refuse to use it.)
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.
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.
I'm grateful to be able to use AppImages for everything that's not in the repos or for anything that I need updated as soon as upstream updates. So far it has worked seamlessly. It's the most user friendly solution of the lot and I don't need sandboxing.
How do you know when to update an AppImage? I would use the Krita AppImage but I would have to hunt down the file in my file manager to open it and I can't find a way to update it without straight up replacing the thing manually.
Usually they update automatically. I have AppImage integration and most packages tell me of newer versions.
