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