[ On Sunday, January 23, 2005 at 10:11:11 (-0800), Jason Thorpe wrote: ]
> Subject: Re: PAM and su -K 
>
> As soon as you step up and offer (and follow through) to maintain all 
> aspects of statically linking the NetBSD universe, then maybe I could 
> take this argument seriously.  But until then, all I'm hearing from you 
> (and all the other people who irrationally fear an all-dynamic 
> universe) is an unreasonable demand to increase software maintenance 
> and development costs in a way that impedes the progress that the 
> NetBSD Project needs to make in order to stay relevant in the OS world.

There's no "irrational fear" of static linking from me.

It's outright dislike and disgust of the clear and dramatic technical
consequences and measurable costs and overhead of dynamic linking.

Dynamic linking really has no gain whatsoever for a vast and varied
class of true real-world production systems, and I'm not just talking
about embedded systems but also most day-to-day application servers,
internet servers, file servers, etc., etc., etc.  In fact it is a very
serious pain in the butt more often than not; not to mention being a
_constant_ and unnecessary drain on everyone's resources, no matter how
plentiful they might seem to be.

Of course just as loadable kernel modules have their place in making
kernel code easier to test and debug, dynamic linking has its place in
similar situations as well as in certain specific environments where
some resource constraints outweigh others.  However it is clearly not
the panacea you seem to suggest it to be, nor is it a key feature for
"relevance in the OS world".  I've never heard anything on this topic so
completely ridiculous in my life!

Meanwhile contrary to your suggestion the so-called costs and
"unreasonable demands" on maintaining an all-static build option are
really rather tiny to the point of being non-existent.  The only real
maintenance cost I've _EVER_ encountered with building static-linked
systems (on _any_ platform, including NetBSD) has been the need to bash
a few odd (mostly non-*BSD) developers about the ears and get them to
learn/remember how to do proper dependency checking and parameter
ordering for all their libraries.  I welcome you to try to point out any
that you think I may have missed, but keep in mind that I'm speaking
from a position of considerable experience on this matter, and I don't
just mean my recent year or so of experience with building and using
static-only NetBSD systems in production environments.

On the other hand almost everything about dynamic linking has measurable
and demonstrable costs in many ways, from runtime costs with every
program startup to the costs of complexity that impact both developers
and system managers (though in different ways for each).  This remains
true on all kinds of systems, not just *BSDs of course (with the current
ld.so mechanism and even with the support of helper tools such as
libtool, we're only a very tiny step away from the DLL hell of other
systems).  In fact for anyone who takes the time to look with an open
mind there's a vast mountain of published evidence attesting to the
problems and costs of dynamic linking and all the additional tools and
complexity it requires.

Furthermore all the claims that have been made over the years, and which
are still being bandied about, for the benefits of dynamic linking are
few, of lesser value, with all modern open-source systems.

Support for static linked executables (and their creation) is a basic,
fundamental, requirement for the underlying OS, one that can never
really go away -- at least not without completely changing the
underlying paradigm of how executable code is loaded by the kernel.

Indeed a great number of subtle bugs in many applications can be quickly
and easily discovered and often eliminated just by testing that static
linking works properly.  This is because, unfortunately, the current
linker we use does not even warn about missing symbols or duplicate
symbols -- it just leaves all those problems, and their consequences, up
to the runtime linker, which on the other hand simply assumes naively
that _someone_ must have know what they were doing and it blindly makes
choices that can, often as not, result in runtime errors, data
corruption, etc.

So, as Greywolf so aptly put it, don't you be cutting my rope for me!

Since I do already maintain my own custom static-linked system using the
NetBSD source tree as a base (and provided that the underlying
technology in NetBSD still to makes this possible, as I have no doubt it
will continue to do so), I can make available the fruits of my efforts
to the NetBSD project as a whole.  I'm not sure how this might be made
to work in practice of course, but suffice it to say that there won't be
any question that the little bit of maintenance you so fear will in fact
be being done by someone anyway.  :-)


BTW, if NetBSD (and the rest of the GCC-using free OS projects) really
do hope to remain relevant in the OS world while at the same time
continuing to try to tout dynamic runtime linkers as a benefit, then
they absolutely must work much faster and much harder towards providing
proper pre-binding support (ala Darwin et al) along with much better
facilities to help increase the locality of reference in massive
dynamic-linked address spaces.  Without such enhancements none of the
very real and ever-present and ever-recurring costs of dynamic linking
can ever be mitigated.



As for PAM, well it's still a poor solution looking for a problem, and
one derived from old requirements that no longer exist in any modern
open source systems.

If NetBSD had really wanted to follow the published goals for building a
better system that had decent "dynamic" (i.e. runtime) controls for
selecting different kinds of authentication mechanisms then the better
answer would clearly have been the BSD Auth stuff, not this OpenPAM junk.

Maybe there really is enough benefit to some tiny few number of NetBSD
users who think they need PAM to have OpenPAM integrated into the
official NetBSD source tree, but if doing so forces it down the throats
of all NetBSD users then something just isn't right.  Such a unilateral
move would clearly fly directly in the face of the stated, and widely
accepted, goals of NetBSD.

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>