I find AppImage files quite annoying, I must admit. I understand that it's annoying packaging for all the different Linux distros, but this doesn't feel like the solution. Maybe renaming them and dumping them in /usr/local/bin would make them integrate better with the OS, but I usually just avoid them.
Flatpak has been quite nice when I've used it, if a bit more awkward to figure out first time.
Snap is fine, but the actual publishing side of it I found quite confusing and arduous when I tried it, so from a developer point-of-view I would probably avoid it (unless it improved a lot in the last year).
I dunno if I'm doing it wrong, but I really don't like the .AppImage thing. I've never had it successfully add itself to my system, and I don't like that it isn't actually part of a package management system.
I totally understand the frustration of developers wanting to release on Linux and balking at the faff of adding your app to ~n package managers, but AppImage seems to be the wrong solution to that problem.
Snaps are quite nice though, from my experience so far. I've found the documentation a bit lacking, though it is improving.
EDIT: I got confused thinking FlatPak == AppImage, so you can ignore most of the above! I'm gonna check out the FlatPak system, looks interesting.
I wouldn't put appimage on the same level as snap and flatpak. It's more like a random compiled .exe that you just run, it doesn't have an integrated update mechanism, you're supposed to download a new one with every update.
And between snap and flatpak, flatpak sure seems like a winner. For one, other distros can run it their own store instead of Flathub, while snap is pretty much limited to Ubuntu and Snapcraft. Even Ubuntu's forks like Mint and elementary are ignoring snap and going all in on flatpak.
AppImages are so good. They 'just work'. They're super easy to build and distribute too. I think more Linux distributions should embrace them as the de-facto app standard to replace snap and flatpak.
I really dislike AppImage when it's the only way to get an app. I find it quite annoying to get set up on my system in such a way that it behaves like a normal piece of installed software (I run a fairly basic i3 setup with dmenu for app launching). I mostly just keep an unorganised "AppImage" folder now full of random clicky items I can launch. It's like being on an early 2000s iMac.
Flatpak has been good when I've used it; it works more similarly to how apt functions, and seems to need less faffing to get going on my system.
Snap is almost good. I found the documentation for how to actually make snaps incredibly frustrating (hard to explain, it was like lots of little steps were missing) and I find the permissions model with them more awkward. I tried installing Gitea on my home server via snap the other day, and promptly got annoyed enough to just give up, as I wasn't that invested in it.
AppImage has a feature that neither Snaps nor Flatpak do: You don't need a repository or special manager for them to work. You can literally just take the AppImage file to (almost) any Linux Desktop on a thumb drive and run it.
I can't make out what you're disagreeing with - you seem to be arguing against something I didn't say? The point is that the contents of an AppImage - "a dynamically linked executable + lots of dynamically linked libraries" - works just as well without all the squashfs backflips. If you can ship an AppImage, you can ship a regular ol' tarball with a binary named "RunMe" inside. The purpose of an AppImage is simply to condense such a tarball to a single runnable file, for convenience - nothing more.
Meanwhile, Snap and Flatpak are package managers - what's more, they're invasive heavyweights with permanent costs that are even worse than distro package managers. Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck! They are both trying to impose some dubious vision of sandboxed apps that require bureaucracy to communicate with each other, instead of just tackling the core issue of software distribution. Maybe you even like sandboxing! But I've seen no justification why that should be co-mingled with package management.
Snap and Flatpak are very much not portable (in the Portable Application sense). Snap relies on a repo and Flatpak heavily encourages one, although it does have a single-file bundle concept. Sadly both of them suffer from many of the other restrictions I mentioned.
AppImage is pretty great, I wish more projects used it.
I also prefer appimages as the "least worst" of the three.
However, a quick note: As someone who unofficially maintains a linux port of my companies software, I have considered packaging it as an appimage, but there's one problem with appimages that kills the concept.
Appimages are read-only[1]. I'd love to package my companies product that way, but we already have update-delivery infrastructure that works on windows and mac (and linux), and it assumes it can write to the "install folder". Changing the entire update infrastructure specifically for an OS we don't officially support is a non-starter.
From a developer perspective, I would love the ability to update an appimage's contents in place. However, as a user I'd also like the ability to set it read-only to block updates if I desire. Flatpak's mandatory updates are one of the key reasons I dislike it. Never the less, if the goal is to smooth the path for proprietary software to support linux without making half a dozen different packaging solutions, in place updates need to be supported.
[1] edit: according to comments below, they now have an update mechanism, but it's still a totally appimage-specific process, so my problem remains :/
AppImage makes me nervous because they don't actually create promise cross distro compatibility—it depends on what libraries the developer decides to ship alongside the AppImage, and which they assume the distro has. This also raises questions about forwards compatibility with future OS releases.
Snap and Flatpak, by contrast, have explicit systems in place to prevent this. Of the two, I much prefer Flatpak for being a community-driven project. Also, Snap doesn't let you disable automatic updates (without hacks to your hosts file or such). Whatever you think about the security implications, this feels very against the Linux ethos of the user always retaining ultimate control.
I still don't get the difference between Flatpak and Snap.
I get that AppImage is a self contained executable. Fine - makes sense to me. The others... I've got both installed on my Ubuntu 19.04 box and I really have no idea why I'd choose one over the other, or what the projects are trying to do that's so different from each other.
Sure, competition is good - but wouldn't pooling resources be better?
I get the idea behind snap, flatpak, and appimage. But what I don't like is:
1.) config file locations end up all over the place depending on which you use. I like taking my .thunderbird data and just dropping it from one system to the next as one example. Snap makes that harder. Likewise for firefox - the snap version is behind as well.
2.) It solves a problem already long since solved in linux systems - package management. You still need APT or what ever the distro is built with. Two systems solving the same problem often seems like one cook too many. Hell even homebrew in macos is a pain.
Your description of Flatpak is technically more apt for AppImage than Flatpack.
What you said is not wrong, however, it misses the bigger picture because like Snap, Flatpak also includes a package repository and distribution mechanism, whereas AppImage only solves the problem of running a dynamically linked binary on an unsupported distribution (the problem you described)
I prefer native packaging. Snap and Flatpak are both pretty useless IMO, but I'll reach for Snap over Flatpak if those were my only two options. Partially to spite the Flatpak philosophy, but also because only Snap will let me install local services.
As a user I don't want to deal with updating all my software individually. AppImages also provide that. I would be perfectly fine with AppImage format packages being shipped through my package manager, but I don't want to download isolated software from the web when I can avoid it.
FWIW my package manager of choice is GNU Guix, which solves all of the same problems as snap and flatpak in a much more elegant way.
Flatpak has been quite nice when I've used it, if a bit more awkward to figure out first time.
Snap is fine, but the actual publishing side of it I found quite confusing and arduous when I tried it, so from a developer point-of-view I would probably avoid it (unless it improved a lot in the last year).
reply