The principle of least surprise says to use "entropy" in the name, and
good engineering practice says to use the operating system "getentropy"
call as the source of the resulting sequence.

Programmers have mostly seen the "getentropy" call in standard libraries
and know that it provides bits which are unpredictable. If people
identify a need for an unpredictable source of bits, then whether or not
the name is an accurate use of the term "entropy," they are used to
something whose name includes that term doing what they want. So -
principle of least surprise.

Even if they don't really understand how it works, and even if they
don't really understand all of the requirements they need to meet under
all circumstances.  Getentropy reliably and efficiently produces high
quality results, even under unexpected and adverse conditions.  So -
good engineering practice.

Seriously, the code behind "getentropy" has by now been though the fire
in terms of testing, operation, adverse circumstances, attacks, and
unanticipated requirements.  Whatever it was found to lack, it has
gotten fixed. In practical terms whatever theoretical improvements could
still be made to it would result in behavior indistinguishable from what
it does now.

Bear

On 5/7/26 5:10 AM, Peter McGoron wrote:
> > I'll consider it, but at the moment I see no major advantage to
> 'entropic', except for the one mentioned by von Neumann's in his
> comments to Claude Shannon: "[N]o one really knows what entropy is,
> so in a debate you will always have the advantage."
>
> I'm in favor of "anything except 'crypto"'. "Entropic,"
> "nonrepeatable," "unseedable," etc.
>
> > If I understand correctly, this would give you
> >
> >    (srfi 271 crypto)
> >    (srfi 271 repeatable)
> >    (srfi 271 xorshift)
> >    (srfi 271 xoshiro256++),
>
> I meant what you wrote after:
>
> >     (srfi 271 crypto)
> >     (srfi 271 repeatable)
> >     (srfi 271 repeatable xorshiro256++)
>
> -- Peter McGoron
>