Date: Wed, 16 Apr 1997 16:57:18 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@mt.sri.com (Nate Williams) Cc: terry@lambert.org, nate@mt.sri.com, freebsd-hackers@freebsd.org Subject: Re: On Holy Wars, and a Plea for Peace [sorry Danny, wherever you are, but the title fits]... Message-ID: <199704162357.QAA28419@phaeton.artisoft.com> In-Reply-To: <199704162215.QAA09187@rocky.mt.sri.com> from "Nate Williams" at Apr 16, 97 04:15:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704162357.QAA28419>