Chris (moving to jade.moe)
I got the chance to try out setting up an AppImage app for my brother, and now I can say that it has an absolutely awful UX.

AppImages are just apps and their libraries bundled into one file. You download it, you run it. Simple enough, right? However, the caveat is that these files are likely not marked as executable when you download them.

Scenario: you are a new user to Linux. You go looking for an app, and see that it has a download. You get the AppImage, open your file manager, then click it. Your computer will tell you that there's no way to open the file. Where do you go from here?

AppImages rely on the prior knowledge of how the executable bit works and how to set it. Users without that knowledge will hit a roadblock, and that's not the only one.

From what I know, AppImages are supposed to offer to set up a desktop file for the application on first launch. This one didn't do that. So, a new user might not know they need to go back to the file each time they want to run the app.

In addition, there are updates to worry about. If an AppImage'd app doesn't check for updates and you don't know you need the AppImage Update app installed, you will never get an updated app. A file from a website, like in the case I came across today, might have no indication of what you need to stay up to date.
Feb 21, 2019 at 12:46amWeb
Show threadChris (moving to jade.moe)Feb 21, 2019
I also take issue with the architecture of AppImage in comparison to flatpak. By default, AppImage is unsandboxed. There's "optional sandboxing", but I doubt users will put effort into installing another program and setting up sandboxing manually. If the goal is to protect users, sandboxing needs to be a seamless default.
Show threadChris (moving to jade.moe)Feb 21, 2019
There's also the awful setup process. https://gitlab.com/inkscape/inkscape/commit/24b5b6861dc80ef80c18cc0b26bb448b74500b1b tells me a few things:

• You need to write two scripts to generate an AppImage

• AppImage builds are locked to the packager's distro

This makes me think that AppImage is not suitable for development like flatpak and potentially snap are.
Show threadalcinnzFeb 21, 2019

@brainblasted I recall the instructions on the website saying to compile out on the most out of date distro you can get your hands on, so it'll capture versions of the libraries that'll work across most distros.

Which makes it very poorly suited to me.

Show threadBikey BoiFeb 21, 2019
@alcinnz @brainblasted AppImage does run everywhere, if you want a single file executable for a broad range of platforms it is definitely a working solution.
Show threadBikey BoiFeb 21, 2019

@alcinnz @brainblasted IMO you shouldn't install apps you can't trust, and that is part of why I think Flatpak, Snap and AppImage are not something I want to rely on.

Package maintainers should be QAing each package, ensuring it has no anti-features, and pushing updates through my package manager. Bypassing this process gets us into a situation where Devs can do nefarious things without oversight from nearly anyone.

Show threadChris (moving to jade.moe)Feb 21, 2019
@bikecurious @alcinnz I agree that you shouldn't install apps you don't trust, but that doesn't stop some people from trusting proprietary apps. So if it's inevitable that someone wants to use them, they might as well be protected.

I disagree on having package maintainers block things. Users should be provided the tools and information needed to make decisions, and beyond that app management should be between them and the developer.

GNOME Software does this by showing permissions and telling you when a sanboxed app requests more permissions.
Show threadChris (moving to jade.moe)Feb 21, 2019
@bikecurious @alcinnz AppImage does run everywhere, but in my opinion there are better solutions to the problem, like flatpak and snap.
Show threadpaperdigitsFeb 21, 2019

@brainblasted I don't think a design goal of AppImage is to protect its users. Rather, the point is to get the application running regardless of the distro.

I'm using several AppImages all the time and they're working quite well.

Show threadChris (moving to jade.moe)Feb 21, 2019
@paperdigits I think it should be a goal. Sandboxing is important, especially if you're downloading and running binaries from different websites.

flatpak also should work regardless of distro.
Show threadpaperdigitsFeb 21, 2019

@brainblasted I don't know if it *should* be a goal, but it isn't and they recommend firejail to do the sandboxing. AppImage has been around a long time, it is certainly the oldest of the new packaging formats.

For me, it has been nice to have a new GIMP package with some critical plugins included.

It makes testing new versions of apps easy, and there is a clear path back to the old version when the new one doesn't work.

Show threadwinmine.exeFeb 21, 2019
@brainblasted appimage lets windows users keep the workflow windows users have had for years, be damned if it's actually good
Show threadGDR!Feb 21, 2019
@brainblasted what you are describing is a problem with the distro you're using. It likely doesn't have Appimage utilities installed, because it tries to force feed snap or flatpak, depending on which one you use.
Show threadChris (moving to jade.moe)Feb 21, 2019
@gdr no. It's not my distro, and there were no flatpaks installed. That appimage needs utilities without expressing such is a failure on it's part as it's purpose is to be a single-file binary that runs anywhere.