Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail From: burgess@hrd769.brooks.af.mil (Dave Burgess) Newsgroups: comp.unix.bsd Subject: Re: [386BSD] Enhanced pccons w/source Date: 30 Nov 1992 10:56:07 -0600 Organization: Armstrong Lab MIS, Brooks AFB TX Lines: 54 Message-ID: <1fdh37INN63n@hrd769.brooks.af.mil> References: <4134@wzv.win.tue.nl> <VIXIE.92Nov29123446@cognition.pa.dec.com> <JKH.92Nov29233821@whisker.lotus.ie> NNTP-Posting-Host: hrd769.brooks.af.mil In article <JKH.92Nov29233821@whisker.lotus.ie> jkh@whisker.lotus.ie (Jordan K. Hubbard) writes: ] 386BSD has many fine hackers and many enthusiastic users. What it ] needs is a release engineer, who would free Bill up for the work that ] only he can do, and would keep multiple versions of the console driver ] ]I believe that's what Terry and Julian are trying to be, judging by ]what the patchkit and the /usr/packages directory on ref are trying ]to achieve. Do either of them want to argue with this? Wow, Configuration Management at it's best. Scary how these '70s concepts keep popping up to solve '90s problems :-). Just to further muddy the water, shouldn't we be using configuration control for only those features that actually impact the kernel? For example, the Vixie cron package is cool, and everyone should use it, but if I create a neat replacement that does everything vixie does, but in three bytes of tight assembler, should I be forced to coordinate this? It does not necessarily impact anyone else's work, and shouldn't prevent anyone from successfully installing anything. Of course, things that include kernel patches are a COMPLETELY different story. These competing console drivers both have advantages, and should probably be functionally combined. On the other hand, the shared library stuff provides a function that isn't currently available and (working from memory here) didn't require any kernel patches. My question then is whether or not something as functional as shared libraries (which doesn't impact the kernel) be controlled? Is there anywhere that says 'Mr. Jolitz didn't write it; therefore it can't be included?' Is there anything that has said 'This code is not compatible with the 0.2 design?' Has anyone actually said 'This is crap and should not be propogated?' Have any of the folks that are working on shared libraries actually LOOKED at the shared library code? What can be learned from the shared library code that may be of use to the NEW shared library code? Of course, these questions aren't really about shared libraries or the vixie cron. They are about the development attitude for 386bsd. If anyone is in a position to tell me what I should and should not do to this computer, then I suspect that the entire project is doomed to failure. It is not a matter of talent; there is quite enough talent to make anything we want to happen happen. It is the attitude. As people get stepped on in the name of 'that wasn't the way we were going to do it', they will leave, and become part of that 'release of the week' operating system. Once there, they will probably find a willing audience for their work, and become part of the movement. As people become alienated, they will leave in support of another development platform. It's a fact of business. I would be surprised to find anyone offer any enhancements to the shared library code now that so many people have spit on it. Damn shame too. These are opinions about the process, not necessarily the personalities involved. Please accept them as such. TSgt Dave Burgess NCOIC AL/MIS Brooks AFB, TX