Entropy is a technical term for "Randomness". Computers don't really
generate entropy but gather it by looking at stuff like the variations of
hard drive rotation speeds (A physical phenomena that is very hard to predict
due to friction ect.) When a computer wants to generate a pseudo random data it
will seed a mathmatical formula with true entroy that it found by measring mouseclicks, hard drive spin variations etc. Roughly speaking entropy_avail is
the measure of bits currently available to be read from /dev/random
it takes time for the computer to read entropy from its environment unless it has cool hardware like a noisy diode or something.
if you have 4096 bits of entropy available and you cat /dev/random you can expect to be able to read 512 bytes of entropy(4096 bits) before the file blocks while it waits for more entropy.
for example if you "cat /dev/random" your entropy will shrink to zero. At first you'll get 512 bytes of random garbage but it will stop and little by little you'll see more random data trickle trough.
This is not how people should operate /dev/random though. Normally developers will read a small amount of data like 128 bits use that to seed some kind of PRNG algorithm. Its polite to not read any more entropy from /dev/random than you need to since takes so long to build up and is considered valuable. Thus if you drain it by carelessly catting the file like above you'll cause other applications that need to read from /dev/random to block. On one system at work we noticed that a lot of crypto functions were stalling out. We discovered that a cron job was calling a python script that kept initializeing "ramdom.random()" on each run which which ran every few seconds. To fix this we rewrote the python script so that it ran as a daemon that initialized only once and the cron job would read data via XMLRPC so that it woulden't keep reading from /dev/random on startup.