att & osf

[Richard A. O'Keefe]

In article <12145 at ncoast.UUCP> allbery at ncoast.UUCP (Brandon S. Allbery) writes:
>As quoted from <268 at quintus.UUCP> by ok at quintus.uucp (Richard A. O'Keefe):
[deleted]
>Did we read the same messages?  The "someone from AT&T" NEVER asserted that
>the SVID had not changed!  He said that it had been *expanded* -- which is
>exactly what I'm talking about and what is *necessary* if Unix is not to die.

The original message has long gone, but the someone from AT&T denied that
Henry Spencer's claim that the SVID had had two issues and that there would
be more was true.  The SVID has been expanded.  It has _also_ had a number
of minor features deleted.  The original point of this wretched debate was
precisely that *expansion* (content and timing unilaterally decided on by
AT&T, no right of appeal) is what renders the SVID less attractive to firms
that want to port and sell UNIX than to people who want to write applications.

I honestly cannot see what there is to quarrel with in that statement.
It's AT&T's SVID, they can do what they like with it.
The SVID was not handed down on Sinai.
Why react as if I had blasphemed against the Quran?

>Frankly, POSIX is liable to be *too* stable.  How often have you used pure
>ANSI Standard Pascal?  How about ANSI Fortran?  It is notable that the
>*effective* standard for Fortran has always been set by a single company
>(IBM), and that Pascal (which has no such backing) effectively has no
>standards at all.

I have used pure ANSI Standard Pascal whenever I have had the chance.
(And whenever I have found it necessary to use Pascal.)
In comp.lang.fortran not too long ago, it was claimed that the de facto
standard for Fortran was the VMS Fortran compiler (this is to some extent
supported by Sun's bringing out a "VMS-like" compiler for SunOS 4.0).
Not that that matters, as I wouldn't dream of using any non-standard features
in Fortran.  (Well, I might use lower case, or Ratfor, but I have tools to
convert that to standard Fortran.)  IBM's own "SAA" manual for Fortran
warns you against using mainframe-specific features if you want to port
code between IBM mainframes and IBM micros.  When you have moved a Pascal
or a Fortran program from TOPS-10 to VMS to UNIX to AEGIS you start to get
the idea that maybe sticking to the standard just _might_ be a good idea.
{Note that Fortran 8X met a _lot_ of opposition, for very practical reasons.}

When POSIX is finished, I would be very happy to find a company which would
implement _precisely_ what was mandated by POSIX, and would promise not to
add any features at all until the next edition of POSIX, but would spend
their time fixing mistakes, speeding the thing up, and making it use less
memory.  It would make a _wonderful_ platform for developing portable code.

>| As for bitching about networking, I've read the relevant V.3 manuals
>| several times, and, well, does anyone know of anything printed in English
>| that explains V.3 networking?

>Before anyone answers that, let's make sure it's a real issue:  is there
>anything printed in English which explains BSD networking?  (I.e. if there
>is, the point is valid, but if not then why does it matter?)

What the **** has the existence of otherwise of a description of BSD
networking got to do with my question about V.3?  I am not saying BSD is
better.  I'm not saying BSD is good.  I'm not saying BSD is bad.  I'm
not saying _ANYTHING_ about BSD networking.  There is a whole pile of
new stuff in the V.3 manuals about streams and TLI and I would like to
find out how to use it, but the manuals basically assume you already
understand it all and just need to be reminded.  (I'm happy to accept
the UNIX V7 document set as "English" for the purposes of my question.)
I want to know about V.3 networking because we have some code using
sockets that already works, and we would like to have it run under V.3.
I don't expect the conversion to be trivial, and I hoped to learn more
about V.3 streams &c than I ever knew about sockets (I mean, I've read
all those papers that say how neat and utterly non-kludgy streams are).
I pounced on the relevant manuals with cries of joy, all prepared to
become a True Believer in the AT&T Way, but the relevant manuals would
be nearly as clear if they were written in Reformed Egytian (:-).