I told my coworker that in order to run an app, he needs to download it, chmod +x it, and just run it. I completely lost him on “see ech mod plus ex”.
I gave another my Ubuntu laptop and asked him to download and run my app. He tried, but the OS told him
Could not display “Mudlet-3.0.0-kappa-linux-x64.appimage”. There is no application installed for “executable” files. Do you want to search for an application to open this file?"
He tried to continue getting the application to open by clicking “yes”, “pypar2” came up as a “software to open files”, and he got mislead down a path that many other users on the internet have too.
I think this point deserves a discussion and is a weak spot in AppImage compared to native packaging formats. Is there anyone else who feels the same way?
I would like to see a way for the OS allow the user to do what they want - run the application. As it stands right now, it’s a hard block that you cannot get past without any external input.
If AppImage can’t provide a way around this then I suppose I’m beating a dead horse, not the first developer to see the deployment situation on Linux as user-hostile.
Yes, because a user can double-click on a downloaded .deb package, an app to install it will pop-up, they install it, and then they can intuitive launch it either using the “Launch” button or from their taskbar. They wouldn’t need external input at any point of the process despite it being longer.
That works only if the distribution specifically supports deb. If a distributions wants to specifically support AppImages, then it could install the optional appimaged daemon.
Hey, we can’t force distributions to add support for AppImage files, can we? So the only chance we have is that many users start using AppImages, and at some point will create enough “pull” so that distributions will start to care. If you have a better idea, iI’m all for it
I think calling it “user-hostile” is a bit hyperbole. If you think about it, every installation system requires some kind of user training to use it.
Windows:
Download an exe/msi, double click, “whoa there, would like to install a pointless toolbar?”
“hey you want to install Java? Does this app need Java? no but want it anyway?”
“hey want flash too?”
and so on.
There could also be issues with malware being attached to an installer so common suggestion is to tell people to scan the software before running/installing.
OS X/MacOS:
Download a DMG, extract the DMG into an uncompressed folder then manually move all of the contents into an Applications folder.
Android:
Play Store, search and read through reviews to make sure the app isn’t garbage. Then install and upon first launch agree to various permission settings . . . typically blindly.
Go into developer mode to turn on external APK installs and then find an APK somewhere.
and so on and so on.
Sure there is a bit of user training needed for AppImages but all that training requires a 30 second conversation or a 15 second demo gif.
AppImages:
Download AppImage, right click choosing Properties, go to Permissions tab, click the make executable checkbox. Now it’s ready to be used.
I think this is by FAR the least user-hostile of all the options available for any system.
It would be nice for a more useful message to popup saying to do that in order to launch the AppImage but that’s something the distribution would need to implement unfortunately.
DEBs have their own issues like for example:
Does the user know if they need 32bit or 64bit?
Is the user using Ubuntu based distro or Debian based?
Is the user using Ubuntu LTS or a non-LTS?
Does the user know that DEBs for different versions of Ubuntu don’t work in other versions?
Does the distro they use have gdebi installed or a software center of some kind? (if no, then double clicking a deb for install won’t work)
Many of these come up often and create confusion for users.
Let’s say for example you are providing the DEB which alleviates all of the above issues because you already have the information and are providing the DEB. Your complaint is about needing external input but in this case you would be the external input.
Whether you solve these questions for DEBs or give them a gif to look at for giving executable permissions, both are external input.
This isn’t apathy, this is not having the ability to modify the distro infrastructure. The goal of AppImages is to be usable across as many distros as possible. Compromises are needed to make it as simple as possible to do so and I think AppImages achieve that very well with very little user training needed to use them.
This would be ideal because the more developers and users that use AppImages the more distros have to pay attention to how AppImages are being used and how to improve support for them.
This is actually a security feature of Linux. People can’t just download a program and run it without explicitly saying “yes you can run”. This is a good thing because it means people also can’t accidentally download a virus and the virus launch itself and infect the system. If a user downloads a virus or somehow one gets on their system then literally nothing will happen because the program has no permission to run.
If you give a DEB file to someone they still need to provide permission with a user password and in some cases even that makes people be cautious to run something.
If AppImages were made to have an exception for example then viruses could just be packaged as AppImages.
Ultimately, there is a reason for not allowing executables to have default permissions to be executed. However, the unfortunate situation of not informing a user of how to give said permission is something that could hopefully be fixed provided that distros were willing to implement a solution.
In my opinion, the good out ways the bad in terms of manual permission setting and when it comes to user-training it is by far the easiest approach I’ve ever seen.
AppImages coming from trusted sources should be installed without any additional steps. In the other cases there should be possibility to force the restriction by using Alt-key (or similar) or explicitely by hitting kind of “Install anyway…” button, like in macOS. Requiring “chmod +x” is problematic. Sudo password must be required for apps modyfing system files.
AppImages aren’t really ever technically installed so the process is easier than standard packages in my opinion.
However, the ability to give exceptions to trusted sources would depend on the distro to implement that and it would require someone to curate a list of trusted sources.
I think if there was a warning to tell them they need to grant the AppImage permissions that would be enough. It’s not difficult to do.
It’s not a requirement. Users can use the GUI method which does not require sudo at all.
AppImages don’t need sudo to run and they don’t even need to be installed at all. The only barrier to entry is the “make executable” situation that I feel is important for security and so easy that it shouldn’t really be a barrier especially if a user knows to do that.
We need to ask developers to include the how to make executable when they distribute their AppImages even if it is just a link to that thread I linked.
The more and more people who use AppImages then the more and more who will be accustomed to the make executable permission need and this issue becomes a moot point.
Sorry @MichaelTunnell but you are completely missing my point in all of your replies.
My point is: without external input, I cannot download and run an AppImage as-is. Why? Because the OS simply does not let me execute it and does not tell me how to proceed.
Windows guides you through, you double-click on stuff, dialogs happen, you get to a result in the end. macOS guides you through - you double-click on the dmg, a dialog pops up, easy enough.
Linux distros? You double-click and you get nothing. Nothing guides you to making the software executable. Nothing but external input: instructions you read beforehand or Googling after the OS has successfully blocked you from doing what you wanted to do.
I’m not here to undo the whole security model, but why not guide people to making the binary executable? Pop up some dialog saying “Yes I want to run it”? It’s not a novel idea - on-demand dialogs granting root permissions, a far more dangerous thing, already exist!
Unfortunately it relies on distros to implement a solution but I would be fine with a popup that said “To ensure security, you’ll need to grant permission for this AppImage to run.” Then there would be a button that says “Learn How” and that button could simply direct to the gif or whatever.
Of course, it would be better if there was a more simple way of doing it . . . maybe a popup that asks for user password to automatically apply chmod in the background, maybe.
To clarify, when I said “it’s not difficult to do” I was referring to the action of making it executable not getting this warning to be implemented.
I didn’t miss the point at all. I have already expressed that the distro would need to implement some sort of functionality that addressed this issue. It’s not possible to force the distro to show a warning for the AppImages so if this were implemented it would unfortunately have to be done via the distros themselves.
My point about Windows and MacOS is that you still have to learn something in order to use them. Once this single concept of making executable is learned it doesn’t need to be learned again. I think you are exaggerating the size of the barrier that this is. It is a barrier but, in my opinion, it’s not “user-hostile”.
I agree that it totally is an issue but it’s an issue that requires outside implementation with distros in order to solve it. I wish that wasn’t the case but unfortunately it is. I suppose to best course of action for this is to the AppImage team to decide how they want to present a message that it needs to be done and then ask the distros to implement said message.
I would bet the AppImage team would love to be able to do that.
AppImages use the filetype “.AppImage” which is not recognized by most distros as a known filetype. The distros would need to recognize it as a filetype and invoke actions for that filetype based on whether it has permissions set correctly or not.
You’re right it’s not a novel idea but it’s also something the AppImage team does not have the ability to implement. This is something a distro has to want to implement and do so.
I don’t think many distros have even considered this as a feature to add because sadly many distro developers weren’t even aware of AppImages until a couple years ago and in some cases less than a year ago. I know one of the Fedora developers was discussing which was better Snaps or Flatpaks and someone suggested he look at AppImages and he said “what’s an appimage?”
Now many many more people are aware of AppImages but unfortunately many people still don’t understand how they work so distro developers may be aware of them now but might not be aware of this barrier for them. I suppose advocacy to these distro developers would be the best tactic.
With all that said, there is a workaround but I think it is kind of a messy workaround that I would rather fix the filetype issue than for this workaround to become the normal.
An AppImage can be set as executable and placed in a tar.gz archive. A user would download the tar.gz archive, extract it and the AppImage would be runnable without changing permissions.
There are many issues with this but most notable is that most open source software shares the source code of the software as tar.gz and having the same archive type to be the binary and the source code would be confusing.
This also would be an issue of having to teach people that you need to extract the archive . . . this would likely open up an archive software tool but they would still need to figure out to extract it.
Example: Etcher does it this way with a tar.gz archive. http://etcher.io
Yes, and they should do this for all ELF files (applications). Then it will be fixed for AppImages as a side effect. And with “distributions” you probably mean desktop environments such as GNOME, KDE Plasma, etc.
So if you would like to see this, please open bug reports there.
Please DO NOT do this. It destroys most of the advantages of AppImage:
While it may be tempting to avoid users having to set permission, this breaks desktop integration with the optional appimaged daemon, among other things. Besides, the beauty of the AppImage format is that you never need to unpack anything.
That’s a good point and for the DEs if it is isolated to the file managers supporting formats then yea I guess that’s what I meant.
I’d be fine with making bug reports.
I agree completely. I wasn’t suggesting it, I was just saying it was possible but I think it is a terrible approach overall and creates more issues than if solves.
With just a claim and no information - I don’t see why zipping is a bad idea. It preserves the executable bit and less convoluted to tell someone to unzip a file rather than go dig deep in file properties. File archivers job is to intuitively let people archive/extract and I don’t see it as an issue to leave it up to them.
Agree this should apply to any ELF binaries and not just Appimage.
People need to understand that the executable bit (a) is there, and (b) is a security feature. Any method of bypassing the need for the user to give explicit permission should be seen as extremely bad practise.
Imagine downloading a zip archive that contains image.png, which is actually an executable in disguise. You double-click the image to view it and instead the executable runs and deletes everything in your home directory. The fact that (some) archive formats preserve the execute permission is arguably a security flaw, and one that AppImages should not seek to exploit.
