home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8603 < prev    next >
Encoding:
Text File  |  1992-08-19  |  4.8 KB  |  97 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!mercury.unt.edu!sol.acs.unt.edu!kenc
  3. From: kenc@sol.acs.unt.edu (Ken Corey - Operator)
  4. Subject: Re: Whining...I don't want to hack on the kernel
  5. Message-ID: <kenc.714229866@sol.acs.unt.edu>
  6. Sender: usenet@mercury.unt.edu (UNT USENet Adminstrator)
  7. Organization: University of North Texas
  8. References: <1992Aug18.011305.27223@access.usask.ca> <1992Aug18.212007.28991@unislc.uucp> <1992Aug19.063722.9778@nwnexus.WA.COM>
  9. Date: Wed, 19 Aug 1992 13:11:06 GMT
  10. Lines: 85
  11.  
  12. vince@halcyon.com (Vince Skahan) writes:
  13.  
  14. >[...semi-soapbox on...]
  15. >There *ARE* people who want to investigate Linux as an out-of-the-box
  16. >unix system that they can do stuff with, and who are quite willing 
  17. >(and grateful) to have somebody get their jollies by compiling all the 
  18. >sources and making a kit that they can use (to get their jollies by getting
  19. >their application(s) running, serving as real-world users and testers, etc.).
  20. >I guess it bugs me that the folks who want a stable o/s and compiler
  21. >that they can use to build (or port) software get pounded on in c.o.l.
  22. >as being 'beneath' the folks who are building functionality into the
  23. >kernel.  Both are equally valid users of the o/s.
  24.  
  25. This is *very* true!  There *are* equally valid, yet different users of
  26. Linux.  However, if you'll take a look at most of the pounding messages in a
  27. slightly different light, most of the pounding came when people wanted
  28. conflicting things:
  29.  
  30.  1) Stability for use in non-hacker projects.
  31.  2) The absolute most latest whiz-bang kernel/GCC
  32.  3) The once a week update to program xxxx.
  33.  
  34. It has been said many times that if you want stability, then find a version
  35. that does what you need it to do, and stick with it for a little while, and
  36. don't try to "keep up with the joneses" as far as versions go.
  37.  
  38. Yes, I'm following my own medicine.  I'm still using GCC 2.2.2b, and Linux
  39. .96pl4 (I think, been a while since I looked) because of the fragility of
  40. the ST01/02 support code right now.  I don't feel like hacking, and this
  41. kernel does what I need.  Great.  End of statement.  I won't upgrade for a
  42. while.  Why moan about not being "current"?  Because .a files won't easily
  43. compile?  Heck, they're not any more reliable than regular source code. 
  44. (see my next paragraph.)
  45.  
  46. >The guys who have built the various canned installable sets of goodies
  47. >such as mcc-interim, SLS, the 'rootimage' disk, etc. have done a great
  48. >job.  I'm willing to use the fruits of their labor (as a very grateful
  49. >user) and spend my limited time trying to port the stuff I want to
  50. >run, or to put all the pieces together as a system that does something
  51. >I want it to do. 
  52.  
  53. Yeah, this is a nice idea, but out of all the .a files I tried to download
  54. (probably 20 or so), I only got one to compile and link properly.  The rest
  55. didn't work, and I ended up getting the sources and recompiling from scratch
  56. myself.  I *know* things work that way.
  57.  
  58. >Building kernels is not necessarily great fun.  Once you do a few, it
  59. >gets kind'a boring doesn't it?  I think making patched compiled kernels
  60. >available to stick over the latest mcc-interim (or whatever) is a great
  61. >idea.
  62. >I don't *WANT* to be the local expert in all the obscure non-standard
  63. >gcc flags, just so I can build a darn program.  I want plug'n'play tools
  64. >that I can assemble (ie...mcc-interim+new_kernel+mailpak+perl) to get
  65. [...]
  66. >but I'm also very willing to use mailpak, etc. and say "thanks!!!".
  67.  
  68. Of course it's not fun.  However, with all the changes floating around,
  69. there's no way to guarantee compatibility for all the old library calls and
  70. whatever, SO, when a kernel is changed, or a GCC and its library is
  71. changed, it's gonna break things in other ways with stock releases like MCC. 
  72. Like it or not, if you're gonna use Linux, you're almost going to HAVE to do
  73. a little hacking to get your setup just the way you want.
  74.  
  75. Also, though kernel hacking is no fun, it's much more fun than setting up
  76. the "current" version of Linux, and recompiling ALL the utilities desired,
  77. and then uploading that, and then finally makeing it publicly available. 
  78. I know that for now, I've other things to waste time on...;)
  79.  
  80. >The fact that those folks did a great job doing their parts in no
  81. >way means that I'm less of a valid user for saying "thanks a million"
  82. [...]
  83. >man pages, etc.  They're just as important...
  84. >[...semi-soapbox off...]
  85.  
  86. Yeah, this is true.  Everyone is important.  The only problem is: who is
  87. going to provide the labor to make everything stable between versions
  88. (especially when those versions are coming out every week)? 
  89.  
  90. I *still* say, Stay a few releases behind the "cutting edge", and compile
  91. from sources, not .a files, and you'll be much happier.
  92. -- 
  93. Ken == kenc@sol.acs.unt.edu == kenc@vaxb.acs.unt.edu
  94.  Hurewitz's Memory Principle:
  95.      The chance of forgetting something is directly proportional
  96.      to ..... to ........ uh ..............
  97.