Flatpak is not the future (2021)

It is strange to watch everyone fight about snaps, flatpaks, silverblue ad nauseam when Nix (or its full-OS version, NixOS, or the GNU alternative, Guix) has already definitively solved this problem but is still considered too arcane for most people to use.

It only uses the disk space it must, AND every app only accesses the dependencies it needs. It's the best of all worlds (except for the learning curve, which is of course why it's considered "arcane").

As a use-case where its capabilities came in handy just today, I had some old files I encrypted with gpg1 which didn't cleanly decrypt with gpg2. Accessing the old version of gpg, just for this one console and this one time for this one task, was a one-liner: "nix-shell -p gnupg1orig". With that one command it installed everything that version required, and put its executables at the front of my PATH in my shell, so I was able to do the decryption. When I exit, that stuff will get collected on the next garbage collection.

Just built a new Gaming Linux PC which is intended to replace my aging Dell XPS 13 as my daily driver. Decided to go all-in on flatpaks, as I've been trying to stay away from rpm-fusion.

The Steam Flatpak has been an adventure, to say the least. I added a second SSD just for games that gets automatically mounted on boot, and I gather that having the games installed somewhere outside of steam's /home/ directory was not jiving with flatpak's security model. It took some non-trivial editing (thanks, flatseal) to finally let the Steam flatpak be able to write outside of its own directory and install the games.

I still get occasional weirdness, especially on older games. I wasn't hearing any sound effects on Team Fortress 2, which I eventually discovered was tied to an selinux alert. At last check in, I still can't launch CS:Go, because of some backend problem while trying to play the opening movie...

> Firefox

should be able to just use the mozilla's official build which comes with an auto-updater (and it implements the sandbox itself, so no need for another one on top).

> Zotero

> Joplin

both electron shells. also come with their sandbox already. most rolling release distributions would just package these with a system-provided electron build.

I think it's an unfortunate necessity for some kinds of applications.

Eg, we make this: https://overte.org/

We're currently using AppImage because that was the first thing that worked for us, but most of the reasons are the same either way: We want to spend time developing the software, and that means it's hard to justify packaging every release for a dozen distributions. And I'd say nobody particularly wants to do it.

We also expect our users to keep reasonably up to date, not whenever it's convenient to the distribution. Code changes can change the networking protocol, and some of those can require everyone to upgrade.

So at least to me it makes perfect sense to package some kinds of applications this way. Maybe not KDE's calculator, but definitely things like games and tools with specialized markets, where it may be difficult to find people wanting to do the work of packaging them for a distribution.

Doesn't matter, Flatpak won over Appimages and Snaps in adoption numbers.

And the example given here for GIMP having r/w permission to your home doesn't hold water. The distro-packaged app probably has the same permissions in comparison. At least with Flatpak, to deny it this permission is a simple toggle with Flatseal.