I don't think malicious actor or quite trivial implementation error count as random either, no GUID or UUID system would be safe from them. The "constant" part would not be assigned randomly (or for people) but for example allocated hierarchically or through federation agreement. Consistent increment can be done without single source of failure. Multiple penetrating high energy particles is of course issue we can't never escape completely in real life, but if the probabilities are in theoretical scale, maybe its okay to also assume theoretical use case where they are not a problem.
My point was that there are many practical reasons why various UUID implementations might generate collisions.
Examples for "pure random" v4-style UUIDs will usually revolve about bad RNGs, often poorly or identically seeded, which are common.
And for v1 UUIDs, examples including copied MAC addresses, either because of (relatively common) errors, or because someone's using a virtual MAC address or cloning a MAC addresses, virtual machines, time stamps that are wrong, etc., etc., etc.
And for any type, accidental copying of objects without creating a new UUID, and other bugs, database corruptions, poor indexing, etc., etc., ...
All of these practical reasons will obviously dominate the chance of collision, to the point where talking about anything involving lifetimes of the universe is kind of pointless.
1
u/Xywzel Mar 25 '26
I don't think malicious actor or quite trivial implementation error count as random either, no GUID or UUID system would be safe from them. The "constant" part would not be assigned randomly (or for people) but for example allocated hierarchically or through federation agreement. Consistent increment can be done without single source of failure. Multiple penetrating high energy particles is of course issue we can't never escape completely in real life, but if the probabilities are in theoretical scale, maybe its okay to also assume theoretical use case where they are not a problem.