Splinter Unix?

Doug Gwyn gwyn at brl-smoke.ARPA
Thu May 19 01:44:17 AEST 1988


In article <556 at n8emr.UUCP> lwv at n8emr.UUCP (Larry W. Virden) writes:
>What do you folks think of this "grand" idea of the creation of a third standard 

It should be obvious what their real motives are.  It must grate to
have to pay AT&T royalties.  It must especially grate DEC, who once
had the chance to acquire exclusive rights to UNIX and weren't
interested.  (We're all better off as it turned out, though.)

Notice that all the vendors in this ploy are ones who were pushing
their own proprietary operating systems and were reluctantly forced
to have a UNIX-based offering because customers demanded it.  Old
mindsets sure die hard.

We sure don't need a DIFFERENT system interface.  A true UNIX clone
would be okay (although it would lag in picking up new developments),
except I doubt they will produce one.

>What impact will this have on the Posix effort?  On development of portable
>code?

It has no impact at all on 1003.1 or the NBS FIPS, which are quite close
to being officially approved.  There could be a small effect on other
1003 subgroups eventually, although 1003.2 is probably far enough along
to be relatively unperturbed.

The effect on portable code is this:

	The AT&T/Sun and AT&T MicroSoft agreements to merge the only
	commercially significant UNIX variants into a single system
	would have made it possible for applications to rely on
	several important features of the merged system that go well
	beyond any official (e.g. POSIX) standards, just as the SVID
	specifies far more than does POSIX at this point.

	It is a rare application that does not need more support from
	the system environment than is covered by (almost-)existing
	POSIX standards.  If the AIX system ends up looking entirely
	unlike AT&T's UNIX system outside the domain specified by
	POSIX, then portable applications will be forced to deal with
	logically unnecessary variations among systems, largely
	defeating the purpose of standards and imposing an economic
	burden on software development.  (Note that this can also be
	construed as a complaint about what is actually accomplished
	by POSIX as it turned out.)

	The emergence of POSIX and in particular the NBS POSIX-based
	FIPS has handed the lawyer types a tool for challenging any
	Federal specification for a SVID-compliant system rather
	than just a minimally FIPS-compliant one.  If RFP writers get
	the help of someone who really understands the practical
	effects of the differences between these two system interface
	specifications, it is possible to accommodate them both and
	ensure that the actual customer needs are satisfactorily met.
	Otherwise, there is considerable risk that the silly rules
	constraining Federal procurement will force acceptance of a
	system that does not satisfy the needs that prompted the
	procurement.  (Yes, many of the rules ARE silly.  They appear
	to have been based on an entirely bogus notion of what
	competition is all about, as well as misguided attempts to
	enforce legitimate concerns for impartiality.)

I get pissed off at companies that prefer to resort to marketing and
legal strategies rather than responding technically.  If they're
really going to develop an alternative operating system instead of
adding value to an established standard one, it should be SIGNIFICANTLY
BETTER than UNIX, not just a small incompatible tweak, or else they're
wasting everyone's time.

(It should be obvious that none of the above is necessarily an
official DOD opinion.  I say this to forestall attempts by the same
losing lawyers to exploit these remarks.)



More information about the Comp.unix.questions mailing list