home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.30 / text0048.txt < prev    next >
Encoding:
Text File  |  1993-03-11  |  2.9 KB  |  65 lines
  1. Submitted-by: atkinson@itd.nrl.navy.mil (Randall Atkinson)
  2.  
  3. In article <1k9braINN70g@ftp.UU.NET> jason@cnd.hp.com (Jason Zions) writes:
  4. >>Also, there was already precedent set within POSIX by the POSIX.2
  5. >>inclusion of lp(1) as a command line interface for printing.
  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.   Unfortunately, regular ordinary users ALSO need something like
  10. lpq/lpstat and lprm/cancel and POSIX.2 did not address those needs at
  11. all.  I'd be MUCH MUCH happier if the POSIX.7 folks or the POSIX.2
  12. folks had in fact provided those customary existing practice
  13. interfaces.  Some folks might be surprised how much installed base
  14. there is in people and shell scripts that use these commands.
  15.  
  16. > The completed OSI APIs (1224, 1224.1, and 1224.2) are all based on
  17. > specifications developed by X/Open and other groups and for which
  18. > there were multiple independent implementations. 
  19.  
  20.   I had construed POSIX == 1003.x only and never ever use OSI and
  21. so have not been trying to track that at all.  (I print lots of
  22. things daily by contrast).
  23.  
  24.   Palladium is existing practice in very few if any places, while
  25. lp/lpr and friends are existing practice in an absolutely overwhelming
  26. number of places already.
  27.  
  28. > Sure, it's not close to a majority of the users of distributed
  29. > printing technology, but no one way of doing real-time on Un*x is
  30. > dominant either, ...
  31.  
  32.   I don't recall saying I was a big fan of the real-time work either.
  33. In fact, I'm inclined to dislike most of it because UNIX/POSIX is
  34. almost certainly not the most appropriate basis for a real-time OS.  I
  35. used to work in real-time controls and so while I am a fan of UNIX, I
  36. also know enough to know that UNIX is not the optimal OS from a
  37. real-time perspective.
  38.  
  39.   Palladium is used in very very few places compared with lp/lpr and
  40. friends.  A trivially small number by comparison, in fact.
  41.  
  42. > I admit to being the one that asked them to probe their mock-ballot
  43. > group for the acceptability of Palladium, and the one that helped the
  44. > rest of the TCOS SEC accept their word that it was okay.
  45.  
  46.   Word on the street is that there were only about 25 ballots on the
  47. Palladium mock-ballot.  I dunno if that is true.  If it is even
  48. approximately true, then the mock ballot tells no one anything either
  49. way about the suitability of Palladium -- simply because of too few
  50. ballots to interpret in any meaningful way.
  51.  
  52.   I really really hope a whole lot more folks participate in the real
  53. ballot when that happens.  I have real fears that not enough people
  54. will thoroughly look through the POSIX.7 proposal when the time comes
  55. (and I've certainly at least gotten a lot more people interested in
  56. the effort, though some are VERY unhappy with how I did that.)  Time
  57. will tell if very many people will participate.
  58.  
  59. Ran
  60. atkinson@itd.nrl.navy.mil
  61.  
  62.  
  63. Volume-Number: Volume 30, Number 47
  64.  
  65.