Flatpak Is Not the Future

Of all the arguments of the author I only agree with the RAM usage part. It's true that having containerized apps will lead to much more CPU L-cache trashing which can dramatically reduce performance if you are regularly starting and stopping programs. This is indeed a problem that needs solving. I can envision a NextFlatpak that keeps a global cache of versioned libraries (kind of like Apple does in macOS) so as to try and reduce RAM usage as much as possible.

And I agree with the author on the startup time (which is also related to memory usage and CPU cache trashing). That too is a problem that needs solving.

The rest of the arguments though, meh. Are you seriously arguing the case that we need to respect 120GB NVMe SSDs because they are "expensive"? Really? I spent 255 EUR (288 USD) on a 2TB NVMe SSD (and it has 3210 TBW of endurance, one of the very highest of all NVMe SSDs!) for a spare dev laptop and I am convinced most devs would have no trouble making that purchase any time they get the whim about it. And even people in my poor country, people who are mind-blown by their new 1300 EUR salary, can still plan financially well enough to afford a new iPhone 3-6 months later. So again, not convinced here. As much as NVMe SSDs are expensive per GB, they are still well within the grasp of most users who actually need them.

As for security, it seems the author overstates the efforts of distro maintainers. They do an admirable job, this is well-known, but they really can't be everywhere so him praising them so much might be a bit misguided (as do other posters here). Flatpaks don't change the game in almost no measure there, especially if they get properly isolated (as another poster alluded to: I want to be able to stop all internet access to an app; just one example). And none of what the author states will stop a malicious app that's not in a container so really, what's his point there? That the Debian maintainers inspect 100% of all apps and will spot a malicious calculator? Come on now.

And the rest of the post is just ranting and having a beef with a few things, which is clearly visible by his change of tone. Call me crazy but such an article can't be called convincing. ¯\_(ツ)_/¯

see: https://www.usenix.org/legacy/events/atc10/tech/full_papers/... and http://www.usenix.org/events/lisa11/tech/full_papers/Potter....

what I did differently was basically say that it should be a linux distribution. each layer should be equivalent to a debian/redhat package, with full dependency information between them. therefore it be easy to a) create an image (just pick the highest level things you want and the rest get resolved automatically, much like calling yum/apt-get in a Dockerfile) b) upgrade an image when you want to (i.e. similiar to upgrading an existing redhat/debian system, it just creates a new image artifact that can be tested and deployed)

you also don't have much hiding in the system as opposed to today. Yes, they might be built on debian, ubuntu or redhat, but you really can't verify easily what changes they made in the middle with ease. In my system, imagine there's a "Debian" layer repository, in general, you would end up with a bunch of easily verifiable debian layers and a small set of "user defined" layers (and when an image is deployed, the actual container layer). the user defined layers would be much harder to hide things in, i.e. it be very visible if one is overriding binaries or configuration files that you expect to come from a controlled package.

considering the amount of language and implementation that docker seems to share with mine that predates it, one has to wonder if they saw my talks / read my papers (though yes, its very possible they came up with it totally independently as well). They were active in the usenix and lisa communities (at least when they were more alive).

I think someone else has mentioned this somewhere, but Flatpak exposes information about the runtime it's using -- you can use metadata tools to iterate over the packages installed and check to see if any of them are outdated. I suppose the tooling in that area could be improved, but I suspect that's something that would happen in parallel with more maintainers getting involved in validating/moderating packages. I could easily see a world where you specify a set of minimum runtime versions (or pin an exact runtime version) and set up some rules about what packages you'll allow to run.

Importantly, if you do have a critical vulnerability, you can make a list of the packages in your system that would be affected, and if you're willing to re-bundle them you can update the runtime for just them, which means if you're a maintainer you can push that update out immediately for those programs to everyone; you don't have to wait until somebody has finished checking to see if the update breaks a calculator app that doesn't have Internet or file access anyway.

I don't think there's anything about Flatpak that blocks this kind of auditing (and the core technology may end up making it easier in the long run). So I do get the criticism, but it seems like the criticism here is more, "we need some more focus given to better userland tools" and not "this is the wrong technical/architectural direction to go."

----

> at least when apt-get was upgrading shared libraries, I could be sure that all programs had the fix

Ironically, this is kind of the same behavior that the linked article calls out. You really couldn't be sure about that back then. Plenty of packages embed critical libraries like libsodium and don't use the shared versions. It is very common advice in the Linux world (particularly with games) to embed as many system libraries as reasonably possible, and regardless of whether or not that's good advice, developers do it.

So right now, you're trusting package maintainers to catch that stuff and make sure that the dependencies are updated across the board (or converted into calls to shared libraries) even if the source code isn't using shared libraries by default. And after Flatpak, you'll still to some degree be trusting maintainers to do that, and you'll still be trusting maintainers to say that "updating libsodium" means updating every package that depends on it. The difference with Flatpak is that this is now very explicit and obvious to you, which may be a good thing because (in the article's words) it seems that the single shared runtime model "leads people to place more trust than they should" in their ability to ensure that applications are actually using system libraries.

----

> but the waste of space still bothers me

I don't have too much to say here, it's a legit worry.

I think this mostly comes down to how much space will actually be wasted in practice. Docker seems to be relatively inefficient about this, I'm not sure if Flatpak is better or not. But yeah, it would be good to minimize size as much as possible, I do understand that concern.

Not at all.