home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0062.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  4.3 KB  |  109 lines
  1. Submitted-by: karish@mindcraft.com (Chuck Karish)
  2.  
  3. In article <1991Jul23.065617.20086@uunet.uu.net> brnstnd@KRAMDEN.ACF.NYU.EDU
  4. (Dan Bernstein) writes:
  5. >karish@mindcraft.com (Chuck Karish) writes:
  6.  
  7. >I like to think that if POSIX hadn't tried to standardize
  8. >job control, some vendors would have implemented my model, some programs
  9. >would have been written to use it, and eventually the sheer simplicity
  10. >of the interface would win most vendors and programmers over within five
  11. >or ten years.
  12. >And you, Chuck, tell me that this is how it should be.
  13.  
  14. Sorry, Dan.  No more straight lines from me.  You'll have to
  15. provide your own soapbox.
  16.  
  17. >I consider every solution to this problem to be a poor
  18. >candidate for standardization, because (drum roll):
  19. >
  20. >    The Market Hath Not Chosen A Solution.
  21. >    The Market Hath Hardly Even Considered The Problem.
  22. >
  23. >Can you name a single vendor which has a solution to the problem of a
  24. >secure path for installed utilities? I'm listening.
  25.  
  26. The 1003.2 committee doesn't even see the same problem that
  27. Dan Bernstein does.  _CS_PATH is there for usability, not
  28. for security.
  29.  
  30. Market forces tend to cause divergence on many technical
  31. points, rather than agreement.  UNIX systems have been able
  32. to stay reasonably compatible through the years because of
  33. a lack of market forces in shaping the basic system: AT&T
  34. owned it and sold it at reasonable rates with few restrictions.
  35. Over the last four years competition has splintered the 
  36. market for UNIX-based workstations.
  37.  
  38. >> There's a simple fix that makes [getconf-using] scripts work:  install
  39. >> getconf.
  40. >
  41. >But that requires work on the part of *everyone* who wants to use the
  42. >script!
  43.  
  44. Not everyone; just every system administrator who wants to
  45. run new software on an obsolete operating system.  Good
  46. scripts will be written to work properly with or without
  47. getconf, anyway.
  48.  
  49. >> The issue of script portability is something of a red herring,
  50. >> because it has never been possible to write really portable
  51. >> scripts.
  52. >
  53. >Uh, say what? People *do* write scripts all the time which work on lots
  54. >of systems; Configure is a supreme example, but nearly every script is
  55. >portable to similar machines.
  56.  
  57. If they require "similar machines", what does "portable" mean?
  58. UNIX utilities vary quite a bit in syntax, return status, and
  59. undocumented internal limits.  The goal of POSIX.2 is to get
  60. rid of a lot of these pitfalls.  getconf is there to make
  61. visible those differences that aren't to be eliminated.
  62.  
  63. "Configure" is a particularly ironic example, because it makes
  64. inferences about the host that don't always stand up on
  65. machines that have multiple universes or lots of compatibility
  66. features.  It has unbounded potential (and need) for increase
  67. in complexity as it's developed to handle new environments.
  68. That is exactly why standards are needed.  getconf is intended
  69. to provide definitive answers to some of the questions that
  70. Configure has to guess about.
  71.  
  72. Configure could be used to write an implementation of getconf
  73. for an OS that fits its preconceptions.
  74.  
  75. >> getconf, sysconf(), pathconf() and fpathconf() exist to make it
  76. >> possible to allow programs to make full use of system
  77. >> capabilities without being re-compiled for differently-
  78. >> configured members of a binary-compatible family and without
  79. >> being crippled down to a lowest common denominator.
  80. >
  81. >Here's your unstated assumption again: that the standard *has* to
  82. >provide some way to do anything that systems code might want to do.
  83. >Why?
  84.  
  85. Hyperbole aside (though I'm sure you could implement job
  86. control from the POSIX.2 shell, Dan ;-), it's because software
  87. developers and end users want software that doesn't have to be
  88. hacked every time they want to run it on a new platform.
  89.  
  90. >Why is this sort of invention better than letting the market come
  91. >to a consensus on each feature first?
  92.  
  93. There's no way to unbundle the features so that market feedback
  94. on each individual feature can be meaningful.  "The Market"
  95. seems to be demanding shrink-wrap software for workstations.
  96. This sort of standardization helps make that possible.
  97. -- 
  98.  
  99.     Chuck Karish        karish@mindcraft.com
  100.     Mindcraft, Inc.        (415) 323-9000
  101.  
  102.  
  103. [ Moderator's note:  The previous message, by Peter da Silva, went out with
  104.   the wrong number.  It should have been Volume 24, Number 62.  I apologise
  105.   for the error -- mod ]
  106.  
  107. Volume-Number: Volume 24, Number 63
  108.  
  109.