Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!wuarchive!cs.utexas.edu!fletcher From: ahby@bungia.bungia.mn.org (Shane P. McCarron) Newsgroups: comp.std.unix Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop Message-ID: <13272@cs.utexas.edu> Date: 6 Oct 90 14:43:47 GMT References: <558@usenix.ORG> <107019@uunet.UU.NET> <13137@cs.utexas.edu> Sender: fletcher@cs.utexas.edu Organization: Bugoslavian Embassy, St. Paul, MN Lines: 102 Approved: fletcher@cs.utexas.edu (Guest Moderator, Fletcher Mattox) X-Submissions: std-unix@uunet.uu.net Submitted-by: ahby@bungia.bungia.mn.org (Shane P. McCarron) In article <13137@cs.utexas.edu> domo@tsa.co.uk writes: >Submitted-by: domo@tsa.co.uk (Dominic Dunlop) > >While we can wish for an ideal world where standards committees are >always able quickly to reach a broad consensus based on well-tried >existing practice, and can deliver a well-rounded document to an >accepting and grateful public, we have to concern ourself with real >life. Dominic says that we have to concern ourselves with real life. Real life is that POSIX.2 Draft 9 is an immature document. Making it a procurement specification means that system vendors will have to do a lot of work that they will, to some extent, just throw away later. Moreover, this work will be duplicated by every system vendor wanting to sell into that market. Also, since there are organizations like the Open Software Foundation and UNIX System Laboratories producing reference implementations of the operating system, these vendors could have not done the work themselves at all! This economy is development is something that must be taken into account by the US government, and in fact by any organization specifying procurement requirements. These organizations want to procure something TODAY! They want it to look like a standard implementation, but they would probably be just as happy if the applications that they really need ran. MS-DOS is not a standard, but it runs flight-simulator and Lotus. That's enough for most people. What we, as people involved in the standardization process, have to do is work with the Federal government and other organizations to help them understand the folly of prematurely pointing to standards. Those standards are, for the most part, build upon existing practice. When organizations go to put together a procurement specification, they need to know what components of that standard are stable and represent existing practice that is available to them TODAY. If they use that as the basis of their procurement they will have an Open Systems solution that they can actually get their hands on. Further, that solution will be upwardly compatible with the final standard because it is a proper subset of the functionality in that standard. A example of reasonable subsetting from Draft 9 would be system limits like LINEMAX. In POSIX.2 this is specified as being something like 4k (I can't remember). Anyway, the limit is supposed to apply to any utility that reads lines of input from the user or from text files. No system in the world that is shipping today supports this limit in every system utility. It is an ideal goal that the companies represented by the participants in POSIX.2 have agreed to move to over time. Producing a standard is just that: an agreement that all of "this" existing practice is pretty good, and here are the areas in which we agree that it should be better defined or enhanced to make the functionality maximally advantageous for application developers and end users. This is a very important point, and tends to be lost on casual observers of standardization efforts. >And I think that requiring conformance to a draft standard is a whole >lot better than not requiring conformance to anything in particular. >Sure, it will be annoying and painful to convert later when the real >thing comes along. And it will cost real money. But it will cost a >whole lot less money in total than -- say -- implementing using a >proprietary environment now, and switching to an official POSIX.2 when >it comes along. Yes, the up-front costs may be higher because a draft >9-conforming environment is likely to be more or less custom-built (or >at least, suppliers are liable to try to stick you for the costs of a >fully custom job, even if such costs are not justified). But the >downstream costs, including the costs of any draft-to-final conversion, >are likely to be way lower. Well, it depends. The cost to the system vendor will be lower, but not to the end user. Any functionality that user took advantage of that was not represented in the final standard will suddenly become non-portable. Worse yet, it may become unavailable. From a system vendors perspective, they may have to support some strange functioanlity or system limits because the draft standard required them to, some agency took advantage of it, and now they are stuck. They have to support thios non-portable functionality forever, as well as the real standard. This is not at all the goal of standardization, and should not be the goal of the agencies procuring systems. Standing on my soap-box again for a minute, we have to keep the overall goal of open systems in sight. That goal is that the application developers of the world are given a guaranteed base on which they can develop portable applications that can interoperate with one another. This means having a steady functional migration which NEVER capriciously breaks compatability. This may mean that in the short term new, exciting functionality is not introduced to the disadvantage of existing practice. This is the price we pay for keeping the application developers interested in open systems. The personal productivity application base is just coming available for open systems platforms in ways that are attractive to the casual computer user. We CANNOT abdicate our responsibility to retain that extremely hard-won base of applications by allowing radical change in the definition of the system. If we do that, we might as well go and buy DOS. Shane P. McCarron Secretary, IEEE TCOS-SS -- Shane P. McCarron Phone: +1 612-224-9239 Project Manager Internet: ahby@bungia.mn.org Volume-Number: Volume 21, Number 189