Path: sparky!uunet!dtix!darwin.sura.net!jvnc.net!nuscc!ntuix!eoahmad From: eoah...@ntuix.ntu.ac.sg (Othman Ahmad) Newsgroups: comp.unix.bsd Subject: Honesty with 386BSD 0.1 Message-ID: <1992Jun24.025455.3548@ntuix.ntu.ac.sg> Date: 24 Jun 92 02:54:55 GMT Organization: Nanyang Technological University - Singapore Lines: 107 This posting is meant for William Jolitz or anyone intimately involved with beta testing 0.1 386BSD. First I would like to apologize if I may make any uncalled for remarks. My intention is to gather discussion on the best methods of releasing new versions. This problem occurs even in commercial packages which are distributed in binary form. 386BSD creates more opportunities (problems) because it is also distributed in source form. Maybe a more honest admission is that I am under stress waiting for something. Stress is not bad for our health. It is just that without a debugger I feel helpless. The debugging time would be more if I simply use printf statements. I dare not embark on a major project without having a debugger. Although I have other options like MSDOS which has even better debuggers(user friendly), I prefer to stick to a more lasting standard (BSD Unix!). I think the intention of William Jolitz is to release 0.1 only when there are almost no obvious bugs. As my colleague says 90% of time in software development is in the last 10% of the code. This is nobel but faulty in the point of view of marketing success. Let me state my opinions first: 1)we can release a product even if there are problems with it. 2)we must set a deadline for the release of a product(firm and honest) 3)the best way to get feedback about a product is from customers/users 4)we must announce new products/improvements frequently I think the Japanese apply all 4 methods. Some companies just apply a subset of the above method. Let me explain in context with 386BSD. 1) Let us face the fact that a product is never perfect. Even in an unlikely scenerio that all bugs are fixed, there are still urges to incorporate new features. Customers also tend to expect that anything new will create new problems. Some companies think that a get an almost perfect product to market is the ultimate aim but it does not ensure a success. Case of MSDOS. Everyone knows that MSDOS 1.0 was too buggy and inadequate and yet it was released by IBM. At least MSDOS 1.0 allows basic programs to run, such as Wordstar, Dbase II etc, at least for the majority of users. 2) If we accept 1, then it would be easy to accept 2. Honesty is very important. Unkept promises creates problems to customers because it upsets their plans. If Microsoft does not release MSDOS 1.0 at the same time as IBM PC XT, the IBM would suffer a lot of losses. The danger is that the product could be dangerous. But all software come with disclaimers. Hardware products must look out for safety portions. The structure design must be solid but it is easy to test it, just subject it to stresses just as crashing the car e.g. For software , just run a typical application. I think for an operating system, the ability to compile a C compiler e.g. is the safety portion. For 386BSD, it is less critical because it is free and comes with sources. It does not have any commitment at all. However DDJ magazine published an article that 386BSD would be released in July without any date though. Who knows 0.1 would be release now. Howeve this article still needs discussion especially for future releases. 3) No matter how much tests we have carried out, we would never know which is more important. The customers may be even better than the original designers in putting the product to good use, bugs or no bugs. In fact few customers trust manufacturers specs 100%. They tend to bend it to suit their needs. In the case of 386BSD, the designer may think that some bugs must be cleared before release but a lot of customers may not bother at all because it does not affect their operations. The customers may even offer their own bug fixes. This occurs even in hardware products. Customers regularly request changes to design to correct flaws because the customers are experts in their specialised areas. In 386BSD, William may be expert in porting designs but he may not be good in debugging support(just an example). Some users are even better than Bill in this area. He may as well learn from him. If 386BSD is not released, how would the customer correct it? 4) Everyone knows that new versions are inevitable. But the success of an enterprise depends on the frequency of this versions. Just look at the Leyland Mini. It is the longes lasting model in the world because probably the design is perfect, but it does not make as much money as a toyota corolla that has changed faces so much. In fact toyota corolla changes face every six months. The same with their video recorders. The frequency depends on the product. For 386BSD I recommend every month. Just throw out the old versions if there is not enough space. If the bug fixes which comes cannot be incorporated in that particular month, just release whatever fixes that had been incorporated. If new features are added and yet not fully functional, just include it, because the customers may contribute in correcting it. I think there is not much problem in copying files to agate.berkeley. There may be valid reasons for delaying the release of new versions of 386BSD which I am not aware like politics but I think by letting out the problems, the customers may contribute towards helping it. For example, if UCB refuces disk space someone else can take over and look for someone who can take over. If UCB refuces to release more codes, customers can lobby UCB into doing so. I hope this article would generate discussions or more new ideas. I dont mind being flamed as long as the reasons are correct and sources of facts pointed out clearly to me so that I can double check. Othman bin Ahmad, School of EEE, Nanyang Technological University, Singapore 2263. Internet Email: eoah...@ntuix.ntu.ac.sg Bitnet Email: eoah...@ntuvax.bitnet
Path: sparky!uunet!elroy.jpl.nasa.gov!ames!agate!soda.berkeley.edu!wjolitz From: wjol...@soda.berkeley.edu (William F. Jolitz) Newsgroups: comp.unix.bsd Subject: Re: Honesty with 386BSD 0.1 Date: 24 Jun 1992 18:02:50 GMT Organization: University of California, Berkeley Lines: 102 Sender: Lynne Jolitz (ljol...@cardio.ucsf.edu) Message-ID: <12adcaINNiuc@agate.berkeley.edu> References: <1992Jun24.025455.3548@ntuix.ntu.ac.sg> NNTP-Posting-Host: soda.berkeley.edu Summary: Release 0.1 and Perspective on 386BSD. Keywords: 386BSD 0.1 Lynne Jolitz responds to article 1964 regarding Mr. Ahmads "open letter" to William Jolitz and the 0.1 beta testers: ------------------------------------------------------------------------- Dear Mr. Ahmads (and all the 386BSD Users), Firstly, I urge anyone concerned about the status of 0.1 or any other items that I can answer please send email to me directly, instead of plastering it all over netnews. I do try to respond to email appropriately. However, I will respond this way, if so demanded. Please, though, anyone who is interested in discussing 386BSD can always send me email at ljol...@cardio.ucsf.edu, as mentioned in the reg file and read.me file of 0.0. I have also supplied my fax number, if that is more convenient. It helps also if you register so I know who you are, as we are quite inundated, and I spend several hours a day now on 386BSD mail alone. Release 0.1 is in beta test right now at several sites. We hope to have it out very shortly. We are doing the best we can, given the circumstances. I think it is time to put some things regarding 386BSD in perspective. For the last 7 months Bill and I have dedicated our entire full-time personal resources (which means we don't have a company or granting agency) to getting these releases out the door. Bill and I are not a university, non-profit organization, or commercial company, nor have we ever claimed to be. We are just two people using a few borrowed PCs and a laptop and essentially doing the impossible -- putting together a complete 100+ MB source release with binary and installation floppy, documenting, debugging, and enhancing it, completing the release engineering and asking nothing for it, except the goodwill of other volunteers. We had always intended CSRG to handle this, which is why we worked for three years and contributed for no consideration the port to UCB (of which I am an alumna) -- however, when they decided to take it private, we found the only way we could counter this aberrant situation was to complete the system ourselves and release it as should have been done by CSRG years ago. There have been a lot of great people who have volunteered their time to work on this system since release 0.0 (which Bill had to do entirely himself). They have contributed fixes, tested software, and generally worked on pieces of the puzzle. However, it has ultimately come down to one man who has had the vision to see this through to completion. Bill has worked on BSD releases for over 12 years, and he is trying to continue the technical direction of Berkeley UNIX, so that if anyone uses this system, IT WILL BE BERKELEY UNIX, and not some motley or proprietary substitute. He will accomplish this, not on the basis of arrogance, as others often do, but with a firm understanding of what must be done. While he is both brilliant and determined, this project is not easy or trivial. Most people get overwhelmed at the sheer size and complexity. He is not daunted. He will quietly continue and complete each task, enduring the slings and arrows flung by others. After all, the final victory is realized by accomplishing a goal, not just by talking about it. I can empathize with the frustration expressed from 386BSD users. Everyone would like more -- better and faster. However, it may be instructive to try to see it from the other side. So I ask each of you to honestly search your conscience and ask the following question: Would you honestly be willing to put everything you personally have, sacrificing your own personal gain, time with your children, even a normal life, to keep to a commitment and vision without any real expectation of gain? Would you do this over an extended period of time, just because it is the "right thing to do"? And finally, would you continue to put your own resources into this project, knowing that others are looking to you to supply the leadership and vision required, but also knowing that there are many other things you could be doing in the small time alloted in a lifetime? This is where 386BSD and Berkeley UNIX now stand. There are many dedicated and bright people out there who need to focus on their particular area of expertise, not plan for where 386BSD should head. That is the responsibility of the developer. So using 386BSD does have it's price. For us, for all the users, for the larger community. Nothing is free. In this case, it requires cooperation, teamwork, respect, support, time and consideration -- all of which can be avoided by giving USL (AT&T) money for a commercial system. As to commercial comparisions, I find them inappropriate. I ran a systems company for many years, and, quite frankly, no one gets the turnaround on release times from a paid effort that is now demanded from an unfunded effort. Expressions of frustration in this manner are unrealistic and counterproductive. As I look on the list of contributors which will appear with Release 0.1, I can only say that I am grateful that so many have been willing to give something to make things better. We're all working on this together, so we must show a little patience, generosity, and respect to each other. After all, genius is not a commodity, and 386BSD is not an entitlement. Both are hard-earned and sweeter for it. Lynne Jolitz. ljol...@cardio.ucsf.edu