Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AppImage: Linux apps that run anywhere

appimage.org

Post reply on HN
Print view View original

201–210 of 241 posts

Re: AppImage: Linux apps that run anywhere

#201

Post by anonbanker »

nickpsecurity wrote: post #194
anonbanker wrote: post #187

Earlier quoted context omitted.

running/building a full plasma 5.5 KDE 5.x current. Full install including most office apps (Libreoffice, etc), a bunch of emulators/games (free and proprietary - steam included), and other apps. Intel haswell/sandy bridge chromebooks with custom hard drives. I think you're greatly overestimating how difficult it is to maintain all of this on Portage. I invite you to try a distribution that isn't Debian or Redhat-bas…

A comment like this is even better if you mention what distro you were using and maybe drop a link to a guide showing how easy Portage is to use. Then, people might experience what you describe.

I already mentioned in the great-grandparent that I was doing this with Gentoo and Calculate linux (which are interchangeable).

I try not to specifically invite people to "install gentoo" thanks to /g/. they'll find it on their own. There's a lot of learning before quickpkg makes an install take 3-5 minutes.

Re: AppImage: Linux apps that run anywhere

#202

Post by nickpsecurity »

anonbanker wrote: post #201
nickpsecurity wrote: post #194

Earlier quoted context omitted.

A comment like this is even better if you mention what distro you were using and maybe drop a link to a guide showing how easy Portage is to use. Then, people might experience what you describe.

I already mentioned in the great-grandparent that I was doing this with Gentoo and Calculate linux (which are interchangeable). I try not to specifically invite people to "install gentoo" thanks to /g/. they'll find it on their own. There's a lot of learning before quickpkg makes an install take 3-5 minutes.

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.

Re: AppImage: Linux apps that run anywhere

#203

Post by e12e »

brbsix wrote: post #73
vbernat wrote: post #62

Earlier quoted context omitted.

That's hardly related to a package manager. You can for example run Debian unstable to get more up-to-date stuff or mix Debian Jessie with backports. Same package manager, different sources.

I think the whole point of OP is to have completely separate installs (e.g. system apps installed in one root and user apps in another). If you go installing latest apps from different sources/repos, you're bound to face conflicts with the system packages. E.g. while installing packages with CPAN or pip, it is really easy to cause conflicts with the system Perl or Python, respectively. Right now there are lots of var…

FWIW, it's generally a bad idea to mix in testing and unstable in a stable system (or even just testing). My recommendation is to run stable along with backports (if needed) -- and use something like schroot[1] for running persistent (separate) sessions under testing, unstable etc.

Schroot essentially wraps up debootstrap and chroot along with mounting /proc etc, and (optionally) bind-mounting /home (which among other things gives access to x11 session cookies, for sharing one xorg display -- so one could run firefox, gimp or mplayr from an unstable-chroot on a stable system). Overall, with SSD prices dropping as sizes are increasing -- it might be better to simply use vms (one of the nice (potential) things about rkt -- the ability to run a "container" under kvm, turning it into a vm).

[1] https://wiki.debian.org/Schroot

Re: AppImage: Linux apps that run anywhere

#204

Post by pmontra »

takluyver wrote: post #78
jessaustin wrote: post #61

Earlier quoted context omitted.

Sure, you're boned if the security flaw is in the custom protocol handler of some random package of which you are one of 37 total users. Typically, however, security code does not reside in such packages. They typically link to popular libraries for e.g. TLS support. Those popular libraries are kept current by reputable distros. You shouldn't be using low-volume packages that implement their own security, anyway.

One of the packages in the article I linked above was Wordpress, which is not exactly low volume. I work on the Jupyter/IPython notebook - we found a security bug last summer, got a CVE (CVE-2015-5607), issued patches... and the version in Debian unstable hasn't been fixed, seven months later. If distros can't do security maintenance for the software people use, claiming that they shouldn't use that software at all i…

I didn't even know that Debian has a WordPress package. I always downloaded it from here https://wordpress.org/download/ and applied updates as soon as my WP servers ask me to. I don't trust Debian mantainers to be faster than that.

As a comparison: WordPress is at 4.4.2, Debian 8 has it a 4.1 and Debian 7 at 3.6.1. You can't use those, you must use the one from the developers.

Same thing for example with Ruby: Debian 8 is stuck with 2.1.5 (November 2014), which is not even the latest one of the 2.1 series. The current version of the language is 2.3. And Node.js? 0.10.29 (June 2014). Again, you can't use the packaged versions and you must go to the developers, maybe through rvm, nvm or other language specific package managers. I really don't understand why they bother packaging those languages. They should have tiny packages that explicitly tell that you are on your own and redirect to the appropriate package manager for the language.

Re: AppImage: Linux apps that run anywhere

#205

Post by xorcist »

sillysaurus3 wrote: post #186
otabdeveloper wrote: post #41

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…

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 arcane one at that) but at least lets you avoid the easy traps. Also, indent and comment. Surprisingly many people seem to think hygiene is somehow less important outside their main language.

On a side note, what's up with not reading manuals these days? When I am tasked with something new, no matter how trivial, my first step is to at least skim the manual get a feel for what the problem domain looks like and how you are supposed to wield the tool I am about to use. Turns out nobody does that anymore. Zero, out of over a dozen people in my closest (java, web) team have read the documentation for the product we build on. I find it unprofessional, but I realize I'm the strange one and it's probably just me getting older.

Re: AppImage: Linux apps that run anywhere

#206

Post by anonbanker »

nickpsecurity wrote: post #202
anonbanker wrote: post #201

Earlier quoted context omitted.

I already mentioned in the great-grandparent that I was doing this with Gentoo and Calculate linux (which are interchangeable). I try not to specifically invite people to "install gentoo" thanks to /g/. they'll find it on their own. There's a lot of learning before quickpkg makes an install take 3-5 minutes.

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 tool to learn linux. By the end, you have an expert's understanding of how Linux works, and how to install it without a GUI (or even a package manager). I learned it during the "Stage 1 era", when the install started with bootstrapping, then building your compiler before installing the rest of your system. Nowadays, you partition disks, format, chroot in, set timezone and encoding, untar the stage 3 tarball, emerge --sync, build your kernel (which is the hardest part), install a bootloader, install wpa_supplicant, and you're done. It's about 30% more difficult than an Arch install, becuase you probably will screw up your first kernel configuration and make a nonbooting kernel, booting to a black screen. But unlike Other OS's and distros, when it breaks in Gentoo, it's probably your fault.

I have way less headaches, because chromebooks are braindead to deploy this way. flash a bios, and then install the binaries once booted off a LiveUSB. Quickpkg allows you to make binaries of your existing system (built for Sandy Bridge, until I decommission the C710's, then I'll build for haswell) with all your custom flags already set, so VLC and other apps are far more robust than their Ubuntu/Redhat versions. Gentoo is also the only distro other than GalliumOS that actually has working Elan touchpads for many chromebooks (thanks to Hugh Greenburg of GalliumOS's patches that I'm maintaining for newer kernels), as the patches have not been included in Arch or other distributions's kernels.

I run a Poettering-free install (JACK instead of PA, wpa_gui instead of NetworkManager, OpenRC instead of systemd), so having one master install I can re-deploy in the amount of time it takes to brew coffee is pretty handy, especially considering de-poetterizing a new Debian/RHEL/Fedora/Arch install is painful, if not nigh-impossible, and at the very least time-consuming.

Re: AppImage: Linux apps that run anywhere

#207

Post by vpkaihla »

anonbanker wrote: post #110
drdaeman wrote: post #24

I believe the core problem here (that led to containerization, application images and alike) is that correct packaging for most distros is hard. There are tools like fpm or even checkinstall that can build simple good-enough-but-not-really packages, but I think maintaining a "proper" Debian packaging requires some pretty arcane knowledge that's spread around various pieces of documentation (and maybe I'm just stupid,…

Ranking package managers by difficulty of creating packages (1-10, lowest to highest): 1. tarballs (slackware) 2. Ports (FreeBSD) 3. Portage (Gentoo, Calculate Linux) 4. pacman (Arch, Archbang, KaOS, Manjaro, Antergos) 5. building from source (Linux From Scratch, Most old installs eventually turn into this) 6. rpm (Redhat, Mandriva, Scientific Linux, UnitedLinux) 7. deb (Debian, Ubuntu, Mint/LMDE, Hanna Montana Linux…

Perhaps it's slightly subjective, since I would place FreeBSD ports in between rpm and deb in terms of difficulty.

Re: AppImage: Linux apps that run anywhere

#208

Post by chei0aiV »

sillysaurus3 wrote: post #186
otabdeveloper wrote: post #41

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…

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…

Some commands that can help with nuances of shell:

Check syntax:

sh -n myscript

Check for bash-specific syntax:

checkbashisms myscript

Check for various gotchas:

shellcheck myscript

Check for style:

bashate myscript

Check for badness:

grep -rE '(wget|curl).\|( sudo)? *(ba|z|)sh' myscript

Re: AppImage: Linux apps that run anywhere

#209

Post by chei0aiV »

lukaslalinsky wrote: post #118
probonopd wrote: post #45

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.

If you don't have Linux in each app bundle, it won't run everywhere. Linux breaks userspace ABI sometimes.

Re: AppImage: Linux apps that run anywhere

#210

Post by chei0aiV »

digi_owl wrote: post #197
lwf wrote: post #195

Earlier quoted context omitted.

There's nothing fundamental that means that has to be the case; in fact, Debian does (in some cases) ship multiple library versions in a stable release. The primary reason this is usually not done is the work required: it means you need to support two versions in stable, two (or more?) versions in unstable, &c. This quickly becomes a great deal of work :)

Err, their solution is the one i lay out in the second paragraph, where foo 1.0 becomes foo0 1.0, and foo 1.1 becomes foo1 1.1 simply to get around package manager limitations. That is where the extra workload is coming from, the need to juggle effectively two package trees, and the patches for each. If instead the manager was properly able to handle multiple versions, they could all be named foo, and the manager wou…

I think lwf was talking about the human cost of having two versions. That doesn't go away when they are both named foo instead of foo0 and foo1.
Post reply on HN