home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / misc / 4816 < prev    next >
Encoding:
Text File  |  1993-01-04  |  4.4 KB  |  97 lines
  1. Newsgroups: comp.unix.misc
  2. Path: sparky!uunet!think.com!ames!nsisrv!author.gsfc.nasa.gov!rkoehler
  3. From: rkoehler@author.gsfc.nasa.gov (Bob Koehler)
  4. Subject: Re: What makes Unix Special?
  5. Message-ID: <4JAN199309464458@author.gsfc.nasa.gov>
  6. News-Software: VAX/VMS VNEWS 1.4-b1  
  7. Sender: usenet@nsisrv.gsfc.nasa.gov (Usenet)
  8. Nntp-Posting-Host: author.gsfc.nasa.gov
  9. Organization: CSC System Sciences Division
  10. References: <1992Dec31.062544.5838@news.columbia.edu> <31DEC199210495450@author.gsfc.nasa.gov> <C04zI3.EuK@mtholyoke.edu>
  11. Date: Mon, 4 Jan 1993 14:46:00 GMT
  12. Lines: 83
  13.  
  14. In article <C04zI3.EuK@mtholyoke.edu>, jbotz@mtholyoke.edu (Jurgen Botz) writes...
  15. >Unix wasn't really "written in 1969".  It was begun in 1969.  There's a big
  16. >difference... the common Unix variants (SV, BSD4) are products of the late
  17. >70s.
  18. > 
  19.  
  20. Of course, is fairly obvious from the advances of the last 5 years that the
  21. writing of UNIX isn't done.  My claim, however, is that the UNIX kernel shows
  22. the result of decisions made early on, back in the days when we rebooted our
  23. PDPs fairly often, and 1 MIPS was not available on the typical budget.  I will
  24. site only one example.  The used and free space in the file system buffer in a
  25. typical UNIX is tracked through a series of fixed size arrays.  When the buffer
  26. becomes more fragmented than can be tracked due to one of the arrays being
  27. full, the next to last entry is dropped (the last entry is likely to point to a
  28. large space).  Several resources within the kernel are tracked in this manner,
  29. thus leading to the gradual loss of such resources until the system is
  30. rebooted.  This algorythm is fast, simple, and require little overhead in
  31. memory, but the extra instructions needed to use something a little more
  32. complex, like a doubly-linked list, are insignificant for todays CPU speeds and
  33. memory sizes.
  34.  
  35. People with access to sources have told me that BSD actually contains improved
  36. algorythms in several (not all) areas simmilar to this in the kernel, but 
  37. System V does not contain all of even these improvements.
  38.  
  39. > 
  40. >Arguments can be made for anything.  Sound ones... well, make some! ;-)
  41. > 
  42.  
  43. On comp.unix.misc?  You must think me suicidal! :-)
  44.  
  45. Yep, I could argue the point, and I suppose you could argue the counter-point,
  46. or in fact I could argue the counter point, or that DOS is better than MVS, or
  47. (fill in you favorite 2 OSs)...
  48.  
  49. Most of this would boil down to anecdotal evidence, a large body of which
  50. surely exists for almost any point of veiw.  Beyond the example sited above
  51. I will not fill bandwidth with what is not likely to be a full, satisfying
  52. answer.
  53.  
  54. >>One of my pet peeves in UNIX land is its closed nature.  To me, open means you
  55. >>can look inside.  I cannot afford the current UNIX source license prices, but I
  56. >>have found source licensing arangements for proprietary systems often an order
  57. >>of magnitude lower.
  58. > 
  59. >Really?  I don't know otherwise, but I find this /very/ surprising.  How
  60. >much for a VMS source license?  Can anyone even get it?
  61. > 
  62.  
  63. I have had the VMS source-listing microfiche, which used to ship with VMS ($0,
  64. suprise, ah for the good old days), and I last bought for around $1500 (its
  65. probably a bit higher now).  The sources have always been available to me
  66. whenever I needed them.  A machine readable copy would be much more expensive,
  67. and it seems right now that the only option available from my UNIX vendors.
  68.  
  69. >Besides, a BSD-NET2
  70. >"source license" is $0.  Ditto for Linux.  Ditto for the Mach microkernel (not
  71. >Unix, but a good foundation for a Unix-workalike).  Ditto for GNU.
  72.  
  73. I'm not sure this does me any good when I'm tracking down a problem within an
  74. AIX, HP-UX, or ULTRIX based application.  The last nice round figure I got
  75. was "oh, about $50000" (ouch).
  76.  
  77. > 
  78. >>Personally I hope POSIX will catch on [...]
  79. > 
  80. >I agree.
  81.  
  82. Now I new there was something we could agree on, along with UNIX being better
  83. than (at least) most.
  84.  
  85. >*grin*... I don't consider this response a flame, and I'm also not writing
  86. >it to goad a response out of you, so go ahead and ignore it.  
  87.  
  88. Well if I had thought it was a flame, you probably wouldn't have seen this.
  89.  
  90. ------------------------------------------------------------------------------
  91. Bob Koehler                     |   Any illusion to these opinions being other
  92. rkoehler@author.gsfc.nasa.gov   |   than just mine alone is just that.
  93.  
  94.  " Life is life, and fun is fun, but it's all so quiet when the goldfish die. "
  95.                          - Blixie
  96.  
  97.