Quality of FreeBSD

[Robert Watson]

On Thu, 21 Jul 2005, MikeM wrote:

> Thank you for the clear answer.  For the record, I am very pleased with 
> the overall quality of FreeBSD, my comments were only meant in the sense 
> of "everything has room for improvement", even something as excellent as 
> FreeBSD.

I think everyone agrees there's room for improvement -- many FreeBSD 
developers come to work on FreeBSD because they are enjoy writing software 
and are dissatisfied with what they find in the commercial world. 
However, I've found most problems in the FreeBSD development process stem 
from a lack of resources to implement the best processes, rather than 
processes being wrong "by design".  I.e., there being a strong interest in 
producing tested code, but inadequate resources to provide the thorough 
testing we'd like.  Or, the best of intentions (a company agrees to 
support development of a feature, starts work, and then goes out of 
business) preventing follow-through.  As has already been mentioned we're 
intentionally going for a much less agressive 6.x feature set in order to 
refine some of the hard architectural work in 5.x, and to avoid 
over-committing resources.  One of the biggest problems with the SMP work 
in 5.x was the dot.com crash: companies that had committed resources to 
manage and develop on the project ceased to be available.

> I snipped out one section of your reply because it illustrates a main 
> point of my message.
>
> While it is good to have the testing in place to catch race conditions, 
> has anyone done a post mortem to determine why and/or how the race 
> conditions got into the code in the first place?  *Someone* coded that 
> race condition.  Was it that two developers were using the same data 
> structure without one knowing about the other?  If so, then there's a 
> problem that needs to be fixed.  Chances are, though, that wasn't the 
> problem.  Only the developers would be able to look at the development 
> process and determine why the process allowed a race condition to occur 
> in the code.  But if they took the time to do this, then the knowledge 
> gained would be useful across a wide swath of FreeBSD development.

There's some information, FYI, on the netperf cluster:

     http://www.freebsd.org/projects/netperf/cluster.html

It needs a bit more updating for recent hardware additions, courtesy 
Sentex.

With respect to the network stack changes -- yes.  And in some cases, the 
areas of problems were actually marked with comments indicating they were 
known, but not easily resolvable (or not thought to be bugs that were 
exercised in practice).  In other cases, they were due to the 
mis-understanding of code in the stack, or the fact that data structures 
or code were not originally designed with parallelism in mind, and the 
communal discovery of unexpected or undocumented complexity.  A 
significant part of 5.x and 6.x work has been fixing existing 
architectural problems present for decades, but that suddenly become more 
relevant as the kernel supports SMP and threading better.

In several cases, they were bugs already present in FreeBSD 4.x, but only 
exercisable under extremely high memory load.  Something you'll find in 
later 5.x versions is a much greater use of locking assertions than in 
earlier versions.


> Thank you for your offer of allowing me to contribute to the FreeBSD 
> project, however I have professional obligations that prevent me from 
> making the necessary commitment to the project.  For the most part I 
> just lurk here, popping my head up on occasion.  In doing so, it is not 
> my intent to to snipe at anyone or carp at anything.  As such, I'll let 
> this sub-thread die out at this point....

If only the realities of paid work didn't intervene so frequently -- 
sadly, I'm only too familiar with that problem :-).

Robert N M Watson