[ Trimmed CC list a bit ]

> > :* even if you are not willing to pay that price, there _are_ people
> > :who are quite willing to pay that price to get the benefits that they
> > :see (whether it's a matter of perception or not, from their
> > :perspective they may as well be real) of such a scheme.
> > 
> >     Quite true.  In the embedded world we preallocate memory and shape
> >     the programs to what is available in the system.  But if we run out
> >     of memory we usually panic and reboot - because the code is designed
> >     to NOT run out of memory and thus running out of memory is a catastrophic
> >     situation.

*ACK*  This is unacceptable in many 'embedded' systems.

> There's a whole spectrum of embedded devices, and applications that
> run on them.  That definition works for some of them, but definitely
> not all.
> 

Totally agreed.  A previous poster brought up the fact that *some*
embedded systems are built to deal with 'out of memory' situations, and
that the 'total' amount of memory used in the system can be used by
other parts of the system.

For performance reasons, a particular application may choose to 'cache'
data, but in low memory situation it can 'free' up alot of memory.  You
don't want to put hard-coded limits the process simply because if the
memory is there you want it to be able to use it, but you *certainly*
don't want to go through a reboot just to get memory back.

[ And, I don't want to write my own OS to do this for me. :) ]

(However, I agree that for general purpose computing, over-commit is the
way to go.  But, *BSD is not just for general purpose computing,
although that is it's primary market.)



Nate