Linked by Thom Holwerda on Tue 30th Jan 2007 21:36 UTC, submitted by David Dengg
BSD and Darwin derivatives DragonFly 1.8.0 has been released. The biggest kernel change in this release is the addition of virtual kernel support and a virtual kernel build target. The biggest user-visible changes include updates to third party applications included in the base system, a major rewrite of NULLFS which removes all directory recursion restrictions from mount_null and removes nearly all the kernel resource overhead when using such mounts, and a multi-ip feature for jails.
Permalink for comment 207609
To read all comments associated with this story, please click here.
Don T. Bothers
Member since:

"so matt was right all along about freebsd 5.x. I like DF because it's based of freebsd 4.8., i have been a huge fan of freebsd's 4.x, but now that freebsd 4.11 is about to be retired, i might switch over to df 1.8.x. and add df along the other os i run."

From my understanding of the situation, the answer to whether Matt was right or wrong is yes and no and quite a bit more complex than that. ;)

Theoretically speaking, the FreeBSD project chose the correct solution but ran into several major problems. 1) It is extremely difficult to implement, the code becomes extremely bloated, and there just isn't enough resources to maintain it. 2) There is little to no application that could take advantage of the advanced threading model. From what I understood of what I read, FreeBSD was basically implementing a very complex M:N scheduler where all the applications were treating things as M=N=1. So in almost all cases, a native 1:1 threading model scaled much better because it did not have any overhead. 3) In the spirit of biting more than you can chew, the FreeBSD team decided to also implement some kind of fair queue scheme for processes. However, the fair queue code was a place holder waiting for someone to properly implement it. This place holder code had the nice benefit of slowing things to a crawl while causing all sorts of instabilities. A lot of these problems have been fixed for FreeBSD 7.

In addition, it is very hard to fault the FreeBSD team for making the decision to which way to go. What Matt wanted to do is rather revolutionary and is rather risky for a product lots of companies use for production purposes. While there is the potential of a huge payoff, there is a certain amount of risk involved with it. The FreeBSD project would be rather self-centered and careless to try such a revolutionary path without some alternate "safe" path to fall back to if it fails. In a way, the way Solaris, HPUX, AIX, and Linux chose to scale was the only safe and reasonable choice for such a large project.

What happened was probably the best thing for both projects and for BSD in general. Now, the FreeBSD project is free to provide a safe, proven path for scalability, performance, and stability for companies dependent on it while Matt is free to explore an alternative path that might prove to be superior.

Edited 2007-01-31 04:19

Reply Parent Score: 5