Date: Tue, 4 Apr 95 19:09:28 MDT From: terry@cs.weber.edu (Terry Lambert) To: nate@trout.sri.MT.net (Nate Williams) Cc: rkw@dataplex.net, current@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Message-ID: <9504050109.AA24717@cs.weber.edu> In-Reply-To: <199504042127.PAA07392@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 03:27:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> What does the binary link bit by the avg. user that downloading the > source tree doesn't? Most of the sources have conditional code in them > which makes a binary link kit less useful than a source-code kernel kit. One source tree worth of disk space. 8-). The need to install 'ld' but not 'cc' if it's done right. 8-) > And, it also is less sexy to get .o files when users can get sources. :) Well, yeah... there is that. }B-). > > The really nice thing about this, of course, is that multiport > > board drivers and Adaptec drivers using Adaptec code, and (potentially) > > the Intel supplied-for-MACH binary math coprocesser emulator could > > all be supplied without sources in full conformance to the non > > disclosure agreements required to obtain them. > > This can still be done. Read the docs on config on how to provide > binary-only modules. It's fairly easy to setup, and it's how Ultrix is > distributed currently. Yeah; the problem is that it isn't really as "drop-in" as System V at this point. It ought to bea able to beat up System V. 8-). Basically, there's no place to just drop your binary files in. This is kinda out of it until the device and device driver writer kernel exported interfaces are cleaned up to the point that no one will screw with them for long enough that a binary driver could live through a couple of releases without changes. The main problem is one of synchronizing developement efforts between multiple object sources when any *BSD is an "also ran" that doesn't get a commercial driver until the write happens to hit a lull in their tech support calls to let them work on it. 8-(. > But, the issue of binary modules is a political one not a technical one. > I'll let you deal with the bigger problem rather than attacking straw > men. Sigh. 8-(. You are right that it is political; I tried to abate that somewhat with the "escrow" argument for people who would like to make the code available but can't because of the non-disclosure. Given a choice between code that runs my hardware with no sources and no code to run my hardware, I know which I'd choose, politically incorrect though that might be. 8-(. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504050109.AA24717>