> The default seeding for the random module currently used 32 bytes from
> urandom() to create the initial state of the random number generator.
> This is far less than the number of possible states 2**19937-1.

I'm not a cryptography expert, but IMO 32 bytes is more than enough:
for example, ssh-keygen only reads 32 bytes from /dev/urandom when
generating a new key (and I assume the authors know what they're
doing).
So I'm not sure that "convering the state space" is a good enough
reason to increase the amount of data read: it can hut performance,
not only for the singla process case, but also because /dev/urandom is
protected by a spinlock/mutex, it can hurt workloads where multiple
processes are simultaneously reading from /dev/urandom (which is the
reason we switched to a persistent /dev/urandom FD), see e.g.
http://drsnyder.us/2014/04/16/linux-dev-urandom-and-concurrency.html

And I especially like this answer by Ted Ts'o (once again, I assume he
knows what he's talking about):
"""
Doctor, doctor it hurts when I do this. Well, then don't do that!

The reason for the spinlock is to avoid having two reads from
/dev/urandom return the same results. That would be undesirable...

If people are trying to read from /dev/urandom a huge number of times
per second, then they're doing something wrong. The real issue, as
Sebastian has pointed out, is that issue spawning a huge number of
curl processes for each request. Then hopefully curl is using
/dev/urandom to initialize its own userspace RNG (many crypto
libraries do this; most *should* do this), so you're not trying to
read from /dev/urandom for every single request. /dev/urandom is
designed for security, not for speed.
"""