Linux is highly portable. Fact. On the other hand, Linux software is the least portable technology in the world. Try running Firefox designed for Debian on Fedora. In fact, try running Firefox designed for one version of Fedora on another Fedora, perhaps a slightly older version. Godspeed, Captain Jack Sparrow.

The fanatical rigor with which the Linux backward compatibility is maintained in the enterprise flavors, SUSE and Red Hat, is inversely proportional to all other incompatibilities that exist in the Linux space. This ain’t no news. I have most artfully elaborated on this problem in my illustrated Linux guide. But now, there’s a thing that promises to solve all these problems forever. AppImage.

Introducing AppImage

The need for this solution has been around since last Thursday (intentional use of meme). And if you read the official page, the list of goodies is longer than Chuck Norris’ fun fact collection. You no longer need to worry about dependencies. You do not need to mess with permissions and installations and whatnot. You grab a program, make it executable and run it. As simple as that.

AppImage runs on all major Linux platforms – and applications bundled as AppImages should behave and run the same way on all of them. One for all and all for one. This is the great selling point of this project, in that it allows software developers to focus on core functionality rather than waste time trying to satisfy X permutations times & misery versions of this or that library that will be replaced by the upstream project in a few weeks anyhow and break everything.

In a way, the idea is similar to what Windows has been doing for a long time. Stuff that used to run on Windows 95 will still run pretty well on Windows 10, with a small number of exceptions. But in general, you don’t really need to think and worry how applications work, they just do.

How does it all work?

Magic. Underneath the hood, there’s a whole lot happening. AppImage is a build system, and it needs all the necessary bits and pieces to create working images including a kernel. So what you have is a devil combo of chroot, virtualization, sandboxing, static linking, patching, and more. Too techy to explain in layman’s terms. Hence, magic is the best description.

But there’s a catch …

If you thought you were going to escape the gory stuff, think again. When we’re talking about AppImage, there are two aspects to this technology – the creation of AppImages and the use thereof. The later part is designed for the vast majority of people who utilize Linux. The first is the wizard dust required to create portable, Linux-distro-agnostic applications. And this is where it all gets very, very messy.

The official documentation is old, outdated and difficult to follow. The steps required to create a portable application are comparable, in terms of time and complexity, to compiling a kernel and bundling an RPM package, both at the same time. If you do not have the necessary expertise, you will not be able to create even a single AppImage that is usable in any way, shape or form.

For example, on the GitHub page, the right pane contains links to scripts that allow you to bundle AppImages on your system for some popular applications, like Google Chrome, GIMP, DropBox, and several others. I examined the contents of the GIMP bundle, just to see what it contains. Here are some of the contents (and comments) from the template:

# Now let's find out whether it runs on the latest Ubuntu too...
ISO=/isodevice/boot/iso/ubuntu-15.10-desktop-amd64.iso
sudo ./AppImageKit/AppImageAssistant.AppDir/testappimage $ISO ./$APP.AppDir

# No it does not. So we need to fix things. First, let's see which libraries are missing on Ubuntu.

This sounds like someone is arguing with themselves. What?

Based on the recommendation I act... i't s a bit an art rather than a science?

Through trial and error, I still get "babl_format("cairo-ARGB32"): not found" and a crash. It took a while for me to realize that I needed to do

I examined several more recipes, and they do look like quite like RPM spec files, but with less clarity and less order. Again, this is what it looks like to my untrained if still a technical eye. I was also not able to find the common set of requirements on how to bundle applications as each one had a different set of links, directories and little tweaks required to get everything in order.

Anyhow …

I decided to try creating my own applications, just to see how it all works. The initial git clone was easy enough, and with the right dependencies in place, I had the build framework in place. It’s called AppImageKit, and you use it to build applications.

Following the Wiki information, I tried to create my own GIMP bundle – as opposed to the Leafpad example provided in the documentation. I executed the following command, again much like specified in the Wiki stuff:

export APP=gimp && ./apt-appdir/apt-appdir $APP && ./AppImageAssistant.AppDir/package $APP.AppDir $APP.AppImage && ./$APP.AppImage

The error message was quite intriguing:

Skipping gimp, it is already installed and upgrade is not set.
0 to upgrade, 0 to newly install, 0 to remove and 149 not to upgrade.
find: ‘/var/cache/apt/archives/*.deb’: No such file or directory

I realized the downloaded GIMP deb archive has been removed from under /var/cache. I tried again, and every time, the result was the same. I then downloaded the file using the download option in apt-get (-d), and the file was indeed located in the cache, but after running the commands above, it would get deleted.

I decided to take one step back. Leafpad then. The application was created successfully, but then trying the exact same thing as provided in the output of the AppImageKit run resulted in an error. The program aborted and Leafpad did not run.

./leafpad.AppDir created. Now run:
./AppImageAssistant --package ./leafpad.AppDir ./leafpad

Icon could not be found based on information in desktop file, aborting

I also had problems with the testappimage binary, which is designed to help with the portability of created images. Again, based on the wiki information, I ran a bunch of stuff, except my output was less glamorous – yes the variables were all defined.

sudo ./AppImageKit/AppImageAssistant.AppDir/testappimage $ISO ./$APP.AppDir
sudo: ./AppImageKit/AppImageAssistant.AppDir/testappimage: command not found

Testing pre-built images

I made zero progress this way, and decided to try something else. Luckily, there’s a fair amount of available AppImages, which you can download and try on whatever distro you like. A central repository does not exist yet, and it will be required to transform this endeavor into a serious, cross-distro project.

My test bunnies were Firefox Nightly and VLC, available from the official site. I tested in Fedora 24, Linux Mint 18 Sarah and CentOS 7.2, with three different desktop environments and a pretty colorful set of kernels and libraries.

AppImages do ask to be installed the first they are run. There’s also a fair amount of errors on the command line, however these do not seem to adversely impact the software execution. Moreover, they are common across all distributions.

The selected AppImages worked fine. They provided the necessary functionality, the performance was just like the installed software, and if I did not know I was running the special versions, I would not have known. Which is how it should be. Pity about all the chaos and vomit earlier.

Conclusion

AppImage is a very noble project, with a huge potential and value. But it is too big to be just another GitHub page with lots of text, code and developer notes. Going from a good solution to a great one requires an extraordinary amount of investment. It’s exponential. Definitely not manageable as yet another software idea.

Now, AppImage could make it big, but there must be aforementioned rigor, process and standard in the whole scheme, as boring as it sounds. What will kill this excellent concept is not that it provides an inadequate solution to a big, compelling problem – it does that marvelously – is that the development ecosystem is so buggy and complex, no one will have any incentive or desire to sit down and use it. Developers will require a foolproof setup. Otherwise, if they need to invest the same amount of works it takes to compile all those versions for different distributions, they might as well continue with the old, familiar, tested, and proven system of fragmentation, speed, success, and madness that is Linux.

I would like to see this project mature. At this point, technological merit aside, it feels too jumbled, too busy, not precise, sharp or focused enough, and it’s missing in the so-called enterprise bits and pieces that separate amateur work from professional giants. Well, let’s see how it evolves. I’m liking, but then, ability and vision have never been the issue with Linux. It’s execution to the finest of details. The craftsmanship that separate boys from Star Trek fans. Or something. AppImage, both on my happy-go-lucky-me radar and skepticism gauge. Let’s see how it goes. Dedoimedo over and out.

 

[sharedaddy]