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

191–200 of 241 posts

Re: AppImage: Linux apps that run anywhere

#191

Post by Pyxl101 »

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…

To elaborate, the GP should have put quotes around command arguments that included variables. For example:

  cp $INSTALLDIR/app AppDir/bin
Should be:

  cp "$INSTALLDIR/app" AppDir/bin

Re: AppImage: Linux apps that run anywhere

#193

Post by zanny »

pdonis wrote: post #164
toyg wrote: post #152

Earlier quoted context omitted.

> preferably with two different managers. That's overcomplicating things. The "user" manager would have to figure out where the specific distribution is storing this or that lib. Doing it reliably across even a small subset of distributions (say, Ubuntu, Debian, Fedora and RedHat) and a small subset of their releases, would be very challenging. It would make much more sense to add a "user mode" option for the likes o…

> It would make much more sense to add a "user mode" option for the likes of apt-get, whereby it does not need sudo and it will install the specified package in ~/bin, ~/usr etc, symlinking necessary libraries. And then any random piece of malware running in your browser can in principle hose all your applications. There's a very good reason that ordinary users do not have write access to application binaries on Linu…

Any proposal of untrusted user level software installation will require, to be legitimate, a well implemented MAC solution to the program. Android actually demonstrates this fairly well using SELinux and app permissions.

New software could present its access requests to the user, to be approved or not. Unapproved or undocumented accesses are also displayed as notifications, where declining the running apps access becomes a permanent rule.

Of course, to standardize such a system across distros, either you need an abstraction layer access management syntax, or you have to get everyone to agree to one of SELinux / Grsec / Tomoyo / Apparmor.

Really though I think the obvious answer is that ten years from now we have something like xdg-app shipping generic usage filters and mandating userspace MAC on new programs, along with an xdg -> distro specific library mapping layer from something like appstream.

Re: AppImage: Linux apps that run anywhere

#194

Post by nickpsecurity »

anonbanker wrote: post #187
toyg wrote: post #149

Earlier quoted context omitted.

The web of dependencies for both build and execution can be maddening. This is why apt-get and yum have won: they take care of finding and downloading those 3246536245 libraries which are absolutely essential for each stupid two-liner application out there. And when it comes to large software (which you probably don't manage on a chromebook), good luck downloading and compiling several GBs of KDE or GNOME source code…

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.

Re: AppImage: Linux apps that run anywhere

#195

Post by lwf »

digi_owl wrote: post #189
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,…

One part of it is that every damn package manager out there (outside of perhaps Nix/Guix and Gobolinux) is hung up on having one canonical version of every lib package. Meaning that the package manager balks at having lib 1.0 and 1.1 installed at the same time, even though ld can handle it just fine, unless you play sleight of hand with the package names (meaning that you get something like lib0 and lib1 for 1.0 and…

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

Re: AppImage: Linux apps that run anywhere

#196

Post by _ZeD_ »

FooBarWidget wrote: post #115
_ZeD_ wrote: post #104

"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

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?

Re: AppImage: Linux apps that run anywhere

#197

Post by digi_owl »

lwf wrote: post #195
digi_owl wrote: post #189

Earlier quoted context omitted.

One part of it is that every damn package manager out there (outside of perhaps Nix/Guix and Gobolinux) is hung up on having one canonical version of every lib package. Meaning that the package manager balks at having lib 1.0 and 1.1 installed at the same time, even though ld can handle it just fine, unless you play sleight of hand with the package names (meaning that you get something like lib0 and lib1 for 1.0 and…

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 would be able to traverse the tree and see if foo 1.0 could be discarded or not based on the dependencies listed in other packages.

You get something of this nature in Nix (though they take it one step further) and Gobolinux, by using the directory tree as the final arbiter.

On Gobolinux you have /Programs/name/version, thus installing foo 1.0 would end up in /Programs/foo/1.0, while foo 1.1 ends up in /Programs/foo/1.1.

Then as long as you have one or more programs installed that need 1.0, you can leave it in place, and remove it when no longer needed.

For sake of compatibility, Gobolinux also have a /lib (along with the rest of the FHS) that contains symlinks back to the individual lib files in /Programs, using SONAME to its full potential.

Re: AppImage: Linux apps that run anywhere

#198

Post by digi_owl »

anonbanker wrote: post #185
jessaustin wrote: post #144

Earlier quoted context omitted.

Why would "building from source" be a difficult way to create a package? ISTM that if you have any software at all, it's already building from source? I understand that building from source is considered difficult for users, but here you seem to be talking about maintainers. Or do you mean setting up $#%&ing autotools? In that case I agree.

the dependency hell from building from source is slightly less of a purgatory than that coming from anything above it. That includes the headaches of autotools.

I dunno, Gobolinux is pretty much LFS with addition layer of tools. And more often than not, the problem is that of developers doing a crap job of actually documenting their dependencies (or hardcoding paths and/or filenames).

Re: AppImage: Linux apps that run anywhere

#199

Post by fredsir »

toyg wrote: post #178
matzipan wrote: post #158

Earlier quoted context omitted.

I've been spending a lot of time in the embedded area lately (sub-200Mhz 32k RAM automotive systems, firmware and fpgas) and I agree with you. But there's always tradeoffs. In this case you're trading some memory (which is cheap nowadays) for up-to-date, secure, usable apps, which seems to be a pretty complex thing to do. Nobody solved it so far. The people using node-webkit are offloading the library compatibility i…

Or in other words, they use a poor man's Java vm, except bigger and more fragile.

To be honest, chrome-"native"-packaged-webapps, or what you wanna call them, feels a whole lot better to use than any java based GUI app I have ever used, including JetBrains products.

I hate to use any of these chrome-"native"-packaged-webapp, though. I just hate java based GUI apps more.

Re: AppImage: Linux apps that run anywhere

#200

Post by vacri »

SwellJoe wrote: post #89
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,…

Debian packaging isn't too awful, though I don't like how many files are involved (I prefer a single spec file, plus patches, as found in RPM). But, apt repository management is truly terrible. The documentation is laughably bad and disjointed, and it points to several different tools and processes that may or may not work together; my Debian/Ubuntu repo generation script is a ridiculous mishmash of stuff that kinda…

> But, apt repository management is truly terrible.

Aptly is a relative newcomer to the scene that makes repo creation/management much easier. It's actively developed.

http://www.aptly.info/

Post reply on HN