131–140 of 241 posts
Earlier quoted context omitted.
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?
With APT you can run apt-get purge to delete most configuration files and such, if it is packaged properly.
Earlier quoted context omitted.
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)
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
You can use either static or dynamic linking. An AppImage is really just an ISO container wrapping around your binaries.
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]
Earlier quoted context omitted.
You can use either static or dynamic linking. An AppImage is really just an ISO container wrapping around your binaries.
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]
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.
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.