...

...

 Why not use /dev/random, instead of "ensuring you have entropy"Â

...

/dev/random limits the output size to the estimated entropy. So it has abysmal performance unless there are high performance entropy sources available.

This is for a one-time pad. Limiting the output size to the estimated entropy is a *requirement*. Abysmal performance is fine, because you're going to transfer the pad using a briefcase handcuffed to a courier's arm or some similarly high-cost high-latency physical distribution method, though if you've got a higher-performance entropy source, great.

After the initial seeding this gains very little security in practice.

If "gains very little security in practice" is good enough for you, you don't need a one-time pad. Yes, the pseudo-random bits you get out of /dev/urandom will probably be much better than the bits the Russians got by mashing down the keys on typewriters, and you're probably not going to be attacked with the persistence of the Venona decrypters, but don't waste your time using one-time pads unless you're going to use them perfectly. You're much better off using a long-enough RSA key and some Diffie-Hellman session key generation. (Of course, you still want good random numbers for those, but /dev/random is plenty fast enough for that, at least on any non-virtual machine.)