Marc G. Fournier wrote:
> On Fri, 1 Sep 2006, Gilles Chehade wrote:
>
>> Marc G. Fournier wrote:
>>>>
>>>> I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all
>>>> different goals...
>>>
>>> Even at the kernel level? Look at device drivers and vendors as one 
>>> example ... companies like adaptec have to write *one* device 
>>> driver, for, what, 50+ distributions of linux ... for us, they need 
>>> to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* 
>>> one for DragonflyBSD ... if we had *at least* a common API for that 
>>> sort of stuff, it might be asier to get support at the vendor level, 
>>> no?
>>>
>>
>> How would a common API provide more support from the vendor ? What 
>> does the API have to do with releasing documentation ?
>
> I'd rather have Adaptec provide a source code driver for their cards 
> directly, then have Scott Long have to fight with unavailability of 
> documentation itself ... if the driver works, what do we need 
> documentation for?
mmmh ... you've got a point ... you just opened my eyes ... 
documentation is pointless when I have a blackbox doing the work.
I assumed a BSD system was supposed to provide access to all of the 
source tree with no restriction so that one could study, fix or improve 
any part of the system; but you are right and BSD should follow Linux 
path and focus on quantity, not quality. My eyes are opened, I do trust 
random vendors to provide fixes and not force me into buying new 
hardware. I do trust their code to be bug-free and of high-quality. I 
trust them so much actually, that I don't consider incorporating their 
code into any of the BSD projects as prostituting their goals:

 From OpenBSD's goal page:
"Integrate good code from any source with acceptable copyright (ISC or 
Berkeley style preferred, GPL acceptable as a last recourse but not in 
the kernel, NDA never acceptable) <http://www.openbsd.org/policy.html>. 
We want to make available source code that anyone can use for ANY 
PURPOSE, with no restrictions. *We strive to make our software robust 
and secure, and encourage companies to use whichever pieces they want 
to.* There are commercial spin-offs 
<http://www.openbsd.org/products.html> of OpenBSD."

 From NetBSD's goal page:
"avoids encumbering licenses 
<http://www.netbsd.org/Goals/redistribution.html>,"

 From FreeBSD's goal page:
"The goal of the FreeBSD Project is to provide software that may be used 
for any purpose and without strings attached. Many of us have a 
significant investment in the code (and project) and would certainly not 
mind a little financial compensation now and then, but we definitely do 
not insist on it. We believe that our first and foremost ~Smission~T is to 
provide code to any and all comers, and for whatever purpose, so that 
the code gets the widest possible use and provides the widest possible 
benefit. This is, we believe, one of the most fundamental goals of Free 
Software and one that we enthusiastically support.

That code in our source tree which falls under the GNU General Public 
License (GPL) <http://www.FreeBSD.org/copyright/COPYING> or GNU Library 
General Public License (LGPL) 
<http://www.FreeBSD.org/copyright/COPYING.LIB> comes with slightly more 
strings attached, though at least on the side of enforced access rather 
than the usual opposite. Due to the additional complexities that can 
evolve in the commercial use of GPL software, we do, however, endeavor 
to replace such software with submissions under the more relaxed FreeBSD 
license <http://www.FreeBSD.org/copyright/freebsd-license.html> whenever 
possible."


Then, next step would be a rewrite of ``Design and Implementation of the 
FreeBSD Operating System" to remove some of the descriptions concerning 
structures and code, and incorporation of a chapter on how to load 
opaque objects to add support for adaptec hardware. Actually ... each 
edition should have an additionnal chapter for new vendors following 
adaptec's path and being supportive by providing more opaque objects. 
After all, that's what BSD is about ... bending to vendors.