Subject: Re: RFC: migration to a fully dynamically linked system
To: Todd Vierling <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 12/23/2001 23:36:24
# 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 <email@example.com> * Wasabi & NetBSD: Run with it.
# -- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/
NetBSD: More Nines.