Subject: Re: PAM
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 08/28/2002 16:31:17
[ 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
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
> 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.
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>