On Wed, Mar 01, 2023 at 06:17:59PM +0100, Michal Suchánek wrote: > > Using a random number generator for clock can help, but it's only 13 > > bits, so it's certainly not fool-proof. Given that using a time-based > > UUID leaks the MAC address of your ethernet port as well as when the > > UUID was generated (which can be interesting when you're curious say, > > when a Libreoffice doc was created), in general best practice is to > > use the random UUID type, especially given that modern Linux systems > > all have the getrandom(2) system call. That gives you 58 bits of > > entropy in the UUID, so that's probably the better way to go. > > That explains why I don't have a clock.txt file. I did not go out of my > way to generate time-based uuids. Note that the only reason why you might be trying to generate a huge number of time-based UUID is if you are running a database (cough, SAP, cough) that is doing database index compression hacks so they can use still (a) use UUID's, but (b) not pay the cost of 16-byte UUID for every single object in their database. But if they are doing this, you ***really*** want to be using uuidd, because even using clock.txt in tmpfs, it's going to be *way* faster to use uuidd, and since some workloads (cough, SAP, cough) are creating a vast number of UUID's per second while initializing their database, your distribution users *will* want to install uuidd if they are using those kinds of Enterprise Resource Planning systems. If you consider how much per hour these users pay for their certified implementation consultsants, it's worth real $$$. :-) - Ted
