Live data from Hacker News

AppImage: Linux apps that run anywhere

appimage.org

161–170 of 241 posts

Re: AppImage: Linux apps that run anywhere

#161

Earlier quoted context omitted.

Memory spend on executables isn't a bottleneck even on mobile. You are getting into embedded territory for this to become an issue.

I really hate that people have this idea. It's why people create apps which consist of a built in web server their own copy of chrome that connects to said server. In the end something that ought to have taken 10mb of space and 20mb of ram requires 100mb of space and half a gig of ram and still manages to be slow on a new system at operations that ought to have been fast on a ten year old machine. Down with the Javas…

The software that we build tends to gain layers. In theory, each layer adds new functionality that couldn't be done on a lower layer. The problem comes when someone unnecessarily implements lower functionality in an upper layer (like reading local files through a web server). It happens because systems are too complex now for a specific dev to know every layer, and new hardware is fast enough that it doesn't matter that you're taking an order of magnitude more resources than you actually need to do the task.

Re: AppImage: Linux apps that run anywhere

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

GNOME is working on it: https://wiki.gnome.org/Projects/SandboxedApps

Re: AppImage: Linux apps that run anywhere

#163

This is missing the point. Linux distributions do not lack package management options, they lack stable and sane APIs for developers to work against. No amount of static linking and binary bundles can fix that.

Yup, and it seems we forgot about static linking, then broke it, and now are reinventing it in new and convoluted ways.

I do think Linux could make smarter use of static linking in places. Weird, esoteric and tiny libraries with unstable APIs make terrible shared libraries and are a constant source of irritation.

Static linking has it's place, and so does shared libraries.

Re: AppImage: Linux apps that run anywhere

#164
post #152

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…

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

Re: AppImage: Linux apps that run anywhere

#165
post #22

TL/DR: Let's take the broken app model that lets people download and run buggy, virus-infected programs on Windows and OS X, and bring it to Linux!

Every model ever devised lets people run buggy programs. If I couldn't run buggy programs, I wouldn't be able to run any programs at all.

> Every model ever devised lets people run buggy programs.

There's a big difference between:

(1) A user being able to run buggy programs if someone is able to hack the secure distribution chain or if someone is able to get the user to give root permissions (or any permissions other than those of their ordinary user account) to a piece of malware;

and

(2) A user being able to run buggy programs because the default app model on their system dumps all app binaries into their ordinary user account's data area, with that user having write access to all the files, so any random piece of malware running as that user can hose them.

Re: AppImage: Linux apps that run anywhere

#166

Earlier quoted context omitted.

If one can't build a server app from source then one shouldn't be connecting it to the internet all by oneself. There are any number of companies who are happy to host WordPress for reasonable fees. Keeping software updated is hard work, and those who do it for free will keep their own schedules. I'm sure it's frustrating to maintain a package that's "in the middle": too popular to just say "install with pip", not en…

If building it from source is acceptable, why would using packages direct from the maintainers not be? For anything in an interpreted language, there's little difference anyway. I agree that Debian is too accepting of packages. We don't recommend that anyone installs Jupyter/IPython with apt, and I wouldn't mind if Debian removed it from the repos. But if there are all these packages that shouldn't be distributed thr…

I think it's perfectly acceptable for project maintainers to provide rpms, debs, ppas, etc. as long as those artifacts are organized in largely the same way that distro maintainers would organize them. (I doubt any distro maintainers would disagree.) I don't think it's a good idea to pack lots of already-distro-packaged libraries into those artifacts. Building for many distro formats is a pain, but I doubt that building this new format in a universal way will be easy either. If you have a different AppImage for each distro/version combo, is that an improvement?

For the packages you've mentioned, live active projects with maintainers who can produce this distribution format but can't deal with apt, maybe the giant ball of wax is okay. I won't be installing anything this way, but clearly I'm not the target user. It seems certain, however, that in future we'll be hearing about lots of vulnerabilities attributed to AppImages linking in old library versions.

Re: AppImage: Linux apps that run anywhere

#167

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.

This makes a mockery of shared libraries. The technical debt will accrue and run unfathomably deep. Security failures due to currency issues are simply the most obvious. The insoluble mystery bugs of mismatched dependencies will plague application developers that choose this distribution strategy.

Re: AppImage: Linux apps that run anywhere

#168
post #123

Earlier quoted context omitted.

I wastes memory too, having multiple copies of the same shared libraries loaded.

Memory spend on executables isn't a bottleneck even on mobile. You are getting into embedded territory for this to become an issue.

Not so. This matters at scale too. Multiplied by ten thousand nodes, a 50MB wasted RSS becomes half a terabyte of unnecessarily procured silicon. I don't want to pay that tax.

Re: AppImage: Linux apps that run anywhere

#169

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…

If you don't share common dependencies you're doomed to have security hazards. Consider it this way: if you install package FOO with its dependencies A,B and C, and FOO's developer thinks it's "feature complete", the package will never be updated, but every time a vulnerability is disclosed in his dependencies you'll be it. For _every_ program maintained this way.

My argument is that you'd have cross-distribution appimage maintainers who would press a button and rerun the build script with the new library if it's needed.

Re: AppImage: Linux apps that run anywhere

#170
post #143

Earlier quoted context omitted.

Yea I never understood why there's no separation between these two. The fact that apt-get needs root password only makes sense if apt-get is meant for system packages. User applications should not require root privileges to install.

Installers regularly install packages to system dir because it would be idiotic on a multi user system for each user to install different versions of Firefox to their home dir. It also serves to keep unprivileged users from installing software. You are free to install software to your home but it shouldn't be the default behavior

The overwhelming use case for desktop users is there's usually one user on the system.
Post reply on HN