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"
-
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"
-
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"
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?
-
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 The funniest is when people store them as strings in their database.
-
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 java stuff likes them as well, that probably didn't hurt.
what really upsets me though is your randomness library doesn't actually support a bit at a time because that would be silly, so of course you just grab 128 bits and then drop 4 on the floor and waste them.
it's a silly thing, but when you're making it worse in the process...
-
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 Pretty much. Plus, MS has its own special variant that only they use.
-
@whitequark java stuff likes them as well, that probably didn't hurt.
what really upsets me though is your randomness library doesn't actually support a bit at a time because that would be silly, so of course you just grab 128 bits and then drop 4 on the floor and waste them.
it's a silly thing, but when you're making it worse in the process...
@whitequark actually i remember microsoft more for GUIDs than UUIDs
-
@whitequark The funniest is when people store them as strings in their database.
@stevestreza @whitequark If it works...
-
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 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.
-
@whitequark java stuff likes them as well, that probably didn't hurt.
what really upsets me though is your randomness library doesn't actually support a bit at a time because that would be silly, so of course you just grab 128 bits and then drop 4 on the floor and waste them.
it's a silly thing, but when you're making it worse in the process...
@dysfun i don't think 124 vs 128 bits of randomness makes any salient difference
-
@dysfun i don't think 124 vs 128 bits of randomness makes any salient difference
@whitequark no, it doesn't. but you've already generated them then you just throw them away because they've arbitrarily decided to mark some of them with a constant.
-
@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).
