[cycloptic]

I don't see what you mean. Qubes is great, but it is not the same thing as Docker, flatpak, or snap. Are you saying Qubes should somehow be changed so that it works similar to Docker? And if so, why wouldn't you just use Docker?

[airhead969]

Then you need to understand how they work differently and their contrasting limitations. Qubes (based on Xen) is great for desktop users to segregate applications. Xen standalone is similarly great for general server containerization.

Docker doesn't work anything remotely like a hypervisor. It doesn't provide the much greater assurance of security, scalability, isolation, resource metering, accounting, or flexibility that a hypervisor does. Docker is a security disaster and it only runs Linux. Xen/Qubes runs Windows, BSDs, or any other OS. Docker seems "easy" but with many subtle costs that come later at scale. You can't live migrate a Docker container from one host to another, where you usually can with Xen using shared storage. There are many other gotchas in the lifecycle of Docker containers that are eliminated or mitigated by using hypervisor guests instead.

flatpak and snap are basically filesystem overlays. They're gross, poorly-managed, incompatible duplications of package management.

[cycloptic]

I am not sure I see what the significant difference is, I've heard of security escapes happening in both Docker and in various hypervisors. Either way there is a risk of some privilege escalation bug that allows access to the full RAM. I think if you want isolation, both of them lose out to having a separate firewalled off machine. Also I think the companies running heavy Linux workloads on Docker are probably not interested in the ability of Qubes to run Windows or Mac, just my read on the situation from talking to some of them.

I don't know about snap but from what I have seen of flatpak, it allows for different versions of the same package to be installed, not many package managers are supporting that currently. (Nix and Guix being some notable exceptions, and those should be able to re-use some of the sandboxing bits from flatpak if they need to) Of course, that is one of the main benefits to building this on top of filesystem overlays, and why it requires a different approach from a traditional package manager, i.e. it's not just a duplication.

Edit: Live migration actually does work for containers, take a look at CRIU. (I don't know the current status of this being integrated in Docker) I never even saw this as being opposing technology anyway, for example if you need to you could migrate a container in or out of a VM.

[airhead969]

I know all about application file systems overlays, I was part of a startup that shipped a multiplatform one. They have many many problems because they blow in a fixed set of dependencies as a monolith. It's a similar to the difference between image-based deployment and configuration management-based deployment: granularity of lifecycle including updates, and management.

The nuances become readily-apparent running anything real at scale, especially if you're only given a herring (Docker) to chop down the mightiness tree in the forest when you need a harvester (hypervisor). Docker, flatpak, and snap are unnecessary other than as shiny, fragile toys that attempt to (poorly) replicate the functionality of other tools. Live migration for containers is like adding high availability to a solar calculator: completely pointless and inappropriate engineering. Just don't get attached to these limited "advances" / fads / religions because popularity and newness aren't the same as demonstrable progress.

It's better to use something like Nix or habitat for multiversion app dependencies or just privately vendor them. There is no need for snap or flatpak if a containerizable OS can choose the correct dependency constraints for an app. The problem of concurrent package versions in existing package management systems can be solved with naming and numbering standards rather than reinventing everything.