4.x era

[Brett Glass]

At 08:05 PM 9/25/2011, Greg 'groggy' Lehey wrote:

>As you (Brett) should have known, the reason we did that was because
>of the enormous upheaval that 5.x represented.  And we knew in advance
>that we'd have problems with 5.x as a result.

Yes; because I was developing products based on it at the time, I attended
and spoke at!) several BSD conventions during that period. I was concerned
about the architectural upheaval. Too many radical changes were being
undertaken at once, and that way lies instability. I never deployed
a single 5.x machine in production, and had some lingering problems with
6.0 and 6.1.

Now, FreeBSD is moving to 9.x before some of the glitches in 8.x are
fully worked out. (There are serious bugs in 8.2-RELEASE that have forced
me to move some production machines up to a snapshot of 8-STABLE.) I'm a
bit worried about that.

>We had already recognized the folly of keeping the same release too long
>with 2.x.

It isn't the number, per se, it's the quality. After 12 releases, 4.x was
hard to beat. Still is. If the core team had focused on modifying one thing
at a time, so that 5.x had incorporated fewer and less radical changes, that
stability could have been carried forward. FreeBSD lost momentum
relative to Linux because it didn't take that route. It also had trouble
because, rather than looking forward to next generation SMP concepts, it
looked backward toward BSDi's scheme.

>Do you find 8.x less stable?

See above. 8.x might be really good quality by 8.4 or 8.5, but chances are
that 8.3 will be the last release on that branch.

>But if you want 4.x again, take a look
>at DragonFly.  That grew out of Matt Dillon's disagreement with the
>direction we took for 5.x (and thus all subsequent FreeBSD releases).

Dragonfly took an approach which, IMHO, scales better to large numbers of
CPUs than FreeBSD's current architecture. It's a lot like QNX, with which
I also worked during the 90s: messaging, loose coupling between CPUs,
and a strong emphasis on nonblocking IPC. Other OSes are coming around to
that approach as multicore systems proliferate.

Alas, Dragonfly as a project has a different problem. They have fewer
developers, and so do not have the manpower to polish and polish every bit
of the code.

In any event, if I had my wish, I'd like to see development on 8.x extended
to 8.6 or 8.7, with the best changes (e.g. softupdates with journaling)
carefully backported from 9.x.

--Brett Glass