On Sat, 29 Dec 2001, Rick Kelly wrote:

: >I think it is more that the objections have boiled down to not wanting
: >change as opposed to specific features of the change. Also, I don't really
: >think the objections are the majority.
:
: It just boggles my mind that anyone would want to increase the level of
: convolution in NetBSD. So far we have stayed away from the mess of twisty
: little passages that is SVR4 and Linux.

NetBSD has added many features in the past that have been called "SVR4isms"
or "Linuxisms" at first.  However, we've gone to great pains to make sure
that we have peer commentary and brainstorming sessions to make sure such
features are implemented Correctly.  As a result, they don't have the same
problems exhibited in these other OS's.

Having dynamic binaries in /bin and /sbin does not inherently increase the
complexity of NetBSD by itself.  However, using dynamic binaries in /bin and
/sbin in a sloppy manner, such as in Linux's approach, would.

: Also, one should consider how these changes will affect the performance of
: 68k and other very old systems.

Actually, dynamic binaries in /bin and /sbin should significantly *decrease*
system boot time on older and low-memory systems, because of the inherent
shared code between all such programs.  In fact, I had measured a very
significant speed increase on a netbooted SPARCstation 2, in NetBSD-current
between 1.3 and 1.4, with 8MB RAM when /bin and /sbin are dynamic -- nearly
50% faster bootup at the time.

There is a concern when it comes to /bin programs used extensively in
scripts, for instance; but these can be tested empirically.

: >The fundamental point is that we want to be able to add locale support and
: >new authentication schemes to all(*) programs, even ones in /bin and
: >/sbin. We really need that to be able to move forward in a number of
: >directions that I gather the majority of the project folks (including
: >myself) want to move.
:
: All of the binaries in /bin and /sbin don't need locale support.

But most do require access to the passwd database, which we want to use via
pluggable modules.

: >Everyone agrees we need statically linked recover tools (they were in the
: >initial posting as I recall), and static binaries will still be supported
: >(you can make them, run them etc.).
:
: How many megs of stuff does all this add to /? What happened to neat,
: complete operating systems that can fit easily on a 1 gig disk with room
: to spare? Or even a 250 meg disk?

The disk space requirements of the system are reduced by having dynamic /bin
and /sbin.  This was illustrated earlier.

A single crunchgen'd binary for recovery tools, or a gzipped recovery kernel
with a ramdisk, still leaves the system with a free space gain.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/