The official LQ poll series continues. This time we want to know: Do you use Appimage, Flatpak, and/or Snaps?

Interested in any comments you may have on the topic as well.

--jeremy

I haven't had occasion to muck about with any of them.

There was a good article about them in Linux Magazine last month, but it's not free. (I was a Linux Voice subscriber and loyally followed Linux Voice to Linux Magazine.)

I have no intention of installing any software that has not been reviewed by my distro maintainers, unless I have heard reliable good reviews of it. And then it will be via a .deb , thanks very much.

6 members found this post helpful.

^ a deb wouldn't be much help on a non-debian distro, but i agree otherwise.

these packs often scratch a particular itch:
i want the newest version, but my distro won't let me!

and, rarely, solve a real problem.

i have used an appimage once, no problem there, except it took minutes to load the super-bloated electron interface, only to find out i could do the same with 'dd'...

None of those come with Tumbleweed AFAIK. And I see no reason (yet?) for them.

By way of impact, I must say that I am not using any of these technologies for business purposes. I, essentially, am an experimenter with these technologies. I must say that I have used several Appimage based applications with some success. I truly believe that these approaches have great promise, in particular, to allow less balkanization between distros when in some ways that has been the nemesis of success of Linux generally.
I feel that Containers and these compartmentalized approaches have a great future. The ease of installing, using this approach, has a bright future.

I use snappy for any app that supports it (and I file bugs for those with bugs in their snaps as well as helping to maintain the snaps in the snapcrafters repo (which we hope will be eventually maintained by the original developers)) and love the general idea of universal application distribution. People ask 'what's the point?' but the current system is an absolute mess. If you want up-to-date applications you have to either wait for the next distribution release (which most aren't patient enough for), or add external repositories, or use a rolling release distribution (or a development branch for a time- or feature-based release distribution for somewhat faster updates). The problem with this is that: In the first case (using distribution packages), you shouldn't have to wait for updates to your front-end applications. The second case (external repositories) is usually not user-friendly (requires diving into Terminal) and runs the risk of introducing packages that expect different dependency versions to what every other program on the system expects, which leaves you with bugs that aren't inherent to the software itself (only to the nature of the packaging system being used) and, in the worst case, a broken system. The final case (rolling distros) is not user-friendly because introducing new packages (core and front-end, indiscriminately) into an OS with only a short testing period before introduction can very easily break things that shouldn't be broken (see Antergos' breaking of LightDM as an example). Rolling release users are usually OK with this, saying that you need to learn more about how to manage the distro you're using and to keep an eye on various feeds for bugs, but I want to be able to use an OS that I can recommend to my Windows/macOS-using friends and one that is low maintenance and doesn't require that level of focus. Also if the OS just introduces front-end package updates on a rolling basis then it encounters the same problem as with external repositories - applications expect dependency versions that other packages don't expect, which introduces unnecessary bugs.

Snappy resolves all these problems by simply allowing upstream developers to distribute the applications themselves and bundle the dependency versions they know works for their software. GIMP, for example, is not yet distributed by upstream, but Daniel, who has snapped GIMP, fixed a crash after cage transformation (caused by the Ubuntu package depending on gegl 0.3) by simply changing the dependency version to gegl 0.2 (that process was a little more involved than it seems but he managed it). Would've been possible in Ubuntu in this case, because libgegl-0.2.0 and 0.3.0 happen to be separate packages anyway, but Ubuntu only has one version on any given release and it would've required work with distribution maintainers to get the bug fixed in the Deb (it hasn't been fixed so far and the bug has been open for over a year) since they would've had to get 0.2.0 back into the distribution using the SRU process and then modify the GIMP Deb to depend on it and update that via an SRU. To fix it in the snap - we edit the `snapcraft.yaml` (which is the declarative file that defines all the packaging) and push out the update and users are then automatically and silently updated to the new version so the issue is fixed. (By the way, if you want that GIMP snap, first install snappy (the version table may be out-of-date), then use `sudo snap install gimp`). Hopefully, over time, more distros will support snappy in their software centers by default so you won't need to use Terminal to use snaps.

The snappy system is rather centralized around the snappy store and with automatic and silent updates that currently aren't easy to turn off, many Linux users won't like it because it seems to take power out of their hands. However for the 'average Joe' switching from Windows and macOS wanting everything to be easy, I think the system is very promising. Sandboxing using AppArmour (which is supported in Linux 4.13 and also in current Ubuntu and Solus thanks to kernel patches) helps increase security and help compensate for the centralization of the system (whilst also helping make sharing dependencies harder because each snap is isolated with its bundled dependencies - so snappy does certainly lose in terms of disk space, though things like the GNOME platform snap are helping resolve that to an extent). Also, of course, snaps work on any distribution that supports snapd (which is, basically, any distribution, though sandboxing only works on Ubuntu and Solus (and other rolling distributions?) at the moment but will work on more as distributions adopt Linux 4.13 - also classic snaps don't yet on Arch because of a decision by the snapd maintainer there, I'm not sure they work on Fedora due to distro decisions there too). They're also easy for upstream to integrate with their CI and distribute mostly automatically - they can also make things easier by using the snapcraft build service.

Flatpak and AppImage (with appimaged and AppImageUpdate) have similar benefits and disadvantages (disk space usage being the common one - though innovations are helping with that as the projects mature), but snappy is the one I'm most familiar with and the one I primarily use. (Edit: I've managed to install GNOME Recipes via Flatpak, since GNOME apps haven't been snapped yet, but I will switch over to snappy for that when they are). There are some differences with the three formats. Flatpak is less centralised than snappy, it's not essentially locked into one software store like snappy is, but also seems to use looser sandboxing than snappy (snappy actually calls what I've called sandboxing so far 'confinement') and AppImage gives the user much more control because appimaged and AppImageUpdate aren't used by default, but this also makes AppImages less user-friendly - to get manual in-desktop updates and desktop integration you need those two packages, you also have to give permissions to run for all the AppImages you install. You also can't yet have properly automatic updates (even with appimaged and AppImageUpdate you have to install updates when you want via right-click on a Launcher item, for example). On top of that, as far as I know, there's no usage of runtimes/platforms in the same way as Flatpak/snappy yet, so AppImages are still huge in terms of file size. So AppImage is much more radically decentralised and thus much less user-friendly, in my view, but this won't bother many desktop Linux users I'm sure! Further to this, if distributions bundle appimaged (and maybe AppImageUpdate) out-of-the-box and support it in their software centers (which they don't currently), then many of these problems (for noob end-users) would disappear.

3 members found this post helpful.

Source, .deb, or not interested.

I have itch.io games distributed as AppImages. Yes, I play them.

Curious about this response: Is your assertion that you don't trust software authors or that you're under the impression that most distros audit software before inclusion? Or something else entirely?

--jeremy

Thoughts on my reply? I think I've given a rationale

Ads,
You have all valid points.

T.-

Sorry, never heard of any of them

Regards,

Alaric

I use LFS so I basically only install from source, as I want to decide what features to include in the software I install, any prepackaged app has been configured to use options that the maintainer wants/uses/thinks is cool, install from source gives best control over software, the only prepackaged app I install is virtual box'cos the dependenceis are hell!

None of the above.

I am still in the deep learning phase. Reading everything I can geet my hands on.