🚀 go-pugleaf

Submitted-by: jason@cnd.hp.com (Jason Zions)

>  Also, there was already precedent set within POSIX by the POSIX.2
>inclusion of lp(1) as a command line interface for printing.

Doug Gwyn already addressed this; one can bind the lp interface to Palladium
and still have the 1003.2-required right thing happen.

>> POSIX has expanded beyond the "only existing practice" rule.  Look at
>> 1003.4, 1003.6, and the OSI APIs.  If you don't like this, your recourse
>> is to campaing and vote against it, but if the majority disagree, this is 
>> the way it will be.
>
>  This does not bode at all well for POSIX, because the last sentence
>above can be safely translated as "POSIX is no longer a technical
>process, it is now primarily a political process with vendors fighting
>it out on marketing grounds."

The double-quoted text is both hyperbolic and somewhat incorrect. It's not a
majority that's required; it's 75%. And if the other 25% are hard-core set
against something, the IEEE Standards Board (RevCom) will see that and ask
some very nasty questions.

As for the given examples of POSIX expanding upon the "existing practice"
rules, let's remember how things really are. 1003.4 was a dumping ground for
all the stuff people wanted in 1003.1 but couldn't get concensus for in
1988. Nothing to do with real-time, or not much. It's gotten better. 1003.6
was sponsored before TCOS really clarified the "we don't invent here"
policy. And they've suffered for it. The completed OSI APIs (1224, 1224.1,
and 1224.2) are all based on specifications developed by X/Open and other
groups and for which there were multiple independent implementations. The
other OSI stuff (FTAM et al) has just had a change in direction; it will be
based on yet more X/Open specs for which there are multiple (i.e. at least
two) independent implementations.

As Stephe Walli pointed out in his late-December gallstone, Standards have
always been a political process with vendors fighting it out on marketing
grounds. Nothing new here.

>  Also, POSIX.4 is reportedly partially derived from years of
>experience with a commercial real-time UNIX-like operating system.
>POSIX.6 is derived significantly from experience building operating
>systems targeted for B1 evaluation from NCSC and from other OSs that
>have had ACLs for a while now.

And the Palladium-based spec is derived significantly from several extant
implementations of it. The one I'm most familiar with is HP's OpenSpool
product, which is based on Palladium technology (with lots of changes).
They've sold a bunch of them; there's existing practice. Sure, it's not
close to a majority of the users of distributed printing technology, but no
one way of doing real-time on Un*x is dominant either, or is any way of
putting ACLs in Un*x either. Quite a parallel.


I watch 1003.7.* very closely; I'm the TCOS PMC mentor for the project. I
admit to being the one that asked them to probe their mock-ballot group for
the acceptability of Palladium, and the one that helped the rest of the TCOS
SEC accept their word that it was okay. Has nothing to do with HP making
anything that looks remotely like the evolving standard; that's not my part
of the company (and it's not my company anymore after Jan 29).

Jason


Volume-Number: Volume 30, Number 45