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 _______________________________________________ freebsd-chat@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-chat To unsubscribe, send any mail to "freebsd-chat-unsubscr...@freebsd.org"