Thread View: comp.std.unix
2 messages
2 total messages
Started by Jason Zions
Thu, 28 Jan 1993 19:23
Re: 1003.7.1/Palladium/Existing Practice
Author: Jason Zions
Date: Thu, 28 Jan 1993 19:23
Date: Thu, 28 Jan 1993 19:23
65 lines
3804 bytes
3804 bytes
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
Re: 1003.7.1/Palladium/Existing Practice
Author: Randall Atkinson
Date: Thu, 28 Jan 1993 23:49
Date: Thu, 28 Jan 1993 23:49
63 lines
3481 bytes
3481 bytes
Submitted-by: atkinson@itd.nrl.navy.mil (Randall Atkinson) In article <1k9braINN70g@ftp.UU.NET> jason@cnd.hp.com (Jason Zions) writes: >>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. Unfortunately, regular ordinary users ALSO need something like lpq/lpstat and lprm/cancel and POSIX.2 did not address those needs at all. I'd be MUCH MUCH happier if the POSIX.7 folks or the POSIX.2 folks had in fact provided those customary existing practice interfaces. Some folks might be surprised how much installed base there is in people and shell scripts that use these commands. > 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. I had construed POSIX == 1003.x only and never ever use OSI and so have not been trying to track that at all. (I print lots of things daily by contrast). Palladium is existing practice in very few if any places, while lp/lpr and friends are existing practice in an absolutely overwhelming number of places already. > 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, ... I don't recall saying I was a big fan of the real-time work either. In fact, I'm inclined to dislike most of it because UNIX/POSIX is almost certainly not the most appropriate basis for a real-time OS. I used to work in real-time controls and so while I am a fan of UNIX, I also know enough to know that UNIX is not the optimal OS from a real-time perspective. Palladium is used in very very few places compared with lp/lpr and friends. A trivially small number by comparison, in fact. > 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. Word on the street is that there were only about 25 ballots on the Palladium mock-ballot. I dunno if that is true. If it is even approximately true, then the mock ballot tells no one anything either way about the suitability of Palladium -- simply because of too few ballots to interpret in any meaningful way. I really really hope a whole lot more folks participate in the real ballot when that happens. I have real fears that not enough people will thoroughly look through the POSIX.7 proposal when the time comes (and I've certainly at least gotten a lot more people interested in the effort, though some are VERY unhappy with how I did that.) Time will tell if very many people will participate. Ran atkinson@itd.nrl.navy.mil Volume-Number: Volume 30, Number 47
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads