Seems unnecessarily complicated.<p>A script like this gets you 95% of the way there:<p><pre><code> mkdir AppDir
mkdir AppDir/bin
mkdir AppDir/data
cp $INSTALLDIR/app AppDir/bin
cp -r $INSTALLDIR/data AppDir
cp `ldd AppDir/bin/app | grep -o '\W/[^ ]*'` AppDir/bin
cat << "EOF" > AppDir/app
#!/bin/bash
SCRIPT_PATH=$(dirname $(readlink -f $0))
$SCRIPT_PATH/bin/ld-*.so.2 --library-path $SCRIPT_PATH/bin $SCRIPT_PATH/bin/app $*
EOF
</code></pre>
(Sometimes I wonder if people make a big mystery of Linux app distribution on purpose, to discourage distribution outside of proper, secure channels.)
What this could and should lead to is this: a separation between system packages and user applications, prefferably with two different managers.<p>What we have now are mostly system package managers, you want them to be stable, secure, having the latest features might not be necessary.<p>But we see more and more often that that distribution channel doesn't work well with applications: you end up with old, buggy, insecure applications because the distribution just couldn't keep up with the upstream update cycle. Why not have a cross-distribution application manager which distributes AppImages? That way, application distribution is an effort concentrated over all the distributions, possibly benefiting the entire community.
I believe the core problem here (that led to containerization, application images and alike) is that correct packaging for most distros is hard.<p>There are tools like fpm or even checkinstall that can build simple good-enough-but-not-really packages, but I think maintaining a "proper" Debian packaging requires some pretty arcane knowledge that's spread around various pieces of documentation (and maybe I'm just stupid, but also a lot of trial-and-error).
On my Linux Mint 17.3:<p>1. Downloaded the app, opened Nemo and double clicked on the app. Another Nemo window popped-up and the app didn't start. Opened terminal and checked permission to find that it wasn't executable. The point of the ease-of-use is kind of lost as user would be puzzled and give up.<p>2. How do I uninstall the app? Is it as simple as deleting the file? What if doing that leaves orphan files (that I don't know about) that double-clicking on the appimage file could have created? The website doesn't mention how to uninstall files?<p>PS: regarding #2 above, I found that right clicking on the Mint Menu entry for the app shows Uninstall option. Clicking on Uninstall removes the entry from Mint Menu. The .appimage file needs to be deleted manually separately (which kinda makes sense). I just hope it hasn't left orphan files.
Having re-transitioned last year back to the land of Free *nixen after a long stint on OS X, I marvel at how awesome package management is, and wonder how I ever gave it up. Even where I'm now forced to use OS X (work), I try to brew / brew cask everything.<p>The Windows / Mac distribution model feels more like a necessity on a closed system than something that is ideal.<p>EDIT: I realize that comment sounds more critical than what I intended. While I have a preference for package management, others clearly don't. Also, I might be inclined to use something like this for fast-moving big apps where I want the newest features. I could see trying Guile-Emacs or QGIS this way.
I am profoundly uninterested in a third-party package manager that does not provide any sandboxing features. xdg-app has them, but AppImage does not mention sandboxing on its web site or in its README.
I too love package management like the rest of the people on this thread but the existence of this project confirms that we have a problem, distribution is pretty hard.
This is very similar to the approach that we took in our InstallBuilder cross-platform installers (<a href="http://installbuilder.birock.com" rel="nofollow">http://installbuilder.birock.com</a>), embedding a filesystem in the executable that gets mounted at runtime. If you do it right, it can support a wide variety of Linux distributions and significantly decrease the amount of pain end users and app developers experience. Those who disagree with this approach and believe "this is not the Linux way" should take a look at the referenced Linus Torvalds vieo
I find it interesting in a "Post-Snowden" 2016, that the web page with details about a mechanism to produce fat executables (and links to a demo app) is not protected with SSL. Certificates were cheap before... Now they are free thanks to Let's Encrypt.<p>There's really no excuse for this.
One of the best things about Linux systems is having this huge pool of apps that you update centrally that are guaranteed to work on your system.<p>This is a backwards step, if anything.
I'm confused and couldn't find an answer searching for "xdg-app" in AppImage's website/github. Is this a whole alternative to xdg-app, or a layer on top of it?<p>If it's indeed an alternative, why would anyone choose this rather than xdg-app? xdg-app being backed by fedora/freedesktop/gnome folks might mean more traction and maintenance, doesn't it?<p>EDIT: okay, saw <a href="https://github.com/probonopd/AppImageKit/wiki/Similar-projects" rel="nofollow">https://github.com/probonopd/AppImageKit/wiki/Similar-projec...</a> mentioned below by the author, sorry for the noise.
Why not just use a package manager? If the one in your distro sucks, find a better distro. (Arch Linux would be a good example.) The rule of thumb with OSes and implementing features is to avoid reinventing the wheel.<p>Ports-like tools work very, very well on Linux. Binary distribution works fine too. Also, the shared libraries of each application don't have to be (and usually shouldn't be!) bundled with the application.<p>Finally, I'm concerned about the MIT licensing, with all the GPL code floating around in that repository.
This is missing the point. Linux distributions do not lack package management options, they lack stable and sane APIs for developers to work against. No amount of static linking and binary bundles can fix that.
This is what powers [1]PortableLinuxGames and it often comes pretty handy.<p>[1] <a href="http://www.portablelinuxgames.org/" rel="nofollow">http://www.portablelinuxgames.org/</a>
So this attempts to solve the problem of shipping and running desktop applications in a distribution agnostic way.<p>It cannot actually do this however, because in order for an application to actually run you need to ensure that it's dependencies (in particular shared libraries) are installed on the OS in a version that's compatible with the application, and the documentation is essentially hand-waving the problem away:<p><pre><code> Gather suitable binaries of all dependencies that
are not part of the base operating systems you
are targeting. For example, if you are targeting
Ubuntu, Fedora, and openSUSE, then you need to
gather all libraries and other dependencies that
your app requires to run that are not part of
Ubuntu, Fedora, and openSUSE.
</code></pre>
So what does an application author do if the application requires OpenSSL, which exists in multiple ABI incompatible versions in different versions of distros?<p>xdg-app actually solves that problem with its Runtimes - you create an xdg-app application by building it against a SDK that corresponds to a particular Runtime, which won't be updated in ABI breaking ways. Application authors know exactly which libraries they can rely on and which they have to bundle.
The problem boils down to shared library version number compatibility. The idea of shared libraries is to reduced storage space (disk and memory) at a processing price overhead. Note that this storage constrain becomes less critical these days.<p>Another benefit of shared libraries is security fixes and this becomes more and more important.<p>The only solution I see is that distros must preserve the role of shared library managers and support cohabitation of many library versions. The shared libraries have been designed to support this cohabitation. Any app that doesn't support this cohabitation should be fixed or rejected.<p>Shared libraries should have a version release and patch number. The apps should only depend on version and release number. The patch number is for bug fixes.<p>Users ahould have specific permissions to add new software, which can be enforced by write access to the shared library directory. Users should not be allowed to install crappy and insecure software/libraries on computers shared with other users.
Issues others mentioned are the bundling of libs as well as the lack of sandboxing. But I think the developer experience of xdg-app is superior specially if you just want to make a small change to an app without needing a day setting up the dev environment and maybe even another distribution for compiling the stuff.
So .. I have project on my plate which is basically a firmware updater for a project based around the ESP8266 (see <a href="http://magicshifter.net/" rel="nofollow">http://magicshifter.net/</a> if you're interested).<p>My question to anyone who knows the answer: would it be possible to write an app (in Linux of course) which access the /dev/tty.FORESP8266 and writes/reads raw blocks, such that it could be bundled into AppImage and run on, basically, OSX and Windows as a Linux app - and still have the raw i/o access it needs to perform a firmware update?<p>If so, I'm willing to expend the time to learn how to use it and build this app .. it seems to me to be a more interesting approach than using, for example, Qt to build a cross-platform serial i/o app ..
"As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application."<p>what? no, man... this is the win9x "freeware" application install.exe, with my machine fill with crap
I wish we could kill this idea that the Windows/Macintosh model of running around the web finding random binaries to install is a good one. Every time I have to use a Mac or Windows machine and do this I find it a major chore, and also get pretty firmly freaked out by the number of spoof application homepages with trojaned installer "bundlings" you see flying around the web. could be an easy mistake to make for a less savvy user.<p>As for "it just works", I do wonder how long the rest of you have spent trying to get Postgres and psycopg2 reliably working together on a Mac. (Yeah, Postgres.app "just works"...)<p>It's a one-command, ten-second install on my Debian machine.
I used to be interested in this kind of thing but it turns out lxc containers are lightweight and do the isolation thing well so let's use them!<p>Just need something in the file manager to recognize container images and run them like an app.
This is pretty exciting to me. At my job we create a Linux desktop app using NW.js, which basically has Ubuntu 12.04 as a minimum requirement. Unfortunately almost all of our customers use RHEL/CentOS 6.x, which dates from 2010. I've gotten NW.js compiled in CentOS 6.x (and submitted patches to it as well as Chromium, which it is based on), but Chromium is a famously moving target and the latest betas will take even more work to backport. Hopefully this will solve this problem.
> "As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application."<p>Has <i>anyone</i> ever said such a thing? My guess would be the exact opposite: users like the comfort of installing via the OS package manager, rather than hunting for binaries on the internet.
This seems like it does fill a need, but what I'd really rather avoid the Windows scenario, where each and every single app has its own auto-update manager - in addition to the system update manager. That just becomes a redundant mess very easily.
How would this relate to AppC / RunC?<p>Why not take the opportunity and package app in a way that isolates them like SubgraphOS is trying to achieve? :)
<i>As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application.</i><p>Please pull over. I want off this ride.<p>Why the hell are we regressing to shipping around hackily built binaries?
From the website:<p>>Just download the application, website, make it executable, and run!<p>You want me to download some mystery program and run it with all my privileges? No ... that isn't going to happen...
TL/DR: Let's take the broken app model that lets people download and run buggy, virus-infected programs on Windows and OS X, and bring it to Linux!