Important excerpt from random.c:

   * When random bytes are desired, they are obtained by taking the SHA
   * hash of the contents of the "entropy pool".  The SHA hash avoids
   * exposing the internal state of the entropy pool.  It is believed to
   * be computationally infeasible to derive any useful information
   * about the input of SHA from its output.  Even if it is possible to
   * analyze SHA in some clever way, as long as the amount of data
   * returned from the generator is less than the inherent entropy in
   * the pool, the output data is totally unpredictable.  For this
   * reason, the routine decreases its internal estimate of how many
   * bits of "true randomness" are contained in the entropy pool as it
   * outputs random numbers.
   *
   * If this estimate goes to zero, the routine can still generate
   * random numbers; however, an attacker may (at least in theory) be
   * able to infer the future output of the generator from prior
   * outputs.  This requires successful cryptanalysis of SHA, which is
   * not believed to be feasible, but there is a remote possibility.
   * Nonetheless, these numbers should be useful for the vast majority
   * of purposes.

This is the same old story. /dev/urandom is what you should use, unless you believe that the hash function is broken

This is sort of accidentally technically correct.

It's not always right to use /dev/urandom on Linux. During system startup, it does bad things if the entropy pool hasn't been initialized yet. So yeah. You shouldn't always use /dev/urandom, if you are writing code that's designed to run during system startup.

In every other case, you should use /dev/urandom.

It's a super-minor technicality preventing this article from being 100% wrong. Please don't follow its advice.

For an alternative (and more widely accepted afaict) opinion, see http://www.2uo.de/myths-about-urandom/

  Majority of web pages and blog posts I’ve read suggests to use /dev/urandom

Even the man page was updated to state that this is what you want unless under specific circumstances:

  The /dev/random interface is considered a legacy interface, and
  /dev/urandom is preferred and sufficient in all use cases, with the
  exception of applications which require randomness during early boot
  time; for these applications, getrandom(2) must be used instead,
  because it will block until the entropy pool is initialized.

Yet another blogger spreading an ancient myth.

"/dev/urandom gives lower quality randomness" - Simply. Not. True.

Or one could just use the syscall[0] which does the right thing™. If no flags are provided it only blocks at boot until the pool is properly seeded and then becomes nonblocking until shutdown.

[0] http://man7.org/linux/man-pages/man2/getrandom.2.html

The post lacks the term "CSPRNG", which I would have thought to be there in a discussion about randomness. Especially in collaboration with the concept of security.

The long story short, a Pseudorandom sequence can be more than enough in a security setting, provided that the stream of bits follow certain rules. For instance, it should be impossible to guess the next bit based on known history of bits. If /dev/urandom is backed by such a generator, which it is in many modern operating systems, then it is arguably safer than what the claim of the post is.

Why's it GNU/Linux when there's no userspace involved?