Live data from Hacker News

AppImage: Linux apps that run anywhere

appimage.org

221–230 of 241 posts

Re: AppImage: Linux apps that run anywhere

#221
post #57

Earlier quoted context omitted.

I agree, sandboxing is a must-have feature. xdg-app has a system of runtime so it can run on any distro as long as you have installed the runtime needed by the app. Also GNOME and Papyros will have it while KDE seems interested in it also so it should have quite a lot of support.

xdg-app looks good, but I think we're still at least a couple of years away from the point where a developer can use xdg-app to reach the majority of desktop Linux users. That's a long time in software development terms.

You can ship xdg-app + your app in the meantime? Consider it a 'polyfill'. Some best practices around this would be great.

Re: AppImage: Linux apps that run anywhere

#222

Earlier quoted context omitted.

I think you meant "$@" rather than $* (The quotes in "$@" are important.) Also, your script will fall over if any of the paths have spaces in them, such as INSTALLDIR. You should use lowercase for variable names like SCRIPT_PATH. Uppercase is for exported variables. readlink -f $0 breaks on OS X. You must do both readlink -f $0 and readlink $0 in order for it to work everywhere. Shell scripting isn't easy. It took a…

> Shell scripting isn't easy. It took a year to understand That might make it seem like too hard for some people. It's really not that bad. These particular mistakes were beginner's mistakes. But it is tricky! I usually try to tell people to avoid writing shell scripts until you've at least read the "Bash Beginners Guide" or something similar. It's comparably short (remember, you're learning a new language and an arc…

> On a side note, what's up with not reading manuals these days?

The difficulty of finding manuals, and when you do, they're badly written in such a way that they assume all sorts of contextual knowledge based around the sorts of problems the author of the software was trying to solve in 1986 or whatever year. Manual writing is at least 1000x more difficult than bash scripting, because you have no way of knowing up front how the target "machine" is going to interpret your "script".

And of course that's all assuming a manual even exists at all.

Re: AppImage: Linux apps that run anywhere

#223

Earlier quoted context omitted.

Gotcha. But thanks to /g/? Didn't know that existed so how would I have found it on my own? And "lots of learning" despite you having way less headaches? I'm a little confused as some of your answers inspire more questions.

/g/, the technology troll board of 4chan, has a meme of "install gentoo" whenever someone says "which is the best distribution to install for a new user?" Those users usually come back about a week later hating everyone for putting them with such a difficult OS. Calculate Linux has effectively removed most of this barrier, though, making Gentoo really easy to maintain for newbies. The Gentoo Handbook is an amazing to…

re /g/

Haha. That is pretty evil given my experiences starting with command line Linux back in the day. Far as learning, I've heard that before about Gentoo. Thought about doing it at some point. Right now, kind of mixed between learning BSD or Linux as the security enhancements I create might need to temporarily stay proprietary to support their development. BSD vs GPL you know. I mean, I'd give back bug-fixes or feature developments where possible but differentiator has to be secretish.

"But unlike Other OS's and distros, when it breaks in Gentoo, it's probably your fault."

I'm avoiding that right now but fine with the concept. Reminds me of Mentor's Hacker Manifesto we used to quote to justify such responsibility.

"so having one master install I can re-deploy in the amount of time it takes to brew coffee is pretty handy"

That is handy. I've always especially liked how the source-based distros were customized to one's own hardware. That drastically increases the initial deployment time but significantly reduces many issues along the way.

Re: AppImage: Linux apps that run anywhere

#224

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…

That depends on your target user. I can't imagine asking my parents to run your script (even if it was packaged up as a single file), but I'd like to think that they could run something like AppImage without too much problem.

Re: AppImage: Linux apps that run anywhere

#225
post #190

Earlier quoted context omitted.

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. Sure, but literally the first thing on the landing page is... > 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.

On my windows box, if I download an exe, windows won't let me run it until i go and "unblock" it. So it seems the experience is sort of similar.

Re: AppImage: Linux apps that run anywhere

#226
post #212

I wish we could kill this idea that the Windows/Macintosh model of running around the web finding random binaries to install is a good one. Every time I have to use a Mac or Windows machine and do this I find it a major chore, and also get pretty firmly freaked out by the number of spoof application homepages with trojaned installer "bundlings" you see flying around the web. could be an easy mistake to make for a les…

as long as you do proper signing of code, reproducible builds, then your security concerns go away. https://defuse.ca/triangle-of-secure-code-delivery.htm

Re: AppImage: Linux apps that run anywhere

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

Wouldn't this raise the issue of application updates ? If the app imports its own libraries, who will take care to update them if a security issue is detected ? That's the point to enforce using shared libraries on unix system.

Re: AppImage: Linux apps that run anywhere

#228

Earlier quoted context omitted.

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…

I am sorry, but if YOU, the author, will ship MY GPLed library with YOUR application, then YOU are FORCED to open YOUR code under MY terms. Understand? Don't steal my code, please. Don't bundle it with your proprietary app without my written permission.

What does the GPL or using libraries have anything to do with the topic discussed?

Re: AppImage: Linux apps that run anywhere

#229
The problem boils down to shared library version number compatibility. The idea of shared libraries is to reduced storage space (disk and memory) at a processing price overhead. Note that this storage constrain becomes less critical these days.

Another benefit of shared libraries is security fixes and this becomes more and more important.

The only solution I see is that distros must preserve the role of shared library managers and support cohabitation of many library versions. The shared libraries have been designed to support this cohabitation. Any app that doesn't support this cohabitation should be fixed or rejected.

Shared libraries should have a version release and patch number. The apps should only depend on version and release number. The patch number is for bug fixes.

Users ahould have specific permissions to add new software, which can be enforced by write access to the shared library directory. Users should not be allowed to install crappy and insecure software/libraries on computers shared with other users.

Re: AppImage: Linux apps that run anywhere

#230
post #196

Earlier quoted context omitted.

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?

linux repositories, whatever distro you choose, are great because of that: I don't trust $developerfoo or $startupbar, I just trust my distro packager. BTW: normally I don't care if I don't use the latest latest version of $program. Do you REALLY need to always get the latest tip of git of every program you use? oh, and who said to you the latest version of $program is packaged?

Sometimes you just need the latest version. KiCAD has recently gone through development sprint after being dormant for years. My distro offered ancient version without new features. After trying to resolve source building dependencies for an hour, I just ran latest windows binary using Wine, and had no issues using it. It was bizarre experience.
Post reply on HN