home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / unix / 537 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.3 KB
  1. Path: sparky!uunet!not-for-mail
  2. From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: 1003.7.1/Palladium/Existing Practice
  5. Date: 28 Jan 1993 15:49:08 -0800
  6. Organization: Naval Research Laboratory, DC
  7. Lines: 63
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <1k9rdkINNiu1@ftp.UU.NET>
  11. References: <1k9braINN70g@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: atkinson@itd.nrl.navy.mil (Randall Atkinson)
  16.  
  17. In article <1k9braINN70g@ftp.UU.NET> jason@cnd.hp.com (Jason Zions) writes:
  18. >>Also, there was already precedent set within POSIX by the POSIX.2
  19. >>inclusion of lp(1) as a command line interface for printing.
  20. >Doug Gwyn already addressed this; one can bind the lp interface to Palladium
  21. >and still have the 1003.2-required right thing happen.
  22.  
  23.   Unfortunately, regular ordinary users ALSO need something like
  24. lpq/lpstat and lprm/cancel and POSIX.2 did not address those needs at
  25. all.  I'd be MUCH MUCH happier if the POSIX.7 folks or the POSIX.2
  26. folks had in fact provided those customary existing practice
  27. interfaces.  Some folks might be surprised how much installed base
  28. there is in people and shell scripts that use these commands.
  29.  
  30. > The completed OSI APIs (1224, 1224.1, and 1224.2) are all based on
  31. > specifications developed by X/Open and other groups and for which
  32. > there were multiple independent implementations. 
  33.  
  34.   I had construed POSIX == 1003.x only and never ever use OSI and
  35. so have not been trying to track that at all.  (I print lots of
  36. things daily by contrast).
  37.  
  38.   Palladium is existing practice in very few if any places, while
  39. lp/lpr and friends are existing practice in an absolutely overwhelming
  40. number of places already.
  41.  
  42. > Sure, it's not close to a majority of the users of distributed
  43. > printing technology, but no one way of doing real-time on Un*x is
  44. > dominant either, ...
  45.  
  46.   I don't recall saying I was a big fan of the real-time work either.
  47. In fact, I'm inclined to dislike most of it because UNIX/POSIX is
  48. almost certainly not the most appropriate basis for a real-time OS.  I
  49. used to work in real-time controls and so while I am a fan of UNIX, I
  50. also know enough to know that UNIX is not the optimal OS from a
  51. real-time perspective.
  52.  
  53.   Palladium is used in very very few places compared with lp/lpr and
  54. friends.  A trivially small number by comparison, in fact.
  55.  
  56. > I admit to being the one that asked them to probe their mock-ballot
  57. > group for the acceptability of Palladium, and the one that helped the
  58. > rest of the TCOS SEC accept their word that it was okay.
  59.  
  60.   Word on the street is that there were only about 25 ballots on the
  61. Palladium mock-ballot.  I dunno if that is true.  If it is even
  62. approximately true, then the mock ballot tells no one anything either
  63. way about the suitability of Palladium -- simply because of too few
  64. ballots to interpret in any meaningful way.
  65.  
  66.   I really really hope a whole lot more folks participate in the real
  67. ballot when that happens.  I have real fears that not enough people
  68. will thoroughly look through the POSIX.7 proposal when the time comes
  69. (and I've certainly at least gotten a lot more people interested in
  70. the effort, though some are VERY unhappy with how I did that.)  Time
  71. will tell if very many people will participate.
  72.  
  73. Ran
  74. atkinson@itd.nrl.navy.mil
  75.  
  76.  
  77. Volume-Number: Volume 30, Number 47
  78.