From owner-freebsd-hackers Wed Apr 16 17:19:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA12764 for hackers-outgoing; Wed, 16 Apr 1997 17:19:50 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA12716 for ; Wed, 16 Apr 1997 17:19:47 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA28419; Wed, 16 Apr 1997 16:57:19 -0700 From: Terry Lambert Message-Id: <199704162357.QAA28419@phaeton.artisoft.com> Subject: Re: On Holy Wars, and a Plea for Peace [sorry Danny, wherever you are, but the title fits]... To: nate@mt.sri.com (Nate Williams) Date: Wed, 16 Apr 1997 16:57:18 -0700 (MST) Cc: terry@lambert.org, nate@mt.sri.com, freebsd-hackers@freebsd.org In-Reply-To: <199704162215.QAA09187@rocky.mt.sri.com> from "Nate Williams" at Apr 16, 97 04:15:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I supposed this semantic attack serves me right for attempting to be terse in my reponse in consideration of past requests by you, Jordan, et. al.. If this is the use to which you choose to put my attempted conformance to those requests... C'este la guerre. > > > > what implementable *process* do you propose? > ^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > Pot, kettle, black. > > > If this is in reference to something else, name it, and I will > > propose a process for it. It will probably be a reiteration of > ^^^^^^^^^ > > Note the difference. Very few of your 'processes' are implementable I might agree, with the caveat that it's not because of technical issues that the processes are unimplementable, and the claim that technical issues are the only issues which matter and everything else is horse puckey of the sort engaged in by pointy-haired bosses. Sidebar: This is called "AI" or "Artificial Importance", and has to do with people being "in the loop" for the gratification of being "in the loop" rather than out of technical necessity. It's a form of narcissism, and should not be tolerated, much less encouraged, and never *ever* rewarded. > or would solve the problems you propose to solve. That remains to be seen. In general, there is no question that they would solve the problems they propose to solve. The disagreement has been on whether or not what I think is a problem is acknowledged by others to actually be a problem. The FS stuff is a prime example: I want the changes so that I can do substantive work down there, and the people who aren't interested in working down there can't see why the way it is presents a barrier to me, since it doesn't present a barrier to them. Of course, they aren't working down there, so their opinions are technically suspect. It should be obvious to even a novice softwre engineer that using a functional interface to encapsulate the process of obtaining and freeing the path buffers would enable keeping a pool of path buffers that can be reused, avoiding the allocation/deallocation which has to occur on each and every path related system call. Can you say "useful performance improvement"? I knew you could. The changes should go in to enable that, even if you didn't give a shit about FS engineering issues, or the other uses to which I would put the reflexive properties of the changed interface. I find it repugnant that I have to state the blatantly obvious to justify organizational changes to code that you personally couldn't give a rats ass about, other than to ensure its continued function. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.