Date: Thu, 8 May 2003 19:03:01 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Paul Richards <paul@freebsd-services.com> Cc: Dag-Erling Smorgrav <des@ofug.org> Subject: Re: `Hiding' libc symbols Message-ID: <20030509020301.GA2323@athlon.pn.xcllnt.net> In-Reply-To: <1052440952.619.59.camel@cf.freebsd-services.com> References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org> <20030508161223.GL1869@survey.codeburst.net> <xzpu1c5unx1.fsf@flood.ping.uio.no> <1052433233.619.27.camel@cf.freebsd-services.com> <20030508233431.GA1461@athlon.pn.xcllnt.net> <1052440952.619.59.camel@cf.freebsd-services.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 09, 2003 at 01:42:33AM +0100, Paul Richards wrote: > > Eliticism can have both a positive and negative connotation. In the > context I use it I mean it as a positive thing, where people who write > good code uphold high standards and encourage less experienced people to > grow in their ability. Amendable. I'm all for it... > The negative connotation is one of exclusion. Precisely. The promotion of good practice is not elitism, except where it results in the automatic rejection of (what is perceived to be) bad practice. > To get this back in context, we're talking about a decision where a) > FreeBSD gets hacked to accomodate bad programmers or b) we show up bad > coding practices where they exist in third party ports. I'd much prefer > to take the latter path and encourage quality code writing. Encouragement by way of having the "bad" application fail in some way or another is not encouragement. It's enforcement. In this case there is not even good and bad. People have written applications that work (one way or the other). If we suddenly don't like what people did, then we cannot label them bad. We are just as guilty for allowing it to work in the first place. All we can do is come to some compromise as to what we think is the way to go and reimplement libc in a way that reflect the compromise, taking into account all possible scenarios. Whatever we do, we cannot do it 5.x for it's probably an ABI breakage. We better implement it in libc.so.6 so that we have a version bump to prevent FUBAR. Hence, we have at least until 5.x becomes -stable to figure out what we want to do. Which leaves us enough time to address the issue with the detail and care it deserves, rather than to scratch the surface and kludge something for inclusion in 5.1. > If that > makes us eliticist then I'm happy with that and as long as we don't > exclude people who are willing to learn then that's not a bad approach > for the project. To quote Hamlet: To exclude or being excluded. What's the difference?... :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030509020301.GA2323>