🚀 go-pugleaf

Lopaka (lo@kokee.hawaiian.net) wrote:
>   Hello, anyone have a few moments to explain these two net
> terms? They aren't in the books that I have.

There's a document you should get, namely The Hacker Jargon Guide.
docs/hyper/jargon.lha on Aminet for instance.

**

daemon /day'mn/ or /dee'mn/ n.  [from the mythological
   meaning, later rationalized as the acronym `Disk And Execution
   MONitor'] A program that is not invoked explicitly, but lies
   dormant waiting for some condition(s) to occur.  The idea is that
   the perpetrator of the condition need not be aware that a daemon is
   lurking (though often a program will commit an action only because
   it knows that it will implicitly invoke a daemon).  For example,
   under ITS writing a file on the LPT spooler's directory
   would invoke the spooling daemon, which would then print the file.
   The advantage is that programs wanting (in this example) files
   printed need neither compete for access to nor understand any
   idiosyncrasies of the LPT.  They simply enter their implicit
   requests and let the daemon decide what to do with them.  Daemons
   are usually spawned automatically by the system, and may either
   live forever or be regenerated at intervals.

   Daemon and demon are often used interchangeably, but seem to
   have distinct connotations.  The term `daemon' was introduced to
   computing by CTSS people (who pronounced it /dee'mon/) and
   used it to refer to what ITS called a dragon.  Although the
   meaning and the pronunciation have drifted, we think this glossary
   reflects current (1996) usage.


demon n.  1. [MIT] A portion of a program that is not
   invoked explicitly, but that lies dormant waiting for some
   condition(s) to occur.  See daemon.  The distinction is that
   demons are usually processes within a program, while daemons are
   usually programs running on an operating system.  2. [outside MIT]
   Often used equivalently to daemon-- especially in the
   Unix world, where the latter spelling and pronunciation is
   considered mildly archaic.

   Demons in sense 1 are particularly common in AI programs.  For
   example, a knowledge-manipulation program might implement inference
   rules as demons.  Whenever a new piece of knowledge was added,
   various demons would activate (which demons depends on the
   particular piece of data) and would create additional pieces of
   knowledge by applying their respective inference rules to the
   original piece.  These new pieces could in turn activate more
   demons as the inferences filtered down through chains of logic.
   Meanwhile, the main program could continue with whatever its
   primary task was.


--
Lauri Aalto <aalto@iki.fi> --- http://www.iki.fi/aalto/