[ On Tuesday, August 27, 2002 at 23:47:10 (-0400), David Maxwell wrote: ]
> Subject: Re: HEADS UP: migration to fully dynamic linked "base" system
>
> On Tue, Aug 27, 2002 at 11:26:30PM -0400, Greg A. Woods wrote:
> > [ On Tuesday, August 27, 2002 at 10:44:45 (-0400), Bill Sommerfeld wrote: ]
> > > Subject: Re: HEADS UP: migration to fully dynamic linked "base" system 
> > >
> > > 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
anything but the kernel and the exact filesystem storage and structure
they are stored in (and the underlying hardware, of course) to load and
run successfully.  No other files or programs are needed (at least not
to the point where their main() functions are called).

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

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

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
directories.  The reach-over build stuff is trivial to maintain since
it's just a set of symlinks and one Makefile.inc file.  There's nothing
else different about the construction or use of those programs beyond
that -- their dynamic-linked variants are built and used in exactly the
same way as the programs in /usr/bin, etc.

> 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
procedure to install even just one shared library.  All the development,
testing, and Q/A stuff is exactly the same in either case.  Indeed there
are tremendous advantages to full upgrades in the way I do them since
other minor things can be "fixed" at the same time with no extra
headache -- less headache in fact since assurances can be made about all
those things at the same time.  Ideally TNF (or some central "shared"
service) produces branch upgrade releases on a timely fashion and
everyone can upgrade everything with nothing more than a recompile and
testing and Q/A of their own applications (which if they use pkgsrc and
generate binary packages for multiple machine installs is nearly trivial).

Just to make the point more concretely (and I know David knows this, but
FYI others who may not):  I currently do create custom binary releases
of NetBSD (and have done so for FreeBSD too) with local fixes,
modifications, all complete with pre-tested binary packages ready to
install.  I do this for myself and for some of my paying customers.  The
more customers I have the more releases and testing I can do.  An entire
building of machines can be regularly upgraded with nearly complete
automation using these "products".

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>