diff --git a/pep-0522.txt b/pep-0522.txt
index 07e8bea4b..395f5061f 100644
--- a/pep-0522.txt
+++ b/pep-0522.txt
@@ -49,7 +49,10 @@ the kernel reports that the call would block.
 
 No changes are proposed for Windows or Mac OS X systems, as neither of those
 platforms provides any mechanism to run Python code before the operating
-system random number generator has been initialised.
+system random number generator has been initialised. Mac OS X goes so far as
+to kernel panic and abort the boot process if it can't properly initialise the
+random number generator (although Apple's restrictions on the supported
+hardware platforms make that exceedingly unlikely in practice).
 
 Other \*nix systems that offer a non-blocking API for requesting random numbers
 suitable for use in security sensitive applications could potentially receive
@@ -129,6 +132,8 @@ This behaviour is potentially problematic, so Linux 3.17 added a new
 ``getrandom()`` syscall that (amongst other benefits) allows callers to
 either block waiting for the random number generator to be ready, or
 else request an error return if the random number generator is not ready.
+Notably, the new API does *not* support the old behaviour of returning
+data that is not suitable for security sensitive use cases.
 
 Versions of Python prior up to and including Python 3.4 access the
 Linux ``/dev/urandom`` device directly.
@@ -204,7 +209,7 @@ Affected Linux specific non-security sensitive applications
 Non-security sensitive applications that don't need to worry about cross
 platform compatibility can be updated to access ``/dev/urandom`` directly::
 
-    def blocking_urandom(num_bytes):
+    def dev_urandom(num_bytes):
         with open("/dev/urandom", "rb") as f:
             return f.read(num_bytes)