On Fri, 30 Aug 2002, Richard Earnshaw wrote:

# > Corrupted file system is not unheard of, and often a reason why things
# > break down. :-)
#
# But irrelevant to this discussion, since a corrupted /rescue is no more or
# less likely than a corrupted /bin.

I think this is stemming from the point that the whole tree of this
discussion -- /rescue, and dynamic linking /bin and /sbin (including
init) -- is pointing out that the way we have it now consists of fewer
points of failure than the proposed direction we are going (which is
why I'm grateful for the option to rebuild into the current situation).

I think the init thing is more for localisation, really, since I don't
see network authentication being possible from init (since it would have
to plumb the network first, and that doesn't happen in single-user mode).

But I digress, sorry.

If /bin itself is corrupted, then, yes, okay, we have a small problem :).
It's a bit less of a miss - and less likely, I think - for anything IN
/bin to be corrupted.  But if /rescue (the directory), /rescue (the
filesystem) or /rescue/bin (the crunched binaries) are corrupted, bye, bye,
baby.

It comes to this:  Change is unstable by its nature, even if only temporarily.
Obviously, the directors of this ship are dead-set in its direction, because
they either have not thought out the pros and cons properly, or because the
pros sufficiently outweigh the concerns - technical or otherwise - that
it's deemed a necessary period of change, adjustment and suffering while the
bugs and issues get ironed out.

I refuse to speculate at this point whether this is a truly well thought-out
direction because a) I'm not there as part of the deciding group, b) I
have no real input on which to base that speculation, c) it's opinion due
to the lack of indepth information and d) I'm pretty sure I've been marked
as someone who's not quite educated enough to have an opinion that matters.
I will state that it's not a direction I would have chosen but then I'm
not known for crystal-clear foresight, either.

In any case, while pros and cons and concerns might be voiced, and bugs
do need to be fixed, someone is going to need to come up with an
extremely compelling reason as to Why This Cannot Be Done In A Sane Manner.

If there are no good reasons - not OPINIONS, like mine and Greg's and Mouse's
and Johnny's, but technical reasons which exceed the level of reason as
shown by many others (including the aforementioned) - not to do this, then
let it be done and maybe we can get energies being spent on this to be focused
on real work like the SMP and SA work which we are, by comparison to the
entire rest of the UNIX community, WOEFULLY behind on (for whatever reason,
and I think Frank and Bill Sommerfeld and Nathan are doing decently - I
don't think they have a lot of help.)

But I digress.  It's friday.  Sorry for the diatribe.

				--*greywolf;
--
NetBSD: unshackling hardware designers and users from the bondage of WinTel.