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

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 is no kind of an answer.

I didn't even know that Debian has a WordPress package. I always downloaded it from here https://wordpress.org/download/ and applied updates as soon as my WP servers ask me to. I don't trust Debian mantainers to be faster than that.

As a comparison: WordPress is at 4.4.2, Debian 8 has it a 4.1 and Debian 7 at 3.6.1. You can't use those, you must use the one from the developers.

Same thing for example with Ruby: Debian 8 is stuck with 2.1.5 (November 2014), which is not even the latest one of the 2.1 series. The current version of the language is 2.3. And Node.js? 0.10.29 (June 2014). Again, you can't use the packaged versions and you must go to the developers, maybe through rvm, nvm or other language specific package managers. I really don't understand why they bother packaging those languages. They should have tiny packages that explicitly tell that you are on your own and redirect to the appropriate package manager for the language.

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.

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.

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.