home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8652 < prev    next >
Encoding:
Text File  |  1992-08-19  |  3.1 KB  |  65 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!stanford.edu!snorkelwacker.mit.edu!bloom-picayune.mit.edu!root
  3. From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  4. Subject: Re: header woes with 2.2.2d
  5. Message-ID: <1992Aug19.201415.12339@athena.mit.edu>
  6. Sender: root@athena.mit.edu (System PRIVILEGED Account)
  7. Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  8. Organization: The Internet
  9. Date: Wed, 19 Aug 1992 20:14:15 GMT
  10. Lines: 53
  11.  
  12.    From: davidsen@ariel.crd.GE.COM (william E Davidsen)
  13.    Date: 19 Aug 92 12:46:49 GMT
  14.    Reply-To: davidsen@crd.ge.com (bill davidsen)
  15.  
  16.      Having done a good bit of distributed development over the years has
  17.    convinced me that this is one place where a little good software
  18.    engineering practice is important. We are talking about three people (or
  19.    groups) promptly sharing changes to the header file. People who are in
  20.    fast communication via network.
  21.  
  22. Ah, the difference is that's what I think is happening right now.  Keep
  23. in mind that most of the incompatibilities happen because of new features
  24. in the kernel.
  25.  
  26. So when Linus releases changes to the kernel, he's doing exactly what
  27. you ask.  He generally does so quite promptly (especially if you compare
  28. what he does against the release cycles of companies like Microsoft),
  29. and he does so publically.  Then,  everyone who does work on these
  30. changes (like the maintainers of ps, GCC, and possibly others that we
  31. don't know about) can update their programs so that they work again.
  32.  
  33. The problem is that everybody *else* takes the new patches right away,
  34. and complains when things break.  I don't know.... when *I* took
  35. patchlevel 1 to 0.97, I took a couple of minutes glancing through the
  36. changes, and then I was able to quickly hack ps to make it work.  It
  37. didn't slow me down much.  But if it is going to slow you down; if
  38. you're only interested in doing applications development on Linux (and
  39. that *is* an honorable thing to do), I would suggest that you wait for a
  40. few weeks until everything settles down.
  41.  
  42. Keep in mind that when the next set of patches to Linux comes out, Linus
  43. has already said that the virtual memory code has been rewritten, and ps
  44. is going to break in major ways.  I'd rather not have him hold back his
  45. release while other people scurry around and fix ps, and the other
  46. programs.
  47.  
  48. I would rather the kernel changes get released, and people who don't
  49. mind living on the bleeding edge, or who don't mind living without "ps"
  50. can play with it right away, and people who want all of the comforts of
  51. home SIMPLY NOT TAKE THE KERNEL CHANGES RIGHT AWAY.  Is that such a hard
  52. thing?
  53.  
  54. If people don't have enough self control to keep their paws off of the
  55. latest stuff (or who could take the latest stuff and then not bitch when
  56. things broke), one alternative is to have a fascist alpha-testing
  57. program, as you suggested --- but when you have to do this in the
  58. freeware domain, what you are doing is forcibly excluding people from
  59. taking the "testing release" when they should know better.  Perhaps it
  60. is a stupid hope, but I was hoping that people would be adult enough and
  61. intelligent enough and have enough self-control so that sort of thing
  62. wouldn't be necessary.
  63.  
  64.                             - Ted
  65.