[ekimekim]

As the article points out, this is only an issue with UUIDv1. They claim "However, it is what most applications use." but I have no idea how true this is. I was under the impression that the vast majority of UUID generators were v4 by default. For example:

Postgres only offers random uuid generation (https://www.postgresql.org/docs/15/functions-uuid.html).

The `uuidgen` CLI tool, at least for modern versions (I have not checked historically), says (from https://man7.org/linux/man-pages/man1/uuidgen.1.html): "By default uuidgen will generate a random-based UUID if a high-quality random number generator is present." (later it lists /dev/random as such a generator, present on almost all systems)

What's an example of a system that generates v1 uuids by default?

[antonjs]

Isn't the string comparison claim also wrong?

Although plenty of UUIDs are passed as strings in eg JSON, I was under the impression that where performance really matters (like db indexes) they were stored and compared as 128 bit fields. To be fair, the points about word sizes and ordering make sense.

[wswope]

> What's an example of a system that generates v1 uuids by default?

MySQL. One of many reasons to avoid it.

[smaccona]

Didn’t know this - true as of MySQL 8.X. I would say “shocking” if it wasn’t in keeping with a number of dubious decisions made over the years. We are using MySQL, but thankfully are generating UUIDs in our app layer.

Kludgy, non-cryptographically-safe UUID4 implementation in MySQL: https://stackoverflow.com/a/32965744