Re: Stop shipping static libraries for NetBSD

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

On 18-Aug-08, at 6:11 PM, Matt Thomas wrote:
> The proposal is stop shipping; not stop using.  Anything in the  
> build can
> continue to use them, as can anyone doing their own builds.  The  
> proposal
> is to not ship them so the average user won't be able to link static  
> programs.
To me it is just as sad that NetBSD, in its role as as a binary-only  
vendor, would like to take the same attitude that Sun and Apple and  
Microsoft have done and also force everyone providing source-based  
software to those using those binary-only distributions to be totally  
locked into the "everything must be dynamic all the time" mindset.
It just doesn't make any sense whatsoever no matter which way I look  
at it.
Of course I just don't get the whole mentality of using binary-only  
distributions of open-source systems in the first place.
In any case one can choose to lock one's self into requiring dynamic  
runtime linking all the time even when sane alternatives exist and  
regardless of whether one has source or not, but I think doing so is  
rather short-sighted and wasteful in the worst of ways.
Why not just crunchgen the whole system into one "lean" binary and  
maybe even lock it right into the kernel?  Then you get the benefits  
of being able to upgrade your whole system just by booting a new  
kernel!  No runtime overhead, and not one byte of waste through  
duplication of object code either.  Pure and total reuse everywhere  
all the time but never any possibility of DLL hell!  What an amazing  
idea!  Come on now, let's get mozilla into the kernel!  And it'll  
always just be one program to recompile.  It just can't get any simpler!
Or why not just run a fully interpreted system, or at least put a just- 
in-time compiler into the kernel -- much more robust and even more  
dynamic.  Never recompile again!  Resurrect that machine independent,  
compiler intermediate object format from the OSF days for the  
proprietary vendors.  Performance?  No worries since everyone has  
multiple multi-GHz cores in every system they could ever want to use.   
Security?  Well we can put that in later once the JVM folks finally  
figure out how to do it properly.
Can someone involved in this crazy proposal _please_ go re-read the  
published goals for NetBSD?
--
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>