[ On Wednesday, August 28, 2002 at 17:28:26 (-0400), Jim Wise wrote: ]
> Subject: Re: PAM
>
> Instead, the following benefits of loadable modules have been proposed:
> 
>     * easy propagation of library and locale updates to utilities

"make build" does the same thing.  NetBSD is distributed as source.

don't like to recompile to upgrade?  get someone to do it for you.

It doesn't take a rocket scientest to cut intermediate releases from the
release branches if TNF isn't doing it to any one person's desired
schedule.

This "recompiling is a pain" BS is nothing but whining.

>     * access to a wide range of locales from a single binary, without
>       having to bloat that binary by statically linking in every locale
>       which may someday be used

Nobody's proven this isn't possible anyway.  All I've seen and heard so
far is smoke and mirrors and one lone implementation, the design
rationale for which is as yet unexplained.

Others have already suggested, perhaps naively of course, that there
must be better ways to design the necessary algorithms so their
behaviours can be data driven (just as we can put error messages and
such in message catalogues) instead of requiring new object code.
(whether such an implementation would be smaller than the combined
direct implementation is an open question I suppose).

Also remember that if not done very carefully and correctly the use of
dynamic object code loading to switch between locales prevents an
application from living in multiple, or all, locales simultaneously.  I
don't know how to weigh those tradeoffs accurately, but I do know that I
already make use of applications which do simultaneously support all
locales they have been programmed to support.

Dynamic loading for locales just doesn't make sense to me.  The benefit
of bloat avoidance is far outweighed by at least my own desire to want
to use multiple locale features simultaneously in the same process.  And
who the heck cares about bloat except those of us who would only use
EN_US (or some other 8-bit locale) on our old vaxen and SS1's anyway!?!?!?

Dynamic loading of code that really can only be used one option at a
time might make some sense for some things some of the time (eg. xmms
can only decode one kind of audio file at a time, and maybe audio
decoders are big hunks of code and not residing on the right page
boundaries so they can be left paged out), but it makes absolutely no
sense in other places people have used it just for the whiz-bang effect
(fake eg.: a multi-protocol chat program where you can simultaneously
use different chat protocols but support for each has to to be
dynamically loaded).

>     * easy provision of third-party auth or nsswitch modules, including
>       those which depend on code not shipped with the base system

That's an empty argument.  Any third-party scheme can be just as easily
supported in plain old static-linked code.  NetBSD is distributed as
source.

Ultimately there is no technical _need_ for dynamic loading of code in
any open source environment (outside of the bloat and recompile whines),
especially not for forcing it across the board in an entire base
open-source operating system.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>