[sorry if I digress a bit; there seem to be some nontechnical points
 that need to be addressed.]

On Wed, 28 Aug 2002, David Maxwell wrote:

# > There's nothing "special" about /sbin and /bin programs other than they
# > are compiled and linked as static binaries and they don't depend on
#
# Paraphrased: There's nothing special about X, except that they're
# treated differently than every other binary on the system.
#
# Rather than searching for an interpretation of my words that works for
# your argument, how about trying to understand why I said what I did? (1)

That's kind of a red herring, don't you think?  Wouldn't you agree that
it's rather dependent upon the importance and quantity of the X rather
than just the existence of the X vs. the Y?  It matters to me, certainly.
I'm not inclined to complain about a single element, or even a handful, or
even a lot if their importance is not great, but /rescue or /recover or
whatever we're calling this certainly does seem to imply that "well, we're
ripping this out, even though we're aware of its importance, and we're
epoxying it and nailing it in place over here."  Or, to phrase it less
popularly, "We do see the need for that, but its benefits are outweighed
by those provided by a dynamically-linked system whose benefits simply
cannot be matched without a complete redesign of the CCS (which the GCC
folks won't buy back (which is just a symptom of "NIH!", the ultimate
arrogance, but I digress)), so this is really our only option unless we
want to support our own compilers."  (the cost, in time/$ of redevelopment
of this whole framework is prohibitive.)

#
# > If the ability to build and use static binaries ever becomes a "special"
# > feature on NetBSD then that's the day I'll start using some other OS (or
# > at least stop using newer versions of NetBSD :-).
#
# Jason already said that isn't the case, so are you throwing alcohol on
# the flames just for fun? (2)

[which is why I think a few other people have shut up.]

# > The /rescue program(s) isn't just different, it's as currently proposed
# > much more complex and special (in terms of construction and use) than
# > even the programs in /bin and /sbin.  It's also not anywhere nearly as
# > regularly used as the perfectly fine static programs we have now in /bin
# > and /sbin.  Thus there's much more complexity to /rescue than to just
# > having /bin and /sbin left static linked.
#
# NetBSD 'ls' is more complex and special than 4.4BSD's 'ls'. That's a
# comment, but not an argument. It will continue to be meaningless as
# anything but a comment unless someone causally proves that this
# negatively impacts reliability, or some other goal of the project.

That's an extreme abstraction of the statement given, and it's about
as absurd as the difference between offering $100,000 for "a night of
fantastic lovemaking" and offering $100 for "a roll on the bed" and
saying it's the same thing.  A hardbound novel and a trade rag are the
same thing if you break them down far enough, but how far down actually
makes sense?

# I guess SMP and SAs and UVM and RAIDframe and everything else should be
# thrown away too - they're far more complex than what was there before.

[Should I *really*?  Nah.]

In general, it's a matter, really, of weighing the pros and the cons.  One
thing that MUST BE TAKEN INTO ACCOUNT, really, is that the pros and the
cons are not going to weigh equally for everybody.

SMP is something EVERYONE wants, because MP boxes are becoming more
attainable.

SAs (kernel-based process threading) is something most people have been
clamoring for, since it represents a degree of interoperability.

UVM is hailed as good by the community since it promises to improve overall
performance.

RAIDframe is seen as useful since it offers a cheap alternative to people
who can't afford or don't really need the full power of real RAID
hardware.

Dynamic root, including init, is seen as useful by some because it
will, ultimately, allow future interoperability on the fronts of a12n and
i18n; it is seen as useless by some because they will never use the
features.  I will sort of reluctantly agree that it's better to have the
functionality POSSIBLE (though optional to those who want it) than not
to have it present at all.  I might have to set up a system this way
in the future, and if I can't, well, I'm sunk, then.

I appreciate that the direction to be taken is one which will promote
interoperability (that is, after all, NetBSD's goal -- to maintain inter-
operability with The Real World, or else we are sunk), but not everyone
will share the exact same view.  It then becomes a matter of choosing
one's battles, one's priorities.

Luke's already assured that the build procedure will have a capability
NOT to build root dynamically-linked, for which I, at least, am grateful.

It's all said and done at this point, from what I can tell; since the
option to do or not is available to me, I no longer have a reason to
gripe, which is fine! :)

				--*greywolf;
--
NetBSD: The free OS with a money back guarantee!