AppImage: Linux apps that run anywhere

> If you don't want to exclude older browsers, you need a dedicated IP address, or you need a system to manage putting multiple names on one certificate. Let's Encrypt is a great option for multi-SAN certificates, as long as you don't care about Windows XP users.

This is a website for AppImage. I doubt they're targeting XP users.

> If you have any kind of redundancy, doing perfect forward secrecy gets much harder. The open source approaches to scaling TLS along with PFS are bleeding edge, poorly documented, and may involve writing some code.

This is simply a brochure website, so this does not apply.

For more complex applications or websites, there is a certain degree of engineering required to support HTTPS-by-default. But in today's world it is a necessity.

I have to wonder if the Subsurface demo was key to achieving the endorsement from Torvalds.

This is very similar to the approach that we took in our InstallBuilder cross-platform installers (http://installbuilder.birock.com), embedding a filesystem in the executable that gets mounted at runtime. If you do it right, it can support a wide variety of Linux distributions and significantly decrease the amount of pain end users and app developers experience. Those who disagree with this approach and believe "this is not the Linux way" should take a look at the referenced Linus Torvalds vieo

What OS X at least gets right is that OS-bundled software is immutable, or desired to be. If you want a recent version of e.g. Python, you install separately and add it to your $PATH instead of changing the base. Then any app that depends on Python can continue using the system version.

Debian packaging isn't too awful, though I don't like how many files are involved (I prefer a single spec file, plus patches, as found in RPM). But, apt repository management is truly terrible. The documentation is laughably bad and disjointed, and it points to several different tools and processes that may or may not work together; my Debian/Ubuntu repo generation script is a ridiculous mishmash of stuff that kinda sorta works if I squint and don't look at it too closely (and a lot of the repo is manually created and maintained because I couldn't figure out any tools to automate it).

Contrast that with creating yum/dnf repos: run 'createrepo' on the directory of RPMs, and you're done! Signing RPMs is much better documented, as well. There were like three or four (conflicting and mutually incompatible) processes that come up when you google signing debian packages and repositories, and I still don't know with certainty what the "right way" is.

I don't know why Debian never got this part of things right; apt/deb has been around for about two decades, you'd think someone would have looked at createrepo and said, "Oh, hey, we should do something like that so it's easier for people to distribute package for Debian/Ubuntu."

All that said: I'm rarely a fan of "new package managers". I like having one standard package manager on my system (I don't really care whether it is apt or yum/dnf), and I strongly believe everyone ought to be using the system standard package manager across all of their systems even for custom software. I don't like the proliferation of language specific package managers, in particular. npm, gems, crates, PyPI, eggs, pear, pecl, composer, etc. Shit's gotten ridiculous. Even on my own systems, I can't keep up with what's installed from where. And the problem has gotten much worse over the years; I used to package all my own stuff as RPMs, and all of the CPAN or Python dependencies, as well, using automated tools for building RPMs from Perl or Python libraries (the old cpanflute2 and the dist_utils RPM target; there are better ways in both cases, now, I think, for those languages). But, now that I have a much more diverse set of systems with more languages and more dependencies, that's become more difficult. And, it's also become the norm for people to document only installation with oddball package managers (npm, in particular, is the way everyone documents everything these days), with no good mechanism to package for RPM or deb.

I dunno, I think we're going down a risky path with all these "package managers" that only work for one little niche and I believe security issues will be the major negative side effect. I mean, I have great tooling to let me know when my RPMs or debs are out of date across my couple dozen servers; it's much harder to know when packages installed via all those other systems are out of date; it becomes a manual process in some cases, and it's also risky because dependencies are not always very reliable in those systems. I do a lot of, "Will this break some other thing when I upgrade this library?" Which I don't worry about with RPM updates from CentOS (because of the compatibility assurances of that system), or from my own company repos (because we do our own testing and understand the parts we're distributing).

In short: Yes, it's hard to package and distribute for RPM or deb. But, not as hard as dealing with a half dozen different package managers, containers, and a wide variety of other things being updated via a wide variety of other mechanisms. The former is hard but quantifiable and manageable. The latter is a nightmare for security and reliability.