> a) somebody might sbrk or malloc a lot and use up all swap space... resulting
> in denial of other services (and no, limit()ing is no solution... if you divide
> your, say, 1 GB of swap space by your 32 users, and by the 64 processes you 
> allow per-user (maximum), you end up with err... half a MB of swap space per
> process, which is unusable... so you have to overcommit the limit settings.
> The problem was just shiftet to another domain... it was there earlier.

No, it is not just shifted.
sbrk()/malloc() failure could be checked by the well-written program
on non-over-commiting systems.
But on over-commiting systems, it could not be checked, even if the
program is well-written.
I believe this is certainly problem to implement reliable application.

> b) Many modern databases depend on efficiently handled sparse data
>    structures.

Almost all commercial UNIX are non-over-commiting systems,
so this should not be problem.

Also, sparse data structure could be implemented by other way
on non-over-commiting systems, for example, mmap MAP_SHARED with ffs
backing store. (not only ffs, but also all filesystems which support
hole)

It would be cool, if NetBSD could have kernel option to disable
over-commiting.
--
soda