I prefer to trust the NSA on these matters.  They end up saying much of what the author has written, but they make it clear why you want to use one vs the other.<p>The excerpt below is from
<a href="https:&#x2F;&#x2F;www.nsa.gov&#x2F;ia&#x2F;_files&#x2F;factsheets&#x2F;I43V_Slick_Sheets&#x2F;Slicksheet_RNG_IntroForAppDev.pdf" rel="nofollow">https:&#x2F;&#x2F;www.nsa.gov&#x2F;ia&#x2F;_files&#x2F;factsheets&#x2F;I43V_Slick_Sheets&#x2F;S...</a> (which in turn also references 
<a href="https:&#x2F;&#x2F;www.nsa.gov&#x2F;ia&#x2F;_files&#x2F;factsheets&#x2F;I43V_Slick_Sheets&#x2F;Slicksheet_RNG_IntroForOpSysDev.pdf" rel="nofollow">https:&#x2F;&#x2F;www.nsa.gov&#x2F;ia&#x2F;_files&#x2F;factsheets&#x2F;I43V_Slick_Sheets&#x2F;S...</a> )<p>Unix-like Platforms (e.g. Linux, Android, and Mac OS X):<p>Application developers should use the fread function to read random bytes from &#x2F;dev&#x2F;random for cryptographic RNG services. 
Because &#x2F;dev&#x2F;random is a blocking device, &#x2F;dev&#x2F;random may cause unacceptable delays, in which case application developers may prefer to implement a DRBG using &#x2F;dev&#x2F;random as a conditioned seed.<p>Application developers should use the “Random Number Generators: Introduction for Operating System Developers” guidance in developing this solution.  If &#x2F;dev&#x2F;random
 still produces unacceptable delays, developers should use &#x2F;dev&#x2F;urandom which is a non-blocking device, but only with a number of additional assurances:<p>- The entropy pool used by &#x2F;dev&#x2F;urandom must be 
saved between reboots.
- The Linux operating system must have estimated that the entropy pool contained the appropriate security strength entropy at some point before calling &#x2F;dev&#x2F;urandom. The current pool estimate can be read from &#x2F;proc&#x2F;sys&#x2F;kernel&#x2F;random&#x2F;entropy_avail.<p>At most 2^80 bytes may be read from &#x2F;dev&#x2F;urandom before the developer must ensure that new entropy was added to the pool.