Every few years someone reminds the internet that you should just use /dev/urandom on Linux, and every few years the same myths come back. Thomas Hühn's classic write-up Myths about /dev/urandom is still the cleanest takedown I've read, and it's wild how relevant it remains a decade later.
The core myth is that /dev/random is somehow "more secure" because it blocks waiting for entropy, while /dev/urandom is the cheap knockoff. That mental model is wrong. Both pull from the same CSPRNG. Once the pool is properly seeded, a modern cryptographic PRNG doesn't "run out" of randomness — that's not how stream ciphers or hash-based DRBGs work. Entropy isn't a fluid you drain.
The one real concern is the early-boot case: on a fresh system, before the kernel has gathered enough seed material, /dev/urandom could return predictable output. That's exactly the problem getrandom(2) solves — it blocks until the pool is seeded, then never blocks again. So the modern answer is boring: call getrandom(), or on userspace, use your language's CSPRNG which almost certainly does the right thing.
What frustrates me is how much old advice still floats around in Stack Overflow answers and shell scripts piping /dev/random into key generation. It makes builds hang on headless VMs and teaches juniors a broken mental model. If you see /dev/random in a script written after 2018, replace it with /dev/urandom or getrandom() and move on with your life.
