Nix is probably the optimal package manager, but it still <i>is</i> a package manager, and so still encodes particular ontological choices that get made differently by different distros at different times.<p>In other words: I don&#x27;t just want my game from ten years ago to run; I want my game from ten years ago that was built for a RHEL-alike to run on the Debian-alike I&#x27;ve got today (or maybe even using FreeBSD&#x27;s Linux-binary support.) Nix can&#x27;t give me that, except by just being the particular tool that ends up putting together the packages that <i>go into</i> a container-image.<p>Nix <i>can</i> be used to exactly re-instantiate the same set of files ten years later, presuming the original Nix repo you found the software on was still alive ten years later. In that way, it <i>is</i> similar to creating a container-image. But for this use-case, it doesn&#x27;t give you anything that the container-image doesn&#x27;t, while the container-image <i>does</i> give you an assurance that a stable (sandbox-based) interaction model was defined at the time of the image&#x27;s creation, which can still be used today.<p>Something that intersected the Nix package-management model with the Mac App Store &quot;only self-sandboxed apps will be accepted&quot; model would be strictly equivalent to containers, though.