Live data from Hacker News

AppImage: Linux apps that run anywhere

appimage.org

111–120 of 241 posts

Re: AppImage: Linux apps that run anywhere

#111
post #32

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.

Well, first of all AppImageKit is not a package manager. For a comparison with xdg-app and other systems, see https://github.com/probonopd/AppImageKit/wiki/Similar-projec... 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 - thoughts and pull requests welcome!

Why are you not using containers for sandboxing?

Re: AppImage: Linux apps that run anywhere

#112

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…

[deleted]

Re: AppImage: Linux apps that run anywhere

#113

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…

   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?

Re: AppImage: Linux apps that run anywhere

#114

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…

Everything seem complicated when you dont properly understand the problem.

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)

Re: AppImage: Linux apps that run anywhere

#115
post #104

"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

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?

Re: AppImage: Linux apps that run anywhere

#116
post #9

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

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?

Re: AppImage: Linux apps that run anywhere

#117
post #7

Earlier quoted context omitted.

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.

Then use one of the many available PPAs? If the package is so unique that no one maintains a PPA, then chances are that no one maintains an AppImage either. In that case, build from source. (Pro tip: when building from source, install using GNU stow so you can easily uninstall as well.)

But as a developer you don't want to build a gazillion of packages to be able to reach many users.

Building from source? Please try to imagine this from the point of view of users who aren't so technically expert as you are. They just want to, for example, run the latest version of VLC.

Re: AppImage: Linux apps that run anywhere

#118

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…

Yes, except that you might want to be a bit more selective in which parts you use from the base system and which parts you want to bundle - some people might not want to have e.g. glibc in each app bundle. This is where it starts to become a little more complicated than the above, see https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm...

If you don't have glibc in each app bundle, it won't run everywhere. Different distros have different versions of glibc and it's very easy to end up in a situation where you use some symbol that's not defined in the system one.

Re: AppImage: Linux apps that run anywhere

#119

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…

[deleted]

Re: AppImage: Linux apps that run anywhere

#120
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…

There's also NIX, which I think does a good job of issolation in user space. https://nixos.org/nix/
Post reply on HN