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

141–150 of 241 posts

Re: AppImage: Linux apps that run anywhere

#141

Post by jessaustin »

takluyver wrote: post #78
jessaustin wrote: post #61

Earlier quoted context omitted.

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.

One of the packages in the article I linked above was Wordpress, which is not exactly low volume. I work on the Jupyter/IPython notebook - we found a security bug last summer, got a CVE (CVE-2015-5607), issued patches... and the version in Debian unstable hasn't been fixed, seven months later. If distros can't do security maintenance for the software people use, claiming that they shouldn't use that software at all i…

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 enough volunteers to maintain the Debian package in-house. Perhaps that means that Debian is too accepting of packages. I don't think it's an indictment of the idea of a package manager. I also doubt that lots more free labor will appear now that there is yet another new zipfile format to keep maintained.

Re: AppImage: Linux apps that run anywhere

#142

Post by marcosdumay »

veddan wrote: post #123
matzipan wrote: post #101

Earlier quoted context omitted.

Is space really an issue in most non-mobile user devices nowadays? Consider the tradeoffs: a bit of space vs. packaging nightmare which results in old, buggy and insecure packages. This was posted a few days back on hn: https://statuscode.ch/2016/02/distribution-packages-consider... I am not sure if the whole jar package dependency management would work under ART.

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

#143

Post by hasenj »

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…

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.

Re: AppImage: Linux apps that run anywhere

#144

Post by jessaustin »

anonbanker wrote: post #110
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,…

Ranking package managers by difficulty of creating packages (1-10, lowest to highest): 1. tarballs (slackware) 2. Ports (FreeBSD) 3. Portage (Gentoo, Calculate Linux) 4. pacman (Arch, Archbang, KaOS, Manjaro, Antergos) 5. building from source (Linux From Scratch, Most old installs eventually turn into this) 6. rpm (Redhat, Mandriva, Scientific Linux, UnitedLinux) 7. deb (Debian, Ubuntu, Mint/LMDE, Hanna Montana Linux…

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.

Re: AppImage: Linux apps that run anywhere

#145

Post by jessaustin »

FooBarWidget wrote: post #117
jessaustin wrote: post #63

Earlier quoted context omitted.

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

But as a developer you don't want to build a gazillion of packages to be able to reach many users. Building from source? Please try to imagine this from the point of view of users who aren't so technically expert as you are. They just want to, for example, run the latest version of VLC.

Yes this is a challenge for developers. I don't think the answer is yet another package format.

Re: AppImage: Linux apps that run anywhere

#146

Post by takluyver »

jessaustin wrote: post #141
takluyver wrote: post #78

Earlier quoted context omitted.

One of the packages in the article I linked above was Wordpress, which is not exactly low volume. I work on the Jupyter/IPython notebook - we found a security bug last summer, got a CVE (CVE-2015-5607), issued patches... and the version in Debian unstable hasn't been fixed, seven months later. If distros can't do security maintenance for the software people use, claiming that they shouldn't use that software at all i…

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 through Debian, we need some other way for users to get them conveniently. We often use language package managers like pip, but they're not great for desktop applications - they can't easily set up a launcher entry, for instance. That's where something like AppImage comes in.

Re: AppImage: Linux apps that run anywhere

#147

Post by oblio »

DanielDent wrote: post #106
revelation wrote: post #100

Earlier quoted context omitted.

What exactly was achieved in the backwards compatibility nightmare that is Gnome 3, for example? This: https://trac.transmissionbt.com/ticket/3685 All things UI in Linux distributions go through so much insane thrashing that very very few application developers want to bother. There are no tangible benefits to UI thrashing; people use systems for software , not window chrome!

Desktop Linux is definitely still maturing... I'm not up on the latest in Gnome-land and don't know the background on the issue you linked, but it looks like the benefit is that they get to stop maintaining a bunch of code for a UI feature they've decided isn't actually a good idea. That will make it easier for them to continue to build reliable software, as there will be less legacy code to consider when writing fut…

> Desktop Linux is definitely still maturing...

You're such an optimist.

https://www.jwz.org/doc/cadt.html

c 2003

Re: AppImage: Linux apps that run anywhere

#148

Post by RocketWolf »

noisy_boy wrote: post #80

On my Linux Mint 17.3: 1. Downloaded the app, opened Nemo and double clicked on the app. Another Nemo window popped-up and the app didn't start. Opened terminal and checked permission to find that it wasn't executable. The point of the ease-of-use is kind of lost as user would be puzzled and give up. 2. How do I uninstall the app? Is it as simple as deleting the file? What if doing that leaves orphan files (that I do…

As to 1.) you downloaded the app (.appimage) and double clicked on it. Why? Nowhere in any documentation does it say that .appimages are executable out of the box. In fact this is a security feature that it doesn't. IN all placves that I have seen .appimages available there is a statement that says the user has to go into permissions and make the file executable before it will run. Makes sense since most malware is made to run without user intervention. If an app doesnt need you to run it, then its the perfect platform for malware/virus.

Re: AppImage: Linux apps that run anywhere

#149

Post by toyg »

anonbanker wrote: post #110
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,…

Ranking package managers by difficulty of creating packages (1-10, lowest to highest): 1. tarballs (slackware) 2. Ports (FreeBSD) 3. Portage (Gentoo, Calculate Linux) 4. pacman (Arch, Archbang, KaOS, Manjaro, Antergos) 5. building from source (Linux From Scratch, Most old installs eventually turn into this) 6. rpm (Redhat, Mandriva, Scientific Linux, UnitedLinux) 7. deb (Debian, Ubuntu, Mint/LMDE, Hanna Montana Linux…

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 with the right options for your hardware.
Post reply on HN