
AppImage: Linux apps that run anywhere - b169118
http://appimage.org/
======
otabdeveloper
Seems unnecessarily complicated.

A script like this gets you 95% of the way there:

    
    
      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
    

(Sometimes I wonder if people make a big mystery of Linux app distribution on
purpose, to discourage distribution outside of proper, secure channels.)

~~~
sillysaurus3
I think you meant "$@" rather than $*

(The quotes in "$@" are important.)

Also, your script will fall over if any of the paths have spaces in them, such
as INSTALLDIR.

You should use lowercase for variable names like SCRIPT_PATH. Uppercase is for
exported variables.

readlink -f $0 breaks on OS X. You must do both readlink -f $0 and readlink $0
in order for it to work everywhere.

Shell scripting isn't easy. It took a year to understand these nuances to the
point that they're second-nature, and I'm still discovering new ones. Anything
that improves this situation would be a welcome change in my opinion.

EDIT: cat<<'EOF' is necessary here. cat<<"EOF" will interpolate variables.

~~~
xorcist
> Shell scripting isn't easy. It took a year to understand

That might make it seem like too hard for some people. It's really not that
bad. These particular mistakes were beginner's mistakes.

But it _is_ tricky! I usually try to tell people to avoid writing shell
scripts until you've _at_ _least_ read the "Bash Beginners Guide" or something
similar. It's comparably short (remember, you're learning a new _language_ and
an arcane one at that) but at least lets you avoid the easy traps. Also,
indent and comment. Surprisingly many people seem to think hygiene is somehow
less important outside their main language.

On a side note, what's up with not reading manuals these days? When I am
tasked with something new, no matter how trivial, my first step is to at least
skim the manual get a feel for what the problem domain looks like and how you
are supposed to wield the tool I am about to use. Turns out nobody does that
anymore. Zero, out of over a dozen people in my closest (java, web) team have
read the documentation for the product we build on. I find it unprofessional,
but I realize I'm the strange one and it's probably just me getting older.

~~~
ZenPsycho
> On a side note, what's up with not reading manuals these days?

The difficulty of finding manuals, and when you do, they're badly written in
such a way that they assume all sorts of contextual knowledge based around the
sorts of problems the author of the software was trying to solve in 1986 or
whatever year. Manual writing is at least 1000x more difficult than bash
scripting, because you have no way of knowing up front how the target
"machine" is going to interpret your "script".

And of course that's all assuming a manual even exists at all.

------
matzipan
What this could and should lead to is this: a separation between system
packages and user applications, prefferably with two different managers.

What we have now are mostly system package managers, you want them to be
stable, secure, having the latest features might not be necessary.

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.

~~~
rythie
Not everyone has root on their Linux box and even if you do, you ought to be
able to install applications as you without sudo'ing anything. Right now most
Linux applications guide you to a deb/rpm which runs as root (and who knows if
you can trust it).

TBH this is just the start of making applications more secure, they ought to
be sandboxed too, so one application can't read the data from another
application by default (similar to how phones work).

~~~
jhasse
GNOME is working on it:
[https://wiki.gnome.org/Projects/SandboxedApps](https://wiki.gnome.org/Projects/SandboxedApps)

~~~
michaelmrose
You can make it slightly harder to infect the rest of the system leaving the
factual truth that the moment you install malware you are hosed unchanged

------
drdaeman
I believe the core problem here (that led to containerization, application
images and alike) is that correct packaging for most distros is hard.

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).

~~~
anonbanker
Ranking package managers by difficulty of creating packages (1-10, lowest to
highest):

1\. tarballs (slackware)

2\. Ports (FreeBSD)

3\. Portage (Gentoo, Calculate Linux)

4\. pacman (Arch, Archbang, KaOS, Manjaro, Antergos)

5\. building from source (Linux From Scratch, Most old installs eventually
turn into this)

6\. rpm (Redhat, Mandriva, Scientific Linux, UnitedLinux)

7\. deb (Debian, Ubuntu, Mint/LMDE, Hanna Montana Linux)

Why Debian and Redhat-derivatives are the most popular, I'll never understand.
I have _way_ less headaches maintaining custom Calculate Linux chromebooks
than I ever did with fleets of Redhat or Ubuntu laptops.

~~~
toyg
The web of dependencies for both build and execution can be maddening. This is
why apt-get and yum have won: they take care of finding and downloading those
3246536245 libraries which are absolutely essential for each stupid two-liner
application out there. And when it comes to large software (which you probably
don't manage on a chromebook), good luck downloading and compiling several GBs
of KDE or GNOME source code with the right options for your hardware.

~~~
anonbanker
running/building a full plasma 5.5 KDE 5.x current. Full install including
most office apps (Libreoffice, etc), a bunch of emulators/games (free and
proprietary - steam included), and other apps.

Intel haswell/sandy bridge chromebooks with custom hard drives. I think you're
greatly overestimating how difficult it is to maintain all of this on Portage.
I invite you to try a distribution that isn't Debian or Redhat-based. You
might never go back.

~~~
nickpsecurity
A comment like this is even better if you mention what distro you were using
and maybe drop a link to a guide showing how easy Portage is to use. Then,
people might experience what you describe.

~~~
anonbanker
I already mentioned in the great-grandparent that I was doing this with Gentoo
and Calculate linux (which are interchangeable).

I try not to specifically invite people to "install gentoo" thanks to /g/.
they'll find it on their own. There's a lot of learning before quickpkg makes
an install take 3-5 minutes.

~~~
nickpsecurity
Gotcha. But thanks to /g/? Didn't know that existed so how would I have found
it on my own? And "lots of learning" despite you having way less headaches?
I'm a little confused as some of your answers inspire more questions.

~~~
anonbanker
/g/, the technology troll board of 4chan, has a meme of "install gentoo"
whenever someone says "which is the best distribution to install for a new
user?" Those users usually come back about a week later hating everyone for
putting them with such a difficult OS. Calculate Linux has effectively removed
most of this barrier, though, making Gentoo really easy to maintain for
newbies.

The Gentoo Handbook is an amazing tool to learn linux. By the end, you have an
expert's understanding of how Linux works, and how to install it without a GUI
(or even a package manager). I learned it during the "Stage 1 era", when the
install started with bootstrapping, then building your compiler before
installing the rest of your system. Nowadays, you partition disks, format,
chroot in, set timezone and encoding, untar the stage 3 tarball, emerge
--sync, build your kernel (which is the hardest part), install a bootloader,
install wpa_supplicant, and you're done. It's about 30% more difficult than an
Arch install, becuase you probably _will_ screw up your first kernel
configuration and make a nonbooting kernel, booting to a black screen. But
unlike Other OS's and distros, when it breaks in Gentoo, it's probably your
fault.

I have way less headaches, because chromebooks are braindead to deploy this
way. flash a bios, and then install the binaries once booted off a LiveUSB.
Quickpkg allows you to make binaries of your existing system (built for Sandy
Bridge, until I decommission the C710's, then I'll build for haswell) with all
your custom flags already set, so VLC and other apps are _far_ more robust
than their Ubuntu/Redhat versions. Gentoo is also the only distro other than
GalliumOS that actually has working Elan touchpads for many chromebooks
(thanks to Hugh Greenburg of GalliumOS's patches that I'm maintaining for
newer kernels), as the patches have not been included in Arch or other
distributions's kernels.

I run a Poettering-free install (JACK instead of PA, wpa_gui instead of
NetworkManager, OpenRC instead of systemd), so having one master install I can
re-deploy in the amount of time it takes to brew coffee is pretty handy,
especially considering de-poetterizing a new Debian/RHEL/Fedora/Arch install
is painful, if not nigh-impossible, and at the very least time-consuming.

~~~
nickpsecurity
re /g/

Haha. That is pretty evil given my experiences starting with command line
Linux back in the day. Far as learning, I've heard that before about Gentoo.
Thought about doing it at some point. Right now, kind of mixed between
learning BSD or Linux as the security enhancements I create might need to
temporarily stay proprietary to support their development. BSD vs GPL you
know. I mean, I'd give back bug-fixes or feature developments where possible
but differentiator has to be secretish.

"But unlike Other OS's and distros, when it breaks in Gentoo, it's probably
your fault."

I'm avoiding that right now but fine with the concept. Reminds me of Mentor's
Hacker Manifesto we used to quote to justify such responsibility.

"so having one master install I can re-deploy in the amount of time it takes
to brew coffee is pretty handy"

That is handy. I've always especially liked how the source-based distros were
customized to one's own hardware. That drastically increases the initial
deployment time but significantly reduces many issues along the way.

~~~
anonbanker
there are two solutions for reducing deployment/build time. First is to use
distcc on all machines (so when idle, they contribute to the building of any
packages). Second solution is to build one master image, quickpkg it, and then
deploy the binaries. I use a combination of both; all binaries are compiled
for sandy bay architechture, so I get _most_ of the benefits (though
haswell/broadwell gets faster VLC/ffmpeg if I recompile), and they build at
night when nobody's around.

------
noisy_boy
On my Linux Mint 17.3:

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.

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?

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.

~~~
RocketWolf
As to 1.) you downloaded the app (.appimage) and double clicked on it. Why?
Nowhere in any documentation does it say that .appimages are executable out of
the box. In fact this is a security feature that it doesn't. IN all placves
that I have seen .appimages available there is a statement that says the user
has to go into permissions and make the file executable before it will run.
Makes sense since most malware is made to run without user intervention. If an
app doesnt need _you_ to run it, then its the perfect platform for
malware/virus.

~~~
zyxley
> Nowhere in any documentation does it say that .appimages are executable out
> of the box.

Sure, but literally the first thing on the landing page is...

> 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.

~~~
s369610
On my windows box, if I download an exe, windows won't let me run it until i
go and "unblock" it. So it seems the experience is sort of similar.

------
hrtghrth3
So every time there is glibc / openssl / anything else security update, We
will have to update all appimage programs as well ?

~~~
wereHamster
Do you have any specific problem with that?

~~~
kiallmacinnes
I'm not hrtghrth3, so can't speak for him... but..

Yes, I have a problem with that. I trust I can count on Debian/Ubuntu/RHEL
will ship a new package for every critical CVE promptly, without forcing me to
upgrade to the latest upstream version. I have zero faith upstream maintainers
will do the same - which leaves me with two choices

1) Pretend there is no CVE

2) Use the latest app version, bringing with it all new bugs, workarounds,
incompatibilities and so forth - and hey, the latest version might not even
have the fixed code in it.

~~~
takluyver
> I trust I can count on Debian/Ubuntu/RHEL will ship a new package for every
> critical CVE promptly, without forcing me to upgrade to the latest upstream
> version.

There was an article just a couple of weeks ago pointing out that
distributions frequently don't fix security issues:

[https://statuscode.ch/2016/02/distribution-packages-
consider...](https://statuscode.ch/2016/02/distribution-packages-considered-
insecure/)

No doubt it's better for high-profile applications, but there are far more
applications that people want to use than distros have the resources to issue
security updates for.

~~~
jessaustin
Sure, you're boned if the security flaw is in the custom protocol handler of
some random package of which you are one of 37 total users. Typically,
however, security code does not reside in such packages. They typically link
to popular libraries for e.g. TLS support. Those popular libraries are kept
current by reputable distros. You shouldn't be using low-volume packages that
implement their own security, anyway.

~~~
takluyver
One of the packages in the article I linked above was Wordpress, which is not
exactly low volume. I work on the Jupyter/IPython notebook - we found a
security bug last summer, got a CVE (CVE-2015-5607), issued patches... and the
version in Debian unstable hasn't been fixed, seven months later.

If distros can't do security maintenance for the software people use, claiming
that they shouldn't use that software at all is no kind of an answer.

~~~
jessaustin
If one can't build a server app from source then one shouldn't be connecting
it to the internet all by oneself. There are any number of companies who are
happy to host WordPress for reasonable fees. Keeping software updated is hard
work, and those who do it for free will keep their own schedules. I'm sure
it's frustrating to maintain a package that's "in the middle": too popular to
just say "install with pip", not enough volunteers to maintain the Debian
package in-house. Perhaps that means that Debian is too accepting of packages.
I don't think it's an indictment of the idea of a package manager. I also
doubt that lots more free labor will appear now that there is yet another new
zipfile format to keep maintained.

~~~
takluyver
If building it from source is acceptable, why would using packages direct from
the maintainers not be? For anything in an interpreted language, there's
little difference anyway.

I agree that Debian is too accepting of packages. We don't recommend that
anyone installs Jupyter/IPython with apt, and I wouldn't mind if Debian
removed it from the repos. But if there are all these packages that shouldn't
be distributed through Debian, we need some other way for users to get them
conveniently. We often use language package managers like pip, but they're not
great for desktop applications - they can't easily set up a launcher entry,
for instance. That's where something like AppImage comes in.

~~~
jessaustin
I think it's perfectly acceptable for project maintainers to provide rpms,
debs, ppas, etc. as long as those artifacts are organized in largely the same
way that distro maintainers would organize them. (I doubt any distro
maintainers would disagree.) I don't think it's a good idea to pack lots of
already-distro-packaged libraries into those artifacts. Building for many
distro formats is a pain, but I doubt that building this new format in a
universal way will be easy either. If you have a different AppImage for each
distro/version combo, is that an improvement?

For the packages you've mentioned, live active projects with maintainers who
can produce this distribution format but can't deal with apt, maybe the giant
ball of wax is okay. I won't be installing anything this way, but clearly I'm
not the target user. It seems certain, however, that in future we'll be
hearing about lots of vulnerabilities attributed to AppImages linking in old
library versions.

------
peatmoss
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.

The Windows / Mac distribution model feels more like a necessity on a closed
system than something that is ideal.

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.

~~~
alextgordon
What OS X at least gets right is that OS-bundled software is _immutable_ , or
desired to be. If you want a recent version of e.g. Python, you install
separately and add it to your $PATH instead of changing the base. Then any app
that depends on Python can continue using the system version.

------
yrro
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.

~~~
probonopd
Well, first of all AppImageKit is not a package manager. For a comparison with
xdg-app and other systems, see
[https://github.com/probonopd/AppImageKit/wiki/Similar-
projec...](https://github.com/probonopd/AppImageKit/wiki/Similar-projects)

As for sandboxing, this is definitely an area which we would like to add to
AppImageKit, e.g., see
[https://github.com/probonopd/AppImageKit/issues/77](https://github.com/probonopd/AppImageKit/issues/77)
\- thoughts and pull requests welcome!

~~~
braderhart
Why are you not using containers for sandboxing?

~~~
probonopd
Probably just because I haven't had the time to investigate them yet. Can
containers be used without the need for root access? Pull requests welcome.

------
aksx
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.

~~~
probonopd
Linus Torvalds addresses some core issues in his "DebConf 14: QA with Linus
Torvalds" talk starting around 5:40
[https://youtu.be/5PmHRSeA2c8?t=5m40s](https://youtu.be/5PmHRSeA2c8?t=5m40s)

------
ridruejo
This is very similar to the approach that we took in our InstallBuilder cross-
platform installers
([http://installbuilder.birock.com](http://installbuilder.birock.com)),
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

~~~
norova
Just a heads up, your link is pointing to the birock.com domain instead of
bitrock.com.

This is the correct URL:
[http://installbuilder.bitrock.com](http://installbuilder.bitrock.com)

------
tshtf
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.

There's really no excuse for this.

~~~
DanielDent
The cost of the certificate is a very small part of the overall cost of a
proper SSL/TLS implementation.

If you don't want to exclude older browsers, you need a dedicated IP address,
or you need a system to manage putting multiple names on one certificate.
Let's Encrypt is a great option for multi-SAN certificates, as long as you
don't care about Windows XP users.

If you have any kind of redundancy, doing perfect forward secrecy gets much
harder. The open source approaches to scaling TLS along with PFS are bleeding
edge, poorly documented, and may involve writing some code.

I agree, TLS everywhere is a worthy goal. But I think it's easy to
underestimate how complicated it can get, especially at scale.

~~~
tshtf
> If you don't want to exclude older browsers, you need a dedicated IP
> address, or you need a system to manage putting multiple names on one
> certificate. Let's Encrypt is a great option for multi-SAN certificates, as
> long as you don't care about Windows XP users.

This is a website for AppImage. I doubt they're targeting XP users.

> If you have any kind of redundancy, doing perfect forward secrecy gets much
> harder. The open source approaches to scaling TLS along with PFS are
> bleeding edge, poorly documented, and may involve writing some code.

This is simply a brochure website, so this does not apply.

For more complex applications or websites, there is a certain degree of
engineering required to support HTTPS-by-default. But in today's world it is a
necessity.

------
Samathy
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.

This is a backwards step, if anything.

~~~
probonopd
Well, this is what Linus had to say about packaging: "I've seen this firsthand
with the other project I've been involved with, which is my divelog
application. We make binaries for Windows and OS X. We basically don't make
binaries for Linux. Why? Because binaries for Linux desktop applications is a
major f*ing pain in the ass. Right. You don't make binaries for Linux. You
make binaries for Fedora 19, Fedora 20, maybe there's even like RHEL 5 from
ten years ago, you make binaries for debian stable, or actually you don't make
binaries for debian stable because debian stable has libraries that are so old
that anything that was built in the last century doesn't work. But you might
make binaries for debian... whatever the codename is for unstable. And even
that is a major pain because (...) debian has those rules that you are
supposed to use shared libraries." (August 29, 2014 DebConf Q&A with Linus
Torvalds)

------
ronjouch
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?

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?

EDIT: okay, saw [https://github.com/probonopd/AppImageKit/wiki/Similar-
projec...](https://github.com/probonopd/AppImageKit/wiki/Similar-projects)
mentioned below by the author, sorry for the noise.

~~~
takluyver
From an application developer POV: AppImage looks like something I can use to
package an application today. xdg-app looks like what I might want to use in a
few years.

------
striking
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.

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.

Finally, I'm concerned about the MIT licensing, with all the GPL code floating
around in that repository.

~~~
FooBarWidget
Did you read the intro paragraph on the website?

"As an application author, I want to provide packages for Linux desktop
systems, without the need to get it 'into' a distribution and without having
to build for gazillions of different distributions."

So you are a developer. You don't want to build gazillions of packages, but
you want to target lots of users. Suppose you build a package for one
distribution. Good luck convincing all your users to switch to that
distribution.

I guess you are using Arch. Suppose the developer's opinion is that Gentoo's
package manager is better, so he only bothers making a Gentoo package. He then
tells you to switch to Arch if you want to use his app. Will you seriously do
that?

~~~
lisivka
I am sorry, but if YOU, the author, will ship MY GPLed library with YOUR
application, then YOU are FORCED to open YOUR code under MY terms. Understand?

Don't steal my code, please. Don't bundle it with your proprietary app without
my written permission.

~~~
FooBarWidget
What does the GPL or using libraries have anything to do with the topic
discussed?

~~~
striking
Bundling a GPL library with your application, even as a shared object file, is
not allowed unless your application is also under the GPL.

Furthermore, the application seems to include parts of Linux and certain other
GPL'd code files while trying to maintain an MIT license.

This is rife with licensing concerns, only one of the many concerns I have
with it.

------
revelation
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.

~~~
DanielDent
The Linux Kernel interface does an excellent job of remaining stable. There's
a surprisingly small set of interfaces that the kernel actually exposes to
userland, and in the words of Linus, "WE DO NOT BREAK USERSPACE!".

I don't see the lack of stable APIs elsewhere as an actual problem. The
biggest problem is that it makes life harder for proprietary software
developers - it's pretty much mandatory for them to setup automated CI &
release processes if they want their software to actually be usable.

There's a huge upside to not caring about a huge stable userspace API: it's
much easier to continue to evolve if you just stop caring about backwards
compatibility. And often, backwards compatibility means giving up your future
to hold on to your past. The difficulty of getting _anything_ done grows
exponentially more complicated, often with few significant tangible benefits.

~~~
revelation
What exactly was _achieved_ in the backwards compatibility nightmare that is
Gnome 3, for example?

This:

[https://trac.transmissionbt.com/ticket/3685](https://trac.transmissionbt.com/ticket/3685)

All things UI in Linux distributions go through so much insane thrashing that
very very few application developers want to bother. There are no tangible
benefits to UI thrashing; people use systems for _software_ , not window
chrome!

~~~
DanielDent
Desktop Linux is definitely still maturing...

I'm not up on the latest in Gnome-land and don't know the background on the
issue you linked, but it looks like the benefit is that they get to stop
maintaining a bunch of code for a UI feature they've decided isn't actually a
good idea. That will make it easier for them to continue to build reliable
software, as there will be less legacy code to consider when writing future
code.

The UI churn you talk about may be because the "window manager" concept is
probably fundamentally flawed. Creating a coherent and sensible UI when you
have to target a whole suite of different window managers which may use
entirely different UI paradigms is... probably a nigh-unsolvable problem which
might not even be worth working on.

~~~
digi_owl
The only time you run into a WM issue is when you try to ape the OSX singular
menubar.

As long as you go with the Windows thinking of having the menubar inside the
relevant window, your UI will work across just about every WM out there.

I really don't see why the UI world is so hell bent on moving away from the
menubar. That is unless they are stuck up on turning every UI into a touch
UI...

------
feirlane
This is what powers [1]PortableLinuxGames and it often comes pretty handy.

[1] [http://www.portablelinuxgames.org/](http://www.portablelinuxgames.org/)

------
the_why_of_y
So this attempts to solve the problem of shipping and running desktop
applications in a distribution agnostic way.

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:

    
    
      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.
    

So what does an application author do if the application requires OpenSSL,
which exists in multiple ABI incompatible versions in different versions of
distros?

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.

------
chmike
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.

Another benefit of shared libraries is security fixes and this becomes more
and more important.

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.

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.

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.

------
Klasiaster
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.

------
fit2rule
So .. I have project on my plate which is basically a firmware updater for a
project based around the ESP8266 (see
[http://magicshifter.net/](http://magicshifter.net/) if you're interested).

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?

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 ..

~~~
RazZziel
Bear in mind AppImages are not Java, they run only on Linux, not on OSX or
Windows.

Anyway, I'm using Qt5+QtSerialPort myself inside AppImages, and works
beautifully.

------
_ZeD_
"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."

what? no, man... this is the win9x "freeware" application install.exe, with my
machine fill with crap

~~~
FooBarWidget
If you install an untrustworthy application, it's game over no matter which
packaging model is involved. That doesn't mean it's not worth the effort to
make sure you can easily install _trusted_ apps directly from the author.

What if you want to install the latest version of VLC?

~~~
_ZeD_
linux repositories, whatever distro you choose, are great because of that: I
_don 't_ trust $developerfoo or $startupbar, I just trust my distro packager.

BTW: normally I don't care if I don't use the _latest_ _latest_ version of
$program. Do you REALLY need to always get the latest tip of git of every
program you use? oh, and who said to you the latest version of $program is
packaged?

~~~
veli_joza
Sometimes you just need the latest version. KiCAD has recently gone through
development sprint after being dormant for years. My distro offered ancient
version without new features. After trying to resolve source building
dependencies for an hour, I just ran latest windows binary using Wine, and had
no issues using it. It was bizarre experience.

------
ris
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.

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"...)

It's a one-command, ten-second install on my Debian machine.

~~~
probonopd
You shouldn't run "random binaries", but binaries from the original author of
the software. E.g., Scribus from
[https://www.scribus.net/](https://www.scribus.net/) or Subsurface from
[https://subsurface-divelog.org/](https://subsurface-divelog.org/). If you
don't trust the original application author, then you should better not run
the software at all.

~~~
JupiterMoon
For the average user this relies on the original author having the resources
to be the top hit on google.

------
mixmastamyk
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!

Just need something in the file manager to recognize container images and run
them like an app.

~~~
a3n
What about the stereotypical non-technical relative, who you've moved to Linux
(because all they do is web and email and message) to reduce your family
support effort. Is it reasonable to expect them to run container and run
things in that? It seems at least more support load.

This "drop this in and run it" seems a lot more promising for that use case.
Similar to freezing a python app, I suppose.

~~~
mixmastamyk
It all depends on a simple interface, no reason containers couldn't be run on
(double) click, or put in the main menu, etc.

------
polpo
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.

------
disordinary
Isn't this what dockers original design goal was?

------
hobarrera
> "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."

Has _anyone_ 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.

------
theon144
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.

------
brbsix
I have to wonder if the Subsurface demo was key to achieving the endorsement
from Torvalds.

------
RRRA
How would this relate to AppC / RunC?

Why not take the opportunity and package app in a way that isolates them like
SubgraphOS is trying to achieve? :)

------
hcarvalhoalves
[http://www.gobolinux.org/](http://www.gobolinux.org/)

------
sigmonsays
This uses the fuse file system to intercept and rewrite paths. Anyone know the
performance hit of doing this?

~~~
probonopd
Depending on the scenario, an app packaged as an AppImage may launch as fast
as or sometimes even faster (due to the compression) than an installed app. In
most cases, there will not be a noticeable difference for normal desktop
applications. Since an AppImage is also a valid ISO, you can loop-mount it and
copy its contents wherever you like, and do a comparison.

------
a-dub
So it's shar that cleans up after itself with LD_LIBRARY_PATH set for you?

------
megraf
Do you guys remember those "Portable" Windows executables?

~~~
swsieber
I do - they worked find for me. Did they give you a hard time? I ask because
of the quote marks around portable.

~~~
megraf
Some better than others- I was able to grab a copy of portable office (Office
2007?) that ran fantastic on x86. I also went through the trouble of
sandboxing every one I ran due to the unknown packing mechanics... Cool stuff
none the less

------
zelcon5
Oh exploitable!

------
aeharding
Ugh, please don't fuck with my scrollbar.

~~~
hmottestad
I just made a pull request for fixing it.

~~~
aeharding
Thanks, looks like it was merged.

------
StripeNoGood
Congratulations, you just have invented Windows ;)

------
mozil
is it safe?

~~~
zelcon5
Of course not. Hehehee. Stuff like this makes people like me happy, because of
all the exploits.

------
subway
_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._

Please pull over. I want off this ride.

Why the hell are we regressing to shipping around hackily built binaries?

~~~
cwyers
Because users and developers both want to be able to download and use new
versions of software at a release cadence that makes sense for that
application. The "every application gets the same release cadence no matter
what" approach only appeals to people making distros.

~~~
vidarh
Nothing in using the distro's packaging formats forces you to release only at
the same time as the distro.

~~~
ohyeshedid
While of course you are technically correct, think about it from the grandma
perspective. Grandma uses $app that requires wine, but grandson set her up on
Debian stable. She can't run the latest wine because it isn't stable, and it's
needed for $app, without updating the system to unstable.

I could be erroneously attributing the intended use case, but I believe this
isn't designed for people who know what they're doing; it's for people who
don't know, like grandma.

------
upofadown
From the website:

>Just download the application, website, make it executable, and run!

You want me to download some mystery program and run it with all my
privileges? No ... that isn't going to happen...

~~~
recursive
Presumably, you'd only do this if you knew what it was and you wanted it.

------
pdonis
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!

~~~
recursive
Every model ever devised lets people run buggy programs. If I couldn't run
buggy programs, I wouldn't be able to run any programs at all.

~~~
pdonis
_> Every model ever devised lets people run buggy programs._

There's a big difference between:

(1) A user being able to run buggy programs _if_ someone is able to hack the
secure distribution chain or _if_ someone is able to get the user to give root
permissions (or any permissions other than those of their ordinary user
account) to a piece of malware;

and

(2) A user being able to run buggy programs because the default app model on
their system dumps all app binaries into their ordinary user account's data
area, with that user having write access to all the files, so any random piece
of malware running as that user can hose them.

