Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New UUID Formats

ietf.org

Post reply on HN
Print view View original

71–80 of 172 posts

Re: New UUID Formats

#71

Post by dtech »

blueflow wrote: post #24
amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

This mishap lives forth in the UUID stored in a machines DMI data, as well in GPT partition tables, which are required when EFI is used. It would be really cool if we had some replacement for EFI that would not harbour these kind of painful legacies.

On the other hand, this is an easy to implement conversion, while changing such a fundamental thing from EFI sounds pretty hard, making it not worth it.

Re: New UUID Formats

#72

Post by secondcoming »

amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

I thought Windows uses GUIDs, not UUIDs

Re: New UUID Formats

#73

Post by jandrewrogers »

jasonwatkinspdx wrote: post #55
zbuf wrote: post #39

Earlier quoted context omitted.

"Unique IDs" _can_ be super really easy to work with if they're not so baffling complicated. A random string generated using quality randomness can be adjusted to length to suit the quantity of data (negligible probability of a collision) which in most cases is very short. It's easy to increase the length as you get more data. They are visually very different for each item of data. They're evenly spread which means t…

Using purely random ids in your database destroys locality. They mention this in the introduction: > Non-time-ordered UUID versions such as UUIDv4 have poor database index locality. Meaning new values created in succession are not close to each other in the index and thus require inserts to be performed at random locations. The negative performance effects of which on common structures used for this (B-tree and its v…

100 billion UUIDs per millisecond is the 50% collision probability threshold. Achieving an acceptable collision probability for most applications would limit the UUID generation rate to more like thousands of UUIDs per millisecond.

Even if one was not generating millions of UUIDs per second on average, the risk of spiky temporal distributions when generating UUIDs would still need to be considered.

Re: New UUID Formats

#74

Post by takeda »

secondcoming wrote: post #72
amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

I thought Windows uses GUIDs, not UUIDs

It looks like GUID is synonymous with UUID, but the name GUID also implies that it could contain that bug/feature mentioned[1]

[1] https://en.wikipedia.org/wiki/Universally_unique_identifier#...

Re: New UUID Formats

#75

Post by lewisl9029 »

I've been using ULID for a while now, which analogous to UUID v7 but with a different (better IMHO) string representation. They've been awesome for using as sort keys in dynamo for instance, since they're lexicographically sortable as strings.

But one thing I'm still wary about is exposing these IDs with millisecond-precision time components to end users, since I've seen multiple discussions here on HN about the potential for timing attacks.

How worried should I really be? Do people have useful heuristics on the kinds of data where it's safe/unsafe to expose timing information, or should I just only expose a separate UUID v4 externally across the board just to be safe?

Re: New UUID Formats

#76

Post by wolverine876 »

tech2 wrote: post #59
wolverine876 wrote: post #56

Earlier quoted context omitted.

You're saying it won for this application (UUIDs)? Universally? What is the most common remaining use of big endian?

TCP/IP might be a reasonable example. There's a reason "network byte order" and "big endian" are the same thing.

> TCP/IP might be a reasonable example.

That's a pretty significant example of widespread usage that isn't going away soon. Perhaps the GGP was only referring to UUID applications.

Re: New UUID Formats

#77

Post by e4m2 »

kevincox wrote: post #61
Someone wrote: post #44

Earlier quoted context omitted.

> Hint: do not use integer types in C code for portable data structures. ntohl, etc are a mess. Just use arrays of bytes. I don’t see how that helps much. If a developer forgets to call ntohl on multi-byte integer fields, I don’t trust them to correctly convert said integers to arrays of bytes, either.

If you write it the naive way it works. uint8_t bytes[4]; uint32_t = bytes[0] The endianness is whatever you write in the indexing and will be the same across architectures.

Unfortunately, the naive way also turns out to be wrong in C. uint8_t gets promoted to a signed int when shifting, which in turn causes undefined behavior for specific input. One way of fixing this is casting to the desired type before the shift, thus avoiding surprising conversions.

On a side note, compiler warnings and sanitizers help with this kind of stuff greatly, use them if you have the option: https://godbolt.org/z/8oq9GTcze

Re: New UUID Formats

#78

Post by okr »

nixpulvis wrote: post #66

Maybe I'm being slow right now, but can somewhat help me understand why Max UUID is ever specifically useful?

My guess is, that it is just a constant, ready to be used for bitwise operations.

Re: New UUID Formats

#79

Post by throwaway9870 »

firebird84 wrote: post #45
amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

It's actually worse than that. The first 3 groupings (textually) of the uuid might be little endian while the other 2 are big endian. Learning this cost me more time than I care to admit. https://en.wikipedia.org/wiki/Universally_unique_identifier#...

I had to write some EFI/GPT code earlier this year and was dumbfounded to learn this. This is right up there with the mork file format.

Re: New UUID Formats

#80

Post by formerly_proven »

firebird84 wrote: post #45
amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

It's actually worse than that. The first 3 groupings (textually) of the uuid might be little endian while the other 2 are big endian. Learning this cost me more time than I care to admit. https://en.wikipedia.org/wiki/Universally_unique_identifier#...

Making mixed-endian even more haunted is quite the achievement. I congratulate whoever did this at Microsoft for their lasting contribution.
Post reply on HN