home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0067.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  4.3 KB  |  116 lines
  1. Submitted-by: stephe@mks.com (Stephen Walli)
  2.  
  3. In <1992Apr2.025846.29245@uunet.uu.net> tg@utstat.toronto.edu (Tom Glinos) writes:
  4.  
  5. >At the risk of being flamed back into the stone age I'll offer
  6. >the opinion that the whole POSIX exercise has been a waste, for
  7. >the following reasons.
  8.  
  9. No flames. :-)
  10. I'll leave that to better flamers than I....
  11.  
  12. >[1] It's never been clear to me what the original POSIX proposals were
  13. >supposed to define and accomplish. (What is the deliverable?)
  14.  
  15. Where/when are you referring to? 
  16. The /usr/group standard (POSIX.1's ancestor) had a very definate 
  17. scope/purpose. Likewise, POSIX.1 has a similar well defined scope/purpose.
  18. For that matter, so does each and every piece of POSIX. They have all had
  19. to go through the IEEE's review process for new proposed work items. 
  20.  
  21. ``This part of ISO/IEC 9945 defines a standard operating system interface
  22.   and environment to support application portability at the source-code
  23.   level.  It is intended to be used by both applications developers and 
  24.   system implementors.''
  25.  
  26. First page, first paragraph of the normative part of the POSIX.1 standard. 
  27. Similar statement as the first paragraph of POSIX.2, and so on. 
  28. Each document that is either a real standard, or fairly far along in the 
  29. development process is clearly declared. 
  30.  
  31. >[2] This led to the ever widening number of groups. (More deliverables.)
  32.  
  33. No. Each project belonging to each working group serves a clearly defined
  34. purpose. The breadth of the entire POSIX family of standards is very large, 
  35. but then the 
  36. book shelf space of a lot of operating systems User/Programmer documentation
  37. can be considerable as well. (VMS's historical ``wall of orange'' for 
  38. instance.)
  39.  
  40. >[3] Some groups then started to argue and propose interfaces that in
  41. >some cases had never been widely implemented or thoroughly studied.
  42.  
  43. Yep. Happens. Which is why there is a consensus based process in place to 
  44. build de jure standards.  And there are people who regularly try to 
  45. subvert it. Also happens.  Other people try and make it work. Sooner or later
  46. it all balances out. Sort of like the informal consensus process which 
  47. surrounds the formal one. 
  48.  
  49. P.J. Plauger writing about the politics of standards 
  50. [specifically the C standard] talked about good politics (when things are 
  51. going your way) versus ``Damned'' politics (when you're losing the fight.) 
  52. It's part of the process. But then it's part of any process where there are 
  53. a lot of people with a diverse set of experiences trying to build 
  54. something. [No ``blind men identifying an elephant'' jokes, please.]
  55.  
  56. And sometimes you lose. Hopefully, they aren't in places that will break
  57. the standard badly enough to cast into doubt the entire standard or the 
  58. process that built it.
  59.  
  60. >[4] Some groups have let company and market pressures direct what should
  61. >be an exercise in common sense and good engineering.
  62.  
  63. There are rules in the IEEE standards process to do with the balance 
  64. of membership in working groups (building draft documents) and balloting
  65. groups (commenting on those drafts). They cannot be heavily weighted 
  66. towards Users OR Vendors. 
  67.  
  68. There is a balance involved between users (wanting the sun and the stars) and
  69. the vendors who can build something efficient (that will get you to the moon.)
  70. Somewhere in the middle lies reality. 
  71.  
  72. It's all about market pressure and economics at some level. If you want
  73. great solutions based on ``common sense and good engineering'', live in a 
  74. research lab, which is probably the closest you'll get to such a perfect
  75. world. 
  76.  
  77. >It's been a bit more than a year since I looked at any POSIX document.
  78. >If memory serves me correctly it's been about 5 years since the first
  79. >document was tabled. 
  80.  
  81. IEEE 1003.1-1988
  82.  
  83. >Has nothing been voted on? 
  84.  
  85. IEEE 1003.1-1990 == ISO/IEC 9945-1:1990
  86. IEEE 1003.3-1991
  87. In ballot:
  88. POSIX.2 *
  89. POSIX.2a *
  90. POSIX.3.1
  91. POSIX.4 *
  92. POSIX.4a
  93. POSIX.5 *
  94. POSIX.6
  95. POSIX.9 *
  96. POSIX.13
  97. * -- Optimistically, almost done.
  98.  
  99. >When will it all end?
  100. Wont. Standards change as technology changes. Not as rapidly, but they change.
  101. New standards are added. Out-of-date standards are removed. Bad standards die. 
  102.  
  103. >"Life is so much more meaningful if you take the time to hunt down and 
  104. > strangle twits who post blather to inappropriate newsgroups." Henry Spencer
  105.  
  106. Yes.
  107.  
  108. Cheers,
  109. stephe
  110.  
  111.                    ``So there *is* a God. What's your point?''
  112.  
  113.  
  114. Volume-Number: Volume 27, Number 67
  115.  
  116.