4 ms·

I don't think the OP meant to piss on GUIDs. I think they are laughing at a very cryptic command line recommended to access "old devices and printer". That was

by hawski 3y ago

I don't think the OP meant to piss on GUIDs. I think they are laughing at a very cryptic command line recommended to access "old devices and printer". That was always a classic jab at Linux and this looks extra cryptic as it is a literal random string. Also UUIDs in the classic sense do suck in my opinion and Linux and FreeBDS use them, because they have to, to support standards that were made with Windows in mind. UUIDs are strange - i.e. their mixed endianess or how version bits are placed in them. All for a 128 bit random identifier as it is mostly used nowadays. I like the below to get a random identifier: __uint128_t random; char id[17] = {0}; getentropy(&random, sizeof(random)); for(int i = 0; i < 16; i++) { id[i] = 'a' + ((random >> i) & 0xf); } This gives a 16 character identifier, like: pphlfcjmophlnohl Chrome Web Store uses something similar.

Lammy 3y ago
I think it's kinda nice that my random identifiers have a little flag bit to indicate they were random v(._. )v > their mixed endianess Pardon my pedantry here but this is a misinterpretation of GUIDs through the lens of the UUID structure. The actual difference between GUID and UUID isn't the endianness-on-the-wire within the chunks but the number and sizes of the chunks themselves. GUIDs are [32 bits, 16 bits, 16 bits, [8, 8, 8, 8, 8, 8, 8, 8] bits]. UUIDs are [32 bits, 16 bits, 16 bits, 8 bits, 56 bits]. Endianness only matters with multi-byte data, so the "mixed-endianness" thing comes from the fact that the two specs mostly line up, but then people interpret GUID's array of octets as if ⅞ of it were a single multi-byte field as it is in UUID. > or how version bits are placed in them Indeed this is mostly lost to time and seems like odd placement these days. For anyone who's curious, the reason why those bits are where they are is because the Apollo Network Computing Architecture "version 0" UUIDs had a different third layout where the ninth octet indicated socket address family. IP's dominance led to the ossification of AF numbers which did not keep growing as anticipated, leaving several bits of effectively wasted space that were then reused to indicate the version since those bits could always be assumed to be 0 on NCA/NCS due to lack of any network standard on which they could be anything else. Source: wrote a GUID/UUID library that implements all the old weird shit just for the fun of it: irb> GlobeGlitter::from_gregorian_time.inspect => "#<GlobeGlitter 01eed42e-d812-1db0-0f52-00e04c180069>" irb> GlobeGlitter::from_ncs_time.inspect => "#<GlobeGlitter 3cd0b18cbd50.02.00.00.e0.4c.18.00.69>"

by hawski 3y ago

Lammy 3y ago

I think it's kinda nice that my random identifiers have a little flag bit to indicate they were random v(._. )v > their mixed endianess Pardon my pedantry here but this is a misinterpretation of GUIDs through the lens of the UUID structure. The actual difference between GUID and UUID isn't the endianness-on-the-wire within the chunks but the number and sizes of the chunks themselves. GUIDs are [32 bits, 16 bits, 16 bits, [8, 8, 8, 8, 8, 8, 8, 8] bits]. UUIDs are [32 bits, 16 bits, 16 bits, 8 bits, 56 bits]. Endianness only matters with multi-byte data, so the "mixed-endianness" thing comes from the fact that the two specs mostly line up, but then people interpret GUID's array of octets as if ⅞ of it were a single multi-byte field as it is in UUID. > or how version bits are placed in them Indeed this is mostly lost to time and seems like odd placement these days. For anyone who's curious, the reason why those bits are where they are is because the Apollo Network Computing Architecture "version 0" UUIDs had a different third layout where the ninth octet indicated socket address family. IP's dominance led to the ossification of AF numbers which did not keep growing as anticipated, leaving several bits of effectively wasted space that were then reused to indicate the version since those bits could always be assumed to be 0 on NCA/NCS due to lack of any network standard on which they could be anything else. Source: wrote a GUID/UUID library that implements all the old weird shit just for the fun of it: irb> GlobeGlitter::from_gregorian_time.inspect => "#<GlobeGlitter 01eed42e-d812-1db0-0f52-00e04c180069>" irb> GlobeGlitter::from_ncs_time.inspect => "#<GlobeGlitter 3cd0b18cbd50.02.00.00.e0.4c.18.00.69>"