On Tue, 13 Jul 1999 14:56:52 -0700 (PDT) 
 Matthew Dillon <dillon@apollo.backplane.com> wrote:

 >     Jason, I am using real life situations to demonstrate my point.  You are
 >     perfectly welcome to use your own REAL-LIFE situations to demonstrate 
 >     yours.  It is the real-life application that matters, not a worst-case
 >     nightmare theory.  No engineer designs systems based on nightmare 
 >     theories.

Yes, you're using your own REAL-LIFE situations, from a large ISP, using
systems for a few specific server applications, where you have the space
to put lots of disk, etc.

The things I'm thinking of aren't even necessarily "large server"
applcations.  NetBSD runs on a CPU that is *often* used in small
embedded applcations -- the StrongARM.  NetBSD also runs on the
Hitachi SH3, another popular embedded processor.

An an example of the latter case, NetBSD is actually the OS software running
in a *camera* made by a company in Japan.

If you can run on a camera, you can run on a lot of other small appliances
too (this isn't a stretch).  You might be running on a cash register (err,
well, those new-fangled touch-screen "transaction terminals").  This isn't
a stretch, either.  You might be running on a set-top box (nor is this
a stretch; hell, I have one of these in my living room, and it's capable
of booting the OS from ROM card -- who needs a diskless server? :-).

We're talking about systems which just don't have a lot of disk space (in
fact, NO DISK AT ALL), but may be running software which is designed to
gracefully deal with memory allocation failures.

What do you have against giving people the flexibility of preventing
overcommit?

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>