They are using it only to generate UUIDs. They could have avoided collisions using the clock or even a counter as part of the uuid. But for some reason systemd is always creating a lot of drama before they accept they were wrong and fix the bug (which doesn’t always happen).
Actual UUID? 122 random bits? Using random numbers to make a UUID is not a bug. If you think you see multiple separate UUID collisions then you know for sure you have an implementation or hardware problem, not an algorithm problem.
>Using random numbers to make a UUID is not a bug.
the thing about randomness is you can get two 0x00 answers in a row and they are 100% valid. Using random numbers for something which required Unique numbers is crazy.
No matter what, you could get hit with a cosmic ray or spark of static or a bug could corrupt your program's memory.
The state of "we somehow generated two identical UUIDs" cannot be prevented in the real world. You can only reduce the chance to acceptable levels.
Compared to the risks that are accepted in basically all devices, the danger from using big random numbers is negligible. Which makes it not crazy to do.
Did you just compare normal operation (true randomness allowing for a string of duplicate outputs) to a bug caused by stray cosmic ray in an effort to excuse brain dead decision by systemd?
If you choose to run on unreliable hardware, then bugs caused by that are normal too.
And everyone runs on unreliable hardware.
So yes, I did compare them. Do you have a reason I shouldn't?
If cosmic rays will cause one collision per decade, and "allowed" random collisions will cause one collision per million years, then why care about the increase in risk?
And let's be clear. This github issue is not happening because of using truly random numbers to generate full-size UUIDs. The problem is something else.
