Any of the existing packaging solutions work to a greater or lesser degree so long as the namespaces guarantee uniqueness in the package identity and dependency graphs which is what most packagers do when they put it together for other distros.

As for automating the identity hash generation so it is perfectly deterministic, its not possible so long as you map onto Galois Fields due to their finite field length (and inherent non-unique solutions).

I'm not aware of any mathematical alternative for cryptography, to finite fields, and a hash is a cryptographic function.

Strictly speaking, you have a tradeoff in terms of stability as well as additional cost from the language complexity, and non-deterministic behavior is the fallback when discrete time invariance or determinism is violated.

Many people like Nix, but many people also don't understand how it works, and thus it will work until it doesn't, and then you'll be stuck.

Its not like there is tooling to check determinism, and if time invariance fails because of say a cache (memory property), then you can't even troubleshoot because everything we do to troubleshoot relies on those fundamental system properties with exception to Guess and Check which to be successful requires the highest specialization and understanding of the system.

> Many people like Nix, but many people also don't understand how it works, and thus it will work until it doesn't, and then you'll be stuck.

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).

Non-deterministic problems don't give you clear signs that they are those class of problems.

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.

> Any of the existing packaging solutions work to a greater or lesser degree

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.

Unfortunately, these are famous last words in a professional IT environment.

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.

You don't get it. The main issue with a hash collision in sha256 wouldn't be Nix breaking for a few hours; it would be the modern internet breaking down.

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.

I'll admit, I don't have a ton of experience with rpm- I've generally avoided it since I had to help a client deploy a website on I think CentOS, and the available packages for imagick, language X, and language-X-imagick bindings were all three incompatible with each other. Not a great excuse, but I since lean towards other distros and tools.

In that sense, I alone have lost more time to rpm than the entire world has with nix sha256 collisions.

Adding support for collision detection to nix, involves a one or two line change to libstore. You should implement such an assert statementt and contribute it to Nix. Nix is open-source and would likely gladly accept it.

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.

Just because finite fields are finite doesn't mean that every finite "thing" is a finite field.

Hashes don't really map onto finite fields. They purposefully try to not preserve any algebra.

> so long as the namespaces guarantee uniqueness in the package identity

There are existing issues from this not being the case. Uniqueness of names can only be guaranteed in a single repository and this causes many problems for people pulling from multiple enterprise repos (because everyone packages their own ruby for example).

> Many people like Nix, but many people also don't understand how it works, and thus it will work until it doesn't, and then you'll be stuck.

Considering git still uses sha1 and just about all of web cryptography uses sha1 or sha256 for signatures, block deduplication uses typically 128b hashes, etc., we'll have other problems way before this becomes a problem for nix.

Basically you're worried about a collision in nix, when the whole stack of 10 different things leading to you even reading an article about nix already relies on no collisions.

This will not be an accidental issue within multiples of our lifetimes, and malicious actors will not 0day some nix package in public.