Linux apps that run anywhere

by devaroop • 7 years ago

89 114 7 years ago

You know if even Linus Torvalds likes it, you've done something right. I love the idea of solving the current approaches to installing / maintaining software on Linux. This is one approach I do like, but I still appreciate maintaining packages through a package manager. I would love to see a best of both worlds, packages like deb that can both run directly and be managed through the package manager, depending on how you choose to run them.

stubish3• 7 years ago

The quote doesn't say he liked it. The quote says it is 'just very cool'. Maybe I've dealt with too many out of context book blurbs and sound bites in my time, but a single dubious endorsement like that is worse than no endorsements.

progval• 7 years ago

Full quote: https://web.archive.org/web/20170914030116/https://plus.goog...

dorfsmay2• 7 years ago

Anybody has strong feelings about AppImage vs Snap vs Flatpack (and any other similar ones)?

sandov4• 7 years ago

I like the concept of AppImage much more than Snap and Flatpak.

I fully embrace the idea of decentralized distribution of applications, as opposed to the way package managers work (central repository mantained by the distro)

I believe the operating system should only be concerned about the base software and present a sane interface so that the user can then install the specific programs they need, the OS should not care about how or where the user gets those programs.

Appimage is the only project I know that respects that idea. Snap and Flatpak are centralized AFAIK (or are unnecessarily hard to use in a decentralized manner).

viraptor3• 7 years ago

If you haven't seen it yet, you may find Fedora Silverblue interesting.

Wowfunhappy5• 7 years ago

Flatpak's can be distributed as standalone ".flatpak" bundles that can be installed offline. I'm not sure why this isn't promoted more.

deviantfero2• 7 years ago

How is this different from windows? I think this is good for dependency heavy apps, such as krita, but you should still try to keep things as centralized as possible, makes updates easier and painless

morpheuskafka• 7 years ago

I have a similar but different view. I don't mind a centralized distribution platform, but I like how snap seperates that from the distro so it's easy to target many distros with one package.

mikelpr• 7 years ago

flatpak's decentralized - there's for example the firefox wayland repo https://firefox-flatpak.mojefedora.cz/

stubish3• 7 years ago

How does AppImage solve distribution of applications? It seems to do packaging, but the actual distribution part is left to the developer. Maybe they put them in a somewhat trusted location like a github releases page, or maybe they are pinned to a webforum post.

Something like Snap tries to solve distribution and updating, using a store and cryptographic signatures. For decentralized use, the snaps can be downloaded along with a signature, and they can then be installed on computers with no net access. The snapd software can verify that the binary came via the store and can be trusted that far at least. Or you can avoid the store entirely, distributing .snap files unsigned or using your own verification mechanisms exactly as a developer does with AppImage, and force the installation using the relevant CLI arguments.

Wowfunhappy5• 7 years ago

AppImage makes me nervous because they don't actually create promise cross distro compatibility—it depends on what libraries the developer decides to ship alongside the AppImage, and which they assume the distro has. This also raises questions about forwards compatibility with future OS releases.

Snap and Flatpak, by contrast, have explicit systems in place to prevent this. Of the two, I much prefer Flatpak for being a community-driven project. Also, Snap doesn't let you disable automatic updates (without hacks to your hosts file or such). Whatever you think about the security implications, this feels very against the Linux ethos of the user always retaining ultimate control.

ktpsns2• 7 years ago

On the other hand, AppImages are dead easy. They do not assume any host infrastructure installed which is especially handy if you are lacking root on a shared system.

bengotow• 7 years ago

I'll bite. I ship the Mailspring email app on Linux and I prefer Snaps as an application developer. The big win is that the snap system provides automatic updates for packaged apps. You publish the build on Snapcraft and 24 hours later everyone on all linux distros has it. I cannot understate how incredible that is as a developer. I used to burn a lot of time investigating issues that users reported on Linux only to find that they were running a version a year old because each update required them to visit the site, download the dpkg/rpm, and install it. I know I could set up an apt-server and whatever else to vend updates to the major linux distros, but we also ship on Mac and Windows and that's a lot of overhead.

The downside is that Snap-packaged apps don't always integrate correctly with the underlying system. For a while theme support was pretty broken. And subtle configuration options aren't always passed in. Worth it in my case though!

dorfsmay2• 7 years ago

Interesting, very similar to Android app store. The concern though is what if your new release break something and this was a really bad time for the user? Can they temporally revert to a previous version?

im_down_w_otp• 7 years ago

One of the issues I've had with things distributed as Snaps or Flatpaks is that they tend not to pickup the settings and preferences that I've configured on my workstation.

For example, if I've setup themes, fonts, scaling factors, custom keyboard shortcuts, etc., they tend not to be available/utilized by the applications which are distributed in these bundling formats. For the most part, that's why I avoid using them.

I assume, but don't actually know, that this also true of AppImage. Can anybody who knows better confirm, or deny, that?

viraptor3• 7 years ago

Just from reading the docs, it looks like your settings will be respected. By default it doesn't look like there's any sandboxing / namespaces happening. Haven't tried it in practice though.

zaarn• 7 years ago

Not any better than Flatpak or Snap in my experience, since Appimage applications have to (technically) ship their own libraries for everything.

pushpop3• 7 years ago

Honestly, I would much prefer using a package manager than manually installing packages. Using a package manager means you only have one place to look for the package (searching in a browser for software can be so error prone for inexperienced users. Not to mention more disruptive and time consuming). Using a package manager means you only have one place for upgrade installers (3rd party updaters are a plague on Windows) and having everything updated through a centralised package manager means you’re less likely to overlook upgrading a package, which is better for your overall system security.

My biggest gripe with OSX is that the default way of installing software is via manual downloading. Sure OSX has the AppStore, but that’s mostly garbage. Homebrew is a hell of a lot better but it’s frustrating that I have to install a 3rd party package manager on a modern OS.

I get your rant about shared libraries but you can get around those problems surprisingly easily (eg you can ship your SOs in the package directory like you might with DLLs in Windows. Or you could just statistically compile your binaries and do away without the SO problem entirely). Problems with SOs are something you’d expect a junior Linux sysadmin to learn so any developer or maintainer worth their salt should have already figured this out.

omnimus• 7 years ago

I assume you install different browser than Safari. So is it frustrating that you have to install 3rd party browser?

Come on homebrew is awesome. Install is easy and then you just point brew bundle to file with everything you need, go for coffe and your computer is ready.

vhhn• 7 years ago

I was surprised when VSCode snap told me that I should start using different snap to install new versions if VSCode and that my settings would be kept. And it did. So there is some way to respect users settings across snaps at least

redmorphium• 7 years ago

Possibly how it's done: the settings are stored in a config directory, like ~/.vscode or something.

For instance, my neovim AppImage works this way (it still reads ~/.config/nvim/init.vim like regular neovim).

Lorkki• 7 years ago

The official VS Code snap is unconfined, ie. it only uses snap for package management without the sandbox. This means it can access the settings stored in your home directory just the same as if it was installed through apt.

Snaps with strict confinement can also ask for home directory access as a specific permission.

voodootrucker• 7 years ago

What people use it for at the top, what it does in the middle, and how it works at the bottom, buried in a video - typical modern sites (except this one at least has the video).

What I would like to see: 1. Problem statement 2. How this solves it 3. Usage guide 4. Source code link 5. No appeal to authority of who's using it

satori99• 7 years ago

and how it works at the bottom, buried in a video

A video that plays for 12 minutes before it explains the bit about using an ELF header which mounts a disk image payload using FUSE.

beatgammit3• 7 years ago

Eh, I think 5 is important because it shows that there's a vested interest in keeping the project going. I absolutely do make decisions on what to use based on who is using it because switching to something else after a project dies is a royal pain, and I don't have the time to maintain it myself (though I can certainly submit patches here and there).

Annatar10• 7 years ago

"No need to install". This is every system administrator's nightmare: users running arbitrary executables bypassing operating system packaging. Come time to upgrade or reinstall what can happen? If there are security updates which are needed to the program, what could happen, since this is statically linked?

This is the pinnacle of destructive lazyness and amateurism in IT: as a developer it is one's job to master every operating system packaging format for the target platform one develops for. OS packaging is a tool invented for developers, not a tool meant to be subverted at every turn and opportunity like this.

viraptor3• 7 years ago

I don't believe this is really a problem for administrators. Reasonable multi-user hosts will have both home and tmp mounted no-exec and will not allow fuse - appimage will not work. This solution will work just fine of personal machines though. I'd rather native packages were distributed too, but if the choice is this or nothing... why disappoint people?

pjmlp6• 7 years ago

Any savy UNIX admin will be able to prevent new executables to run under user accounts.

Annatar10• 7 years ago

But it won't solve the problem of developers' unwillingness to learn how to make operating system packages now will it?

I don't get it: people like that will sink and waste hundreds of hours learning useless garbage like Puppet, Ansible, Chef, Docker or Kubernetes without batting an eyelash or even thinking twice about it, but they'll argue and fight back like hell come time to deliver their software as clean OS packages because they don't want to learn the technology. Technology which exists for them first and foremost: OS packaging is meant to be a developer's tool and best friend.

etaioinshrdlu3• 7 years ago

Literally the reason why PCs won over mainframes. Users want to run the software they want to run.

If you don't trust your users to run software on your server you probably shouldn't let them on your server in the first place... or else contain and isolate them with a VM or similar.

Multi-user operating systems are feeling a bit like they are going the way of the dodo, to me... That is acutall multi-user systems, not user accounts for system services.

Annatar10• 7 years ago

What do you think powers the InterNet that you're connected to right now? Multiuser systems, running applications under different logins. Even the much hated systemd brought physical multiuser computing back to GNU/Linux.

Pneumaticat• 7 years ago

FYI, AppImages do not run anywhere. There are a lot of issues with them in NixOS, since NixOS is all about having explicitly-linked dependencies, and AppImages still often have implicit dependencies that aren't in the image itself, since they are assumed to exist on the host system.

See https://github.com/NixOS/nixpkgs/pull/51060 for an example.

allset_• 7 years ago

It also requires FUSE to work, which may not be available.

tigrezno• 7 years ago

but who really uses NixOS? a 0.001% of linux users?

nyanloutre• 7 years ago

How did you came up with that number ?

majewsky• 7 years ago

In my circle, roughly 30%.

anderspitman• 7 years ago

There are dozens of us.

sjellis• 7 years ago

Yeah, AppImages are not really comparable to snap and Flatpak, which both address this issue by managing shared sets of libraries as well as applications. Flatpak calls these sets of libraries "runtimes", and snap calls them "base snaps". The metadata for each application declares one runtime or base snap that it uses.

This ability to easily provide different userlands to different applications is one of the critical advantages of these new application formats.

ktpsns2• 7 years ago

Something you can do always on a Linux system as a user is to run the AppImage with

  LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH" ./Your*.AppImage

and, before that, put all the missing dynamic libraries in the same path. That task might however be nontrivial due to (hiearchical/nested) dependencies (try "ldd *.so" to inspect it) of the so files itself. That's one of the reasons why we have package managers at the first place...

hardwaresofton3• 7 years ago

Video introduction to AppImage (linked on the AppImage website): https://www.youtube.com/watch?v=mVVP77jC8Fc

Also, a side point -- is it wrong to want people to spend more energy on building fat binaries? To me they are the ultimate in portability (by definition), and investing in projects like musl libc and distributions like alpine, languages like go and rust that build portable static binaries is so much more accessible to me as a developer.

All the approaches to portable apps seem to just be hacking around the problem but I wonder if we should instead be pouring energy into making fully static binaries easier to build, then trying to optimize them to get them smaller.

pknopf• 7 years ago

What if another heartbleed happens? Wouldn't it be better to update a single shared library?

mickael-kerjean• 7 years ago

In theory. In practise it's much faster to push for a fix to your users with a brand new fat binary than having to figure out the mess that is distributing your software on every possible Linux distribution (obligatory XKCD: https://xkcd.com/927/).

Also shared libaries assumed your software will work on a different version of a library which is quite a bold assumption that may or may be true depending on the phase of the moon

earenndil7• 7 years ago

It makes me really sad that this is necessary. Unix has a concept of shared libraries. And somehow it managed to get ruined so irrevocably that there's no going back. This—this was a solved problem! It really was. It was solved, and then we unsolved it when we decided that 'move fast and break things' was more important than ABI stability. And now shared libraries are completely useless. I struggle to name a single useful c library that's useful as a system-wide shared library nowadays. Libc/m doesn't really count because it's part of the language, and libz is small enough that everyone who needs it statically links it. Everything else is neither ubiquitous nor stable enough to be used. HOW DID THIS HAPPEN?

kitotik• 7 years ago

Isn’t cross platform/multi vendor development the cause?

Static binaries are just a form of vertical integration.

earenndil7• 7 years ago

The problem that's being solved is that vendors are incompatible, which could easily be solved if they were compatible. They all run a linux kernel. They all use ELF and x11 and opengl. If I compile 'hello, world' on one distro, I can drop it onto another random distro and it'll still work, but after a certain threshold of complexity, that stops working. It doesn't have to stop working.

vlovich123• 7 years ago

Private developer wants to distribute binary + shared dependency libs. On Windows they package it into an installer which unpacks it into the target destination & everything works. On MacOS the user gets a folder that acts like file within which everything is stored. Additionally there are reliable releases so something targeting a minimum of MacOS 10.14 has a reliable way to specify that in the toolchain & know that the prerequisite runtimes are there (Windows is a bit less elegant here but still manageable).

On Linux you have to provide RPMs for Redhat, DEB files for Debian-variants, ??? for Gentoo users. Moreover, your dependencies have to be managed in a totally bizarre way & you need special launchers to put your shared libraries elsewhere & add them to the path to avoid making assumptions about whether or not the user has the right prerequisites. Or you run your own apt/yum/etc servers to host your packages & play nice within the ecosystem. Additionally, some do periodic releases. Some do rolling releases. Considering how small of a population Linux it makes it more headache than it's worth to target for commercial shops that are cross platform as most of their customers are. That also isn't getting into the mess that 32-bit vs 64-bit is on Linux.

Finally, the big advantage is that the release is done by the author. No more package maintainers providing questionable maintenance across a bunch of distros.

bubblethink• 7 years ago

Finally, the big advantage is that the release is done by the author

I see that as the biggest net win of the current system although it may seem inefficient or bureaucratic. I do not trust the authors. The only modicum of sanity and trust comes from the fact that debain/fedora maintainers are actually on your (the user's) side and have strong rules and guidelines about everything. Desktop linux doesn't have that much meaningful isolation or sandboxing that malicous apps cannot circumvent. It's only now that we are seeing some efforts in this direction. Still, it's quite far from something like android where you can quite safely run arbitrary applications.

earenndil7• 7 years ago

Private developer wants to distribute binary, have system include shared dependency libs because—guess what, they're shared. That's what we could have had. That's the problem this is getting around.

beatgammit3• 7 years ago

It really isn't that hard on Linux. Basically:

1. define your dependencies (try to be conservative so you're not reliant on bleeding edge features) 2. Make a good app that people want with a fairly simple build step 3. Support one or two major distributions 4. Ask for help in bundling for everything else 5. Fix issues as they're discovered

If you ask nicely and people want your app, the community will help you out with the rest. Just look at Steam, which is really only supported on Ubuntu and SteamOS, but is packaged by pretty much everyone.

nemothekid• 7 years ago

It was solved, and then we unsolved it when we decided that 'move fast and break things' was more important than ABI stability.'

I don't believe it was "solved", and I don't believed it was caused by people "moving fast and breaking things".

Linux became HUGE, in terms of the number of people involved, and there is no master body that would govern anything. As an application developer, you could build against libfoo, then your app break on debian because they never updated libfoo besides some strange monkeypatch, and be broken on redhat because they decided to fix bug #12494 differently from the developers of libfoo.

God himself has decided it's too hard, too complex and too much of a clusterfuck of competing motivations to expect that RedHat/Debian/FooBarLinux will reliably all provide the same shared library. And the user doesn't case, bandwidth the cheaper than disk, and its most certainly cheaper that user's time.

earenndil7• 7 years ago

That's a pessimistic and imo unwarranted attitude. There are absolutely platforms that maintain backwards compatibility for decades on end. The most salient example is the linux kernel, but—-well, linux distributions are not a monolith. Fine. How about the c language, or common lisp? Perl packages are installed relatively globally, and things don't really break. And sure there's some fragmentation there, like with sbcl-only lisp packages, or gnu extensions, but by and large I can compile an arbitrary perl/common lisp/c package with an arbitrary implementation of that language and, at least in the case of perl and lisp, it works basically the same way it did 10 years ago. This is possible, because it has happened.

I will grant, however, that it is hard. Newer languages—rust, c#, java, python, js—are trying. Of them I would say rust is the best, followed closely by c#, with python and js taking a distant 3rd and 4th, but none of these match the older languages. But—rust is newer than c# and java and python and js. They decided: we're going to make a high-quality, stable package repository, with a culture of stability in packages. And aside from stuff requiring nightly, that seems to be happening, it's still pretty good, and it's still a hell of a lot better than linux. Granted, linux has a much more difficult situation to wrangle, and because it's less monolithic than those other constructions, tragedy of the commons tends to occur, but I think all it takes is a group of people deciding that they will take the work to make things right, getting support, getting lucky, making a super-dynamic linker, and we can fix this.

flukus3• 7 years ago

I struggle to name a single useful c library that's useful as a system-wide shared library nowadays.

Libcurl is the only one I frequently use that seem to take it seriously, there might be others but frustratingly few will indicate what level of binary compatibility they guarantee, it would be nice to have a list of reliable libraries. Not just for binary compatability but I would be nice to know how much churn you can expect with any given library.

On the other hand, considering the state of the software industry with relation to privacy (including some open source products) running software from arbitrary sources is becoming less and less viable anyway, I'm not sure it's a problem worth fixing.

kbumsik• 7 years ago

HOW DID THIS HAPPEN?

For example, distribution's package update cycle is so slow that some packages are never updated to upstream for some reason. For example, x11vnc's latest version is 0.9.16 but Ubuntu/Debian has locked down to 0.9.13 for more than a half of a decade [1]. ddclient is also a good example [2].

In my case, I made a program that requires >= Python3.6 but I realized Ubuntu was stuck in 3.5 for years so that I was forced to use AppImage to include in-house compiled Python3.6.

Not to mention that Electron apps are simply not compatible with distribution's dependency management.

[1] https://packages.ubuntu.com/search?keywords=x11vnc&searchon=...

[2] https://packages.ubuntu.com/search?keywords=ddclient

curt15• 7 years ago

HOW DID THIS HAPPEN?

Microsoft treats Windows APIs as a contract with the developer, with behavior defined by specifications. Are Linux libraries typically managed that rigorously?

earenndil7• 7 years ago

Linux the kernel does that—see linus's rants about how 'kernel does not break userspace'. Unfortunately, someone decided at some point that versioned libraries should be a thing, and then all hell broke loose when openssl and glibc decided to break compatibility in minor versions so now it's just a free-for-all.

jillesvangurp• 7 years ago

It was never really solved. Shared libraries create huge integration testing headaches and the linux landscape fragmented early. This means that there are a lot of combinations of libraries out there in lots of different versions. Some distributions stick to really old versions of stuff to preserve backwards compatibility. E.g. Red Hat is really awful if you are a developer since it pretty much has the wrong version of anything you'd care about. But I remember this being a real PITA when you wanted to use e.g. the current versions of java, node.js, python or whatever and then realize that all of these basically are 2-3 years behind because the LTS version of the distribution was released just before the major release of what you need. That, and the wide spread practice of engineering around that (e.g. building from source, installing from debian unstable, etc.) results in a lot of problems.

Luckily these days you package the correct versions up as Docker images so, it's much less of an issue. The amount of space you save with sharing your libraries does not really outweigh the benefits of shipping exactly those things you need as a statically linked binary.

Doing the same for user space software makes a lot of sense. Apple figured this out in the nineties already. Mac software never really needed installers. Drag the app to the Applications folder, delete to remove. Just works. The only package managers on OSX are for managing OSS linux software.

dTal• 7 years ago

Nowhere is it written that a system can only have one version of each library. Indeed, there is an entire system (soname) for resolving which of many versions of a library a binary should run with. There is no reason at all why you couldn't have a system where all the libraries are shipped in your application folder, but it uses the system ones where available. There's also no reason why every distro couldn't have every version of every library, and all software since ever would just work with the system version.

Distros screwed the pooch here.

mrkeen• 7 years ago

I hit this when I wrote some C on a modern Ubuntu machine.

I wanted to sort an array based on information in another array. I don't think qsort has the power to do this, so I used qsort_r.

I later found it didn't compile on another system (termux on android) because qsort_r didn't exist there.

I don't feel like 'move fast and break things' is the culprit here (although it undoubtedly is in other cases).

Having qsort_r in some unixes and not others feels wrong. And doing without qsort_r also feels just wrong. I don't know the solution.

baroffoos• 7 years ago

What is the difference between appimage and just a binary marked as executable?

osrec• 7 years ago

It's supposed to contain all its dependencies.

opan• 7 years ago

I'd rather see people use Guix or Nix when their native package manager doesn't have something.

sprash2• 7 years ago

If you want portable apps just make one fully staticly compiled binary.

This is the worst of all worlds. No security updates for used libraries and no performance gain that comes with static linking.

zurn2• 7 years ago

The static linking ship has sailed years ago for glibc based apps (no static linking support).

sprash2• 7 years ago

Always use musl for static linking. As a bonus you might get an even smaller binary than a dynamically linked glibc binary.

hpaavola2• 7 years ago

"To run an AppImage, simply:

Make it executable

$ chmod a+x Subsurface.AppImage

and run!

$ ./Subsurface.AppImage

That was easy, wasn't it?"

No. How about click/double click the app icon in your menu/desktop/the folder where you downloaded it into?

IloveHN84• 7 years ago

You need .desktop files in /use/share/apps

hpaavola2• 7 years ago

I, as a user, do not need any files in /usr/share/apps. The system might need. And I don't want to deal with those.

All other major operating systems (can) work like this; download something > click it > it works. No need to launch terminal, set executable permissions and type the name of file.

shmerl• 7 years ago

Don't forget about trade-offs. Such kind of bundled packages have worse security than distro packaged method, where dependencies are getting patches and fixes. Because most developers won't ever bother patching their bundled dependencies.

So know what you are paying with.

jhoh• 7 years ago

This website just makes me angry:

- Fixed social media share buttons that cover the text on mobile

- It auto-translates to German even though my system language is set to English (seems like they use geolocation for this which is bad practise)

- Center aligned text that is annoying to read

Lowkeyloki• 7 years ago

What I'm disappointed about with AppImage is that it doesn't deal with differing architectures as far as I can tell. Which would really help me right now as I had to send my laptop to Dell for repairs and I'm now using just my Android phone and my Raspberry Pi 3B+ as a desktop. And compiling stuff on the Pi is SO SLOW!

TBF-RnD• 7 years ago

Come on guys, I see a lot of negativity here but we can have the cake and eat it. Look at the following imaginary but likely scenario. A promising coder creates an app in C using cmake or whatever. For a veteran linux user to use git and compile is not a problem. Our up and comming coder want to reach out to a wider audience however so instead of creating X packages he provides an appimage. All of the sudden all the fedora, debian and ubuntu guys etcetera can run it without the hassle.

Now imagine if the project turns out to be a silver bullet for some really important problem. What will happen, the maintainers for the bigger distros will simply download the code and there will be maintainers that steps up and maintains the software for the repos.

Voila, the best of two worlds.

... and if the project doesn't become a huge mainstream access users now can get it via source or appimage .

As far as commercial projects are concerned they will operate according to different dynamics. But who cares we want open source solutions for our linux systems anyway.

zurn2• 7 years ago

Does it work on Android? For cli apps running under adb, at least?

znpy• 7 years ago

Every app packaging its own shared library and runtime because someone didn't want to deal with packaging software.

I foresee someone in five years complaining about how much RAM linux on the desktop uses. And somebody else blaming it on shared libraries not actually being shared because all the "apps" load their own snowflake library. So multiple copies of glibc, multiple copies of gtk, multiple copies of everything.

RIP RAM AND WALLET.

Linux apps that run anywhere

Related Stories