What is AppImage?

[GreyGeek]

oshunluver mentioned an application called Etcher. Curious, I took a look at it. It wasn't a *.deb or *.tar or *.zip and it didn't have a repository to add, followed by the usually update & dist-upgrade & install. Its extension was *.appimage. This was the second time in a week that I encountered an app that used the appimage. I didn't even know how to install it after I downloaded it so I went on a DuckDuckGo search. Surprise, surprise, surprise! It is the result of almost 10 years of work by Peter Simon, the developer of Klik, which appeared as a Dolphin plugin about 10 years ago. Klik was a step forward toward distro gnostic installation and running, but was not quite there and disappeared.

AppImage works. You download the file, mark it executable, and then run it. That's it! It does NOT touch your system beyond that. NO files are installed as root and you do NOT need to be root to run it. AppImage carries with it ALL necessary libraries and other files. Finished using the app? Just delete the AppImage file and it's gone. Completely. Your system is unchanged. You can use firejail to run the AppImage in a sandbox.

The AppImage home page is here. A "store" for AppImages is here. AppImages also runs on phones, tablets and RasberriPie.

Oh, Linus Torvolds approves!

From now on, AppImages will be my first choice for foreign application installs.

[oshunluvr]

BTW, you can open an Appimage file with Ark so there's so hidden secrets in there. I extracted Icon file from one for my own use.

[GreyGeek]

BTW, you can open an Appimage file with Ark so there's so hidden secrets in there. I extracted Icon file from one for my own use.

That's what I first did with Etcher. I noticed a "user" directory and decided I wasn't going to unzip it and modify my system, which led me to searching for how to really install AppImage files.

I just finished perusing 19 pages of AppImage offerings on that "store" site. Sweet. Downloaded a dozen or so to play with. AppImage will make getting apps for distros a piece of cake. Distro developers won't have to be bothered about questions as to why a certain app won't work with their distro. Run an AppImage in firejail for security. Sweet!

[GreyGeek]

Well, there are AppImages and there are AppImages. I downloaded 8 interesting applications and so far I've tested Etcher, QCad, LibreCad, FreeCad and Subsurface. All worked flawlessly except FreeCad, which failed with the following information:

So, not all AppImages are created equal, but at least if one fails it won't load your system up with detritus. Things in /tmp go away when you reboot.

[dequire]

Appimage, Flatpack, and Snaps all aim to accomplish basically the same thing. On KDE Neon / Kubuntu and derivatives you're likely to run into Snaps more often as that is what Canonical is pushing. They can also be installed easily via command line:

                                                [B]
How to use snaps from the command line[/B]

      If you are running Ubuntu 16.04 LTS or later, you can already  use snaps from the command line. Otherwise do not despair, we have  instructions for [URL="http://snapcraft.io/docs/core/install"]multiple distros[/URL].
      To list all snaps installed on your machine:
      $ sudo snap list         To find a snap in the store:
      $ sudo snap find <text to search>         To install a snap:
      $ sudo snap install <snap name>         To update a snap:
      $ sudo snap refresh <snap name>         To update all your snaps:
      $ sudo snap refresh all         To revert a snap to the previously installed  version:
      $ sudo snap revert <snap name>         Or remove the snap:
      $ sudo snap remove <snap name>

They also push security and portability. It will be interesting to see who wins the containerized-app wars, but because it's FOSS, it will likely be similar to Linux desktop environments. Meaning they will likely all stick around. Luckily, we have the benefit of using all three as needed / desired. I actually used a Snap to install an instance of Minecraft to test it out and it worked flawlessly.

[GreyGeek]

Appimage, Flatpack, and Snaps all aim to accomplish basically the same thing. On KDE Neon / Kubuntu and derivatives you're likely to run into Snaps more often as that is what Canonical is pushing. They can also be installed easily via command line:
....
They also push security and portability. It will be interesting to see who wins the containerized-app wars, but because it's FOSS, it will likely be similar to Linux desktop environments. Meaning they will likely all stick around. Luckily, we have the benefit of using all three as needed / desired. I actually used a Snap to install an instance of Minecraft to test it out and it worked flawlessly.

I heard about snap but haven't seen any applications that use it. I noticed immediately one advantage of AppImage over snap: the use of sudo & root for the install. AppImage doesn't need root access and I like that. Having all three definitely is a benefit. The "winner" will be the one which offers the most apps AND has the least failures. I downloaded eight AppImage packages and tried four of them. One, FreeCad, failed to install because it was missing internal libraries. Three, LibreCad, Subsurface and SimpleScreenRecorder worked flawlessly.

Flatpak is a new one to me. I never heard of it before.

EDIT:
I found Flatpak. Don't like it. Reasons:
1) it requires that I install a Flatpak "installer/runner" using root, and
2) "every app to specify a runtime that it uses for its dependencies", which requires that I add a repo for the platform the app is written forf (i.e., for a gnome app add "gnome.flatpakrepo"
3) I have to preface commands to run a package with "flatpak": flatpak run org.test.Hello
and I left several intermediate steps out.

For AppImage I just download the AppImage pkg and mark it executable, then run it and/or add it to the menu. I contains all the dependencies it needs. No appimage driver to load, no pre-command parameters, no repo additions or adjustments. Just run it. Because several AppImages may use the same dependencies HD space is taken storing those copies as part of the various AppImages. However, disk space is cheap today. I don't care if I have five different versions of a particular library installed. I can even run different versions of the same app even though their dependencies may conflict if an attempt was made to actually install them on your system as system libraries, etc...

So, Flatpak is out for me.

Next I'm going to look at snap.

EDIT-EDIT:
It turns out that snapd comes preinstalled on my KDE Neon User Edition. (If it wasn't then I don't remember installing it)
BUT: When you are NOT logged into the snap store, most snap commands will require you to run them as root.

Let's give it a try using the "Hello World" demo:
From a Konsole:

$ snap install hello
error: access denied (try with sudo)
$ sudo snap install hello
[sudo] password for jerry:
hello 2.10 from 'canonical' installed (that line overwrote the 75Mb of installed "core" that took place!)
$ hello
Hello, world!
$hello.universe
Hello, Universe!

Since snapd is already installed using root, and I HAD to install 75 Mb of "core" using root as well before I could run a simple "Hello World" program, so I've got nothing to lose by using sudo to run "sudo snap install pkg". Don't want to use sudo? Then you must create an account at the Ubuntu snap store and run the install commands from it. Now they have your demographics and can track everything you install and do while using snap.

From my POV this is exactly how Microsoft gained its advantages. I can, however, uninstall snapd and "core" and refrain from re-installing it.

From what I've read, AppImage is hands down better than snap or Flatpak. No sudo or root. No repos. No core. Just download the image, mark it executable and run it. If you don't need it any more just delete it. Any datafiles you create remain unless you delete them as well. Your system truly is NOT touched.

[dequire]

It looks to me that KDE is looking at Flatpak as the way to the future as far as distributing apps goes(1). It appears the goal is to package all major dependencies and libraries as a Flatpak that other Flatpak's can use at will, along with facilitators to integrate Flatpaks into the desktop. The release notes for KDE Frameworks, for example, says the following about KNotification(2):

KNotification

Add support for flatpak portals
Send desktopfilename as part of notifyByPopup hints
[KStatusNotifierItem] Restore minimized window as normal

Finally there's this from Phoronix(3):

While right now we've seen some KDE efforts around Flatpak (formerly XDG-App) and Snaps along with some in the AppImage space, KDE developers are looking to center their efforts around one next-gen packaging solution moving forward. With focusing around one app bundling solution, they hope to be able to deliver their software to more end-users directly across the distribution spectrum.

Again, us Linux users are free to use whichever distribution architecture we desire (if any because for now their use is still optional), it appears the Devs have spoken and their preference is now known. Interesting times ahead!

(1) http://www.jgrulich.cz/2017/01/18/kd...-introduction/
(2) https://www.kde.org/announcements/kd...rks-5.32.0.php
(3)https://www.phoronix.com/scan.php?pa...t-App-Bundling

[GreyGeek]

I hope not.
AppImage, or something more like it than Flatpak or snap, would allow the distro developers to concentrate on their distro and desktop developers to do the same. Having 80,000 packages in the repos would be a thing of the past. Testing the checksum after download and before setting the execute bit would insure security. For extra security one could run an image using firejail.

As I see it there is little difference between snap and flatpak. Both require a preloaded package, except with snap I don't have to start the package by using snap as the command, with the name of the package as the option. Removing Flatpak apps would require a repo manager, just like we do know with Discover, muon or synaptic, so that you can uninstall the package. With AppImage you just delete the file, and the repo is saved for distro and desktop packages.

It amazes me how the hardest way to do something is most often the way chosen. Fortunately, if AppImage continues to exist and expands its offerings, I can ignore snap and Flatpak and just use AppImage.

[Worzel]

GG

I have downloaded AppImage + the Sub Surface example and very much like the idea of using it and within Firejail.

However, slightly off-topic, but I am totally at a loss as to how to download any AppImage progs. For example, LibreOffice shows "No direct download selected for this package" and nothing I have read (as yet) has shown me where to make the selection. Could you show this old sod where I am going wrong?

Interestingly the LibreOffice website only lists Flatpack and Snap as available.

Thanks

[Snowhog]

GG

I have downloaded AppImage + the Sub Surface example and very much like the idea of using it and within Firejail.

However, slightly off-topic, but I am totally at a loss as to how to download any AppImage progs. For example, LibreOffice shows "No direct download selected for this package" and nothing I have read (as yet) has shown me where to make the selection. Could you show this old sod where I am going wrong?

Interestingly the LibreOffice website only lists Flatpack and Snap as available.

Thanks

The ApplImage 'store' link was provided in GG's first post in this thread. That said, LibreOffice as an AppImage is available there. See https://bintray.com/probono/AppImages and navigate to page 8 (as of this posting).

[dequire]

It looks like Discover is getting a Flatpak backend as well, that integrates ratings and reviews (replacing the Ubuntu Popularity Contest system).

As I’m trying to keep improving the flatpak backend in discover I decided to add support for reviews.

Discover: Open desktop ratings

[GreyGeek]

It looks like Discover is getting a Flatpak backend as well, that integrates ratings and reviews (replacing the Ubuntu Popularity Contest system).



Discover: Open desktop ratings

If Discover is going to load ratings and reviews when it is run then it seems to me that doing so will slow down something that is too slow already.

Right now, if you want to install an app that is in the repository you merely "sudo apt update & sudo apt install appname" and then it puts itself in the menu. You can use the menu or run it fro the cli using its name. With Flatpak you'll have to use "flatpak appname" from the cli. I'm assuming that installing a flatpak app will put the prefix "flatpak" in the KDE Menu system will be done automatically during the install. This is a step toward more complexity, not less.

AppImage, on the other hand, puts the onus on the app developer to create a binary package that contains ALL dependencies necessary to run the app, irregardless of the distro. IOW, a self contained ELF binary that does NOT depend on libraries or other files pre-existing on the user's computer. It doesn't matter how many other libraries, or their versions, that exist on the user's computer because the AppImage app won't touch them. AND, there is no need to install a "pre-loader", as snap and flatpak do. Security is drop-dead easy as well. Merely preface the name of the AppImage app with firejail and it runs in a sandbox.
Deleting an AppImage app is also drop-dead easy. Just delete it using Dolphin or the cli. NOTHING ELSE on the system is touched.

With AppImage distro developers do not have to worry about populating their repository with external packages that they may have to modify to get them to work on their distro. AppImage developers only need to worry about creating an ELF binary that is ubiquitous and agnostic toward all distros. IF their app is popular their issue because one of paying for an internet server that can handle the download volume. Distro developers would then be able to limit the number of packages in their distro to files and apps directly a part of their distro. Kubuntu's (Ubuntu's) repository count would drop from 80,000 to, say, 5000, and their server load would diminish proportionally.

All in all, from my POV, AppImage is a win-win for everyone.

Suttlesworth, OTOH, want's to monetize Ubuntu and the packages that run on it. Having something like snap as a pre-requisite for installing packages allows him to be the gatekeeper. I can forsee sometime in the future where downloading Ubuntu (and Kubuntu?) iss free but intalling packages costs. Let me guess: $1-$10, or more, per app. How much will the app developers get from that kitty? We had a blow=up a couple years ago when Jonathan Riddell discovered that Ubuntu was taking in donations meant for Kubuntu but wasn't giving those donations to Kubuntu.

[vinnywright]

Humm self contained my but ,,,,,

vinny@vinny-Bonobo-Extreme:~/Documents/testing/appimage$ ./SimpleScreenRecorder-0.3.8+1.glibc2.14-x86_64.AppImage 
Could not load system translator. 
==================== SSR started ====================
SimpleScreenRecorder 0.3.8
Compiled with GCC 4.8.4
Qt: header 4.8.6, lib 4.8.6
libavformat: header 54.20.4, lib 54.20.3
libavcodec: header 54.35.0, lib 54.35.0
libavutil: header 52.3.0, lib 52.3.0
libswscale: header 2.1.1, lib 2.1.1
[CPUFeatures::Detect] CPU features: mmx sse sse2 sse3 ssse3 sse4_1 sse4_2 avx avx2 bmi1 bmi2
[ALSAInput::GetSourceList] Generating source list ...
[ALSAInput::GetSourceList] Found card: [hw:0] HDA Intel PCH
[ALSAInput::GetSourceList] Found device: [hw:0,0] HDA Intel PCH: ALC892 Analog
[ALSAInput::GetSourceList] Found card: [hw:1] HDA NVidia
[PulseAudioInput::GetSourceList] Generating source list ...
[SourceNamesCallback] Found source: [alsa_output.pci-0000_01_00.1.hdmi-stereo.monitor] Monitor of GK104 HDMI Audio Controller Digital Stereo (HDMI)
[SourceNamesCallback] Found source: [alsa_output.pci-0000_00_1b.0.analog-stereo.monitor] Monitor of Built-in Audio Analog Stereo
[SourceNamesCallback] Found source: [alsa_input.pci-0000_00_1b.0.analog-stereo] Built-in Audio Analog Stereo
Cannot mix incompatible Qt library (version 0x40807) with this library (version 0x40806)
Aborted (core dumped)

what am I doing wrong ?

VINNY

[GreyGeek]

The version that runs as is is the *.bin download. In Linux the AppImage is compressed file. Open it with Ark, and unpack it into its own directory. The file named "AppRun" should be there and already marked for execution. Double click on it.

[vinnywright]

The version that runs as is is the *.bin download. In Linux the AppImage is compressed file. Open it with Ark, and unpack it into its own directory. The file named "AppRun" should be there and already marked for execution. Double click on it.

I see no *.bin download

as it turns out their must be something wrong with the 0.3.8 version , as ARK wold not open it and gave a warning about corrupted file...(on 2 tries)

the "SimpleScreenRecorder-0.3.6+1.glibc2.14-x86_64.AppImage" downloaded from the same place in the same way is running as expected ,,,,IE with

./SimpleScreenRecorder-0.3.6+1.glibc2.14-x86_64.AppImage

from within the directory that contains it .

and it opens fine in ARK

+it works well

VINNY