posix

by Stephe Walli, SRW Software

This article appeared in the USENIX Association newsletter ;login: (Volume 20, Number 6, December 1995)

"Feds declare NT `open system'; Unix takes a hit" (ComputerWorld news headline, July 31, 1995)

That headline in ComputerWorld appeared, along with similar ones in other trade publications, after a U.S. federal government bid-protest judgement was handed down in June 1995. These news articles all claimed, more or less, that the Federal government had somehow declared Microsoft Windows NT to be an "open system"; that this action was somehow "not right" or "unfair"; that customers would not be able to tell sheep from wolves anymore; and that UNIX vendors had better watch out.

In September, Uniforum entered the fray with a UniNews editorial (Volume IX, Number 15) that was also forwarded to ComputerWorld to "correct" their original article. Unfortunately, this editorial was equally full of speculation and religion, and it got a few facts wrong.

My biggest concern is that a public relying only on trade publications with attention-grabbing headlines might not understand the real issues and might blame or lose faith in well-developed, implemented portability standards such as the ISO C-standard, and POSIX.1, and specifications based upon them such as the X/Open Single UNIX Specification.

I was directly involved in the bid protest trial as an expert witness on POSIX related issues for the Defence Department (yes, I worked for that side.) I have been a long-time member of the IEEE POSIX community and care a great deal about its implementation and use. My involvement in that effort began as an application developer in the commercial world, caring about software portability, and platform independence.

In this article I will present the facts about the bid and its protests, describe the judgement based on those facts, and finish with a few opinions and observations on ``open systems", POSIX, and NT. The information about the RFP, the proposals, the protests and the judgement is taken from the decision document. While you may not agree with my opinions expressed in the conclusion, hopefully the facts will clear up some of the confusion brought about by the sound and fury that passed for news regarding this case. The Facts

The U.S. Coast Guard wanted to procure up to 25,000 new workstations (CGSW III) to take them through the next five to ten years, as they replaced an installed base of CTOS machines (CGSW II). These new machines were to be a combination of desktop workstations, departmental servers, and laptops. A suite of office automation applications (including an electronic mail facility) and an RDBMS were also to be provided.

The body of existing Coast Guard CTOS applications were going to be replaced over time through the use of this RDBMS technology, as these applications are written in a very proprietary manner. (Historically, no use of the CTOS POSIX.1 capabilities appears to have been made.) There was no intention of directly porting the existing application source code. The RDBMS technology was part of the procurement, and there were requirements that it adhere to NIST FIPS 127-1 for SQL. This would allow the re- developed applications (providing they were correctly developed) to be more easily ported to other RDBMSs adhering to SQL FIPS when necessary in the future.

The RFP described the Coast Guard's desire to move in a standards-based "open systems" direction for future work, taking the definition of open systems from the NIST Application Portability Profile (NIST Special Publication 500-187). To this end, the Coast Guard RFP required that proposed systems adhere to a number of standards for specific components (such as the SQL based component mentioned above). They specified that each machine proposed provide a FIPS 151-2 certificate (POSIX.1) and that the bid winner commit to expanding their POSIX support by providing POSIX.2 (shell and utilities) and POSIX.4 (realtime interfaces) implementations within 12 months of the effective date of a US Government FIPS in these areas.

The RFP required "GOSIP" networking support, and this had ramifications for the e-mail component of the procurement. I will not comment further on GOSIP, as my area of experience lies with POSIX standards and portability, not GOSIP.

Value-for-money considerations largely governed the open competition and over-all solution. As with many bids, certain demonstrations were required before the bid was awarded, which in turn required the winner to pass further demonstrations. None of these demonstrations had anything to do with software source-code portability or interoperability.

The Unisys Government Systems Group bid NT desktops and servers. There were two other bidders who made the short list. One bid "UNIX"* desktops and servers. One bid "UNIX" servers and different workstations that provided a POSIX.1 implementation.

• UNIX is a trademark licensed exclusively through X/Open Company Ltd., and is used in conjunction with an X/Open branding programme. When I use ``UNIX" (in quotes) I am speaking of any one of the traditional operating systems of which there are many proprietary versions and some number of public versions available. Any other use of the ``U" word will be appropriately placed in the context of the X/Open specification or brand program. The trade publication articles still don't appear to appreciate the difference between ``UNIX" and XPG4 UNIX.

Unisys was the apparent winner and went on to pass the additional demonstrations.

The companies that did not win protested the award to Unisys. Protestor #1 complained that NT is not a "POSIX"- compliant operating system. Protestor #2 complained that NT did not fulfill the "GOSIP" requirements. The bid protest process then ground into action with lawyers and technical experts entering the fray.

The GSBCA (General Services Administration Board of Contract Appeals) merged the two protest actions into a single case as the two concerned the same procurement and involved similar allegations. The protests were amended to include specific reasons why the Unisys proposal did not fulfill RFP POSIX and GOSIP requirements (i.e. why NT wasn't ``POSIX" and ``GOSIP"), whether the government customer knew what it was doing, whether or not the Unisys proposal failed to satisfy the customer's "open systems" objectives, and certain concerns expressed about the conditions under which the platform demonstrations were executed. Recognize that this is what the protests claimed; the protestors then had to prove they were correct.

Bid protests must be completed in 45 working days. During this intense period of time, about thirty lawyers, almost a dozen technical experts, and numerous factual witnesses from the Coast Guard, NIST and the various vendors involved, testified to the facts, offered opinions and debated the meanings of terms and terminology in the RFP, the NIST procedures, and various other relevant (and irrelevant) documents, building their respective cases for presentation to a panel of three judges. All the material was subjected to intense scrutiny by many people from different perspectives. This decision was not the idle opinion of a few people arguing "open systems" religion.

The protests were denied on all counts. Here is how this decision was reached, based on the "findings of fact" and discussion from the judges' redacted decision. (GSBCA 13201-P, 13211-P, C3, Inc., and TISOFT, Inc., v. General Services Administration, and UNISYS Corporation, June 9, 1995 - released to the public in redacted form on June 30, 1995.)

NT is a FIPS 151-2 certified system, and as such is a "POSIX-compliant" operating system [particular findings of fact are referenced in braces for those who care]:

• FIPS 151-2 is a document that incorporates the POSIX.1 standard (IEEE Std 1003.1-1990 == ISO/IEC 9945-1:1990) by reference, setting certain limits, and requiring certain optional functionality to be supported. {16} The NIST certification process ensures that the results of a run of the authorised FIPS 151-2 test suite are valid. This test suite is not a guarantee of conformance, but contains test cases that cover the functionality as specified by NIST in FIPS 151-2. {35} A certificate of validation is awarded if everything is correct. {36} There is a component of the NT operating system that provides the POSIX.1 specified functionality as defined by the NIST FIPS 151-2 document. {43} The NIST POSIX.1 Conformance Test Suite (PCTS) has been run by an accredited testing lab on NT, and the test suite results were submitted to NIST and validated. The NT operating system received its certificate to this effect. {55, 57} NIST does not certify "operating systems" as ``POSIX" conforming, neither do they test operating systems. They ensure that systems claiming to provide the functionality described in FIPS 151-2 (and the POSIX.1 standard by reference) do so, regardless of how that functionality is implemented. {41} The Coast Guard did not have any reason to constrain bidders (reducing competition) by choosing a particular style of implementation of the POSIX.1 functionality. {20} The POSIX.1 standard itself describes why application writers need not care about how a system provides the functionality. (IEEE Std 1003.1-1990, Section B.2.2.2, descriptions of "hosted implementation" and "native implementation.") POSIX.1 does not specify an operating system. It is a specification of an interface to an operating system. {13} POSIX.1 was written in a minimal fashion and it was expected that other "POSIX" standards would specify further interfaces that an operating system might provide. {12, 17} The U.S. Coast Guard has certainly required further support. * Operating systems that implement the POSIX.1 interfaces are often referred to as "POSIX-compliant" operating systems. {23, 24, 25} (I personally hate this lack of accuracy but it appears to have become commonly abused terminology in our industry.)

Part of the protest revolved around terminology in the RFP that the critical email and RDBMS applications "run under the POSIX operating system". The simple answer to this in the judges' decision is that these two applications run on NT, the NT platforms proposed had their FIPS 151-2 certificates, and therefore the applications run under the POSIX operating system. This simple logic does not begin to describe the painful debates that went on during the protest litigation. Essentially,

• The language "run under" was used by the Coast Guard to prevent bidders from proposing solutions of these applications that were run using emulation. {31} Every one agreed that there were other interpretations of the words "run under" and that a poor choice of words had been made, but there was no reason to doubt the testimony of the Coast Guard representative. {32, 33, 34} The words did not mean that these two applications' source code needed to be coded against POSIX, or ISO C or any other specification, as that is a source-code implementation issue for the application implementors, based on their own portability needs and choices, and makes no difference whatsoever to the end-user of the application, in this case the Coast Guard.

The issue that raises the most heat in this entire protest is the issue of whether NT fulfills the "open systems" direction of the Coast Guard. Unfortunately, this has been reported as "NT declared an open system." No such declaration was ever made by anyone during this bid protest.

Most of the debate concerned how the POSIX.1 functionality is accomplished on NT. The protests argued that the POSIX.1 functionality is not integrated in a coherent fashion with the rest of NT, and that it therefore fails to meet the open system's requirements outlined in the Coast Guard's OSE policy and planning objectives. This protest count was denied in the decision, as follows:

• The protest count attempts to argue the acceptability of the Unisys proposal based on the Coast Guard's OSE policy and planning objectives, not the RFP requirements. The Coast Guard is clearly committed to moving in a standards-based open systems direction based on the minimum mandatory standards requirements that were imposed in the RFP. The Coast Guard did not expect to accomplish its entire OSE objective at one fell swoop in this single workstation bid. There were obvious trade-offs made for competition and cost savings. There were no requirements in the RFP that proposed that portability and interoperability be integrated in any particular way or to any specific degree. There was no extra credit given during the evaluation period for the degree of portability or interoperability provided. * The Unisys proposal did provide the Coast Guard with a greater degree of portability and interoperability than they have in their current workstation environment.

In the words of the judge's discussion:

"Protestors are apparently convinced that the Unisys solution does not promote the Coast Guard's open systems environment objective as effectively as their own proposals would. Consequently, they speculate that the acceptance of the Unisys proposal will have serious long-range economic implications so far as future software conversion costs are concerned. This may or may not be true."

In my opinion, based on the stated problems to be addressed by this procurement, and the chosen application conversion methodology being the RDBMS using SQL, the future application conversion costs will probably be related to how proficient the application development team is with SQL and the RDBMS, rather than anything to do with POSIX.1 and ANSI C. The RDBMS happens to be the NT version of a traditional "UNIX" database, so this should further aid the applications' portability to other platforms supporting this particular RDBMS, even if the application developers use any proprietary extensions beyond SQL.

The GOSIP related issues were apparently not well founded. There were no improprieties with respect to the demonstrations that needed to be performed by the apparent winner of the bid. The protests were denied on all counts.

This decision was handed down on 9 June, 1995. An appeal could have been entered in the next 120 days, by October 9th. No one appealed this decision.

That was the procurement, the bid protests, and the subsequent decision. Unfortunately, this entire incident degenerates into religious debates about "open systems", fuelled by marketing rhetoric. As stated earlier, I am very concerned that this poor reporting and "open systems" rhetoric will damage the reputation of a set of useful portability standards and specifications. Observations and Opinions

As this topic seems so prone to "religious opinions" and, indeed, I may be as blinded by my own beliefs as anyone else, I remind readers that all the following opinions and observations are my own and should not be construed as representing anything other than that.

First, I dislike the term "open systems." It may be a useful term to describe very broad concepts involving source-code portability and application interoperability, but there its usefulness ends. Souce-code portability is considered one of the cornerstones of "open systems," and so the POSIX family of standards is both blessed and burdened by its association with this general and sometimes ambiguous term.

Presumably developers want to support portable software because more than a single computing environment is involved, or because they are investing in the application's future, knowing that platforms will change. Some "open systems" proponents talk about source-code portability as if it is a perfect software development exercise, where all one has to do is purchase FIPS 151-2 certified, or XPG4 Base or UNIX 95 systems, and portable applications will "happen". Even amongst traditional "UNIX" systems, source-code portability is a difficult and diverse software development problem. It is quite possible to write perfectly un-portable code on systems that support ISO C and POSIX.1. If source-code portability was easy and could be solved with a specification alone, it would have been solved with the /usr/group 1984 standard.

The POSIX.1 specification only represents part of the solution. First, other POSIX projects add further functionality to this portability model. POSIX.1 was never meant to be the complete solution. No specification, however, no matter how broad, can define everything that every application is going to need.

Second, the actual building of portable applications source-code requires genuine understanding and real effort. Developers may need to develop parts of an application in a very platform specific manner for a variety of reasons, even on systems certified and branded to conform to broad, robust specifications. It is unfortunate that POSIX.0 (the POSIX Open Systems Environment Guide) and its various brethren (e.g. the NIST APP) have never described the amount of careful engineering that is required to actually implement a software development environment to support the development and maintenance of source-code portable applications, beyond the relatively simple task of itemizing standards in a profile. Source-code portability is an intensive application development concern.

Vendors have a vested interest in the fact that people moving from historical single-vendor environments to multi- vendor "open systems" environments probably do not appreciate that portability is a difficult problem requiring more than a specification on a programmer's bookshelf and a machine with a certificate. A vendor will pay a lot of lip service to your portability and interoperability needs - providing you're buying their solution. And, in their eyes, they're giving customers exactly what they asked for. It is the customers' problem if they don't know how to use it.

POSIX.1 is amazingly successful. As a specification, it has existed and been stable since 1988. It has been incorporated and adopted into the most important portability specifications around us (SVID3, 4.4BSD, X/Open's XPG4 Base and its successor, the Single UNIX Specification). It has been widely implemented on systems as diverse as VMS, MVS, and MPE/iX, as well as most traditional "UNIX" systems. Most of these implementations are either certified by NIST against the FIPS 151-2 test suite, or warranted by an X/Open XPG4 brand. The predecessor to FIPS 151-2, FIPS 151-1, has existed almost from the time POSIX.1 was ratified in 1988.

Which brings us back to a particular thorny implementor. Microsoft did indeed build an exact POSIX.1 implementation. Wherever the standard allowed them to leave something unimplemented, they did so. These loopholes exist in the standard (and therefore in its FIPS) precisely because all of the "UNIX" vendors in the working and ballot groups allowed them to exist. All of these vendors were ensuring their proprietary implementations of "UNIX" didn't have to change too much to conform to the standard. The NIST certification process itself offers certain leeway in the implementation (as allowed by the POSIX.1 standard) to ensure a certain breadth of competition for federal bids. Microsoft exploited these specifications no more and no less than any other vendor. But they did provide an implementation, and it is sufficiently robust to clear a rather large and robust test suite.

Microsoft implemented POSIX.1 as an environment subsystem, such that it is not completely integrated with the Win32 subsystem. Those that claim that the integration aspects of the POSIX.1 subsystem are a problem and that the subsystem should be more integrated with Win32, should stop and think about it a little more. I care about POSIX and the C- standard because I care about portable applications. I do not want to start using OLE calls, Win32 windowing calls and such in my application. This would make it very unportable to any of the FIPS 151-2 certified or XPG4 Base branded machines that are available.

But people in our industry love to beat on Microsoft. Ten years ago, we loved to beat on IBM. I think that, in general, we like to beat on whoever appears to have the most arrogant marketing campaigns, who presume that their solution is the only solution. I cannot think of a single vendor's sales team with whom I have had much patience.

Microsoft treats standards much the same way this decade as IBM did through the eighties. Standards are something they will support by implementation to satisfy customer requirements, i.e. to compete in the market, but which they don't necessarily support philosophically, as they likely believe they already offer better solutions. The traditional "UNIX" vendors, however, don't appear to be doing anything differently.

Many vendors of traditional "UNIX" operating systems point to their "support for open systems standards", and scoff at Microsoft. One might ask them why they haven't yet branded their implementations as XPG4 UNIX 95? The X/Open Single UNIX Specification has existed for a year now and its branding programme has existed since March 1995. As a superset of POSIX.1 and ISO C, XPG4 Base 95 branded systems arguably offer a better base upon which to develop new portable applications, and XPG4 UNIX 95 branded systems offer the extra bits to support porting historical "UNIX" applications to these platforms. All of the traditional "UNIX" vendors loudly proclaim their support for this effort - yet, as of this writing, not a single vendor has claimed the XPG4 UNIX 95 brand. Most cling to their XPG4 Base (not even Base 95) and UNIX 93 brands, so marketing rhetoric and mud-slinging comes off sounding a little shallow from my point of view.

Regardless of the vagueness and overuse of the term "open systems", developers are determining how best to use the standards and specifications that are particular to their needs, and are buying platforms that provide implementations of the same and suit those requirements. This is what portability specifications are all about - providing the systems analyst or applications developer with the ability to choose platforms suited to their needs (price, performance, networking, etc.) while still maintaining as much portability as possible for the application source-code developed to a particular specifications model. Whether or not the platform is a "UNIX" machine, NT, VMS, MVS, or any other system, doesn't matter. It's whether it supports the relevant specifications (X/Open, POSIX, NIST FIPS) required by the application that matters.