16 ms·

AppImage: Linux apps that run anywhere

357 points by b169118 11y ago

hrtghrth3 11y ago
So every time there is glibc / openssl / anything else security update, We will have to update all appimage programs as well ?
- kiallmacinnes 11y ago
  As near as I can tell, yes.
  - tosseraccount 11y ago
    Application binaries must statically link libc and ssl when making programs for packging into appimage?
    - hundchenkatze 11y ago
      Maybe not, but Since "Every AppImage contains an app and all the files the app needs to run." Even if you were dynamically linking, you'd be linking against a lib contained in the AppImage. So, each app would still have its own glibc that would have to be updated.
      - tosseraccount 11y ago
        "The AppImage needs to include all libraries and other dependencies that are not part of all of the base systems that the AppImage is intended to run on" [ https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm... ]
    - kiallmacinnes 11y ago
      I haven't dug far enough into this specific project to know if it's static or dynamic linking, but that just doesn't matter. Each app has it's own copy of libssl etc embedded into the prepackaged "binary" which is executed.. That's enough to know it's going to lead to all sorts of suffering when you actually try and rid yourself of $CVE of the month.
      - probonopd 11y ago
        You can use either static or dynamic linking. An AppImage is really just an ISO container wrapping around your binaries.
        kiallmacinnes 11y ago
        So, yea.. As I said, in this context, it just doesn't matter if your statically or dynamically linked against glibc, every single AppImage published before Feb 15th or so requires an update. What percent of AppImage's in the wild have shipped an update? Of those, how many have updated previous stable releases rather than just the latest version? I suspect very few. [EDIT - Typos]
        jjuhl 11y ago
        Regardless of dynamic or static linking there's the fact that "users dont upgrade" so you've lost either way.
        deleted 11y ago
        [deleted]
- wereHamster 11y ago
  Do you have any specific problem with that?
  - striking 11y ago
    The problem with that should be obvious. Package managers can, right now, update the library that multiple applications use without updating the applications/executables too. One update rather than hundreds or thousands. You could also just not update, but then you'll have massive security holes in your computer. There's a reason Linux adopted the shared library model.
  - kiallmacinnes 11y ago
    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 11y ago
      > 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-considered-insecure/ https://statuscode.ch/2016/02/distribution-packages-consider... 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 11y ago
        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.
- et1337 11y ago
  Follow-up question: is there a built-in app update mechanism? If not, this isn't really a replacement for package systems.
  - probonopd 11y ago
    AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself. No central repository is involved. This enables upstream application projects to release AppImages that can be updated easily. Since AppImageKit uses delta updates, the downloads are very small and efficient. https://github.com/probonopd/AppImageKit/tree/master/AppImageUpdate.AppDir https://github.com/probonopd/AppImageKit/tree/master/AppImag...
- dorfsmay 11y ago
  With the new "statically link all the things" trend from go and rust, that's coming anyway.
  - kibwen 11y ago
    Rust has always been capable of dynamically linking, and I believe that Go is gaining support for dynamic linking sometime in the future as well.
- matzipan 11y ago
  Yes. But it's still better, since your distribution package manager can just pull directly from upstream rather than rebuilding by themselves. Edit: Come to think of it, considering how many applications out there haven't had any updates in years... that might not be such a good idea.
subway 11y ago
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 11y ago
  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.
  - thriqon 11y ago
    So, the problem is not package managers per se, but the velocity of updates? Fix that instead? (see Arch Linux).
    - currysausage 11y ago
      What if I prefer a predictable release cycle for the base OS, but still need the latest LibreOffice/VLC/_____ for one reason or another? I like the approach taken by e.g. Nginx and MariaDB, where I add additional vendor repositories, but this workflow is probably neither user-friendly enough for my mom, nor have all vendors the resources to maintain several repositories for different distributions and their respective versions.
      - vbernat 11y ago
        Use an OS with backports, like Debian. For example, if you took Debian Jessie, you could pull LibreOffice 5 from backports. VLC is already almost up-to-date (2.2.1).
  - subway 11y ago
    People making distos, as well as anyone who has been bitten by unreproducible binaries generated by hand-crafted/manually driven build processes. When I install software from a distro, it's been vetted and I can safely assume the software has a sane reproducible build process, or at a minimum, has had a sane reproducible build process added by the package maintainer. If a new standard wants to solve that process, I'm all for it, but I demand reproducibility (or somebody to hold financially reaponsible, in the case of closed source)in my software builds.
aeharding 11y ago
Ugh, please don't fuck with my scrollbar.
- bbx 11y ago
  It even breaks the trackpad back gesture. This is ridiculous.
- jedisct1 11y ago
  Agreed. I took a look at the website, tried to scroll, closed the window right away due to it messing with the scrollbar.
- hmottestad 11y ago
  I just made a pull request for fixing it.
  - aeharding 11y ago
    Thanks, looks like it was merged.
megraf 11y ago
Do you guys remember those "Portable" Windows executables?
- swsieber 11y ago
  I do - they worked find for me. Did they give you a hard time? I ask because of the quote marks around portable.
  - megraf 11y ago
    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
- BinaryIdiot 11y ago
  Yup and they were fantastic! Mac OS X apps can work in much the same way. It's nice being able to download something and know it'll "just work". Obviously it's terrible for getting security patches. Not entirely sure what to do about that. It would be nice to make package management more consistent across distros but I digress.
- bitwize 11y ago
  a.k.a. how Windows executables more or less used to work before the crawling horror that is the registry. Special support for "portability" is an indicator of a design flaw in your OS.
striking 11y ago
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 11y ago
  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?
  - striking 11y ago
    I get the source, I follow the instructions for building and installing it (usually 3 commands; one to configure, one to compile, one to install). That's usually enough to get it working on just about any distro. If I'm feeling especially up for it, instead of running the install step immediately, I throw together a PKGBUILD so I can use Arch's package manager to manage it (like this one: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=thermald https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=therm...). Gentoo has a really similar system, so I could just about copy the dev's script wholesale. Then instead of running the commands myself, I run "makepkg && sudo pacman -U *.pkg.tar.xz". Oh, you mean for "regular users". Yeah, if you want to support those, you need to do some legwork. Regular users who have no intention of learning how to use Linux usually aren't (and shouldn't be!) using Linux. Mac OS and Windows have support teams and wide adoption. Why use Linux if you don't have to? Please note that I'm not trying to sound elitist. But why would you use an operating system that has a steeper learning curve as a regular user? I'm actually happy that Linux lacks a central concept of package manager because it encourages experimentation. Everyone gets to figure out what kind of package ecosystem they want to see most. We get to choose instead of just getting whatever comes with the computer.
peatmoss 11y ago
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 11y ago
  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.
Samathy 11y ago
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 11y ago
  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)
- emergentcypher 11y ago
  This attitude is exactly why Linux has such a horrible, horrible packaging experience. Building cross-distro packages is awful. Teaching users how to install packages is awful. Installing custom apt sources or repos to get newer versions of packages is awful. And we're getting stuck up on some inconsequential thing like a library will be duplicated. Guess what, OSX has been doing it successfully for years. The Linux community is missing the forest for the trees.
pdonis 11y ago
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 11y ago
  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 11y ago
    > 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.
drdaeman 11y ago
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).
- raziel2p 11y ago
  Completely agree with you in regards to Debian packaging. I googled around and found at least 5 different official guides (on the debian wiki) all using slightly different approaches. I tried 3 of them before giving up, as none of them seemed to work.
  - justinsaccount 11y ago
    Oh? The basics are not that hard. dh_make will do most of the work for you.
    - takluyver 11y ago
      The basics may not be that hard, but the multitude of overlapping tools and frameworks that sit on top of them and try to make things easier is seriously confusing and offputting. For instance, there are build tools called dpkg-buildpackage, debuild, git-buildpackage, pbuilder, cowbuilder, and doubtless some others I've forgotten about. Different guides will recommend different ones. Once you've made a package, you either try to get it into Debian, or put it in your own repository, both of which come with additional challenges. I've done some Debian packaging before - both to go into Debian and to put in PPAs. I've given it up: the effort was too much and the rewards too little.
      - chungy 11y ago
        Sad thing is that this is 100% a problem related to the tools for building Debian packages (same goes for RPM). The tools can be replaced without sacrificing binary compatibility at all. If any aspiring hackers are around, I suggest taking a look at Arch and its makepkg/PKGBUILD tools. Pretty much a simple shell script to define a package, and a uniform tool to build it.
aksx 11y ago
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 11y ago
  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
- djsumdog 11y ago
  Tools like fpm help a lot. Developers have a lot of options now too where they can install python modules and ruby gems as regular users, to their ~/.local directories. It's not ideal, but it helps. And despite all the things I hate about systemd, it does make packaging with a unified initialization script. There have been projects that have tried to do just that piece as a drop in replacement (uselessd) but have gone unmaintained.
yrro 11y ago
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 11y ago
  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-projects https://github.com/probonopd/AppImageKit/wiki/Similar-projec... 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 11y ago
    Why are you not using containers for sandboxing?
    - probonopd 11y ago
      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.
- ugos 11y ago
  I agree, sandboxing is a must-have feature. xdg-app has a system of runtime so it can run on any distro as long as you have installed the runtime needed by the app. Also GNOME and Papyros will have it while KDE seems interested in it also so it should have quite a lot of support.
  - takluyver 11y ago
    xdg-app looks good, but I think we're still at least a couple of years away from the point where a developer can use xdg-app to reach the majority of desktop Linux users. That's a long time in software development terms.
mozil 11y ago
is it safe?
- zelcon5 11y ago
  Of course not. Hehehee. Stuff like this makes people like me happy, because of all the exploits.
revelation 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.
otabdeveloper 11y ago
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.)
- matsemann 11y ago
  Everything seem complicated when you dont properly understand the problem.
  - CharlesW 11y ago
    That's a really interesting thought, because everything also seems simple when you don't properly understand the problem. ("Let Apple open the damn back door, let the FBI know what's on the phone, then close it again. This isn't difficult." — Piers Morgan)
    - arnorhs 11y ago
      you two are discussing separate sides of the same coin. or to clarify: people with a naive understanding of a problem will always feel like people who don't design solutions that are overly complex. people with a deeper understanding of a problem will always feel like people who don't design solutions that are overly simplistic.
      - slavik81 11y ago
        I've successfully refactored way too much code that was needlessly complex to agree. Better understanding of a problem frequently leads to simpler solutions. It doesn't always lead to more complexity.
hcarvalhoalves 11y ago
http://www.gobolinux.org/ http://www.gobolinux.org/
tshtf 11y ago
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 11y ago
  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.
  - deleted 11y ago
    [deleted]
  - tshtf 11y ago
    > 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.
  - michaelmrose 11y ago
    Windows XP users ought to be shown a fullscreen banner ad warning them to upgrade.
matzipan 11y ago
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.
- vbernat 11y ago
  That's hardly related to a package manager. You can for example run Debian unstable to get more up-to-date stuff or mix Debian Jessie with backports. Same package manager, different sources.
  - matzipan 11y ago
    What I'm suggesting is a decoupling between system package managers and application image managers (which should run across distributions/versions). Edit: thinking about it, this should also be the perfect opportunity for a cross-distribution app store/center.
  - brbsix 11y ago
    I think the whole point of OP is to have completely separate installs (e.g. system apps installed in one root and user apps in another). If you go installing latest apps from different sources/repos, you're bound to face conflicts with the system packages. E.g. while installing packages with CPAN or pip, it is really easy to cause conflicts with the system Perl or Python, respectively. Right now there are lots of varying solutions to address this such as virtualenvs and docker images. These are fine for developers, but generally not acceptable to consumers. It would be nice to have a safe consistent experience, a generic user-mode package manager.
    - 11y ago
disordinary 11y ago
Isn't this what dockers original design goal was?
ronjouch 11y ago
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-projects https://github.com/probonopd/AppImageKit/wiki/Similar-projec... mentioned below by the author, sorry for the noise.
- takluyver 11y ago
  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.
theon144 11y ago
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.
mixmastamyk 11y ago
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 11y ago
  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 11y ago
    It all depends on a simple interface, no reason containers couldn't be run on (double) click, or put in the main menu, etc.
noisy_boy 11y ago
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.
- deleted 11y ago
  [deleted]
- dominotw 11y ago
  What if doing that leaves orphan files (that I don't know about) that double-clicking on the appimage file could have created? I'd imagine this is true for all packages like yum ect. How can this problem be solved?
  - 0942v8653 11y ago
    With APT you can run apt-get purge to delete most configuration files and such, if it is packaged properly.
    - jjuhl 11y ago
      That's still a pretty big "if".
      - Drdrdrq 11y ago
        Not really - in my experience it works quite well.
- 11y ago
brbsix 11y ago
I have to wonder if the Subsurface demo was key to achieving the endorsement from Torvalds.
upofadown 11y ago
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 11y ago
  Presumably, you'd only do this if you knew what it was and you wanted it.
ridruejo 11y ago
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 11y ago
  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
polpo 11y ago
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.
justnotforme 11y ago
As a blah blah I want to blah blah; give us a break.
_ZeD_ 11y ago
"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 11y ago
  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_ 11y ago
    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 11y ago
      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.
Klasiaster 11y ago
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.
StripeNoGood 11y ago
Congratulations, you just have invented Windows ;)
feirlane 11y ago
This is what powers [1]PortableLinuxGames and it often comes pretty handy. [1] http://www.portablelinuxgames.org/ http://www.portablelinuxgames.org/
RRRA 11y ago
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? :)
zelcon5 11y ago
Oh exploitable!
a-dub 11y ago
So it's shar that cleans up after itself with LD_LIBRARY_PATH set for you?
ris 11y ago
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 11y ago
  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 11y ago
    For the average user this relies on the original author having the resources to be the top hit on google.
- em3rgent0rdr 11y ago
  as long as you do proper signing of code, reproducible builds, then your security concerns go away. https://defuse.ca/triangle-of-secure-code-delivery.htm https://defuse.ca/triangle-of-secure-code-delivery.htm
the_why_of_y 11y ago
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.
sigmonsays 11y ago
This uses the fuse file system to intercept and rewrite paths. Anyone know the performance hit of doing this?
- probonopd 11y ago
  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.
chmike 11y ago
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.
fit2rule 11y ago
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 11y ago
  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.
hobarrera 11y ago
> "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.

357 points by b169118 11y ago

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

kiallmacinnes 11y ago
As near as I can tell, yes.
- tosseraccount 11y ago
  Application binaries must statically link libc and ssl when making programs for packging into appimage?
  - hundchenkatze 11y ago
    Maybe not, but Since "Every AppImage contains an app and all the files the app needs to run." Even if you were dynamically linking, you'd be linking against a lib contained in the AppImage. So, each app would still have its own glibc that would have to be updated.
    - tosseraccount 11y ago
      "The AppImage needs to include all libraries and other dependencies that are not part of all of the base systems that the AppImage is intended to run on" [ https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm... ]
  - kiallmacinnes 11y ago
    I haven't dug far enough into this specific project to know if it's static or dynamic linking, but that just doesn't matter. Each app has it's own copy of libssl etc embedded into the prepackaged "binary" which is executed.. That's enough to know it's going to lead to all sorts of suffering when you actually try and rid yourself of $CVE of the month.
    - probonopd 11y ago
      You can use either static or dynamic linking. An AppImage is really just an ISO container wrapping around your binaries.
      - kiallmacinnes 11y ago
        So, yea.. As I said, in this context, it just doesn't matter if your statically or dynamically linked against glibc, every single AppImage published before Feb 15th or so requires an update. What percent of AppImage's in the wild have shipped an update? Of those, how many have updated previous stable releases rather than just the latest version? I suspect very few. [EDIT - Typos]
        jjuhl 11y ago
        Regardless of dynamic or static linking there's the fact that "users dont upgrade" so you've lost either way.
        deleted 11y ago
        [deleted]
wereHamster 11y ago
Do you have any specific problem with that?
- striking 11y ago
  The problem with that should be obvious. Package managers can, right now, update the library that multiple applications use without updating the applications/executables too. One update rather than hundreds or thousands. You could also just not update, but then you'll have massive security holes in your computer. There's a reason Linux adopted the shared library model.
- kiallmacinnes 11y ago
  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 11y ago
    > 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-considered-insecure/ https://statuscode.ch/2016/02/distribution-packages-consider... 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 11y ago
      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.
et1337 11y ago
Follow-up question: is there a built-in app update mechanism? If not, this isn't really a replacement for package systems.
- probonopd 11y ago
  AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself. No central repository is involved. This enables upstream application projects to release AppImages that can be updated easily. Since AppImageKit uses delta updates, the downloads are very small and efficient. https://github.com/probonopd/AppImageKit/tree/master/AppImageUpdate.AppDir https://github.com/probonopd/AppImageKit/tree/master/AppImag...
dorfsmay 11y ago
With the new "statically link all the things" trend from go and rust, that's coming anyway.
- kibwen 11y ago
  Rust has always been capable of dynamically linking, and I believe that Go is gaining support for dynamic linking sometime in the future as well.
matzipan 11y ago
Yes. But it's still better, since your distribution package manager can just pull directly from upstream rather than rebuilding by themselves. Edit: Come to think of it, considering how many applications out there haven't had any updates in years... that might not be such a good idea.

subway 11y ago

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 11y ago
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.
- thriqon 11y ago
  So, the problem is not package managers per se, but the velocity of updates? Fix that instead? (see Arch Linux).
  - currysausage 11y ago
    What if I prefer a predictable release cycle for the base OS, but still need the latest LibreOffice/VLC/_____ for one reason or another? I like the approach taken by e.g. Nginx and MariaDB, where I add additional vendor repositories, but this workflow is probably neither user-friendly enough for my mom, nor have all vendors the resources to maintain several repositories for different distributions and their respective versions.
    - vbernat 11y ago
      Use an OS with backports, like Debian. For example, if you took Debian Jessie, you could pull LibreOffice 5 from backports. VLC is already almost up-to-date (2.2.1).
- subway 11y ago
  People making distos, as well as anyone who has been bitten by unreproducible binaries generated by hand-crafted/manually driven build processes. When I install software from a distro, it's been vetted and I can safely assume the software has a sane reproducible build process, or at a minimum, has had a sane reproducible build process added by the package maintainer. If a new standard wants to solve that process, I'm all for it, but I demand reproducibility (or somebody to hold financially reaponsible, in the case of closed source)in my software builds.

aeharding 11y ago

Ugh, please don't fuck with my scrollbar.

bbx 11y ago
It even breaks the trackpad back gesture. This is ridiculous.
jedisct1 11y ago
Agreed. I took a look at the website, tried to scroll, closed the window right away due to it messing with the scrollbar.
hmottestad 11y ago
I just made a pull request for fixing it.
- aeharding 11y ago
  Thanks, looks like it was merged.

megraf 11y ago

Do you guys remember those "Portable" Windows executables?

swsieber 11y ago
I do - they worked find for me. Did they give you a hard time? I ask because of the quote marks around portable.
- megraf 11y ago
  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
BinaryIdiot 11y ago
Yup and they were fantastic! Mac OS X apps can work in much the same way. It's nice being able to download something and know it'll "just work". Obviously it's terrible for getting security patches. Not entirely sure what to do about that. It would be nice to make package management more consistent across distros but I digress.
bitwize 11y ago
a.k.a. how Windows executables more or less used to work before the crawling horror that is the registry. Special support for "portability" is an indicator of a design flaw in your OS.

striking 11y ago

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 11y ago
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?
- striking 11y ago
  I get the source, I follow the instructions for building and installing it (usually 3 commands; one to configure, one to compile, one to install). That's usually enough to get it working on just about any distro. If I'm feeling especially up for it, instead of running the install step immediately, I throw together a PKGBUILD so I can use Arch's package manager to manage it (like this one: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=thermald https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=therm...). Gentoo has a really similar system, so I could just about copy the dev's script wholesale. Then instead of running the commands myself, I run "makepkg && sudo pacman -U *.pkg.tar.xz". Oh, you mean for "regular users". Yeah, if you want to support those, you need to do some legwork. Regular users who have no intention of learning how to use Linux usually aren't (and shouldn't be!) using Linux. Mac OS and Windows have support teams and wide adoption. Why use Linux if you don't have to? Please note that I'm not trying to sound elitist. But why would you use an operating system that has a steeper learning curve as a regular user? I'm actually happy that Linux lacks a central concept of package manager because it encourages experimentation. Everyone gets to figure out what kind of package ecosystem they want to see most. We get to choose instead of just getting whatever comes with the computer.

peatmoss 11y ago

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 11y ago
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.

Samathy 11y ago

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 11y ago
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)
emergentcypher 11y ago
This attitude is exactly why Linux has such a horrible, horrible packaging experience. Building cross-distro packages is awful. Teaching users how to install packages is awful. Installing custom apt sources or repos to get newer versions of packages is awful. And we're getting stuck up on some inconsequential thing like a library will be duplicated. Guess what, OSX has been doing it successfully for years. The Linux community is missing the forest for the trees.

pdonis 11y ago

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 11y ago
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 11y ago
  > 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.

drdaeman 11y ago

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

raziel2p 11y ago
Completely agree with you in regards to Debian packaging. I googled around and found at least 5 different official guides (on the debian wiki) all using slightly different approaches. I tried 3 of them before giving up, as none of them seemed to work.
- justinsaccount 11y ago
  Oh? The basics are not that hard. dh_make will do most of the work for you.
  - takluyver 11y ago
    The basics may not be that hard, but the multitude of overlapping tools and frameworks that sit on top of them and try to make things easier is seriously confusing and offputting. For instance, there are build tools called dpkg-buildpackage, debuild, git-buildpackage, pbuilder, cowbuilder, and doubtless some others I've forgotten about. Different guides will recommend different ones. Once you've made a package, you either try to get it into Debian, or put it in your own repository, both of which come with additional challenges. I've done some Debian packaging before - both to go into Debian and to put in PPAs. I've given it up: the effort was too much and the rewards too little.
    - chungy 11y ago
      Sad thing is that this is 100% a problem related to the tools for building Debian packages (same goes for RPM). The tools can be replaced without sacrificing binary compatibility at all. If any aspiring hackers are around, I suggest taking a look at Arch and its makepkg/PKGBUILD tools. Pretty much a simple shell script to define a package, and a uniform tool to build it.

aksx 11y ago

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 11y ago
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
djsumdog 11y ago
Tools like fpm help a lot. Developers have a lot of options now too where they can install python modules and ruby gems as regular users, to their ~/.local directories. It's not ideal, but it helps. And despite all the things I hate about systemd, it does make packaging with a unified initialization script. There have been projects that have tried to do just that piece as a drop in replacement (uselessd) but have gone unmaintained.

yrro 11y ago

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 11y ago
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-projects https://github.com/probonopd/AppImageKit/wiki/Similar-projec... 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 11y ago
  Why are you not using containers for sandboxing?
  - probonopd 11y ago
    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.
ugos 11y ago
I agree, sandboxing is a must-have feature. xdg-app has a system of runtime so it can run on any distro as long as you have installed the runtime needed by the app. Also GNOME and Papyros will have it while KDE seems interested in it also so it should have quite a lot of support.
- takluyver 11y ago
  xdg-app looks good, but I think we're still at least a couple of years away from the point where a developer can use xdg-app to reach the majority of desktop Linux users. That's a long time in software development terms.

mozil 11y ago

is it safe?

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

revelation 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.

otabdeveloper 11y ago

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

matsemann 11y ago
Everything seem complicated when you dont properly understand the problem.
- CharlesW 11y ago
  That's a really interesting thought, because everything also seems simple when you don't properly understand the problem. ("Let Apple open the damn back door, let the FBI know what's on the phone, then close it again. This isn't difficult." — Piers Morgan)
  - arnorhs 11y ago
    you two are discussing separate sides of the same coin. or to clarify: people with a naive understanding of a problem will always feel like people who don't design solutions that are overly complex. people with a deeper understanding of a problem will always feel like people who don't design solutions that are overly simplistic.
    - slavik81 11y ago
      I've successfully refactored way too much code that was needlessly complex to agree. Better understanding of a problem frequently leads to simpler solutions. It doesn't always lead to more complexity.

hcarvalhoalves 11y ago

http://www.gobolinux.org/ http://www.gobolinux.org/

tshtf 11y ago

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 11y ago
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.
- deleted 11y ago
  [deleted]
- tshtf 11y ago
  > 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.
- michaelmrose 11y ago
  Windows XP users ought to be shown a fullscreen banner ad warning them to upgrade.

matzipan 11y ago

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.

vbernat 11y ago
That's hardly related to a package manager. You can for example run Debian unstable to get more up-to-date stuff or mix Debian Jessie with backports. Same package manager, different sources.
- matzipan 11y ago
  What I'm suggesting is a decoupling between system package managers and application image managers (which should run across distributions/versions). Edit: thinking about it, this should also be the perfect opportunity for a cross-distribution app store/center.
- brbsix 11y ago
  I think the whole point of OP is to have completely separate installs (e.g. system apps installed in one root and user apps in another). If you go installing latest apps from different sources/repos, you're bound to face conflicts with the system packages. E.g. while installing packages with CPAN or pip, it is really easy to cause conflicts with the system Perl or Python, respectively. Right now there are lots of varying solutions to address this such as virtualenvs and docker images. These are fine for developers, but generally not acceptable to consumers. It would be nice to have a safe consistent experience, a generic user-mode package manager.
  - 11y ago

disordinary 11y ago

Isn't this what dockers original design goal was?

ronjouch 11y ago

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-projects https://github.com/probonopd/AppImageKit/wiki/Similar-projec... mentioned below by the author, sorry for the noise.

takluyver 11y ago
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.

theon144 11y ago

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.

mixmastamyk 11y ago

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 11y ago
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 11y ago
  It all depends on a simple interface, no reason containers couldn't be run on (double) click, or put in the main menu, etc.

noisy_boy 11y ago

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.

deleted 11y ago
[deleted]
dominotw 11y ago
What if doing that leaves orphan files (that I don't know about) that double-clicking on the appimage file could have created? I'd imagine this is true for all packages like yum ect. How can this problem be solved?
- 0942v8653 11y ago
  With APT you can run apt-get purge to delete most configuration files and such, if it is packaged properly.
  - jjuhl 11y ago
    That's still a pretty big "if".
    - Drdrdrq 11y ago
      Not really - in my experience it works quite well.
11y ago

brbsix 11y ago

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

upofadown 11y ago

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 11y ago
Presumably, you'd only do this if you knew what it was and you wanted it.

ridruejo 11y ago

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 11y ago
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

polpo 11y ago

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.

justnotforme 11y ago

As a blah blah I want to blah blah; give us a break.

_ZeD_ 11y ago

"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 11y ago
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_ 11y ago
  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 11y ago
    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.

Klasiaster 11y ago

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.

StripeNoGood 11y ago

Congratulations, you just have invented Windows ;)

feirlane 11y ago

This is what powers [1]PortableLinuxGames and it often comes pretty handy. [1] http://www.portablelinuxgames.org/ http://www.portablelinuxgames.org/

RRRA 11y ago

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? :)

zelcon5 11y ago

Oh exploitable!

a-dub 11y ago

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

ris 11y ago

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 11y ago
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 11y ago
  For the average user this relies on the original author having the resources to be the top hit on google.
em3rgent0rdr 11y ago
as long as you do proper signing of code, reproducible builds, then your security concerns go away. https://defuse.ca/triangle-of-secure-code-delivery.htm https://defuse.ca/triangle-of-secure-code-delivery.htm

the_why_of_y 11y ago

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.

sigmonsays 11y ago

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

probonopd 11y ago
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.

chmike 11y ago

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.

fit2rule 11y ago

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 11y ago
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.

hobarrera 11y ago

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