Subject: Re: RFC: migration to a fully dynamically linked system
To: Jason R Thorpe <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 12/21/2001 09:54:19
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
On Fri, 21 Dec 2001, Jason R Thorpe wrote:
# Date: Fri, 21 Dec 2001 09:43:04 -0800
# From: Jason R Thorpe <email@example.com>
# To: Greywolf <firstname.lastname@example.org>
# Cc: Luke Mewburn <email@example.com>, firstname.lastname@example.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 <email@example.com>
NetBSD: the cathedral versus the bizarre.