"comp.sys.3b2" and "comp.sources.3b2" anyone?

[Greg A. Woods]

[ This 'na' distribution stuff has got to stop! ]

In article <1991Jan28.180448.6953 at nmrdc1.nmrdc.nnmc.navy.mil> rdc30med at nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) writes:
> From what I've seen of the traffic in comp.sys.att, it has been either 3b1 or
> 3b2 traffic all along.  Now that the unix-pc traffic will (largely) be going
> into the 3b1 groups, that would seem to leave 3b2 traffic the sole occupant
> of comp.sys.att.

Ah, as a 3b2 fan, I'll just be the devil's advocate for a second....

	What about all the 6386 stuff?

>  Perhaps a rename to comp.sys.3b2 and the addition of 
> comp.sources.3b2 is in order.  How much 3b2 specific source code is actually
> out there?

Absolutely NONE, since I've never seen any device drivers posted.
AT&T System V Release x.x is what the 3b2's run, and that's as generic
as it gets, since the 3b2 was the porting base.

>  With the exception of ANSI C code and heavily BSDish code, I've had
> only minor problems with code from the existing source groups that claims to be
> usable on SysV machines so we may not need a 3b2 specifc source group.

Which reminds me....  How many 3b1 specific sources are there?  Sure
some graphics stuff, not all of which is specific.  Maybe some other
device specific stuff.  Otherwise, anything for 3b1's is basically
SysVr2.x compatible (with the exception of some Starlan/TLI stuff
which seems also to be compatible with SysVr3.0).

Please, anyone porting things to either 3b platform, use generic SysV
features as #ifdef's, etc, not u3bX identifiers.
-- 
							Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP		ECI and UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]  VE3TCP	Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL