This article seems to continually conflate "sources of randomness" with pRNGs. The linux entropy pool is not merely some estimation of randomness by the kernel

This article seems to continually conflate "sources of randomness" with pRNGs. The linux entropy pool is not merely some estimation of randomness by the kernel -- it's a collection of bits accumulated from a variety of sources (including rdrand, btw) -- which are munged in such a way that any single bit of input causes a cascade in the states of all output bits -- then fed into a pRNG. Not trusting rdrand (or any other single source, including input devices, internal sensors, IRQ timings, internal clock, etc.) is a feature and does not somehow make the degree of entropy weaker. Having a broad collection of entropy sources feeding into your entropy pool simultaneously helps make the random device more secure by ensuring that if an attacker gains access to any number of these inputs, they still cannot predict outputs as long as they lack even a single one. This is exactly the article I would have published if I were a state attacker trying to make it easier for myself to create side-channel vulnerabilities in applications relying on randomness. If tpornin's primary concern is blocking IO (and not unpredictable, cryptographically-secure RNG) then his or her advice makes sense. However, if secure randomness is a concern, then the advice should simply be to encourage application developers to use the minimum amount of entropy needed from the entropy pool. Many, if not most applications are guilty of consuming far more randomness than they truly require.