*BSD News Article 10713


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