Tech Insider					   Technology and Trends


			   USENET Archives

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

			   USENET Archives


The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or 
research.


Electronic mail:			      WorldWideWeb:
   tech-insider@outlook.com		         http://tech-insider.org/