I agree with most[1] of the issues he is aiming to solve. But the approach would have been useful if he would have built it on top a superior existing system w

I agree with most[1] of the issues he is aiming to solve. But the approach would have been useful if he would have built it on top a superior existing system which is Nix & NixOS. Docker is increasing popular while missing most of the problem NixOS (and the new vision of systemd) solve, so I'd say it is not wrong to assume there is definitely solid demand for this kind of app "packaging" (virtualization). Tying this to systemd is an "interestingly" bold move, to put it mildly. People don't switch to btrfs just for the sake of an initrd replacement, after all, and forcing them is openly asking for replacements. So, I would be very careful if were willing to see that vision materialize. [1]: One obvious point of discussion is declaring exact versions of library dependencies, which in most systems leads to highly undesirable results: just compare the horrible world of maven packaging (i.e., the java world, mostly) to the efficient (but curated) world of debian packages. But when you have exact declarable dependencies (where any dependency dictates exact versions of its own dependencies), and reliably reproducible builds (the game changing factor), and hopefully some level of automated testing, you will be fine: You can quickly upgrade all your package portfolio to the newest version of the "security fixed" library, have the world get rebuilt against the newness, and get everything verified (using the tests that you have. You have some, don't you?). The problem of transferring only what actually changed is non-trivial but completely solvable in various ways (Example: only send diffs, and issue new encryption/hashes for the diffs through an automated trusted system that does the diffing).