home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.21 / text0193.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  2.8 KB  |  61 lines
  1. Submitted-by: chip@tct.uucp (Chip Salzenberg)
  2.  
  3. According to ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe):
  4. >My program *can't* know what's available.  If someone comes along
  5. >with a special "open hyperspace shunt" function; my program can't
  6. >benefit from it.  If hyperspace shunts are in the global name space
  7. >and posix_open() understands their name syntax, my program will work
  8. >just fine.
  9.  
  10. Thank you, Richard, for stating well what I have intuitively felt.
  11.  
  12. (Dan, you wanted a reasoned rebuttal.  Very well: here it is.)
  13.  
  14. It is true that interactive use of UNIX, especially by programmers,
  15. puts a lot of emphasis on the shell interface.  If such an environment
  16. were all there were to Unix, then Dan's fd-centric view of the world
  17. could possibly be useful.  To use Richard's example: when a hyperspace
  18. shunt became available, its use would require only a change to the
  19. shell source code and a recompilation.
  20.  
  21. However, the reality of modern Unix use is something else entirely:
  22. pre-packaged utilities, usually available only as binaries, that for
  23. practical purposes *cannot* be changed or replaced.  In this
  24. environment, kernel features that require program customization are
  25. unwieldy at best, useless at worst.  As long as shells fall into this
  26. category -- "programs usually distributed as binaries" -- fd-centric
  27. UNIX will never be practical.
  28.  
  29. One could argue that binary-only distribution is evil and should be
  30. stopped.  I can agree that binaries are less useful than source code;
  31. in fact, my personal motto is, "Unless you have source code, it isn't
  32. software."  Nevertheless, copyright and trade secret law being what
  33. they are, we will continue to see binary-only distributions for the
  34. indefinite future.
  35.  
  36. Even if source code were for all UNIX programs were freely available,
  37. I doubt that anyone would seriously propose modifying *all* of them
  38. each time a new kind of fd-accessible object were added to the kernel.
  39.  
  40. Finally, filenames often are stored in places where no shell will ever
  41. see them, such as program-specific configuration files.  So in Dan's
  42. hypothetical fd-centric UNIX, we would have to either (1) pass such
  43. filenames to the shell for interpretation, thus incurring a possibly
  44. substantial performance hit; or (2) modify each program to understand
  45. all the names the shell would understand.  In my opinion, neither of
  46. these alternatives is viable.
  47.  
  48. To summarize:
  49.  
  50. A unified namespace has one great advantage: new types of objects are
  51. immediately available to all programs -- even the programs for which
  52. you do not have the means or the desire to modify and recompile.
  53. -- 
  54. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  55.     "I've been cranky ever since my comp.unix.wizards was removed
  56.          by that evil Chip Salzenberg."   -- John F. Haugh II
  57.  
  58.  
  59. Volume-Number: Volume 21, Number 194
  60.  
  61.