home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / bsd / 8961 < prev    next >
Encoding:
Text File  |  1992-11-17  |  5.2 KB  |  96 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!agate!netsys!decwrl!sun-barr!cs.utexas.edu!sdd.hp.com!caen!sol.ctr.columbia.edu!eff!news.byu.edu!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
  3. From: terry@cs.weber.edu (A Wizard of Earth C)
  4. Subject: Re: XFree86 problems (keyboard hangs overnight)
  5. Message-ID: <1992Nov16.222149.4904@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Organization: Weber State University  (Ogden, UT)
  8. References: <veit.721670337@du9ds3> <STARK.92Nov14094333@sbstark.cs.sunysb.edu> <veit.721901127@du9ds3>
  9. Date: Mon, 16 Nov 92 22:21:49 GMT
  10. Lines: 84
  11.  
  12. In article <veit.721901127@du9ds3> veit@du9ds3.uni-duisburg.de writes:
  13. >In <STARK.92Nov14094333@sbstark.cs.sunysb.edu> stark@cs.sunysb.edu (Gene Stark) writes:
  14. >Codrv is indeed a new package, which is, like other software (see buglist.0.9),
  15. >not directly integrated into the patchkit line.  But as I said, if you
  16. >omit the "pccons" related fixes of the patchkit that come along some time,
  17. >there are no problems with codrv, in contrast to ports and modifications,
  18. >which are based on "pccons". There is a tradeoff between new features and
  19. >portability. However, I must admit, that the way of installation, that is
  20. >used now in keycap, is not very user friendly. This marks a general problem
  21. >with the patchkit: It must be maintained from a central side. I currently
  22. >have about 50-60 patches pending, which are not yet covered by the patchkit,
  23. >some of them are important in my area, one is included in the keycap-kit.
  24. >Should I wait forever until the fixes will flow into the patchkit?
  25.  
  26. I agree that the general problem with the patchkit is the centralized
  27. maintenance.  Thus the same thing that gives it it's strength (the ability
  28. to coordinate multiple patches to the same files and insure patch
  29. precendence ordering) is it's greatest weakness (centralized control, or
  30. at least the handing around of a "magic cookie" [token] to ensure consistant
  31. ordering and patch number assignment).
  32.  
  33. The patchkit grew out of one night of frustration in trying to install
  34. several fixes to kern_exec.c.  I believe that using a patch kit patch
  35. mechanism is still superior to the alternative, which includes having to
  36. manually install all but the first patch to a file, no ability to gracefully
  37. back out a patch (unless you keep your own diffs on the manual installs),
  38. and having the patches "blessed" by installation/deinstallation/stability
  39. testing.
  40.  
  41. By all means, send your 50-60 patches to Nate or myself, or put them on
  42. ref.tfs.com, and we'll grab them!  I think the long delay in putting out
  43. new patches has beenlargely due to Nate and I being confused
  44. over who's going to integrate patches first.
  45.  
  46. >The idea of codrv was the avoidance of these "small, reliable patches".
  47. >Natural growth of software was rarely a good base of software development.
  48. >You might not need keyboard overloading, others might, you may require
  49. >bell and keyboard fixes, others do not, but they might want to have other
  50. >"bells and whistles". So how would you find an integration platform (I
  51. >guess you won't, or at least haven't thought about it yet)? Codrv is
  52. >a product for the future, not for current restricted requirements. This is
  53. >why it has been marked "incomplete".
  54.  
  55. This touches a sacred cow of mine, which is configuration.  There is
  56. absolutely no reason why you should not be able to pick one of several
  57. console drivers, several of many ethernet drivers, or one or more disk
  58. drivers from those available.
  59.  
  60. It should be possible to run "codrv" and still maintain the current
  61. patch level of pccons without effecting it adversely (or even using the
  62. pccons code at all if you don't want to.  SVR4 definitely has Berkeley
  63. beat in this area; at a minimum, the files.i386 file ought to be
  64. created from a set of specific "drop in" files to allow drop in (if not
  65. drop out) of new driver/file system modules.  Some of this is apparently
  66. being addressed in 0.2 from what I hear, but loadable modules don't go
  67. sufficiently far in this direction.
  68.  
  69. It's true that good software tends to be revolutionary instead of
  70. evolutionary (exceptions for BSD and vi 8-)), and there should be some
  71. kind of non-conflicting drop-in mechanism for new kernel subsystems
  72. (like codrv).  I'm not suggesting a "micro" kernel, but a layered
  73. approach couldn't hurt.  One thing I'd like to see is a binary command
  74. line configurator so that, unlike SVR4, we don't have to rebuild all
  75. of our "space.c" equivalents each time.
  76.  
  77. Another thing that would help is a packaging/versioning tool, such as is
  78. provided by SCO, and a logical break-up into "packages" (other than etc,
  79. bin, and src) for the software we normally see on 386BSD.
  80.  
  81. Meanwhile, keep posting/uploading/mailing/ftping patches until we (the
  82. users of 386BSD) can get something more permanent worked out.
  83.  
  84.  
  85.                     Terry Lambert
  86.                     terry@icarus.weber.edu
  87.                     terry_lambert@novell.com
  88. ---
  89. Any opinions in this posting are my own and not those of my present
  90. or previous employers.
  91. -- 
  92. -------------------------------------------------------------------------------
  93.                                         "I have an 8 user poetic license" - me
  94.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  95. -------------------------------------------------------------------------------
  96.