Date: Fri, 3 Nov 2000 11:04:40 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jkh@winston.osd.bsdi.com (Jordan Hubbard) Cc: ignacioc@avantel.net (Ignacio Cristerna), freebsd-advocacy@FreeBSD.ORG Subject: Installation: what to (not) do about it Message-ID: <200011031104.EAA11209@usr07.primenet.com> In-Reply-To: <1158.973215323@winston.osd.bsdi.com> from "Jordan Hubbard" at Nov 02, 2000 05:35:23 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> It wasn't an attack. You seem to have a hard time distinguishing > between hostility and pragmatism, my letter reflecting a 100% dose of > the latter and none at all of the former. I'm not out to quash > discussion, I'm trying to steer discussion into one of the areas it > has consistently failed to go in every single time this issue has come > up (and it's come up with almost stultifying regularity) - IMPLEMENTATION. What ever happened to that huge amount of installer code that The FreeBSD Project funded with that Russian(?) guy? Ist aht code anywhere to be used as a base, or is it all water under the bridge, and time to start from scratch again? For a long time, the FUD that there was going to be an installer that someone had been paid to write, kept people from spending their time on their own version, knowing that theirs would be thrown away in favor of the one the project paid for. > What needs to happen now is for someone, and let's say that someone is > you for the purpose of this argument, to actually sit down and > organize all these desired features into a set of more practical "this > is what we can reasonably accomplish" bullet points. Then for each > bullet, you need to write a first-draft implementation and throw it > out for general comment. Even when you don't get a lot of feedback in > return, you then need to have the perseverance to get through each of > the bullets and wrap it all up in the form of an ftp'able floppy image > (or images) which can actually be run and tested. This is actually a huge pain, when it comes to free software projects: the requirement of a huge, rather than a small, time commitment up front, with only a "maybe, but We Fear Change" to look forward to. In the real world, what happens is that someone comes up with a project proposal by expending a small to moderate amount of effort, and then gets buy-in before proceeding with expending a huge amount of effort, knowing that that huge amount of effort will not be wasted. This involves, first, a requirements document, and, second, a design document. In the process you describe above, the huge amount of effort must be expended up front, and then you risk not getting buy-in, unless you are willing to appease everyone who is standing in the way of your code being committed by tacking on their favorite wart at the last minute in an unplanned way. Then you end up with an unmaintainable mess, and people calling out "why, oh why, can't someone replace this thing?". With respect, sucessive iteration is not the way to arrive at a good product. Please excuse me; I am about to use the strongest language I have ever used in an email: --- Permission to quote this section out of context is DENIED THE PROGRAM "fetchmail" IS A PIECE OF UNPROFESSIONAL SHIT. I can, and did, write a superior proprietary replacement for it -- "cathedral style" -- in six weeks, four of which were spent on design. Further, I have so far had only 3 defects detected in the 28,000 lines of code in a year and a half, all of them one or two line errors, and all but one of them a typo. None were design errors. Eric Raymond should probably be castrated for irretrievably linking "Open Source" with a piece of code which, were it to be professionally reviewed, instead of addle-minded journalists just taking "The Cathedral and the Bazaar" at face value, the entire "Open Source" edifice could topple. If such an event were to occur, it would take the good code with the bad. He should be ashamed of having laid so precarious a foundation. The journalists who find the "Open Source Community" to be such darlings, without investigating whether or not the examples used by Raymond in making his claims holds water and supports his arguments, are accepting a Deux Ex Machina. They are either fearful of looking behind the curtain, i.e. not as brave as the little dog Toto, or they are simply incompetent and not worthy of putting a "Press" card in their hat bands. Neither of these is professional. --- Back to the discussion at hand... Sysinstall was recently taken to task in other threads for having poor human factors: o No universal navigation model o Inadequate POLA on disk layout management (e.g. percentages instead of blocks, a "hog" partition, etc.) o Inconsistant use of partition table and boot record code, leading to support problems (e.g. divide by zero errors in badly written BIOS, which, though arguably a BIOS error, will not be fixed by making that argument) o User experience not comparable to Windows (we should probably say "Windows Upgrade"; for a comparable experience to Windows itself, FreeBSD would have to do what Linux has done, and find a way to get on the "preinstalled OS" bandwagon) It is nearly impossible to maintain good human factors, if you are nailed to a cross which requires the addition of warts to a design not intended to support the functionality they represent. The reason for the buy-in process is to ensure against warts being necessary in the future: you map out the desired functionality, and you map out the expansion path which must be followed, and you map the entire problem space. You implement a framework that can solve the entrie problem space, and then you fill in the details in only those areas necesary for version 1.0. Subsequent versions only provide more fill-in: the skeleton remains intact and is not altered in unexpected ways. In the unlucky event that you find a compelling reason that will require changing the skeletal structure, you _reenter the design phase_ and design a skeleton that can accomodate both the old and the new. You use the fact of clean, abstract interfaces to allow you to reuse all of the muscle, skin, and internal organs _that are reasonable to reuse_, and you put the rest in a container labelled "medical waste", to be incinerated. > I have only one question: When can you get started? > > I also hope you're not going to respond that you lack the time or the > skill to do this since everybody says that and, as an answer, it's > gotten pretty old and weak. Pleasantly surprise us all instead by > answering my question with a proposed time-table why don't you. :-) Can the project guarantee a buy-in phase for a requirements document, then a design document, then an implementation, with a commitment that they will accept the design if it meets the negotiated requirements, and the final product, if it matches the design? In other words, if you want to have a professional-grade effort on this, I think you are going to need to commit to professional process -- and that means defining acceptance criteria on which the project guarantees it will not renig, so that any large effort expended will not end up to be wasted. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011031104.EAA11209>