instability in Berkeley versus AT&T releases

[Guy Harris]

> At Berkeley there were several V6 programs that there was no source to. They
> were running on a 2BSD system (ucbcory). QED.

That's nice.  They sure as hell didn't use "seek" or "stat"...

> > And there are programs written for V7 that will break when you try to
> > compile them and run them under 4.2BSD...
> 
> Actually once you change RAW to CBREAK they're quite compatible.

I'll assume this statement refers to V6 vs. V7; I hope nobody is ignorant
enough to think CBREAK was a Berkeley invention...

> I've moved stuff between V5, V6, and V7 with few problems.

Bet you had fun with the stuff using the old V5/V6 I/O library which was not
available in V7...

> SIII and SV are a royal pain, though.

Only if you don't know what you're doing.  I've moved stuff between V7 and
S3/S5 with few problems.

In case you're curious, I once (as a hack) got most of the way through
turning V7 kernel source into S3 kernel source, working with on-line V7
source and an S3 kernel printout.  I submit that the chances of a V6 binary
running on S3/S5 are very close to the chances of a V6 binary running on V7
(PDP-11 binaries here - although, from a quick look at the system call and
"exec" code of S5R2 and 4.2BSD, the chances look *very* good that you can
run many S5 binaries under 4.2BSD!).  At least V7's "lseek" and "stat" calls
are the same in S5... (if I had a V6 manual, I'd check to see how compatible
the V6 and V7 drivers' "sgtty" structures were, and then check how
compatible the V6 and PWB/UNIX 2.0 structures - as used by S5 - were...)

Then again, you can't run PDP-11 *or* VAX binaries on the 4.2BSD machine I'm
typing this on, so the question of binaries is irrelevant anyway...

Moving on to sources, I merely state again that I've moved code between V7,
4.2BSD, and S5 with few hard glitches.  Converting "ioctl"s is certainly
tedious, but *if* you know what you're doing there are few surprises.  Of
course, a number of flamers against the S3/S5 driver haven't bothered doing
the work of figuring out the (admittedly complex) interface...

(BTW, try porting an S5, S3 *or* V7 program which expects "read", "write",
"wait", etc. system calls to be interrupted by signals to 4.2BSD.  You may
get a little surprise...)

> > ...the S3 driver's backward compatibility with UNIX 2.0 is totally
> > useless to anybody outside the former Bell System.
> 
> And since most real world UNICES are V7 derived, what does that say about
> Bell?

It says that due to a mixture of technical and legal reasons they couldn't
a) throw away the 2.0 compatibility in S3 replacing it with V7 compatibility
or b) offer two versions of UNIX 3.0.1/S3.

As for your claim that "most real world UNICES are V7 derived", I don't
believe it.  Period.  Most commercial vendors are offering S3 or S5-based
systems.  Several 4.2 vendors are now offering 4.2BSDs that have some degree
of S5 compatibility.  Some of them are even clever enough to offer 4.2
functionality and S5 compatibility to the same programs as opposed to
walling the two systems off in separate worlds.  I suspect this will happen
more in the future.

I think enough has been said - more than enough, since most of the postings
on this subject have been broadsides fired in religious wars rather than
accurate discussions of the places where {V7,4.2BSD,S5} do well and where
they do poorly.  If anybody else wants to wage holy war over why their
favorite version of UNIX is the "only true UNIX", could they please move the
discussion to net.flame or net.religion.software?

	Guy Harris