The pseudo-device /dev/random exists due to a collision between modern networks, and the historical design of the Unix operating system. First, we assume that the users of a system need cryptography, either in a form they use directly (ie, PGP), or that the system uses on their behalf (SSL and IPSec). All such cryptography requires the generation of a large amount of random or pseudo-random bits. There are other uses for such random bits, but these are few and far between, and /dev/random was initially designed for crypto, which is why it tries so hard to be cryptographically secure.
As computers are mostly deterministic, it is very hard to generate entropy without interacting with something analog (like a user, or a free-running oscillator). Often these are not available (consider, for example, a web server farm), and even if they are, Unix helpfully prevents us from talking to them directly. For example, Unix ttys are almost always in "cooked" mode, meaning you can't get useful timing information from typing like the old PGP versions used - there are multiple levels of indirection between the keyboard and your program. This type of layering also makes it hard to get useful entropy from packet arrival times, mouse movements, and so on - at least, from userspace.
Thus, in 1994 noted Linux kernel hacker Theodore Ts'o wrote a driver for Linux, which takes information about hard to predict events like keyboard and mouse use, packet and disk drive timings, and so on, and uses it to seed a cryptographically secure random number generator. A process can then open up the 'file' /dev/random (usually a character device), and read out random bytes. The driver keeps an estimate of how much entropy remains in the pool - if it goes below 0 then any reads will block until more entropy is added. This driver is primarily useful for authors of serious crypto software, though many other applications (like Perl) have been known to take a bit or two now and then.
The /dev/random driver was quickly ported to the open source BSD systems, and is also included in MacOS X (not surprising, as OS X is a BSD derivative). Oct 3, 2003: I have now found out that it is also included by default in new versions of Solaris, IRIX, AIX, and HP-UX. This essentially covers all of the Unix variants likely to exist within 5 years (compare with UnixWare, Tru64, etc).
Even MS-DOS has an (third party) implementation of it, apparently. A common alternative to /dev/random on other systems is EGD, though I figure within 5 years 90% of Unix systems will have a /dev/random, from increasing Linux/*BSD use, and others adopting the idea for their own systems. (10/2/03: I was right!)
For those unfamiliar with Unix device semantics, I'll point out that /dev/random is actually just the usual file system name used to access this driver - there is nothing intrinsic about the string /dev/random that makes it generate random bytes (one could easily swap
/dev/zero and /dev/random - good times!).
The actual driver is implemented in drivers/char/random.c in the Linux source tree.