> when in reality they should be calling getentropy()
A new programmer shouldn't be meddling in cryptography, so they probably don't need either cryptographically-secure pseudo-random numbers nor true random numbers. True random numbers are tricky.
My whole point is that cryptographically-secure should be the default, as there are many scenarios where a PRNG leads to a security vulnerability where a CSPRNG would not. It is precisely new programmers who should be using CSPRNGs for everything, because they are the least well-equipped to know when strong entropy is necessary! We should (almost) never be asking "Do you really need a CSPRNG?" but rather "Do you really need a PRNG?"
> because they are the least well-equipped to know when strong entropy is necessary!
Yuh. I'm not sure what "strong entropy" means, in this context; entropy's usually reported as some number of bits of entropy. So perhaps "a lot of entropy" is clearer.
At any rate, by default a (CS)PRNG doesn't have any entropy that isn't present in its seed. According to some, at least, that entropy is diminished every time you read from the RNG, so it depletes to nothing after a finite number of reads.
I've finally come to the conclusion that entropy, whatever that means, is orthogonal to RNGs. Instead, RNGs should be classified by their unpredictability. A CSPRNG is one with high unpredictability. And I've given up on trying to build a DIY HWRNG. It was a misbegotten project.
A new programmer shouldn't be meddling in cryptography, so they probably don't need either cryptographically-secure pseudo-random numbers nor true random numbers. True random numbers are tricky.