edo

> On other file-systems, you may still wish to compress file contents when rsync'ing for backup, copying to a mobile drive etc. You could do this using --copy-cmd and gzip...

> I assume using variant#3 would allow to redefine the the structure entirely. Moving or removing version from the definition for example It is the last unused variant, so there...

> Using the `variant` field to signal different bit semantics within RFC 4122 versions is not appropriate. What about using `variant=0b111` in a new format (without version)? Expanding the variable...

> But imho, defining a new variant should be a Big Deal™ Agree. There were no sortable UUIDs in the standard. Is this a Big Deal™? Seriously though, I want...

> Recommend the use of MAC addresses > Use IPv6 addresses. This is a non-universal solution (for example, the host may have no public IPv6-address or the application may not...

> How so? I faced MAC address conflict few times. Therefore, the existence of a MAC address range registry does not guarantee MAC address uniqueness. My guess is that a...

> I assume 48 bit for random bits should be sufficient for millisecond, microsecond and nanosecond precision as well. IMO this is too little to avoid collisions. Especially with millisecond...

``` UUIDs per nanosecond: 461168601842738816 (2**62 / 10) ``` Wouldn't it be ``` UUIDs per nanosecond: 46116860184273879 (2**62 / 100) ``` ? BTW, your calculator is wrong a bit. https://play.golang.org/p/B-rzKVAJhNE

> I vote to leave at 36 in the current implementation IMO the random part should be as big as possible so keeping 4 leading zero bits is a weird...

> If we use 40 bits with 10-milliseconds or centisecond precision: LGTM > The database will be happy with this precision (right?). 1. Monotonic UUID (centralized generation only) The resolution...