Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA528 ; Thu, 04 Feb 93 16:00:28 EST Newsgroups: alt.suit.att-bsdi,comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!ames!sgi!igor!jbass From: jbass@igor.tamri.com (John Bass) Subject: George William Herbert's Challenge - Part 3 (Let the code speak) Message-ID: <1993Feb3.095304.3744@igor.tamri.com> Organization: DMS Design References: <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com> <1kbtpf$e9h@agate.berkeley.edu> Date: Wed, 3 Feb 93 09:53:04 GMT Lines: 157 In article <1kbtpf$e9h@agate.berkeley.edu> gwh@soda.berkeley.edu (George William Herbert) writes: >And, as to wether UCB has ever invested the manpower to build >software products, well, you're wrong. I can think of a couple >off the top of my head. Sounds to me like you're speaking from a position >of ignorance about UCB's activities over the last fifteen years. Again ... if you wish to quote me do so, but don't put words into my mouth. What I said was: "To strip AT&T of the right to protect it's UNIX property is wrong, no matter how much you may hate AT&T or the Bell System. To bully their employees, or picket their booths or offices, or any other action regarding their attempt to protect their investment of more than 10,000 man years and $5,000,000,000 expenses to develop, support, and market this product -- is simply as flawed and wrong as the UCB team that plagiarized UNIX components for the Net2 and 386BSD releases. UCB has not, will not, can not EVER invest this amount of man power or dollars to make a software product -- if not for any other reason than the people of California will not allow their taxes to be spent competing unfairly with private business." Now I am not aware, nor are the people of California, that UCB has the extra funds available to launch a product development of the Billion Dollar size. I would think that after all the budget cuts, UCB should be focusing it's funding on training students, not competing unfairly with private business. The point is two fold: 1) AT&T has a serious interest in the UNIX product and has brought to bear funding which forms an investment that should be allowed to yeild dividends for it's stockholders (who are largely common folk -- or the pension funds of common folk). 2) UCB's entire development effort represents about 1% of the AT&T development effort. The PRODUCT IS AT&T's ... UCB's efforts are a minor project in the grand scheme of things. >There are perfectly professional ways to argue USL's case; so far, >you aren't doing any of them. You allege that USL is right, but >refused to provide the evidence that, if provided, WILL change at >least my (and almost certainly every other rational Usenet readers) >opinion on the case. The evidence will come out sooner or later >and I'd prefer it be sooner; either CSRG lied about legally making >BSD AT&T-Free, or USL is lying about how close the similarities are. >In either case, some pretty serious shit is going to come down >on someone when the evidence is available. The code will tell, >but as of yet it hasn't. So let the code speak. > >-george william herbert >gwh@lurnix.com gwh@soda.berkeley.edu Actually what I have done so far, is declare "the emperor has no clothes" to the loyal UCB followers, and got flamed at. I have stated that IF you take the time you will find a serious connection between Bach and 386BSD, and in addition, have stated my first hand observations about such. This is hardly a refusal to provide evidence. I did not notice you requiring the same level of "professionalism" on the loyal UCB flaming team. To go beyond this requires introducing AT&T copyrighted matter into my postings ... which would make me nearly as guilty as UCB and give people a real reason to flame me ... as well as piss off AT&T. If AT&T/USL is willing to support their defense in this forum, I expect we will see a posting of the requested source modules and a public release to use selected Bach pseudocode (happy David?) in this discussion ... hopefully within a few days. For those of you without 386BSD sources, 1) you may uucp the interesting parts from uunet archives. 2) you may ftp agate.berkeley.edu from a 386/486 UNIX box cd into pub/386BSD/386bsd-0.1/srcdist mget the entire directory cat src01.?? | compress -d | cpio -idumv Extracting the files on other than a 386/486 port may prove interesting due to byte/word swap problems. Mean while, those of you that have/had AT&T source access to the V7 kernel, please follow along with my introduction to 386bsd standalone code. This code represents strong prior knowledge of AT&T UNIX source, and at the very best is in the heavily tainted gray area. One of the curious features of a unix system is the bootstrap sequence, as briefly mentioned in Bach on Page 235. There are few other references in the literature to base any design decisions on. This code is what you could call very obscure at best. There is a simplistic syncronous driver design interfaced via the bdevsw using iob structures with a UNIX like API. UCB 386BSD manages to replicate the design with important parts of the original AT&T UNIX structure intact. This was not an accident since the AT&T functionality in the stand library is more than is simply required by boot to load /unix. The re-write is largely different only by the choice of the API ... using namei instead of open, and iread instead of read. Now these iob structures are a lot like UNIX buf structures ... and many of us always wondered why they were not called buf structures too ... it is more curious that the UCB 386BSD code follows this variable naming as well, something that forms a very distinctive "finger print" suggesting a re-write and not a new design. Ditto with the variable names inside the iob structure, choice of bdevsw structure, choice of including little known utilities like cat ... which would have more naturally been special cased inside the command line code of boot. Then there is the name of the include file .... "saio.h" Now in the UCB 386BSD re-write they were careful to not directly use the AT&T API or other common UNIX standalone procedure/variable names and re-org'ed the code to make it "look different". But it is close enough that without all the UCB copyrights, a UNIX person familar with boot that hasn't seen the AT&T code for 6 months, might well mistake major parts of the BSD code as AT&T code. Now this is a case where: A) there is no public document which describes the internals of boot at this level of detail that I am aware of. B) the choice of design, structure, and variables follow UNIX source code suggesting that whoever "re-wrote" it, was staring at the UNIX standalone sources, or had a damn good memory of it. It is not a case where two students without UNIX source access were just given the task of designing a new boot. There are simpler ways of reaching that goal. Nowhere in this code is a comment that say's this code is derived from or is patterned after the rather novel UNIX standalone library. No credit what-so-ever is given to the orignal BTL designer or AT&T/USL. No other operating system I am aware of has a boot designed like this ... for the UCB 386BSD design to follow the AT&T design closely, indicates plagiarizm based upon prior/concurrent source code access. It clearly contains the same "methodology and algorithms, including the sequence of processes adopted by the programmer" which is the test by which we must judge. If there is anyone out there with UNIX AT&T source for stand that sees this differently, please make a case for how the UCB standalone design is significantly different and novel. Do not post AT&T source ... assume our reader jurors have it, but provide detailed explainations of how you form the opinion that it was not derived from AT&T source. Please be sure to provide public references that can explain the detailed design choices used to re-write boot, without having AT&T source access or design knowledge. More to follow ... hopefully AT&T will post the requested source modules so we can get a little more detailed for you non-unix source people. stay tuned ... John Bass DMS Design