: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>

    Have you written any of the software running on these?  If not, well...
    I have, though not with FreeBSD specifically.  Embedded systems with 
    no disk.

    When you write embedded systems like these, you do not run any general 
    purpose binaries at all.  You run fully custom binaries and you take
    control of the memory management yourself.

    These systems do not need in-kernel memory reservation to operate.
    In fact, these types of systems generally do not even do dynamic memory
    allocation - most everything is statically allocated and if the system
    tries to use more, it panics and reboots.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>