This is certainly a very good point in favour, probably the best I've
seen.  I'm still not convinced this is the right way to go.  There
must be a better way.

I will emphasize again that I would really *hate* to see a dynamically
linked init.  It strikes me as being fragile, at best.

Here's a thought:

Is there a way to build a program such that it can fall back, somehow,
if it can't find its .so?

It might require a new exec paradigm, but it might be worth it to be
able to build a program with internal fallback in case of a missing
.so [someone help me, please -- I'm starting to refer to them as DLLs!].

I personally think the work would be worth it to have that kind of
flexibility.

On Fri, 21 Dec 2001, Jason R Thorpe wrote:

# Date: Fri, 21 Dec 2001 09:43:04 -0800
# From: Jason R Thorpe <thorpej@wasabisystems.com>
# To: Greywolf <greywolf@starwolf.com>
# Cc: Luke Mewburn <lukem@wasabisystems.com>, tech-userlevel@netbsd.org
# Subject: Re: RFC: migration to a fully dynamically linked system
#
# On Fri, Dec 21, 2001 at 08:36:44AM -0800, Greywolf wrote:
#
#  > Why does nsswitch need to be part of a dynamic library?  Why can we not
#  > just do the lookup in the nsswitch.conf and behave accordingly?
#
# Because then for every possible auth type you want to provide, you
# have to have it included in libc.
#
# That ... does not scale well.  Nor does it handle Special auth schemes
# that local sites might want to use (would you rather just write your
# dynamically-linked auth object, or hack libc?)
#
# --
#         -- Jason R. Thorpe <thorpej@wasabisystems.com>
#


				--*greywolf;
--
NetBSD: the cathedral versus the bizarre.