Ive just gone to update my flatpak. I now have to download 7 slightly different versions of nvidia drivers. 7 Fucking times the same Nvidia driver. 7. 7 Goddamn times.
And no, I dont want to hear your excuses for this. I dont care if it only downloads 370 Mbs instead of 371.
The more I learn about flatpaks, the more I wonder what the fuck happened to APT GET that it was necessary to have everything in one package. Apt would grab dependencies, too, if they were necessary the last time I was heavily using Linux. Is that no longer the case?
So one of the biggest problems Flatpaks solve is that you can have different versions of dependencies installed at the same time (in this particular case, it’s a problem, because the Nvidia drivers are huge). Imagine you have two packages, P1 and P2. Both depend on library L1, but P1 depends on the newest version, L1 2.0, while P2 depends on the last version, L1 1.0. If the package P2 is open source, you can just rename L1 1.0 to L1-1 and patch it, but if it’s not open source, you can’t patch it, and P1 and P2 can’t be installed at the same time.
It also saves developer time, because the OS devs don’t have to maintain a package for every single app that comes out for Linux. Instead, the app developers make one package with all the dependencies they need and the right version of each and push it up to Flathub, where it can be installed on every OS.
Flatpak is not just an alternative packaging format. One of the key advantages is that it provides a predictable runtime environment that is independent from the rest of the system. Sometimes an application needs a particular version of a dependency (called dependency pinning, very common practice in development) and can’t rely on the system having the correct files. It also isolates the application from issues stemming from environment variables and the “global” filesystem.
It also gives developers greater control over packaging. Because of this isolation, they don’t have to rely on downstream packagers to manually adapt the software to the distro’s available packages (potentially introducing bugs).
One infamous example is Bottles. The project is officially distributed as flatpak, but OpenSUSE wanted to distribute it as native binaries. They had to use an outdated, broken version and caused a flood of user reports for issues that were not Bottles’ fault. More in this thread and open letter: https://github.com/bottlesdevs/Bottles/pull/3583
This. Once you know how to use it it’s way, way more preferable than dealing with all the problems that come from how scattered the Linux ecosystem is and how little control you as a dev had about app distribution. Development and debugging gets more predictable, people can get (app-related) fixes faster, it’s hypothetically more secure (if Flatpak gets their shit together) and with the payment backend for Flatpak repos they (Gnome Foundation & KDE e.V.) work on it finally becomes properly viable to distribute paid apps. All the different hacky ways that are currently circulating (which are often outdated, only work on certain distros etc.) to offer paid applications are honestly obnoxious and expensive to maintain. Not to mention Flatpaks work great on immutable distros.
Just hope they gonna moderate things properly. Flathub & perhaps a few others have to place themselves as the de-facto standard marketplace to define and uphold all the important values the Linux community is organized around once it gets commercial. Not to do so would be a phenomenal mistake and end up in enshittification once the tech bros start targeting Linux.
So yeah, Flatpaks, Snaps and (maybe) AppImages are probably the future for most common end-user distros. Sorry for the small tangent.
Two big reasons I know of are dependency conflicts (not a thing with flatpak…i.e. package A requires one version of lib, package B requires a different), and sandboxing (flatpak has no access to the (file)system unless specified).