> If you tell me _why_ you think all-in-one-fs is "BAD", what you think
> is so dreadful about it, I'll be happy to explain why it doesn't always
> apply.

Log Files packing the root slice is my #1 answer.  /var should (in my 
opinion) *always* be separate from / on a production machine.
Users packing your root slice is #2, again (in my opinion, and in think 
in many, many others) if Users have access to a production machine, and 
have the ability to write to it, this is a looming problem.
/tmp being mounted on another spindle (or, if you can get it, another 
SCSI bus) can make large performance differences.  Some browsers (which 
shall remain unnamed at this point, since I don't want to embarrass 
their pin-headed developers in a public forum) store downloaded files 
in /tmp until the download is complete, and *then* copy them to their 
destination.  if /tmp is mounted in your root slice, and you try to 
download a large package or patch bundle from the web, guess what... 
you just might pack your root slice to 105%.

> For the times when all-in-one-fs *is* the wrong way to go, of course.
> For machines with multiple spindles.  For non-disk filesystems.  For
> declaring swap partitions.  Probably for other things, but those four
> should be enough.
Oh, I agree that it's there for good reason.  it should be there.

>> /sbin is for the important tools that need to be statically linked
>> (notice the 's' in the beginning of 'sbin'?)
>
> NetBSD has decided to disagree, and if you disagree with them on this
> point you may want to go looking for another OS, one better suited to
> your particular tradeoffs.

if there were a better one available, I would.  But NetBSD is the top 
of the stack, as far as I'm concerned, and that's why I'm peeved to see 
it going in this direction.

>
> And /sbin works fine for that, unless you've gone and put /lib on a
> separate filesystem from /sbin.

I don't, I leave /lib, /sbin and /etc on the / slice where they belong, 
but the point is that /sbin is supposed to be *statically compiled 
binaries* so that if you can't access your shared libraries, you can 
bootstrap things enough to get to where you can...

I guess I'm going to have to start writing scripts so that I can 
generate statically-compiled binaries for important system tools and 
retro-actively install them in /sbin, they way it should be.

-- 
George