(Sorry for the numerous typos in the original.  On reading it, I'm
appalled at myself.  (^&  Oh well...)


> > The former seems about like the dependancy on crunchgen, and elimites the
> > complexity of having two sets of binaries.
>
> While exploding the / partition size. Otherwise: fine. Maybe we should add

If space on / is a problem for so many, why do /home and /var reside on /
by default?  I have trouble believing that a cramped / is a serious issue.

I'm sure you can find a few machines for which this acttuall matters.
Crunchgen may be preferable for them.  They may even want their / to have
crunchgen binaries (from the numbers someone listed, I think that that
saves even more space than shared, yes?).  People in such "extreme"
environments will presumably want or need to do some extra work to get
things working anyway; a default setup that they can override (and which
doesn't actively impede them installing a working system) seems like the
appropriate response, to me.


> yet another make knob to generate uncrunched /rescue binaries for those that
> like it and have the space available? (No idea if this is easily implementable
> without making a big mess out of the /sbin and /bin makefiles)

Or, generate uncrunched /rescue and add a knob to *not* generate /rescue.
If people want, they can use the dynamic-linked root (or the old
static-linked root) as their sole setup.  Then the Makefile knob would be
"generate /rescue or not", which should be fairly simple.

I'm not sure how much it complicates things to make a crunchgen'ed /rescue
based on present-day /, but if the cost of such things is being weighed
carefully, surely it would be easier to make a /rescue that looks more
like present-day / than to use crunchgen for it.  Yes?  And less "mess" in
the Makefiles?


> > Perhaps, as well (if this isn't already part of the plan), /rescue (if
> > provided) should be a distinct parttion
>
> That you mount by which 'mount'/'mount_ffs' binary if your dynamic binaries
> do not work?

Err...I don't remember if I had fully engaged my brain on that.  (^&

A couple of post-hoc responses would be:

 a) Make mount static, or provide a static copy somewhere.  This still
    depends upon a lynchpin file in your regular / though.

 b) Make the /rescue partition bootable (i.e., include a kernel, etc.).
    This will add a few more megs, but would provide a fairly robust
    rescue environment.  Presumably there is no need to boot multiuser
    on /rescue.

    (Yes, this could be done without any real support from the NetBSD
    project...  But having a ``rescue'' environment optionally created
    at install-time (or easily unpacked into a filesystem from a .tar.gz)
    seems rather simpler, and would make the rescue environment more
    uniform, as an OS feature.)

I think that I had the latter in mind when I posted the original comment,
but I can't be completely sure.  (^&


  ``I probably don't know what I'm talking about.'' --rauch@math.rice.edu