Date: Thu, 21 Nov 1996 13:46:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: sos@FreeBSD.org Cc: rkw@dataplex.net, hackers@FreeBSD.org Subject: Re: Who needs Perl? We do! Message-ID: <199611212046.NAA13887@phaeton.artisoft.com> In-Reply-To: <199611211714.SAA01528@ravenock.cybercity.dk> from "sos@FreeBSD.org" at Nov 21, 96 06:14:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to sos@FreeBSD.org who wrote: > In reply to Richard Wackerbarth who wrote: > > > > >Am I hearing a volounteer here ?? > > > or is there silence again this time ?? > > > > I suggest that you reconsider your (core) willingness to delegate. > > I AM doing some chores which, I assure you, some of the "customers" > > consider important. > > You are ?? > > > I HAVE volounteered to take on some things and been rebuffed in my > > efforts. > > Really, maybe what you wanted to do, wasn't what needed to be done ?? Actually, given your previous statement: | The reason I am picky about what goes in and what does not, is simply | that core is the entity that is going to get blamed/flamed/kicked when | things are not up to snuff. There is only so much we can have on | our platters, if things are not going to melt down. I (me personally) | think we have reached if not exceeded that limit allready, and getting | even more things into the game, be it small things or huge systems | need a _LOT_ of consideration. There is too much "damage control" and too little "consideration" taking place for an unbiased conclusion that what Richard volunteered to do "wasn't what needed to be done". > No, I'm not, core is big enough allready, but we need core to be more > of a governing/directionshowing entity, instead of a poor workhorse.. > Like it or not, there has to be rules (like in the real world out > there), and they should be followed. If we have X developers working > in Y different directions, we have lost the game. So if one want's > to participate, one has to follow the rules, simple as that... Be careful that in elevating the process to this level, you do not make the process into the product. Process is a tool, not a boundry... it seems to me that you are using it as a brake to thwart an increase in complexity, when in fact the complexity is an artifact of the process. If the process did not require single-threading through a non-reentrant "need a _LOT_ of consideration" mutex, I think you would get a much higher concurrency. The Linux process is an example of one with a higher concurrency, though I think it is also hitting its sociological and architectural limits. It just happens that Linux's limits are about 10 times further out than FreeBSD's because of their difference in process. Not that FreeBSD can elect a godlike Linus of their own, and get all the lieutenants to swear fealty to his vision... that's simply not an organization option because of the way organizations evolve. On the other hand, I can build a complex system, like a grandfather clock, put it in place, and with one motion cause it to operate. I don't need to replace my water clock one gear at a time, only using gears which fit the old water clock, thus limiting my ability to build the best grandfather clock I can build. There is something to be said for revolution instead of evolution when you are attempting to build an organization to use as a vehicle to get you to a goal. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611212046.NAA13887>