Date: Sun, 19 Jan 1997 14:59:00 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, dennis@etinc.com, hackers@freebsd.org Subject: Re: Commerical applications (was: Development and validation Message-ID: <199701192159.OAA14188@phaeton.artisoft.com> In-Reply-To: <7144.853657744@time.cdrom.com> from "Jordan K. Hubbard" at Jan 18, 97 11:09:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
One of my main talents is the ability to see order in apparently chatotic systems. But further, I see orders of order in these systems. This is what makes me a good systems engineer. This is also what allows me to ask *precisely* the most inconvenient question that can be asked in any given situation, since there is a great human tendency to favor the status quo. Let me put on my social systems engineering cap, and ask some questions about "FreeBSD the social organism". Let's look at the situation, the order of the situation, and the degree of the order of the situation. A nice physics analogy: Q = m mass Q' = m ds/dt momentum Q'' = 1/2 m (ds/dt)^2 kinetic energy I'll limit myself to asking order 0, 1, and 2 questions, and stay out of the more esoteric heights. [ ... task list ... ] > None of these 4 items are much in dispute, and you are raising "lack > of sufficient clued-in personnel to do the job" issues again, not much > else. AGREEMENT: The problem is lack of people. OBSERVATION: Other OS's have achieved these tasks. QUESTION: Why is it that the "sufficient clued-in personnel to do the job" were not lacking in their camps, but *are* lacking in the FreeBSD camp? QUESTION': What is it about the structure of the FreeBSD camp, itself, the abstracted variable, that promotes this? QUESTION'': What can be done to the structure of the FreeBSD camp, itself, to promote the generation and/or maintenance of increased levels of "sufficient clued-in personnel to do the job"? PROPOSED GOAL: Effect changes as a result of the answer(s) to the question. > John Polstra (now a core team member) has been working on ELF > for a few years now, and I haven't exactly seen a tremendous > outpouring of interest in his work - he's probably dropped it back on > his TODO list for lack of interest. AGREEMENT: There is a lack of interest in John's work having been exhibited by the FreeBSD camp. OBSERVATION: Other OS's have moved to ELF QUESTION: Why has the interest been missing in the FreeBSD camp, but not missing in other camps? QUESTION': What is it about the structure of the FreeBSD camp, itself, the abstracted variable, that promotes this? QUESTION'': What can be done to the structure of the FreeBSD camp, itself, to promote the generation and/or maintenance of increased levels of interest in moving to new, better technologies (including but not limited to ELF)? PROPOSED GOAL: Effect changes as a result of the answer(s) to the question. [ ... about ELF ... ] > Sometimes engineers will out-clever themselves in > their rush to the latest, shiny technology, and I think that a > premature move to ELF would have been a good example of this. Let's > fix some of our nastier bugs and give the users something to run > before we decide to break the world. Post-2.2 might be a good time. AGREEMENT: Premature adoption of a technology is a bad idea OBSERVATION: ELF technology is now mature (it works) QUESTION: Why is is that the adoption of ELF is categorized as premature, when it works? QUESTION': What is it about the structure of the FreeBSD camp, itself, the abstracted variable, that promotes the categorization of the proposed adoption as premature, despite the camps stated primary goal of research? QUESTION'': What can be done to the structure of the FreeBSD camp, itself, to promote the reduced conservatism required for the FreeBSD camp to better enable it to achieve it's stated primary goal of research? PROPOSED GOAL: Effect changes as a result of the answer(s) to the question. > The more-than-on-Intel issue was also a resource problem and, unlike > yourself, few of us have had non-Intel systems to even play with. I > know that I originally gravitated to the PC because it's the only > machine I could *afford*, and I've not been blessed with work > situations which netted me cheap/used workstation hardware as a > side-effect so that was basically it on the cross-platform issues for > me (and no, a pc532 port just wasn't *that* interesting :-) AGREEMENT: Hardware availability is the primary obstacle to multiplatform support OBSERVATION: The Linux camp has hardware donated by major vendors and other interested parties. So have the MACH, NetBSD, and OpenBSD camps. I have received personal email containing such offers, addressed to me, not to the camp. QUESTION: Why is hardware made available to the other camps, either in the form of corporate sponsorship for ports, or in the form of people who already have the hardware available volunteering their effort, but the same is not true for FreeBSD? QUESTION': What is it about the structure of the FreeBSD camp, itself, the abstracted variable, that prevents the same people from flocking to FreeBSD's door instead of Linux, MACH, NetBSD, and OpenBSD's doors? QUESTION'': What can be done to the structure of the FreeBSD camp, itself, to promote the participation of corporate sponsors and volunteers who already own the hardware? PROPOSED GOAL: Effect changes as a result of the answer(s) to the question. > > o Kernel multithreading/reentrancy changes > > Work. Someone needs to do it. AGREEMENT: Someone needs to simply do the work OBSERVATION: I submitted patches in June of 1994 which were in line with this goal, but a number of excuses were responsible for them not being integrated (incuding, it must be admitted, that kernel multithreading was not an overall project goal at the time, and people do not see issues of overall complexity the way I do, and so could not percieve the relationships). There are allegorically equivalent examples in other areas of FreeBSD, most notably, the build envirnment. QUESTION: Why is not "simply doing the work" not enough? QUESTION': What is it about the structure of the FreeBSD camp, itself, the abstracted variable, that imposes hidden conditions above and beyond those implied by the stated goals themselves? QUESTION'': What can be done to the structure of the FreeBSD camp, itself, to insure that all conditions are presented up front instead of hidden, such that "simply doing the work" becomes sufficient cause for inclusion of the work by the project? PROPOSED GOAL: Effect changes as a result of the answer(s) to the question. > > o More and more subsystems having architecturally bereft patches > > applied to them for reasons of expediency (make the problem > > submerge instead of fixing it). Question: how many of the > > This is a software engineering problem which you must *always* grapple > with, no matter how big you are or how many engineers you have. AGREEMENT: This is a problem which you must *always* grapple with OBSERVATION: This is a operational *process* problem, not a software engineering problem, so it is unlikely to be amenable to a software engineering soloution, but should certainly be attacked by considering operational process engineering. QUESTION: Why must the soloution to this problem require human intervention, instead of the being implicit in the definition of the process? QUESTION': What is it about the structure of the FreeBSD camp, itself, the abstracted variable, that prevents it from modifying its process to imply a soloution to this (and similar) problems? QUESTION'': What can be done to the structure of the FreeBSD camp, itself, to cause the process of meta-process itself to implicitly solve this class of problems, which are themselves implicitly soluable with process? PROPOSED GOAL: Effect changes as a result of the answer(s) to the question. > We're > in the middle of a growth period right now, and that means that we > have to put greater emphasis on solving user problems (even if it > sometimes requires an "expedient" type of solution) than we do on > pie-in-the-sky "just virtualize the frammitz and ensure that the > breemis doesn't cross interface boundries" types of proposals which > may be architecturally superior, but will also probably never be > implemented in time to save the user's neck. Do that about 10 times > and your users desert you with well-justified claims of "those losers > don't care about my problems, they just care about some weird hacker > asthetic." AGREEMENT: There are external forces which attempt to promote expediency for their own benefit, without regard to the consequences when measured against the stated goals of the overall project. OBSERVATION: A recent discussion with this same subject line revisited corporate modelling, with the prominant observation that short term expediency is adverse to long term success. In point of fact, inclusion of SVR3-style fixed address shared libraries was passed up *despite* pressures to expediency in the early phases of FreeBSD itself. QUESTION: How can FreeBSD get back to its less expedient roots to better insure long term viability for itself? QUESTION': What is it about the structure of the FreeBSD camp, itself, the abstracted variable, that allows it to be influenced by pressures to expediency, when it was not previously influenced by those same pressures? QUESTION'': What can be done to the structure of the FreeBSD camp, itself, to deemphasize the power of expediency in the overall decision-making process? PROPOSED GOAL: Effect changes as a result of the answer(s) to the question. [ ... ] You can supply your own complexity decomposition examples for the rest. 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?199701192159.OAA14188>