Appimages, snaps and flatpaks

Sohrab Behdani@lemmy.world to Linux@lemmy.ml – 87 points –

Appimages, snaps and flatpaks, which one do you prefer and why?

102

You are viewing a single comment

Snaps. Everyone seems to hate them for ideological reasons rather than practical reasons. But for me, they just work. And if Canonical gets out of line, there's already been proof of concepts of third-party snap repositories, so that's a moot point.

Flatpaks seem like a solution in search of a problem to me. Not everything is a gui app, so not sure why the devs aren't supporting cli apps well. But the biggest problem is that most software I use simply isn't available as flatpaks.

And if Canonical gets out of line, there's already been proof of concepts of third-party snap repositories, so that's a moot point.

That's not really a moot point. A proof of concept is much different than an implementable specification. And especially in the commercial space, you'd want to host your own snap repo just for that handful of software you want to customize and then reference upstream for the other things. Snaps, to be useful to that user, need to have the same sort of design considerations apt/deb an yum|dnf|zypper/rpm have about multiple repositories and an implicit promise to not break the 3rd party stores version to version.

Additionally an open source server component was a day one promise from Canonical about Snaps (along with monetization and a functional license model for closed source software) and the gas lighting from Ubuntu about why that stuff isn't here and doesn't appear to be close gets harder to ignore every year it goes on.

Cli apps not being available as flatpaks is a huge oversight. It makes using flatpaks as my main source of applications a non starter.