Flatpak – a security nightmare

OS packaging formats exist for the "base system", in your terminology. "Applications", in the UNIX world, install in /opt.

Keep in mind that the separation you're talking about is very thin, often non-existent, in any OS. Consider, say, an RDBMS daemon. Is that an application, or part of the base system?

An application? You're sure? But what if components of the base system rely on its presence?

This isn't some wacky idea, and it's not a UNIXism, either. Some components of Windows Server rely on MSSQL. So MSSQL has to be built as a Windows component, rather than a standalone application.

This example helps a lot in understanding what OS packages really are. For example, why do Linux distros package scripting languages like Perl, Python, Ruby? It's not for you to use them to write system administration scripts. It's definitely not for applications to use as their runtime. (All the major distros recommend that you vendor your own runtime into your application, if you're creating a standalone application.) No, the point of these language-runtime packages is that there are system components written in these languages, and the OS package is there to support them.

And this is why you're supposed to install your own copy of these when using them for development: the OS copy isn't maintined for you. These OS-packaged runtimes are frequently not up-to-date, and they bundle with them some of the language's package ecosystem, but not all—and frequently not even the most popular language packages.

That's because the runtime isn't there for you. It's there for the OS to use. It may as well be hidden in /usr/libexec and not even in your $PATH. (Except that $PATH is frequently how system components find one-another.)

People make a mistake when they think it's a good idea to package their applications as e.g. Ubuntu PPAs following the Debian packaging guidelines. That format, and those guidelines, exist for the authoring of system components; the guidelines are the way they are (i.e. very strict) to enable other system components to rely on your component.

If you're building an application, none of that applies.

Until recently, applications on UNIX shipped as tarballs containing ./install.sh scripts that you'd have to run as root, that would unpack things into /opt but also maybe write some service scripts into /etc/init.d. (Even now, this is how heavily-integrated applications like VMWare ship.)

More recently, Docker has replaced this format when packaging applications that don't require much of the underlying platform (e.g. network servers.)

Flatpak and Snaps are two attempts to do for GUI apps what Docker did for network servers.

Unlike OS packages, Docker, Flatpak, and Snaps are all interchangable and inter-convertable as long as you have an application that only requires their least-common-denominator subset of capabilities. A Docker "package" can be repackaged as a Flatpak or Snap losslessly. There is no reason that the Flatpak and Snap ecosystems can't proxy through to Docker Hub and let you pull any Docker image and run it under their daemon. There's no real war here.

"If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted "real" desktop software that Windows has become notorious for then I think we may be better off without it."

You're ignoring a huge amount of business software that is created for, and runs on, Windows. That's like judging Android or iOS based upon the consumer crapware that gets sold/given away in their app stores, as opposed to the many business apps that are used to automate and improve all sorts of tasks on mobile devices.

I keep seeing this pattern repeated over and over again: someone (this has been me, several times) mentions on HN that Linux needs a better way to allow for binaries to be dropped on a system and run without requiring re-compilation or overly-complicated containers/sandboxes, and the answers invariably end up being "don't want it, don't care". But, the reality is that there are a very large number of people that would jump to Linux in a heartbeat if they could target the OS for distribution in that fashion. It just seems like a bunch of ideology run amok with zero thought given to the actual needs of professional developers/companies. And, there's a lot of evidence that this is one of the primary things holding back Linux adoption on the desktop.

The rest of your reply was very informative, thanks.

"Also, even supposing downloading from your website is the only alternative you give me, to do that securely, you'll have to use HTTPS, you'll have to sign your binaries with a public key I trust, you'll have to provide signed hashes so I can verify the download, etc.--in other words, all the stuff you'd have to do if you maintained a third-party PPA."

This is how most professional Windows desktop software is distributed today. Also, you don't need a signed hash if the binaries are code-signed - you can verify that they haven't been tampered with by simply right-clicking on the binary and looking at the cert/SHA-1/SHA-2 signatures.

You'd need to open your entire home dir for that. In VSCode, you normally open the specific directory that contains the source for one particular project you're working on, so in that model, it would only be granted permission to that directory.

The situation is similar on Win10 (and the approach is also the same - sandbox apps have to use a certain API to invoke the file browser and get access to some files or folders).

But apps that don't do that because they're too old, just don't get access to the Store... or at least they didn't use to. Now you can ship non-sandboxed Win32 apps through the Store, and it doesn't even seem particularly obvious which ones are and which ones aren't. Windows 10 S only lets you install the sandboxed ones, but how many people use that?

So basically Windows couldn't solve that - the users ultimately decided that they care about stuff working as it did more than they did about security. I don't see why it would be any different on Linux.