home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / linux / 22957 < prev    next >
Encoding:
Text File  |  1993-01-06  |  2.2 KB  |  47 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!destroyer!cs.ubc.ca!news.UVic.CA!sanjuan!pmacdona
  3. From: pmacdona@sanjuan (Peter MacDonald)
  4. Subject: Re: 386 BSD
  5. Message-ID: <1993Jan6.204304.8580@sol.UVic.CA>
  6. Sender: news@sol.UVic.CA
  7. Nntp-Posting-Host: sanjuan.uvic.ca
  8. Organization: University of Victoria, Victoria B.C. CANADA
  9. References: <C0F8L6.AB4@ux1.cso.uiuc.edu> <1993Jan6.085905.25749@klaava.Helsinki.FI> <1993Jan6.175208.11119@sfu.ca>
  10. Date: Wed, 6 Jan 93 20:43:04 GMT
  11. Lines: 34
  12.  
  13. In article <1993Jan6.175208.11119@sfu.ca> rchen@fraser.sfu.ca (Robert Chen) writes:
  14. >In article <1993Jan6.085905.25749@klaava.Helsinki.FI> lukka@klaava.Helsinki.FI (Tuomas J Lukka) writes:
  15. >>In article <C0F8L6.AB4@ux1.cso.uiuc.edu> Jeff-Randall@uiuc.edu (Jeff Randall) writes:
  16. ...
  17. >>No, not yet. They're in the works, by a mailing list on ref.tfs.com,
  18. >>386bsd-sharedlibs. The implementation is going to be rather high-tech
  19. >>(non-kludged). The current linux shared libraries do their job but
  20. >
  21. >Non-kludged?  I doubt that those on the GCC channel would agree with
  22. >your implication about the *working* linux shared library implementation.
  23.  
  24. Not to perpetuate a flame war, but let me point out something.  Every
  25. so often, the current Linux shared libs are bashed by the puritans
  26. because it is not plug and play for the library builders to
  27. generate the shared libs (and also that they sit at a fixed
  28. address).  
  29.  
  30. Assuming that the fixed location is not a major hardship at this point,
  31. (what, only 1.5 Gig per process, outrageous), the fact that library
  32. builders have to work harder than an elegant solution would require,
  33. shoudn't be an issue: lib builders are only a small fraction of the
  34. user base, lets say 5%.  Is an elegant solution that penalizes 95% of
  35. the users, with say a 30% penalty, to save 5% of the users some work,
  36. a good idea?
  37.  
  38. I do not wish to dispute the above figures.  I am rather just
  39. stepping back and looking at the bigger picture.  If an elegant
  40. and practical solution is demonstrated, I will be the first to
  41. jump on the bandwagon.  But being set back a month to collect
  42. and recompile all of the system again won't make me to happy
  43. either.  Hopefully, the new and old schemes (if a new one appears)
  44. will coexist, at least for a while.
  45.  
  46. Peter
  47.