On Thu, 26 Sep 2002, Greg A. Woods wrote:

# > POV:  I try to take a reasonable stance on this sort of thing.  I'm not
# > altogether enthused with the frailty with which I perceive dynamic/modular
# > loading to be fraught, and this includes PAM and its current complexities.
# > However, I do think that to shut ourselves off to it altogether is not
# > entirely wise.  If we stop and stagnate, we die faster than we will if we
# > move forward and at least attempt to meet up with the rest of the world.
#
# You have a strange outlook on these things.

I try to keep a reasonable and balanced outlook on these things.

# "dynamic loading" does not equate to "modern" -- just because the
# monkeys in Redmond are doing it doesn't mean it's a "good thing", nor
# that it's even remotely modern.

Granted.

# Avoiding "dynamic loading" does not equate to "stagnation".

"Reality is 90% perception and 10% truth, if that."

# Don't confuse the kind of run-time binding that Multics had with
# anything even remotely like what ELF shared libraries, ld.so, and
# dlopen() et al try to do.

The unfortunate "reality" (see above) is that even if NetBSD somehow
manages to do a better job with dynamic loading, it will be very much
out of step with the other animals in the cage.

On the other hand, we may already be so far behind the game as it is
that we *could* carve a new nitch...hmmm.  The possibility you suggest
down a couple levels might have merit at that.

Personally, I'd like to see a run-time binding scheme OR a dynamic
loading scheme that presented enough of a performance AND stability
win over everyone else that it would actually make them take notice.

But that's not likely to happen.

# Do not confuse pluggable modules with dynamic loading -- the latter is
# only one way to achieve the same functional goal.

It happens to be, as I understand it, the simplest way given the current
infrastructure.

				--*greywolf;
--
NetBSD:  Write Once, Run Everywhere.  Java Optional.