Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uwm.edu!daffy!uwvax!oka.cs.wisc.edu!jcargill From: jcargill@oka.cs.wisc.edu (Jon Cargille) Subject: Re: SHARED LIBRARIES - THE END Message-ID: <1993May28.143810.7609@cs.wisc.edu> Sender: news@cs.wisc.edu (The News) Organization: Univ. of Wisconsin CS Dept References: <PC123.93May22195506@bootes.cus.cam.ac.uk> <1993May23.003623.24102@fcom.cc.utah.edu> <1tr05o$qaa@terminator.rs.itd.umich.edu> <1993May24.225014.23425@fcom.cc.utah.edu> Date: Fri, 28 May 1993 14:38:10 GMT Lines: 65 In article <1993May24.225014.23425@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: > >Pete's code is about to be dubbed "official" in Bill's 0.2 release. I >think it's a good interim soloution (hell, I'm using it!), but it seems >to me that it will be extermely difficult to displace it once it becomes >part of a distribution. Pete's code will be the defacto standard because >of it's release as part of the base release. > I guess I don't see the problem you're trying to illustrate here, Terry. I agree that Pete's code would become the defacto standard, at least for the time being. However, should a version of shared libs "done right" become available, I don't see any reason why it couldn't be dropped as a replacement in the next release. There would, of course, be problems if some folks decided to move to it sooner than the next major release. Then no one would know which type of libraries to distribute (with packages like X, for example), and everyone might have to distribute both kinds. >There is an implicit assumption that Pete and I were aware of each other's >work, or that Pete was part of the working group discussions on ref, or >that we don't both have a million things going at once. > I agree that there is definitely a need for tighter communication in the 386bsd community, especially where major subsystems such as shared libs are concerned. >I think as long as no implementation was "dubbed", then there wasn't a >problem; it's certainly wrong to criticize Pete for the code he has >provided, or to criticize the approach taken i the code (Joerg's approach); >but it's right to criticize the cannonization of that code by Bill, since >the code is useful for a user, but restricts the direction that future >developement can take. It is in conflict with the stated goals of 386BSD >to include the code. > If no implementation is "dubbed", and none is distributed with 0.2, there won't be enough of an installed base to encourage library providers to distribute shared libraries at all! I think it is a good thing for there to be an "official" version of shared libraries, even if it's something temporary which will be replaced in the future I don't see that distribution has to be equivalent to "canonization". >If the issue were to be resolved without cannonizing one approach in the >research platform until after the research is done, then I wouldn't have >a problem. I dislike the pressures that are forcing Bill into the >decision to support one approach over another *on any issue* while there >is still research taking place. I view the official 386BSD releases as >codifying one piece of research over another; as far as shared libraries >are concerned, this shouldn't be done yet. I don't see why distribution of one version has to serve as an indication that it is the correct long-term solution. Am I missing something here? Jon -- -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. Jon Cargille jcargill@cs.wisc.edu Want your .sig compressed? Reasonable rates and fast turnaround. Call today!