Canonical To Focus On A New, More Modular Snapcraft - Current Codebase Goes Legacy

[franglais125]

It was designed well ahead of flatpack [sic] [...]

Citation needed.

Spoiler: wrong.

[zxy_thf]

What can I say. Typical Canonical?

[JackLilhammers]

veeableful I think AppImageLauncher is the tool you're looking for

[ernstp]

veeableful I think AppImageLauncher is the tool you're looking for

That looks nice! The update part was also missing..

[Siuoq]

For me, I don't know how to install, or more importantly, uninstall an AppImage. With Flatpak, it's very clear to me how to install or uninstall an app which can be done via the Gnome Software. That has always been the thing that has kept me away from AppImage. Maybe there's a way to install and uninstall it like app bundles in macOS but I currently don't know how to do that. If there's such a way, I would certainly use AppImage in addition to Flatpak.

I remember some AppImages seem to install themselves upon execution but some don't. The ones that do install themselves, I don't know how to uninstall.

https://duckduckgo.com/?q=appimage+package+manager

I don't use it, but e.g. zap seems being able to install and remove AppImages.

[Charlie68]

In my opinion Canonical should decide what to do when they grow up ... they advertised snap as a universal package that works on all GNU / Linux distributions, but then you discover that only Ubuntu and a few others support it. For example openSUSE had to give up due to lack of answers to problems ..., in the end due to this behavior, openSUSE no longer officially supports snap. It is obvious that in this context Flatpak is preferable.

[veeableful]

Thanks JackLilhammers and Siuoq! I will check them out. I hope AppImage will have built-in support in DEs in the future. That would be the dream for me as I see Flatpak as a counterpart to app store but AppImage would fill the "installer" apps role nicely if it is treated as a first-class citizen like Flatpak.

[Sesivany]

It was designed well ahead of flatpack.

It was not. Both projects started in late 2014, just a few weeks apart . Flatpak (xdg-app back then) was based on Alex Larsson's experiments with portable apps that went all the way to 2000s.

[cl333r]

Is it going to be rewritten in Go as opposed to Python?

[ssokolow]

Does anyone notice that Appimages are a bit more underrated compared to Snaps and Flatpaks? I actually had the best experience with them probably because they are not sandboxed, so they don't have all the issues that are caused by sandboxing, from which both Snaps and Flatpaks suffer. They also usually take less disk space. But I guess that the fact that they aren't sandboxed is precisely the reason there is less attention to Appimages.

It's certainly why I don't use them. If something isn't getting at least the basic level of human oversight from a trusted third partu like the Debian/Ubuntu repositories or GOG.com, then damn sure do I want them sandboxed... and even the GOG.com stuff I prefer to run via Firejail.

Heck, I always make sure to use Flatseal (more convenient than the flatpak override CLI) to examine and prune down the permissions before running things. (eg. filesystem=home? No. filesystem=~/Documents;~/src/source_materials:ro or filesystem=/mnt/Seagate_10TB/flatpak-incoming/firefox or something similar. I have a strict policy that, with a few exceptions like gVim, a program can't have both network access and filesystem access outside their little carve-out.

As for taking less space, doubtful once you install more than a handful.

Last I checked, Appimage has no facility for deduplication or sharing dependencies without falling back to relying on the OS, so each Appimage must contain a copy of every dependency the OS might not reliably provide.

Aside from having runtimes to make common dependencies predictable but also deduplicate them in the same way the Steam Runtime does, Flatpak is built on OSTree (Red Hat's equivalent to the non-desktop use-cases for snaps), which is "like git for your OS", allowing files to be deduplicated across all your installed packages, package versions, runtimes, and runtime versions.