4 ms·

You don't need a UUID for that. A 128 bit random integer will work just fine. Better even, as no bits are wasted on meta data.

vanviegen 4y ago
I'm getting down votes, presumably because people think what I said is incorrect. Would anybody care to explain how UUIDs can have lower probability of collision than just random bits? (Apart from using a central coordinator for handing them out of course, which would defate the whole point.)
- JoeAltmaier 4y ago
  A UUID is random bits. The statement was oxymoron
  - edflsafoiewq 4y ago
    But it isn't. A UUID is a disjoint-union of several different types of IDs, only one of which is just random bits, and if random bits is all you care about, then "random 128-bit number" is not only clearer but gives more entropy than "version 4 UUID". That what I'm trying to ask, what is the purpose of this disjoint union, when would you ever use the "UUID-ness" of UUIDs (which is not the same as asking about the virtues of UUIDs of a particular version).
    - JoeAltmaier 4y ago
      The virtue is, software has some idea what a UUID is. There's a mostly-random version which is also understood. If you want to start doing your own thing, a random number is good. It's hard to get a good random number. I suggest starting with, hey you guessed it, the UUID library.
- BeefWellington 4y ago
  It's because this statement: You don't need a UUID for that. A 128 bit random integer will work just fine. Basically reads: You don't need a UUID for that. A UUID will work just fine.
  - vanviegen 4y ago
    The rfc is rather long for a UUID being just a random integer... But if we're talking about UUID v4, it seems that 122 out of 128 are indeed random. [1] So why not just go all the way? Who cares about these 6 bits of meta data? [1] https://www.rfc-editor.org/rfc/rfc412 https://www.rfc-editor.org/rfc/rfc412
- crazygringo 4y ago
  You can easily look it up on Wikipedia. [1] But version 1 of UUID's, for example, concatenates a MAC address, a timestamp, and a "uniquifying" clock sequence. As long as you're ensuring your MAC addresses are all unique (which they should be, except for manufacturing error) and only one UUID library per device, collisions are impossible. Whereas with random numbers, there's always a chance of collisions. (There are also other versions of UUID's that do include randomness, with collision potential, in exchange for not revealing information such as timestamps and MAC addresses.) [1] https://en.wikipedia.org/wiki/Universally_unique_identifier https://en.wikipedia.org/wiki/Universally_unique_identifier
  - vanviegen 4y ago
    Ah, got it. Reading the spec, that seems like an awful lot of trouble to prevent something that will never happen anyway. Just wondering, can v1 guarantee uniqueness with multiple processes using the same network adapter or within containers?

vanviegen 4y ago

I'm getting down votes, presumably because people think what I said is incorrect. Would anybody care to explain how UUIDs can have lower probability of collision than just random bits? (Apart from using a central coordinator for handing them out of course, which would defate the whole point.)

JoeAltmaier 4y ago
A UUID is random bits. The statement was oxymoron
- edflsafoiewq 4y ago
  But it isn't. A UUID is a disjoint-union of several different types of IDs, only one of which is just random bits, and if random bits is all you care about, then "random 128-bit number" is not only clearer but gives more entropy than "version 4 UUID". That what I'm trying to ask, what is the purpose of this disjoint union, when would you ever use the "UUID-ness" of UUIDs (which is not the same as asking about the virtues of UUIDs of a particular version).
  - JoeAltmaier 4y ago
    The virtue is, software has some idea what a UUID is. There's a mostly-random version which is also understood. If you want to start doing your own thing, a random number is good. It's hard to get a good random number. I suggest starting with, hey you guessed it, the UUID library.
BeefWellington 4y ago
It's because this statement: You don't need a UUID for that. A 128 bit random integer will work just fine. Basically reads: You don't need a UUID for that. A UUID will work just fine.
- vanviegen 4y ago
  The rfc is rather long for a UUID being just a random integer... But if we're talking about UUID v4, it seems that 122 out of 128 are indeed random. [1] So why not just go all the way? Who cares about these 6 bits of meta data? [1] https://www.rfc-editor.org/rfc/rfc412 https://www.rfc-editor.org/rfc/rfc412
crazygringo 4y ago
You can easily look it up on Wikipedia. [1] But version 1 of UUID's, for example, concatenates a MAC address, a timestamp, and a "uniquifying" clock sequence. As long as you're ensuring your MAC addresses are all unique (which they should be, except for manufacturing error) and only one UUID library per device, collisions are impossible. Whereas with random numbers, there's always a chance of collisions. (There are also other versions of UUID's that do include randomness, with collision potential, in exchange for not revealing information such as timestamps and MAC addresses.) [1] https://en.wikipedia.org/wiki/Universally_unique_identifier https://en.wikipedia.org/wiki/Universally_unique_identifier
- vanviegen 4y ago
  Ah, got it. Reading the spec, that seems like an awful lot of trouble to prevent something that will never happen anyway. Just wondering, can v1 guarantee uniqueness with multiple processes using the same network adapter or within containers?