Date: Thu, 21 Jul 2005 15:17:20 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: MikeM <the.lists@mgm51.com> Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD Message-ID: <20050721150925.K97888@fledge.watson.org> In-Reply-To: <200507211002580001.03E5249D@sentry.24cl.com> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> <200507210850530519.03A3275D@sentry.24cl.com> <20050721135839.K97888@fledge.watson.org> <200507211002580001.03E5249D@sentry.24cl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050721150925.K97888>