The system works so long as its deterministic, this is a requirement for computation to do work.
Then it stops working or doing work when its no longer deterministic. It does this in unknowable ways, unplannable ways, and you often won't know why something failed or even if it did fail. The only concrete characterization non-determinism has is the result was not expected.
Troubleshooting and repeatability doesn't work, you get different results each attempt.
Many things can happen non-deterministically including data corruption.
Its not nearly as simply or safe as you make it out to be.
You are making light and minimizing non-deterministic issues.
The infantesimal chance that a collision could cause a few hours (at most!) of hassle seems to me to be a far better trade-off in terms of stability and ease of applying and undoing changes compared to pretty much any package managemer that I've used.
I've heard the exact same argument almost verbatim from a C-level exec who got fired after an outage. It was regarding backups and the infantesimal chance that we would have a power outage.
It fundamentally assumes a lot of critical things that you can't control. If you follow your own advice, you will eventually be wrong, and pay more for it than you would have otherwise.
As for undoing or applying changes, I've had nothing but praise for rpm, its pretty rock solid with the right setup, and better, because it is maintainable and supportable.
I don't see why you get so fixated on Nix rather than preaching about
> infantesimal chance that we would have a power outage.
Power outages are experienced every day in every country; sha256 collisions are still to be found. That's not the same magnitude of ‶infinitesimal″ at all.
In that sense, I alone have lost more time to rpm than the entire world has with nix sha256 collisions.
You are way overstating the importance of this. This is not a fundamental design flaw in the nix ecosystem. If there's actually no check it's because most people realize this is not a problem worth spending a lot of time on. But the time required here is a few minutes at most.
Until what doesn't work? The base system is verified continuously, so there's no chance some two packages are linked against each other causing a boot problem.
If there's really a problem ever, then you just find the old system and start it on boot to one that doesn't include that package. This is straightforwards because most nix users have multiple nixos versions installed at once. Then, you update the offending package to not hash to the same thing (add a comment to a build script).