Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.31/text0010.txt

Text File | 1993-07-15 | 3.8 KB | 74 lines

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>>But if that's not enough, I've run into situations where a vendor has
>>implemented a device driver in such a way that some features are totally
>>useless, and refused to fix them because they still conformed...
>
>The POSIX.3.1 test methods were never intended to be all-
>encompassing tests of the quality of POSIX.1 implementations...

There is a problem of perception here, one that goes beyond just the
test-methods issue.  Some people view standards as laws, on the theory
that they establish the minimum that vendors should be allowed to market.
>From this viewpoint, standards should be as strict as possible, to raise
the quality of marketed software.

The problem with this view is that there is nobody standing over the
average vendor with a gun, forcing him to comply with the standard.
If it is too strict, he will simply ignore it.  Standards that are
not accepted are a useless waste of everyone's time.  (Nobody has
ever used ANSI standard EBCDIC -- certainly not IBM!)

The standard-setting process reflects this, by being organized so that
standards (in principle) represent consensus opinion of all concerned,
and so that (in theory) one group cannot ram a problematic standard
down everyone else's throat.  While disgruntled users may *want* to
ram some standards down the vendors' throats, that isn't the way the
standards process usually works... and when it does, you don't want
to be standing too close, because the result is likely to be a mess.

Standards developed by this process are best viewed as contracts,
telling each party what the other one promises to do and not to do.
And even a signed-and-sealed contract is not a substitute for good
will on both sides.  If you try to write an airtight contract, you
will end up with something that few people will sign, with eventual
litigation over details almost guaranteed.  (And the courts will
interpret such a contract very narrowly -- if you fail to fulfill
*your* obligations in the slightest detail, you can forget it.)
In practice, you are better off with something shorter and simpler
that doesn't try to seal every loophole.  This means you have to
pick a supplier who will live up to the spirit of his obligations
and not just the letter... but you have to do that *anyway*, because
there are *always* ways for him to fulfill the letter but not the
spirit.

The *only* way to keep vendors honest is competition.  Standards are
certainly useful in establishing what the vendors should be living
up to, but they won't make them live up to it.  If you don't want
to get shafted by a vendor, have an alternative vendor just in case.
This is what standards are really about -- giving you a stable base
so that you *do* have choices.

(The form of choice that I personally like best is having source code;
that way, if really necessary, I can tell the vendor to go spindle
himself, and make the fix myself.  There has historically been a problem
in that this was very expensive in the Unix world, outside some favored
enclaves like the universities... but that has changed.  You can now get
a decent exactly-like-Unix system, with full commercial support and
*WITH SOURCE*, for not much more than you pay for binary-only sludge
from the "UNIX is a registered trademark of <insert this week's name>"
people.  If you let yourself be locked into a monopoly supplier, it's
your own fault now.)

(To avoid leaving people dangling, I suppose I should say that if you
want to know more, send mail to [e-mail].  I don't work for
them, but I heartily approve of what they're doing.)

--
C++ is the best example of second-system| Henry Spencer @ U of Toronto Zoology
effect since OS/360.                    |  [e-mail]  utzoo!henry

Volume-Number: Volume 31, Number 11