# In any case, claiming that /bin and /sbin are the "system recovery"
# tools is pretty ludicrous, as those same tools still depend on
# several critical files.  The only *real* reason that /bin and /sbin
# have continued to be statically linked is because they contain the
# tools necessary to locate and mount /usr.  That's all.

Apparently, historically, this was not the case.

/ was supposed to be a nice small filesystem by which one could do
system maintenance and/or recovery (hence fsck, restore, dump, newfs
and the like).

I didn't think it a prudent move when Sun decided to mangle the root
filesystem beyond recognition, and I thought BSD had the sanest fs
layout.  I still don't think it a prudent move to follow in Sun's
foot prints.  Honestly, we have much bigger fish to fry than this
kettle of fish we seem to be digging at.  MP/Threading comes to mind;
when that's locked down and sane, maybe we can then prod the other
horses and wake them up, but it seems to me we're prodding at things
that *really* don't need addressing *that badly*.

I mean, hells, since we've already FEM'd (front-end-mangled) fsck
to exec fsck_ffs (with less than desirable results produced by hitting
the QUIT key, I might add), if we're so hung on things like passwd
which produce authentication, why not do something like passwd_file,
passwd_nis, passwd_ldap and the like?

Or have it call out to an alternate process if need be?

I still don't think that mangling the filesystem layout is worth the
grief it's going to cause.  But that's my opinion, and you know what
they usually compare opinions to...

# -- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
# -- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/

				--*greywolf;
--
NetBSD: More Nines.