UUIDs are so funny today because almost all of their deployments is "we take a string of mostly-random bits but give it structure for no apparent reason"
-
@whitequark What makes this stranger is that there's a lot of software around that uses external dependencies to create UUIDs to act as random strings... even when the enthropy to character ratio would be important. After all rolling your own routine is trivial and fast... and allows you to cram in 6.5 bits per character easily.
@casandro 124 bits of randomness is enough for basically any application where UUIDs are used as references
-
it's true that you could populate some of those bits with predictable sequences to avoid clashing (a la snowflake) but guess what: you can do this to a hex string or a number (as does snowflake). i think the only reason UUIDs are as popular as they are today is Microsoft?
@whitequark@social.treehouse.systems I thought Microsoft made GUIDs popular?
-
@whitequark@social.treehouse.systems I thought Microsoft made GUIDs popular?
@nyovaya they are the same thing
-
UUIDs are so funny today because almost all of their deployments is "we take a string of mostly-random bits but give it structure for no apparent reason"
@whitequark Once constructed, I have literally never seen anybody ever care about the specific fields. There's no reason for it to be divided up asymmetrically because the only things people do with those sorts of uids is bit compare the whole thing, or print as text in hex.
-
@casandro 124 bits of randomness is enough for basically any application where UUIDs are used as references
@whitequark Yes, but it takes a lot of characters. Particulary in protocols like SIP where you don't want to spend a lot of bytes for your message (you don't want fragementation), having a SIP-stack that just puts in UUIDs can really cause problems. Plus for SIP you want a variable number of randomness for different parts. While you might want 64 bits for your Call-ID, the From:- and To:-Tags are fine with 16 bits.
Again, every byte saved in the header saves you from problems. -
@whitequark actually i remember microsoft more for GUIDs than UUIDs
@dysfun @whitequark GUIDs and UUIDs are the same, except for the order of the bytes in binary form. For UUIDs, all bytes are in network byte order (big-endian). In a GUID, the order of the bytes are reversed in each grouping for the first 64 bits and stored in little-endian order. The remaining 64 bits are stored in network byte order. Both string representations are the same. Who knows why.
️ -
it's true that you could populate some of those bits with predictable sequences to avoid clashing (a la snowflake) but guess what: you can do this to a hex string or a number (as does snowflake). i think the only reason UUIDs are as popular as they are today is Microsoft?
@whitequark Most applications that use UUIDs these days tend to use version 7 UUIDs, which use milliseconds since the Unix epoch as the most significant bits. This embeds the creation timestamp in the ID and allows for sorting, while also adding in sufficient randomness so they're not incremental and multiple systems can generate them with low probability of collision.
-
UUIDs are so funny today because almost all of their deployments is "we take a string of mostly-random bits but give it structure for no apparent reason"
@whitequark@treehouse.systems The "structure" makes them easier to handle for human brains and they are an RFC that is implemented in a lot of places.
I'd say they've gotten developer experience right by accident.
-
@whitequark Most applications that use UUIDs these days tend to use version 7 UUIDs, which use milliseconds since the Unix epoch as the most significant bits. This embeds the creation timestamp in the ID and allows for sorting, while also adding in sufficient randomness so they're not incremental and multiple systems can generate them with low probability of collision.
@ramsey oh, I didn't know this!
-
@whitequark Most applications that use UUIDs these days tend to use version 7 UUIDs, which use milliseconds since the Unix epoch as the most significant bits. This embeds the creation timestamp in the ID and allows for sorting, while also adding in sufficient randomness so they're not incremental and multiple systems can generate them with low probability of collision.
@ramsey @whitequark yeah, at a previous job we used v7 uuids with for request IDs with a single-character signifying the source of the request and a freeform suffix (guaranteed to be delimited by a non-
\wcharacter for ease of splitting). -
it's true that you could populate some of those bits with predictable sequences to avoid clashing (a la snowflake) but guess what: you can do this to a hex string or a number (as does snowflake). i think the only reason UUIDs are as popular as they are today is Microsoft?
@whitequark i like UUIDs because someone else has already solved the problem of "how to make thing unique" for me and i don't have to think about it
-
@ramsey oh, I didn't know this!
@whitequark @ramsey I've only ever seen version 4 (unstructured random) in production that i can recall
-
R relay@relay.infosec.exchange shared this topic
