Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: Splinter Unix?
Message-ID: <7976@brl-smoke.ARPA>
Date: 26 May 88 20:52:11 GMT
References: <556@n8emr.UUCP> <1936@ssc-vax.UUCP> <581@tapa.UUCP> <254@sdba.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 32

In article <254@sdba.UUCP> stan@sdba.UUCP (Stan Brown) writes:
>didn't want to play if the couldn't set the rules.  This
>situation should change when POSIX becomes a real standard as
>the government has expresed an intent to use it as theilr
>standard spec instead of SVID.

Your summary of the history of AFCAC-251 was pretty much in
accord to what I have heard about it.  The issue was indeed
whether requiring SVID conformance as part of the operating
system specification was contrary to government requirements
for open and fair competition in its procurements.  The
finding was that SVID conformance can properly be required,
although "passing SVVS" would not be a proper way to specify
this.

There is no such thing as "the government's standard spec".
Each RFP contains its own set of specifications.  However,
once there is an official POSIX FIPS (Federal Information
Processing Standard), pressure can be applied to require
justification for specifying something other than the FIPS.
FIPS conformance PLUS additional requirements is fairly
easy to justify in many cases.

I could tell you how some Beltway Bandits exploit the
Federal procurement regulations via legal wrangling in
order to obtain contract awards that they could never have
won on technical merit alone, but you probably already know
about this.  It does make it harder to write specs that
ensure that the delivered goods meet the original needs.

The above is purely personal opinion and does not necessarily
reflect any other person's or agency's official position.