home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.30 / text0044.txt < prev    next >
Encoding:
Text File  |  1993-03-11  |  3.2 KB  |  67 lines
  1. Submitted-by: jason@cnd.hp.com (Jason Zions)
  2.  
  3. >  Also, there was already precedent set within POSIX by the POSIX.2
  4. >inclusion of lp(1) as a command line interface for printing.
  5.  
  6. Doug Gwyn already addressed this; one can bind the lp interface to Palladium
  7. and still have the 1003.2-required right thing happen.
  8.  
  9. >> POSIX has expanded beyond the "only existing practice" rule.  Look at
  10. >> 1003.4, 1003.6, and the OSI APIs.  If you don't like this, your recourse
  11. >> is to campaing and vote against it, but if the majority disagree, this is 
  12. >> the way it will be.
  13. >
  14. >  This does not bode at all well for POSIX, because the last sentence
  15. >above can be safely translated as "POSIX is no longer a technical
  16. >process, it is now primarily a political process with vendors fighting
  17. >it out on marketing grounds."
  18.  
  19. The double-quoted text is both hyperbolic and somewhat incorrect. It's not a
  20. majority that's required; it's 75%. And if the other 25% are hard-core set
  21. against something, the IEEE Standards Board (RevCom) will see that and ask
  22. some very nasty questions.
  23.  
  24. As for the given examples of POSIX expanding upon the "existing practice"
  25. rules, let's remember how things really are. 1003.4 was a dumping ground for
  26. all the stuff people wanted in 1003.1 but couldn't get concensus for in
  27. 1988. Nothing to do with real-time, or not much. It's gotten better. 1003.6
  28. was sponsored before TCOS really clarified the "we don't invent here"
  29. policy. And they've suffered for it. The completed OSI APIs (1224, 1224.1,
  30. and 1224.2) are all based on specifications developed by X/Open and other
  31. groups and for which there were multiple independent implementations. The
  32. other OSI stuff (FTAM et al) has just had a change in direction; it will be
  33. based on yet more X/Open specs for which there are multiple (i.e. at least
  34. two) independent implementations.
  35.  
  36. As Stephe Walli pointed out in his late-December gallstone, Standards have
  37. always been a political process with vendors fighting it out on marketing
  38. grounds. Nothing new here.
  39.  
  40. >  Also, POSIX.4 is reportedly partially derived from years of
  41. >experience with a commercial real-time UNIX-like operating system.
  42. >POSIX.6 is derived significantly from experience building operating
  43. >systems targeted for B1 evaluation from NCSC and from other OSs that
  44. >have had ACLs for a while now.
  45.  
  46. And the Palladium-based spec is derived significantly from several extant
  47. implementations of it. The one I'm most familiar with is HP's OpenSpool
  48. product, which is based on Palladium technology (with lots of changes).
  49. They've sold a bunch of them; there's existing practice. Sure, it's not
  50. close to a majority of the users of distributed printing technology, but no
  51. one way of doing real-time on Un*x is dominant either, or is any way of
  52. putting ACLs in Un*x either. Quite a parallel.
  53.  
  54.  
  55. I watch 1003.7.* very closely; I'm the TCOS PMC mentor for the project. I
  56. admit to being the one that asked them to probe their mock-ballot group for
  57. the acceptability of Palladium, and the one that helped the rest of the TCOS
  58. SEC accept their word that it was okay. Has nothing to do with HP making
  59. anything that looks remotely like the evolving standard; that's not my part
  60. of the company (and it's not my company anymore after Jan 29).
  61.  
  62. Jason
  63.  
  64.  
  65. Volume-Number: Volume 30, Number 45
  66.  
  67.