From owner-freebsd-questions@FreeBSD.ORG Sun Mar 20 09:26:28 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8619616A4CE for ; Sun, 20 Mar 2005 09:26:28 +0000 (GMT) Received: from ghoul.weirdnet.nl (ghoul.weirdnet.nl [62.250.7.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D40043D1F for ; Sun, 20 Mar 2005 09:26:27 +0000 (GMT) (envelope-from weerd@weirdnet.nl) Received: from ghoul.weirdnet.nl (weerd@localhost [127.0.0.1]) by ghoul.weirdnet.nl (8.12.11/8.12.11) with ESMTP id j2K9Q0cn015710 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 20 Mar 2005 10:26:00 +0100 (CET) Received: (from weerd@localhost) by ghoul.weirdnet.nl (8.12.11/8.12.11/Submit) id j2K9PxMI005753; Sun, 20 Mar 2005 10:25:59 +0100 (CET) Date: Sun, 20 Mar 2005 10:25:59 +0100 From: Paul de Weerd To: Charles Swiger Message-ID: <20050320092559.GA1565@ghoul.weirdnet.nl> References: <200503192050.j2JKoesb003713@cvs.openbsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: misc@openbsd.org cc: Scott Long cc: Sean Hafeez cc: freebsd-questions@freebsd.org cc: Theo de Raadt Subject: Re: Adaptec AAC raid support X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2005 09:26:28 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 19, 2005 at 04:29:59PM -0500, Charles Swiger wrote: | > 3) by not insisting at all that vendors open things at least a | > bit, Scott is not like Bill Paul or others who have opened | > up a lot of hardware, but is a lot more like Sam Leffler who | > has perpetuated this (and today, FreeBSD has one 802.11g/a | > driver -- and it uses binary bits). |=20 | Yes, well, I prefer the former approach myself, but I am not going to=20 | complain that Sam has written a wireless driver using binary firmware=20 | rather than one that is completely open. I appreciate the work he's=20 | done, even if I would like to see a completely open series of wireless=20 | drivers. There's a problem with this approach. Vendors will see the efforts of developers using binary-only stuff. And it sends a message : These guys can use our stuff, they will buy our products, and we do not have to give out documentation. This makes it harder on developers and on users than need be. But since the vendor has seen that what they've done so far (releasing binary-only stuff, eg a linux-only program that can run on your BSD system via linux-emu (but only if you run on i386)) works for us, why should they then supply more information/documentation ? What is in it for them ? It works, doesn't it ? Why give the vendor such a hard time, they did their job, see this-and-that project can work it out, why can't you ? It's just like Windows. You buy hardware, run Windows, but have no idea what's going on. The vendor supplies the driver and all is well. However, we have an open source operating system. We can see the internals of the system, we can go in ourselves and fix bugs. We can take the code and port it to other architectures, port it to other operating systems, do whatever we want. This is what we want to do. We do not want to be tied into software we can not examine ourselves. Otherwise, why run BSD ? Why run Linux ? There's Windows for you, it comes with drivers so you do not have to write the code yourself, so you can not be bothered to read the code, to take it and port it or fix its bugs or adapt it to suit your needs. I decided long ago to use open source software. The longer I use it,=20 the more I value the freedom open source software gives me. I therefore appreciate open sourced drivers. And I appreciate the time it takes the developers of my operating system to ask vendors for documentation, then take that documentation and use it to write those drivers. What value is there in trying to support a vendor that is unwilling to share the documentation the developers need to write drivers ? They don't support us, why should we support them ? It's sad that I spend money on hardware I later find is not supported. And of course, I would like to use this hardware rather sooner than later. But I would prefer that support to be open source. If that's not possible, then I'll just go support another vendor who truly supports open source. I'll toss out the unsupported hardware, tell my friends, family and co-workers not to buy stuff from that company and endorse the vendor that is willing to open up their stuff. This grass roots approach has turned out to be pretty succesful in the OpenBSD world. We now have a whole lot of drivers for wireless cards where we were unable to use most cards a year ago. Vendors have learned that they can make more sales if they open up their documentation so they are happy. The wireless card I bought last year now works, so I am happy. Others can take the code and make it work on their systems (hardware architecture/operating system) so they can be happy. I feel that this is in large parts due to Theo's approach (and the other developers) to this issue, so I thank them for it. At least now I know what RAID controller not to buy. Cheers, Paul 'WEiRD' de Weerd PS: that "completely open series of wireless drivers" you talked about is now available at your local OpenBSD mirror. Feel free to take it and port it to your prefered system. --=20 >++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+ +++++++++++>-]<.>++[<------------>-]<+.--------------.[-] http://www.weirdnet.nl/ =20 --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (OpenBSD) iD8DBQFCPUGmmw12l2HFcK0RAii4AJ4utZE5fFOMz/mR6fYWVWtUVgtqpgCggLje elPmXoZqv70z9wXRUyNkCeY= =yvIU -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT--