Let me supplement the other answers by explaining, in some level of detail, how a PRNG with an entropy pool works. This is a bit of an oversimplification, as the current Linux implementation uses multiple pools. But it should help give you the basic idea of how the scheme works.
First, it contains three key parts:
An entropy pool. This is basically just an array of bytes. A key goal of the system is to ensure an attacker does not know these bytes.
A PRNG. This is an algorithmic component that operates on the entropy pool to produce random output.
A collection of entropy probes. These 'mine' randomness from things like network and disk activity and add them to the entropy pool.
The PRNG "draws off" the entropy pool. The exact algorithm is complicated, but the basic idea is that it performs a cryptographically secure hash operation on the pool, outputs some of the hash, and mixes some of the hash back into the pool. (In the current Linux code, it actually uses two SHA1 operations.)
The probes "fill up" the entropy pool. The exact algorithm is even more complicated (twisted GFSR), but the basic idea is that the pool is mixed around and then various information from the probes is XORed into the pool.
In addition, the system keeps a measure of how much entropy is in the pool. It assumes that producing random output "depletes" the pool and that adding entropy "fills" the pool. There is a theoretical sense in which this is true, but effectively it doesn't matter.
For example, assume a 2,048 byte pool and an attacker who knows nothing about the contents of the pool. And then suppose he sees 8 bytes of output from the pool. In theory, that rules out all but 1 in 2^64 possible initial conditions and leaves only those that would produce those exact 8 bytes. But there is no known, or even conceivable, way an attacker could use that information.
With no additional entropy added and with 1GB of output from the PRNG, an attacker has all the information he needs to figure out the pool's initial condition and predict the next output from the pool. The problem is, there is no known method of doing that other than trying all 2^(8*2048) possible initial conditions.
For practical purposes, there are only two attacks possible:
Guess the added contents of the pool. This fails if there are more than, say, 128-bits of unknown data mixed into the pool An attacker cannot try 2^128 or more combinations.
Guess the contents of the pool at some later point. But this requires guessing the entire pool.
In sum, unless there's a defect in the algorithm, output from the pool doesn't reveal useful information about the contents of the pool. So long as an attacker cannot predict or guess all the information mixed into the pool up until the point you drew off the pool, he cannot predict what will come out of the pool. (Assuming he can't look inside the pool itself, of course!)