"Container" is a rather vague term and the implementation details vary. For example, Guix containers (though not fully baked yet) do not have the downsides tha

"Container" is a rather vague term and the implementation details vary. For example, Guix containers (though not fully baked yet) do not have the downsides that we've come to expect from Docker and friends like being based on opaque images with no useful provenance, relying upon complicated overlay file systems, duplication of the same software amongst different container images, and not doing anything to solve the very crucial reproducible builds problem. Instead of using disk image layers, Guix can simply bind-mount the required package builds (we call them "store items") from the host into the container. One of pleasant consequences of this design is that software shared amongst N containers is on the file system in exactly one place. No need to rely on complicated file systems that may or may not actually deduplicate things depending on the circumstances. Let's use heartbleed as an example. It is easily possible with Guix to walk the dependency graph for any package or system configuration (container or otherwise) and inspect for known vulnerable software. Docker simply does not, and cannot, know the level of detail that Guix knows about the composition of software and systems. Furthermore, the Guix tools that build containers use a functional, declarative programming interface. Contrast this with Dockerfiles which are an imperative sequence of steps in which you mutate a disk image in a specific order. To utilize Docker's caching abilities, you have to very careful about the order in which the directives in the Dockerfile are evaluated. In Guix, the order doesn't matter and the "cache" (it's really memoization) can be effectively used when any component of the system has already been built before. I've picked on Docker a lot here because it's the most popular, but you can substitute Docker for any other image-based container system and the same things will more-or-less apply. Docker is great for making things easier right now, in which the status quo package managers are weak and you need on average 3 to 4 package managers to deploy any given web application. But it's not the future. Docker is based on binaries whereas functional package/configuration management is based on source code. We can do much better (and we are doing it already) by building on the functional package management paradigm.