home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0032.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  3.4 KB  |  77 lines
  1. [ Comments within square brackets like this are by the poster,
  2. unless they end with -mod, when they are by the moderator.  -mod ]
  3.  
  4. Date: Sun, 2 Feb 86 14:29:57 pst
  5. >From: aps@DECWRL.DEC.COM (Armando P. Stettner)
  6.  
  7. Hi.
  8. On the subject of umasks:
  9. I feel that setting the modes of a created file according to a
  10. per-directory umask is a bad idea.
  11.  
  12. On the surface, it seems like it might be a good idea.  But what this
  13. change does is to remove some of the responsibility and choice of the
  14. program and certain choices of the invoker to place it where such
  15. decisions may have been (perhaps) arbitrarily made by the people who
  16. created and/or own the target directory.  The word `arbitrary' may be
  17. too strong a word but the point I am trying to make is that one
  18. important characteristic of UNIX I have come to respect, appreciate,
  19. and love is that UNIX doesn't do things one doesn't ask it to do nor
  20. does it change or coerce things one produces (files on UNIX vs files on
  21. VMS, as an example of the latter).  Please leave the decisions with the
  22. programmers and the users.
  23.  
  24. [ The same argument would apply just as well to existing directory
  25. protection modes or the 4.2BSD method of assigning groups to files.
  26. However, the moderator has been sticking his oar in too often lately
  27. and will try to be quiet.  -mod ]
  28.  
  29. My second objection stems from the thought that it might break a large
  30. set of existing programs (uucp, tip, lp{r,d,rm}, data base subsystems
  31. that run across several UNIX implementations and can not assume certain
  32. record locking facilities, etc).  [Don't nickel and dime me with
  33. implementation details; try and understand what I am trying to say.  I
  34. could check the sources also.  Thanks.]
  35.  
  36. [ Please elaborate.  -mod ]
  37.  
  38. On the UNIX IEEE P1003 effort, in general:
  39. This brings me to my next (and maybe the more important) point:  I have
  40. been watching this news group and the standards efforts in general (the
  41. ANSI C effort to a lessor degree).  I am concerned by what I see.  I am
  42. afraid what is happening is sort of what people feared would happen if
  43. a Constitutional Convention were to take place and this is: people now
  44. have a chance to change things.  Intentions are all well and good (I
  45. assume this).  However, things are getting changed.  What I would like
  46. to see in a standard that is attempting to pull together a fragmented
  47. world, such as the UNIX world, is a strong subset of the
  48. characteristics and functions in the more common (popular?) existing
  49. implementations; not one which is implemented by no current version.  I
  50. don't know; maybe this is what is wanted by people on the IEEE
  51. committee:  no current vendor has a head start ...
  52.  
  53. There are few good things that are done by ``committee'' that I know
  54. of.  This does not mean that I feel that P1003 should be disbanded;
  55. however, I feel the members should be aware of the possible pitfalls of
  56. `by committee' design and work to avoid them.
  57.  
  58. [ I'm overdue for posting a report on the latest P1003 meeting and will
  59. address this subject.  However, be aware that the newsgroup is not P1003,
  60. and that the committee members constantly raise your concern.  -mod ]
  61.  
  62.  
  63. Maybe the resulting work of P1003 should be called UNIX2 or unUNIX
  64. (Onionix?**).
  65.  
  66. [Needless to say (I know: then why say it?), these opinions are mine
  67. and not necessarily DEC's]
  68.  
  69.     Armando Stettner
  70.     decwrl!aps, decvax!aps, decwse::aps, aps@berkeley
  71.  
  72.  
  73. ** Onionix is a trademark of aps enterprises...
  74.  
  75. Volume-Number: Volume 5, Number 33
  76.  
  77.