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!
AppImage: Linux apps that run anywhere
111–120 of 241 posts
Re: AppImage: Linux apps that run anywhere
#112On 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…
Re: AppImage: Linux apps that run anywhere
#113On 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
#114Seems 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.
("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"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
What if you want to install the latest version of VLC?
Re: AppImage: Linux apps that run anywhere
#116Why 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…
"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
#117Earlier 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.)
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
#118Seems 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...
Re: AppImage: Linux apps that run anywhere
#119Seems 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…
Re: AppImage: Linux apps that run anywhere
#120What 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…