As best I understand: he explains why you see certain problems when using the Ansible/Chef etc. (the icepack) and then explains why these are symptoms of underlying problems with package management (the heart-attack) which can't be resolved through the use of an icepack.
I disagree, the tools (or, well, Ansible, which is the only one I'm familiar with) are declarative, as he describes. He says "these tools are not enough", then goes on to say that you need stateless package management, through a non-sequitur.
You can specify the packages you want in Ansible, and it will abstract away everything else, giving you what you asked for. Ansible's config language wouldn't look any different if it were using nix (and it probably can), so what he says doesn't follow:
Ansible (et al) aren't enough => We improve a part of the underlying system => Ansible looks exactly the same, but is magically now enough.
> I disagree, the tools (or, well, Ansible, which is the only one I'm familiar with) are declarative, as he describes. He says "these tools are not enough", then goes on to say that you need stateless package management, through a non-sequitur.
There is a fundamental difference between Ansible and co. and NixOS. These tools take you from an unknown state, look at the part of this state you configured in the Ansible files, and apply the modifications necessary. NixOS will take its cue from a single file (possibly with includes) describing the entire machine.
Concretely, if you tell Ansible "package X should be present", apply the configuration and then remove this line before reapplying the configuration, package X will still be present, even though it's not listed in the configuration. I don't mean that as a criticism of Ansible, for my purpose it's about as good as it gets, but it's two different paradigms.
Ansible (et al) aren't enough => We improve a part of the underlying system => We build a new tool that makes use of the improvements and is therefor better than Ansible.
Right. But enforcing state in the packaging system is only one facet of what configuration management tools are used for. Building a better package manager won't remove the need for configuration management tools. The problems that gave arise to these tools extend far beyond package management and cannot be reduced to package management as a root cause.
