AppImage: Linux apps that run anywhere • Hacker News Board

Re: AppImage: Linux apps that run anywhere

#61

Post by jessaustin » Sat, Feb 27, 2016, 5:36 PM UTC

takluyver wrote: post #49

kiallmacinnes wrote: post #17

Earlier quoted context omitted.

I'm not hrtghrth3, so can't speak for him... but.. Yes, I have a problem with that. I trust I can count on Debian/Ubuntu/RHEL will ship a new package for every critical CVE promptly, without forcing me to upgrade to the latest upstream version. I have zero faith upstream maintainers will do the same - which leaves me with two choices 1) Pretend there is no CVE 2) Use the latest app version, bringing with it all new b…

> I trust I can count on Debian/Ubuntu/RHEL will ship a new package for every critical CVE promptly, without forcing me to upgrade to the latest upstream version. There was an article just a couple of weeks ago pointing out that distributions frequently don't fix security issues: https://statuscode.ch/2016/02/distribution-packages-consider... No doubt it's better for high-profile applications, but there are far more…

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.

Re: AppImage: Linux apps that run anywhere

#62

Post by vbernat » Sat, Feb 27, 2016, 5:39 PM UTC

matzipan wrote: post #59

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…

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.

Re: AppImage: Linux apps that run anywhere

#63

Post by jessaustin » Sat, Feb 27, 2016, 5:41 PM UTC

cwyers wrote: post #7

subway wrote: post #3

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. Please pull over. I want off this ride. Why the hell are we regressing to shipping around hackily built binaries?

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.)

Re: AppImage: Linux apps that run anywhere

#64

Post by ronjouch » Sat, Feb 27, 2016, 5:42 PM UTC

I'm confused and couldn't find an answer searching for "xdg-app" in AppImage's website/github. Is this a whole alternative to xdg-app, or a layer on top of it?

If it's indeed an alternative, why would anyone choose this rather than xdg-app? xdg-app being backed by fedora/freedesktop/gnome folks might mean more traction and maintenance, doesn't it?

EDIT: okay, saw https://github.com/probonopd/AppImageKit/wiki/Similar-projec... mentioned below by the author, sorry for the noise.

Re: AppImage: Linux apps that run anywhere

#65

Post by takluyver » Sat, Feb 27, 2016, 5:43 PM UTC

ugos wrote: post #57

yrro wrote: 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.

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.

Re: AppImage: Linux apps that run anywhere

#66

Post by matsemann » Sat, Feb 27, 2016, 5:43 PM UTC

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…

Everything seem complicated when you dont properly understand the problem.

Re: AppImage: Linux apps that run anywhere

#67

Post by theon144 » Sat, Feb 27, 2016, 5:45 PM UTC

This seems like it does fill a need, but what I'd really rather avoid the Windows scenario, where each and every single app has its own auto-update manager - in addition to the system update manager. That just becomes a redundant mess very easily.

Re: AppImage: Linux apps that run anywhere

#68

Post by vbernat » Sat, Feb 27, 2016, 5:46 PM UTC

currysausage wrote: post #27

thriqon wrote: post #13

Earlier quoted context omitted.

So, the problem is not package managers per se, but the velocity of updates? Fix that instead? (see Arch Linux).

What if I prefer a predictable release cycle for the base OS, but still need the latest LibreOffice/VLC/_____ for one reason or another? I like the approach taken by e.g. Nginx and MariaDB, where I add additional vendor repositories, but this workflow is probably neither user-friendly enough for my mom, nor have all vendors the resources to maintain several repositories for different distributions and their respectiv…

Use an OS with backports, like Debian. For example, if you took Debian Jessie, you could pull LibreOffice 5 from backports. VLC is already almost up-to-date (2.2.1).

Re: AppImage: Linux apps that run anywhere

#69

Post by matzipan » Sat, Feb 27, 2016, 5:49 PM UTC

vbernat wrote: post #62

matzipan wrote: post #59

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…

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.

What I'm suggesting is a decoupling between system package managers and application image managers (which should run across distributions/versions).

Edit: thinking about it, this should also be the perfect opportunity for a cross-distribution app store/center.

Re: AppImage: Linux apps that run anywhere

#70

Post by DanielDent » Sat, Feb 27, 2016, 5:49 PM UTC

tshtf wrote: post #56

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.

The cost of the certificate is a very small part of the overall cost of a proper SSL/TLS implementation.

If you don't want to exclude older browsers, you need a dedicated IP address, or you need a system to manage putting multiple names on one certificate. Let's Encrypt is a great option for multi-SAN certificates, as long as you don't care about Windows XP users.

If you have any kind of redundancy, doing perfect forward secrecy gets much harder. The open source approaches to scaling TLS along with PFS are bleeding edge, poorly documented, and may involve writing some code.

I agree, TLS everywhere is a worthy goal. But I think it's easy to underestimate how complicated it can get, especially at scale.