Adding to aidenn0's comment, if you trust /dev/urandom to produce 4kb of random data, it follows that you trust it to produce 128 bits.

128 bits (32 bytes) is sufficient to initialize a PRNG into any one of 115792089237316195423570985008687907853269984665640564039457584007913129639936 states (that's 1 with 77 digits). Consequently, hitting the kernel constantly for so much data is utterly inefficient in the first instance, and totally unnecessary in the second.

Blog author could improve his design's efficiency >128x just by seeding a PRNG with a single 32 byte read at the start of the subprocess

Userland PRNGs are one of the easiest ways to introduce security vulnerabilities into your programs. I would recommend being very, VERY careful before trying to do this, like the traditional "Don't roll your own crypto" advice.

Only in this case you aren't rolling your own crypto, but (hopefully) using a popular, field-tested CSPRNG available as a library for your language of choice. Unless you mistakenly pick a non-cryptographic PRNG, and assuming the implementation is correct (which is just as true of kernel code as it is of user code), I fail to see how you would introduce a vulnerability.

Of course. But there are a lot of needs for random numbers that don't need the random numbers to be secure.

Most developers don't know how to make that distinction, and even savvy ones know better than to take the risk of being wrong.

It's 2014. There are well-funded governments and organized crime attacking our systems. If downstream developers still have to ask the question, "what kind of random numbers does this API provide?", then it's a bug in the platform.

In which case rand and the like really should be renamed unsecure_random to prevent confusion.

Fine by me

If you care about security, avoid this approach; it creates an additional single point of failure, which historically has also tended to be a very likely point of failure (see: Debian randomness, Android Java SecureRandom, &c).