Interview with Matt on bsdtalk about 1.6

[Bill Hacker]

Matthew Dillon wrote:

:On Thu, July 13, 2006 10:01 am, Dimitri Kovalov wrote:
:
:> I listen to this. Very interesting. I only challange one
:> thing. You say that 1.6 is more stable than FreeBSD 4.x.
:> How can you make this claim? FreeBSD 4.x is installed in
:> 1000s of servers and network devices for many years, and I
:> don't hear of anyone using Dragonfly for more than a
:> corporate server or firewall. So how can you claim such
:> stability before it is battle tested?
:
:Because a good number of the issues fixed date back to FreeBSD 4.x?
    Because I'm an optimist.  It's definitely more of a gut feeling then
    anything specific, from having used and worked on FreeBSD almost
    exclusively until I started the DragonFly project.
    In anycase, I really do think that DragonFly is now more stable then
    FreeBSD-4 ever was.  And, yes, a good chunk of the bugs that have been
    fixed, in particular to the buffer cache and softupdates, but also 
    issues with IPSEC, the tcp stack, and a few others, were all present
    in FreeBSD-4.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>


The volume, nature, and high level of competance of the *massive* code-clean-up 
that was the first big chunk of the DFLY project says it has to be at least 
partially true that *parts of* DFLY are superior to FreeBSD 4.X.

OTOH, subsequent progress toward DFLY's goals has led to never-ending need to 
alter all manner of things that arguably 'ain't broke' in their comparable 
position in the 4.X BSD world.

It might have been more accurate to have said that DragonFly *can be* more 
stable than 4.X BSD, as this seems to be highly dependent on what one chooses to 
use either of them for.

Arguably 4.X BSD or even 6.X BSD retain advantages in an 'all known 
possibilities' environment, if only w/r greater certainty that a larger number 
of ports, drivers, and CPU architectures work 'well enough' for production use.

Many of the items fixed in FreeBSD - legitimately in need of fixing or not, were 
simply not problematical at typical production stress levels.

The more curious point of your chat to me was that DragonFly - aimed at serious 
clustering, among other goals - is not yet concentrating on the AMD-64/enhanced 
Intel features.

Given where dualcore hardware, energy/heat loads, and costs seem to be heading, 
IMHO one could do worse than to drop all else and focus *exclusively* on those.

Bill