Live data from Hacker News

AppImage: Linux apps that run anywhere

appimage.org

41–50 of 241 posts

Re: AppImage: Linux apps that run anywhere

#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 wonder if people make a big mystery of Linux app distribution on purpose, to discourage distribution outside of proper, secure channels.)

Re: AppImage: Linux apps that run anywhere

#42

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,…

Completely agree with you in regards to Debian packaging. I googled around and found at least 5 different official guides (on the debian wiki) all using slightly different approaches. I tried 3 of them before giving up, as none of them seemed to work.

Oh? The basics are not that hard. dh_make will do most of the work for you.

Re: AppImage: Linux apps that run anywhere

#43
post #7
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.

This. Distro packaged applications are almost always woefully out of date, because they're frozen before the distro is released, and then you use the stable release of the distro for months or years.

But even if distros adopted some kind of half-rolling-release model so applications could be updated quicker, developers either have to manage N different packaging systems (apt, rpm, etc.) or rely on other people to deal with packaging for different distros, and lose control of a crucial part of their user experience.

Then there's dependencies. Linux distros go to one extreme (no bundling), while the popular approach to developing applications is to bundle most libraries so that you know exactly what version you're working with. There are arguments for both approaches, but it's another source of friction between developers and distros.

Distro packaging works for computational infrastructure that's widely used and not changing much, but it's a poor fit for what users and developers expect for actively developed end-user applications.

Re: AppImage: Linux apps that run anywhere

#44

Earlier quoted context omitted.

Completely agree with you in regards to Debian packaging. I googled around and found at least 5 different official guides (on the debian wiki) all using slightly different approaches. I tried 3 of them before giving up, as none of them seemed to work.

Oh? The basics are not that hard. dh_make will do most of the work for you.

The basics may not be that hard, but the multitude of overlapping tools and frameworks that sit on top of them and try to make things easier is seriously confusing and offputting. For instance, there are build tools called dpkg-buildpackage, debuild, git-buildpackage, pbuilder, cowbuilder, and doubtless some others I've forgotten about. Different guides will recommend different ones.

Once you've made a package, you either try to get it into Debian, or put it in your own repository, both of which come with additional challenges.

I've done some Debian packaging before - both to go into Debian and to put in PPAs. I've given it up: the effort was too much and the rewards too little.

Re: AppImage: Linux apps that run anywhere

#45

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…

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

Re: AppImage: Linux apps that run anywhere

#46

Earlier quoted context omitted.

Application binaries must statically link libc and ssl when making programs for packging into appimage?

Maybe not, but Since "Every AppImage contains an app and all the files the app needs to run." Even if you were dynamically linking, you'd be linking against a lib contained in the AppImage. So, each app would still have its own glibc that would have to be updated.

"The AppImage needs to include all libraries and other dependencies that are not part of all of the base systems that the AppImage is intended to run on" [ https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm... ]

Re: AppImage: Linux apps that run anywhere

#47
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.

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!

Re: AppImage: Linux apps that run anywhere

#48
post #18

Earlier quoted context omitted.

People making distos, as well as anyone who has been bitten by unreproducible binaries generated by hand-crafted/manually driven build processes. When I install software from a distro, it's been vetted and I can safely assume the software has a sane reproducible build process, or at a minimum, has had a sane reproducible build process added by the package maintainer. If a new standard wants to solve that process, I'm…

Nobody except weird Linux nerds and developers cares about any of the things you listed. Normal people just want to click a link and have their app install and run.

I don't why you are been down voted. Normal people would to download the s/w , install and run. As a developer sometimes i wish the same as well instead of hunting down dependencies.

Re: AppImage: Linux apps that run anywhere

#49

Earlier quoted context omitted.

Do you have any specific problem with that?

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 applications that people want to use than distros have the resources to issue security updates for.

Post reply on HN