On Wed, Aug 28, 2002 at 02:50:05PM -0400, Greg A. Woods wrote:
> [ On Tuesday, August 27, 2002 at 23:47:10 (-0400), David Maxwell wrote: ]
> > > > This change *reduces* complexity; instead of having half the system
> > > > statically linked and half dynamic, everything is dynamic.
> > > Hmmmm... I don't think that holds water....  especially not with /rescue
> > > still in the mix on your supposedly "everything is dynamic" system.  :-)
> > Sure it does.
> No, I'm afraid it doesn't -- at least not with the logic below  :-)
>  
> > Currently, /sbin and /bin programs have to be 'special', and have to be
> > maintained that way. After this change, everything that the system runs
> > in normal operation can use the same subsystems, libraries, and
> > resources.
> 
> 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)

> 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)

> > Sure /rescue is 'different' from other parts of the system,
> 
> 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.

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.

> On the other hand my proposal to put dynamic-linked versions of the /bin
> and /sbin programs into some special place such as /usr/i18n/*bin is
> only a tiny bit more complex.  All it requires to implement is a
> reach-over build infrastructure must be maintained for those

This addresses the desire for dlopen() to support locale, but not for
nsswitch and auth reasons. As far as the locale part, I could stand to
hear well reasoned arguments for /usr/i18n/, but if they're only for the
purpose of avoiding /sbin and /bin going dynamic, then don't bother for
my sake.

> > Yes, some of us enjoy doing that, but it doesn't scale. It doesn't scale
> > to a large installation of machines, and it doesn't scale to providing
> > the best service we can to every NetBSD user.
> 
> I beg to differ.  Properly designed binary-only upgrade procedures are
> just as scalable, and some times perhaps even more so, than any

Sure they are, but building and testing large parts of the source tree
on as many architectures as NetBSD supports is problematic.

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
An organization gets what it rewards.
			      - Perry Metzger