To be honest, I don't see why libkern needs to deviate from common convention (including POSIX) here. What problem is being solved?

In D6488#137509, @jilles wrote:

To be honest, I don't see why libkern needs to deviate from common convention (including POSIX) here. What problem is being solved?

The problem is using magic numbers like 123459876, but the real issue is that I would like to have a lighter alternative to arc4random that is not necessarily crypto-safe and I don't want to seed it with predictable numbers

I would prefer Marsaglia's KISS or Mersenne Twister but this would be good enough.

Hmm, random() is already slightly unpredictable because various parts of the kernel use it, so the determinism of srandom(1) is not really there anyway ;)

Because random() is used from various parts of the kernel, the accesses to randseed are data races disallowed by C11. I guess this has limited practical effect.

I wonder whether arc4random() is ready before random() is called for the first time.

In D6488#137515, @jilles wrote:

Hmm, random() is already slightly unpredictable because various parts of the kernel use it, so the determinism of srandom(1) is not really there anyway ;)

Because random() is used from various parts of the kernel, the accesses to randseed are data races disallowed by C11. I guess this has limited practical effect.

Well, I have a patch in D6442, replacing random() with arc4random(), that I plan to abandon in favor of this approach.

I wonder whether arc4random() is ready before random() is called for the first time.

random() was replaced in kern_init.c for something internal (would have to dig the revision), it shouldn't be a problem.

First, It breaks random API which suppose predictable results even with randseed 0.
Second, it is not proper way to make things less predictable. Proper way will be to replace all random() calls where predictable results are not needed (probably all of them) with arc4random() calls, eliminating random() from the kernel.

I.e. it is a hack which may confuse programmer who attempt to use predictable/saved random states in the kernel since function name stays the same and not telling him that results will changed on the fly with saved seed 0.

In D6488#137510, @pfg wrote:

I would prefer Marsaglia's KISS or Mersenne Twister but this would be good enough.

Mersenne primes PRNGs either suffers from visible patters or shorten range to compensate it. Better use this one 32bit and 64bit shifts&xors based, PDF article inside:
http://wwwmaths.anu.edu.au/~brent/ftp/random/xorgens305.tar.gz

In D6488#140505, @ache wrote:

In D6488#137510, @pfg wrote:

I would prefer Marsaglia's KISS or Mersenne Twister but this would be good enough.

Mersenne primes PRNGs either suffers from visible patters or shorten range to compensate it. Better use this one 32bit and 64bit shifts&xors based, PDF article inside:
http://wwwmaths.anu.edu.au/~brent/ftp/random/xorgens305.tar.gz

Mersenne Twister doesn't pass all statistics tests. I even think it's used in courses for wanna-be "hackers". It is very fast though, The MT homepage has accelerated versions for several processors, and it is appropriate for Montecarlo Simulations and/or games (the PS4 credits it in their opensource page).

kargl@ pointed me to Marsaglia's KISS which is about as simple as it can be (a combination of two LCG's I think) and passes all the statistical tests. The problem with both Marsaglia's KISS and MT, is that the seed is too big for what our libc expects.
openoffice-devel now uses 32-bit KISS but is seeded with a local random number (which I thought was crypto-safe when I implemented it). I think I will be changing it to a 64bit algorithm seeded with the randomizer from apr1 (Apache Portable Runtime). But first I will read more about your recent link .. thanks!
.

In D6488#140543, @pfg wrote:

...
kargl@ pointed me to Marsaglia's KISS which is about as simple as it can be (a combination of two LCG's I think) and passes all the statistical tests. The problem with both Marsaglia's KISS and MT, is that the seed is too big for what our libc expects.

I correct myself, Marsagila's KISS combines three RNGs:

http://www.thecodingforums.com/threads/64-bit-kiss-rngs.673657/