-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg,

you're rapidly wandering off into random unbacked accusations here --
any who disagree with you have `not fully disclosed motives', are
spreading `misinformation', and any who agree with them have been
`suckered into' doing so.

A key point of a rational discussion is that those discussing be able to
fairly state the position the position of those they disagree with,
rather than swinging at random straw-men.

Yet, the only positions you seem to argue against are alleged claims
that dynamic modules `reduce build times', or alleged benefits to
commercial vendors of dynamic module APIs.

Looking back, I see _no_ point in this thread where _either_ of these
were proposed as reasons to go with dynamically loaded modules.
Instead, the following benefits of loadable modules have been proposed:

    * easy propagation of library and locale updates to utilities

    * 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

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

Other than swinging at strawmen, I have seen you posit one actual claim
against dynamically linked binaries, the claim that they are somehow
`less secure'.  IMHO, if an intruder is in position to overwrite
loadable modules in {/usr,}/lib, they are almost certainly in position
to overwrite the login binary itself in /usr/bin, so this is a
non-issue.

Perhaps you could voice any disagreements you have with the above
points, rather than making vague insinuations of `undisclosed motives'
and presenting strawmen?


On Wed, 28 Aug 2002, Greg A. Woods wrote:

>[ On Wednesday, August 28, 2002 at 12:21:13 (-0700), Bill Studenmund wrote: ]
>> Subject: Re: PAM
>>
>> Why is it an abomination? Well, since you chose to use such a subjective
>> adjective, you're probably made up your mind well past openness.
>
>I've made my mind up because what I see in the end result isa design and
>implementation clearly done from one very specific point of view with a
>major goal in mind that has no application whatsoever in any true open
>source environment.
>
>The idea of extensibility is great, but we already have it in the form
>of the nsswitch library and its relatively elegant internal API.  It's
>very easy to add stuff to nsswitch, and support for most anything can be
>added to it (i.e. there are no limits eg. as those in BSD-Auth).
>
>> Well, you've chosen to do things in a manner a number of folks haven't.
>
>Sure -- that's one of my reasons for choosing to use open source
>operating systems as the platform for my uses.
>
>However I often hear from folks that they didn't know there was a
>"better" way and so they got suckered into using this whole idea of
>pluggable object code (often without even realizing any of the negative
>implications either).
>
>> They find having to compile each module into each program a support mess.
>
>They may well think that, but it would be irrelevant if someone did it
>for them and they just installed the resulting "package".
>
>People who really don't want to compile the code they use should
>probably consider buying or downloading and using some GNU/Linux
>distribution, or buying M$ or $un (or HP, IBM, etc.) products, or
>similar.  There the final integration and testing of the actual programs
>they use will hopefully have been done for them and it's up to their
>vendor to decide how to best support extensibility and upgrades, etc.
>
>> Yes, our lives are a bit easier in that we have nsswitch, so that there is
>> an API all these modules need to use. But it still means rebuilding chunks
>> of libraries and programs. We want loadable modules so you don't have to
>> do that.
>
>You and a very few people might "want" run-time loadable object code,
>but you sure as heck don't _need_ it.  Almost this entire industry has
>been happily using static bound machine code practically since the dawn
>of compilers.  Only those vendors who wish to have a tight proprietary
>lock on their implementations have really pushed dynamic run-time
>loadable object code out into common use.  Many assumptions are built
>around doing so and even those of us who've thought carefully about the
>implications of going fully dynamic may not yet realize all the issues
>(and I've been thinking of these things ever since I was developing and
>debugging DLLs in M$ Windoze 2.0, oh so many years ago).
>
>Arguments for pluggable code based on build times (which ultimately
>most of those based on memory utilization boil down to as well) are
>rapidly flying off into oblivion now that NetBSD can be cross-built on
>the fastest of development platforms.  All you're left with really are
>the complexity issues of dealing with variant target products, and even
>those don't seem too terrible, especially not from the point of view of
>an organization supplying, primarily, source code.  Groups of users who
>need certain options can build and maintain custom product code with
>great ease these days (and of course there are lots of avenues for
>getting professional support too).
>
>> > > it seems pretty clear where we
>> > > should start...
>> >
>> > It seems pretty clear that all these arguments for PAM are based on
>> > misinformation and false assumptions.
>>
>> Is it that, or that you heard some of what folks wanted to do and
>> projected thoughts onto that that they didn't say?
>
>What I hear is that some people have made a series of decisions that I
>can't find technical merit in agreeing with and they seem to have made
>them for reasons they have not yet fully disclosed (even though there
>are claims of ample background rationale).
>
>Ultimately there is no technical need for dynamic loading of code in any
>open source environment, especially not for forcing it across the board
>in an entire base open-source operating system.
>
>

- -- 
				Jim Wise
				jwise@draga.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (NetBSD)

iD8DBQE9bUB+N71lEcOYcw4RAuR5AJ48pzswoRvwJ6O2PXrojh3aJceyzACeNux4
KPwWYGHgdxD10IcmbEIruJA=
=YzWc
-----END PGP SIGNATURE-----