home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / org / sug / 634 < prev    next >
Encoding:
Text File  |  1993-01-25  |  3.5 KB  |  78 lines

  1. Newsgroups: comp.org.sug
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!bogus.sura.net!darwin.sura.net!ra!atkinson
  3. From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
  4. Subject: Re: IMPORTANT: POSIX threatens our use of lp/lpr and friends
  5. Message-ID: <C1FusF.AyE@ra.nrl.navy.mil>
  6. Sender: usenet@ra.nrl.navy.mil
  7. Organization: Naval Research Laboratory, DC
  8. References: <4169@ecicrl.ocunix.on.ca> <C1DH9B.5Jv@ra.nrl.navy.mil> <DUKE.93Jan25133151@portal.paperboy.osf.org>
  9. Distribution: na
  10. Date: Tue, 26 Jan 1993 01:57:50 GMT
  11. Lines: 65
  12.  
  13. In article <DUKE.93Jan25133151@portal.paperboy.osf.org> duke@portal.paperboy.osf.org (Duke Robillard) writes:
  14.  
  15. >You know, I've been resisting the urge to defend myself against Atkinson's
  16. >uninformed, hysterical attacks, but I've just lost my self-control.  I
  17. >know I'll hate myself later for getting into a flame war....
  18.  
  19. Nah.  Get it off your chest.  You'll feel much better afterwards and
  20. it won't bother me at all.  Really. :-)
  21.  
  22.   However, I do think "uninformed" is wholly inaccurate since I TRIED
  23. to participate in the mock ballot and so I saw that draft (and was very
  24. unhappy about the draft ignoring both the existing practice of lp/lpr
  25. -- recall that MIT _removed_ Palladium from most of its systems
  26. because MIT felt it was less useful than just using existing practice
  27. such as lp/lpr and friends -- and the POSIX.2 precedent of
  28. standardising a simple lp interface).  I sent written comments in
  29. via the USPS as part of the mock ballot process.
  30.  
  31. >Randall Atkinson hasn't been involved with the 1003.7.1 group at all,
  32. >at least not in the last 2.5 years.  If he had spent any time working
  33. >with us, he would know that the people on the group are engineers trying
  34. >to solve a problem, not marketing types trying to make money off other 
  35. >people's misfortune.  
  36.  
  37.   I _TRIED_ very hard to participate in the mock ballot and I _HAVE_
  38. sent written comments in via the USPS and I _HAVE_ looked at the draft
  39. circulated with the mock ballot.  
  40.  
  41.   I might be very very mistaken (clearly I don't think so but I've
  42. surely been wrong in public before now), but if I am wrong it is
  43. legitimate confusion or stupidity or ignorance rather than ill will
  44. towards any individual.
  45.  
  46. >If he has legitmate technical concerns with Palladium, I'd appreciate
  47. >it if he brought them forward, rather than posting nasty cracks about
  48. >people's motives.
  49.  
  50. See the above paragraphs.
  51.  
  52.   AT A MINIMUM, my postings have caused a whole lot more users and
  53. systems administrators to become interested in the POSIX.7 work, to
  54. want to read copies of the POSIX.7 draft, and might well help motivate
  55. some of those folks to get involved in the POSIX.7 balloting group.
  56. More review and participation by users and systems administrators
  57. cannot possibly be a bad thing for the effort.  
  58.  
  59.   If they participate and like the Palladium approach, they will
  60. surely vote for it.  If they participate and don't like it, they will
  61. tell the IEEE why they don't like it and how to fix it and that can't
  62. be a bad outcome either.  It is a kind of win/win scenario for more
  63. users and systems administrators to be involved in all POSIX
  64. standards.
  65.  
  66.   Now while I'm sure that Duke personally thinks that POSIX.7 are
  67. doing The Right Thing, I'm at least as sure that it isn't The Right
  68. Thing.  On that we're not likely to be agreeing soon.
  69.  
  70.   By the way, I do agree with most or all of Doug Gwyn's comments
  71. about how a general batching/queueing solution (e.g. BRL's MQDS) would
  72. be a technically surperior approach and would be compatible with
  73. retaining the current user command line interfaces for printing.
  74.  
  75. Ran
  76. atkinson@itd.nrl.navy.mil
  77.  
  78.