Well, this discussion of mine has persisted quite some time. Fortunately, I
got most of my answers quite some time ago.

I've been reading this, and I've come to the conclusion that the
fundamental question has to do with deterministic system behavior. Most
good systems programmers that I know want deterministic behavior out of
their systems, so they program them that way, and that often involves hard
limits and strict resource accounting. For a very wide variety of
applications, this is exactly the right thing, because that leads to robust
overall system behavior.

By contrast, when you make everything dynamic, it's harder to map out all
the failure modes and edge cases (and all good systems programmers handle
all failure modes as best they can - there is nothing more embarassing than
an OS kernel that just hangs or crashes without a panic or other direct
indication of what went wrong).

The number One win that UNIX and its derivatives have over both MacOS and
WinTel is deterministic and robust behavior - when an application dies, the
whole system doesn't come crashing down around your ears as well. We should
do everything we can do to continue to deliver that robustness. Generally,
however, UNIX has a "give 'em enough rope" philosophy - if a user wants to
hang himself, we let 'im, because we assume he knew what he was doing. The
main place where this is unacceptable is in the multi-user (or server)
context, where one user might screw all users, so there are some mechanisms
to prevent or mitigate that.

However, if you posit a single-user system (as in, just one user; not
single user mode), then the OS shouldn't care so much about preventing the
user from doing things we might otherwise consider unwise; it's his
computer, let him thrash it as he sees fit (though a few "do you really
want to do this?" warnings wouldn't be out of place).

If we're going to support the widest uses of NetBSD, we need to develop
more clear, distinct models of use and system settings for those models,
e.g. single-user workstation, versus multi-user system, versus Internet
server. Each has its own requirements and tradeoffs, and I think we can
partition system behavior in such a way that both Mike and his opponents
can be happy.

For my part, Mike, what you're suggesting gives me the same concern as most
of the rest of the people arguing against you. However, I have no problem
with supporting the behavior you want, provided that it defaults to "off".
I would be happier if you could show that, as part of your implementation
of that dynamism, you handled all the edge cases cleanly. We just spent a
whole lot of effort to nuke the Mach VM from orbit because it behaved
*very* badly in resource-exhaustion cases. I think a lot of people hear you
wanting to bring that back again...

	Erik <fair@clock.org>