Re: fully supporting static linking in NetBSD (ar "zero" flag)

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

der mouse has already given very good answers to most of what you've  
said so I'll only address the few remaining issues:
On 15-Aug-08, at 1:49 AM, Jason Thorpe wrote:
> Of course, you could also make the argument that it's no longer PAM,  
> because it's not exactly plug-able if you can't actually load a plug- 
> in.
It depends on what one means by "pluggable" I guess, but I'm perfectly  
happy with compile-time plugins and the ability to dynamically chose  
from a static set of plugins that was created at compile time.
After all, I'd bet 99% of users will only ever be using the "static"  
set of plugins that was created at compile time anyway, regardless of  
whether their systems dynamically load them at runtime or not.
So, the silly thing is that a vast majority of users will never ever  
make use of more than one fixed set of plugins during the lifetime of  
their systems anyway.  All of that plug-ability (and complexity and  
overhead) is for nothing.  Let's not just waste development and  
maintenance effort on it!  Let's waste everyone's resources all of the  
time!
The sad thing is that another, simpler, safer, and arguably more  
secure alternative is freely available and could have been used in  
place of PAM but it was dismissed for reasons that even binary-only  
vendors cannot fully justify without resorting to arguments based  
solely on marketing hype and propaganda.  So much for goal number one  
of the NetBSD project (as it is stated publicly on www.netbsd.org).

> Well, it's true that part of the issue with the current  
> implementation is that pthreads is in a separate library.  Note, I  
> have also advocated for pthreads to move directly into libc, and for  
> all programs to behave as if they are "threaded".
I'm actually sort of 100% behind you on that one!  (depending on what  
you mean by "behave as if they are threaded")
I do believe that it has been shown categorically that user-level  
threading in single processes leads to a great deal of unnecessary  
complexity, however I'm willing to buy into the utility of having  
threading available in libc et al for those programs who's designers  
have chosen to use threading instead of some simpler and more robust  
design.  We can't get rid of threading as a design methodology despite  
its obvious problems in some (many) programming languages -- it seems  
to be built into the way some people think, and perhaps for good  
reasons.
Most APIs that need fixing to make threading usable in C etc. in a  
more robust manner are arguably in need of some level of improvement  
anyway.  I'd be more than happy enough to have to use a separate  
compatibility library for code that didn't yet make use of the  
improved APIs.  Doing so would also be a good reminder for those using  
threaded code that they are using APIs potentially dangerous to their  
chosen design.  It would also be nice though if there were a lean and  
trim build of all the system libraries which didn't include any of the  
internal code needed for any internal locking, etc. which only  
threaded programs would require.  The latter should be easy enough to  
maintain as it should only be a compile-time variant.
All this might fly in the face of current standards compliance though,  
at least to some level.

> I'm not basing this on "the requirements of binary-only vendors".   
> And my assertion that modern systems "require in some way the use of  
> runtime dynamic link/loading of code" is based on what I have   
> observed of user expectations ... certainly not all users (since you  
> are obviously so biased against the notion of dynamic extensibility).
Say it any way you wish -- what you've said still argues primarily for  
the requirements of binary-only vendors (or user who wish to use  
binary-only systems).
The vast majority of those requirements evaporate if one allows for  
users who are willing and able to recompile their systems when changes  
(such as new PAM modules, or new I18N code sets, etc.) are desired in  
their runtime environment.
Of course you could try to argue that users don't expect to have to re- 
compile their systems when their runtime requirements change, and to  
some degree that's always true, but I think it's _almost_ untrue when  
one considers the expectations of those who do expect to have and to  
compile source code in the first place.  (It seems even linux users  
would choose to compile and recompile far more often if in fact they  
could compile their systems as easily as one can compile NetBSD.)

> We already don't have full support for static linking.  There are  
> some things that don't work well/properly if you use static  
> linking.  I don't think it's a good use of NetBSD's development  
> resources to fix all of those issues and continue to maintain it  
> going forward.
Clearly NetBSD would have more development resources available if it  
were to accept fixes and maintenance help for the very few things that  
don't work well/properly yet in a static-only system.  The rest of  
your argument is therefore bogus.
--
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>