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…
AppImage: Linux apps that run anywhere
161–170 of 241 posts
Re: AppImage: Linux apps that run anywhere
#162What 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…
Re: AppImage: Linux apps that run anywhere
#163This 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.
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
#164What 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…
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
#165TL/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.
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
#166Earlier 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…
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
#167Earlier 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.
Re: AppImage: Linux apps that run anywhere
#168Earlier 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.
Re: AppImage: Linux apps that run anywhere
#169What 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.
Re: AppImage: Linux apps that run anywhere
#170Earlier 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