Live data from Hacker News

AppImage: Linux apps that run anywhere

appimage.org

151–160 of 241 posts

Re: AppImage: Linux apps that run anywhere

#151

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 do…

As to 1.) you downloaded the app (.appimage) and double clicked on it. Why? Nowhere in any documentation does it say that .appimages are executable out of the box. In fact this is a security feature that it doesn't. IN all placves that I have seen .appimages available there is a statement that says the user has to go into permissions and make the file executable before it will run. Makes sense since most malware is m…

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

In fact, just above the download button for the GP's download, it tells you to make it executable before running.

Re: AppImage: Linux apps that run anywhere

#152

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…

> preferably with two different managers.

That's overcomplicating things. The "user" manager would have to figure out where the specific distribution is storing this or that lib. Doing it reliably across even a small subset of distributions (say, Ubuntu, Debian, Fedora and RedHat) and a small subset of their releases, would be very challenging.

It would make much more sense to add a "user mode" option for the likes of apt-get, whereby it does not need sudo and it will install the specified package in ~/bin, ~/usr etc, symlinking necessary libraries. That doesn't seem too hard to pull off, in theory.

Re: AppImage: Linux apps that run anywhere

#153
post #123

Earlier quoted context omitted.

I wastes memory too, having multiple copies of the same shared libraries loaded.

Memory spend on executables isn't a bottleneck even on mobile. You are getting into embedded territory for this to become an issue.

I really hate that people have this idea. It's why people create apps which consist of a built in web server their own copy of chrome that connects to said server.

In the end something that ought to have taken 10mb of space and 20mb of ram requires 100mb of space and half a gig of ram and still manages to be slow on a new system at operations that ought to have been fast on a ten year old machine.

Down with the Javascript generation.

Re: AppImage: Linux apps that run anywhere

#154

Earlier quoted context omitted.

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.

Oh? The basics are not that hard. dh_make will do most of the work for you.

Debian packaging basics aren't hard once you know them, but starting from scratch, it's hard to collate the information. There's lots of stale information out there (including the debian wiki) and disagreement about how to do it - debuild? dh_make? dpkg directly? tar/ar manually?

Similarly, if you want a package up something without a Makefile, you may as well go home. My first packaging attempt was basically to install a tarball at a location (in-house use only), and it wasn't clear that I had to make a Makefile to do this first. And then you get introduced to the bizarre world of make with all of it's idiosyncratic rules and behaviours.

Then you get to play with all the dpkg control files, and if you're using debuild, you have to avoid the lintchecker - because you can override lint rules... but the lint profile then disables overrides for some useful ones (the "install to /opt" rule gives me lots of spam). So now you need to learn about the lint-checker so you can do your own profile (or just disable it).

Then, as takluyver says above, you get to add it to a repo so systems can access it...

Once you know all this stuff, it seems pretty simple, but getting over that hump is difficult.

Re: AppImage: Linux apps that run anywhere

#155

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 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 wonde…

Ohh, yeah, so you force everybody to understand the command line when something does not work as expected.

95% of the way means it is not finished. When I buy a car the seller better does not say that the car works 95% of the time.

Installing something in millions of computers is hard. We do it. Being able to install something on one computer with a person that is a computer programmer with 20 years experience with the command line is completely different from making it to just work for millions of people.

Apple actually makes it work for millions of people in a very simple and elegant way. As a geek I could use homebrew or any other system in Linux if I want, but Apple's system works great for most people.

Re: AppImage: Linux apps that run anywhere

#156
post #143

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…

Yea I never understood why there's no separation between these two. The fact that apt-get needs root password only makes sense if apt-get is meant for system packages. User applications should not require root privileges to install.

Installers regularly install packages to system dir because it would be idiotic on a multi user system for each user to install different versions of Firefox to their home dir.

It also serves to keep unprivileged users from installing software.

You are free to install software to your home but it shouldn't be the default behavior

Re: AppImage: Linux apps that run anywhere

#157
post #107

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…

Not everyone has root on their Linux box and even if you do, you ought to be able to install applications as you without sudo'ing anything. Right now most Linux applications guide you to a deb/rpm which runs as root (and who knows if you can trust it). TBH this is just the start of making applications more secure, they ought to be sandboxed too, so one application can't read the data from another application by defau…

You actually cannot make malicious applications safe you can however make nonmalicious applications inconvenient.

Re: AppImage: Linux apps that run anywhere

#158

Earlier quoted context omitted.

Memory spend on executables isn't a bottleneck even on mobile. You are getting into embedded territory for this to become an issue.

I really hate that people have this idea. It's why people create apps which consist of a built in web server their own copy of chrome that connects to said server. In the end something that ought to have taken 10mb of space and 20mb of ram requires 100mb of space and half a gig of ram and still manages to be slow on a new system at operations that ought to have been fast on a ten year old machine. Down with the Javas…

I've been spending a lot of time in the embedded area lately (sub-200Mhz 32k RAM automotive systems, firmware and fpgas) and I agree with you. But there's always tradeoffs. In this case you're trading some memory (which is cheap nowadays) for up-to-date, secure, usable apps, which seems to be a pretty complex thing to do. Nobody solved it so far. The people using node-webkit are offloading the library compatibility issues to the people who built Chromium and are provided with a consistent container to run their application in.

Re: AppImage: Linux apps that run anywhere

#159

Earlier quoted context omitted.

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)

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.

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.

Re: AppImage: Linux apps that run anywhere

#160

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…

If you don't share common dependencies you're doomed to have security hazards.

Consider it this way: if you install package FOO with its dependencies A,B and C, and FOO's developer thinks it's "feature complete", the package will never be updated, but every time a vulnerability is disclosed in his dependencies you'll be it. For _every_ program maintained this way.

Post reply on HN