The two (for me) important slides:

http://www.openbsd.org/papers/hackfest2014-arc4random/mgp000...

    rc4random cannot fail

    Look at the function definitions:

         uint32_t
         arc4random(void);

         void
         arc4random_buf(void *buf, size_t nbytes);

         uint32_t
         arc4random_uniform(uint32_t upper_bound);

    All 3 functions guarantee a result.  They will not fail, and cannot
    return an error.

http://www.openbsd.org/papers/hackfest2014-arc4random/mgp000...

    Linux?

    We have encouraged Ted Ts'o to create a getentropy-like interface
    for Linux; getrandom()

    Too many options, too easy to misuse

    Interactions with signal handlers (EINTR)

    Hope applications do not directly call getrandom()...


    Bit worrying

    Really feels like there is pressure against easy-access random..

    "Use /dev/random" meme continues damaging effects 

Linux's getrandom really has a bunch of error codes:

http://lwn.net/Articles/606202/

    EINVAL	An invalid flag was passed to getrandom(2)
    EFAULT	buf is outside the accessible address space.
    EAGAIN	The requested entropy was not available, and the
            getentropy(2) would have blocked if GRND_BLOCK flag
            was set.
    EINTR	While blocked waiting for entropy, the call was
            interrupted by a signal handler; see the description
            of how interrupted read(2) calls on "slow" devices
            are handled with and without the SA_RESTART flag
            in the signal(7) man page.

And a few flags:

   GRND_NONBLOCK	Don't block and return EAGAIN instead
   GRND_RANDOM		Use the /dev/random pool instead of /dev/urandom

I agree that the best interface is the one that can't fail.