That’s all. I just found this in a random script. Generates a random UUID every time it’s called. I didn’t know.
Of course I can also use uuidgen or pipe /dev/(u)random into something to get a random alphanumeric string - but this is built right into the kernel!
In /proc/sys/kernel/random/, there’s also boot_id which seems to do the same is static, and some tweakable parameters.
❤️🐧
Interesting,
non-scientific speed test:kernel 6.1.0-37-amd64:
$ time for i in $(seq 1 100000); do cat /proc/sys/kernel/random/uuid > /dev/null; done real 3m53,388s user 1m37,366s sys 2m13,847s $ for i in $(seq 1 100000); do cat /proc/sys/kernel/random/uuid ; done | wc -l 100000vs.
uuid1.6.2-1.5+b11:$ time for i in $(seq 1 100000); do uuid -v4 > /dev/null; done real 4m44,854s user 1m37,867s sys 3m4,414s $ for i in $(seq 1 100000); do uuid -v4 ; done | wc -l 100000EDIT: I’m blind (wrong result).
Yeah but please don’t actually use this. Use a proper UUID library that works cross-platform and lets you choose the UUID type and can be seeded etc.
Can you explain?
Use for what?
Also it is being seeded, according to the fileurandom_min_reseed_secswhich is also writeable. Here are the other files:-r--r--r-- 1 root root 0 25. 5. 11:13 boot_id -r--r--r-- 1 root root 0 25. 5. 11:19 entropy_avail -r--r--r-- 1 root root 0 25. 5. 11:19 poolsize -rw-r--r-- 1 root root 0 25. 5. 11:19 urandom_min_reseed_secs -r--r--r-- 1 root root 0 25. 5. 11:19 uuid -rw-r--r-- 1 root root 0 25. 5. 11:19 write_wakeup_thresholdedit: the type is always DCE/random
That’s what you get when you define a file system as “a system that names things”.
deleted by creator
This is awesome. Thank you
I’ve used this in some bash scripts, very useful!
That’s what I mean. No more searching for ways to create shell-friendly randomness ($RANDOM does not always cut it).
boot_idseems to be static, probably set at boot.
So don’t use it for a random uuid.it’s fine as long as you reboot before each call
Oops you’re correct. Editing OP.
Works in Termux on Android
Thank you so much for sharing this!
See also: /dev/null
It’s basically a black hole where you can throw anything.
Yes, but what if it were a subscription? May I present: /dev/null-as-a-Service.
The most secure Bitcoin endpoint yet!
lol.
Okay, let’s be honest, it’s basically a crappy Pentium 4 box with Debian and nginx installed.
cat /proc/sys/kernel/random/uuid > /dev/nullwhile :; do cat /proc/sys/kernel/random/uuid > /dev/null; doneedit: on all cores for maximum “efficiency”
Would have to be
cat /proc/sys/kernel/random/uuid > /dev/nullYou can’t pipe to a file, only to programs, and since /dev/null isn’t an executable your command will simply give an error.
To make it more clear, consider using
dd, which lets you explicitly specify an input and output file. For example:dd if=/proc/sys/kernel/random/uuid of=/dev/sda1wait shit that wasn’t the right output oh god oh fudd is just cp but more confusing here.
The only thing dd can do that cp can’t is stop ahead of time, which only really matters for infinite files like/dev/randomcp /proc/sys/kernel/random/uuid /dev/sdadd if=/proc/sys/kernel/random/uuid of=/dev/sda1
Peanuts. Real men do
dd if=/proc/sys/kernel/random/uuid of=/dev/sdaThanks, I’m overworked lately.
lol, the last part
i saw this and came to do THE THING but you beat me too it. GOOD ANYA
The information will be evenly distributed upon its surface and some believe one day it will be be radiated back out into the rest of the system.
That’s a horrifying concept. Better not think about it.
no.
That reminds me of the CPU stress test I ran many years ago.
dd if=/dev/random of=/dev/nullIf you have 8 cores, just open 8 terminals, and run that code in each of them.
Can you guarantee that each process will run on its own core?
Absolutely not, quite the opposite actually. However, the end result is close to 100% CPU load, which is good enough for some purposes. Let’s say you want to test the performance of your CPU cooler, or overclock stability, this should good enough. There are also dedicated tools for people with more advanced needs.
/dev/urandom should stress the CPU more. /dev/random can be entropy limited
for i in {1..n} # where n == number of cores do dd if=/dev/urandom of=/dev/null & done # to stop: jobs -p | xargs killOh yeah. This looks like a much better way to do it. My solution is pretty bare bones by comparison.
the advantage of yours is that you can actually see the performance number afterwards.
