FreeBSD Documentation: An Interview with Tom Rhodes

An Anonymous Coward writes "FreeBSD has been known for excellent documentation and here is a rare sneak peak behind the scenes of the FreeBSD document project with FreeBSD's very own Tom Rhodes."

Comments

Re:Tom Rhodes

[Anonymous Coward]

Please ignore this troll. It's the same guy who has been pestering every *bsd (yes, even NetBSD) announcments trying to discredit FreeBSD developers. He usually goes on to say just how FreeBSD devs hate Dragonfly, how they unfairly kicked out Matt, and so on.

Sometimes he links to a message posted by DES on FreeBSD-advocacy in his signiture. If you take the time to see how that thread started, you'll see that the original "quesiont" was quite rude, and follow-up messages from the same person were written in a "I'm a famili member of the former Nigerian royal familiy and want to deposit large sums of money" style. Also if, you follow the thread further, you'll see this reply from a FreeBSD developer:

> BTW, I've spent a lot of time looking at the DragonFly approach, and I met
> with Matt for quite a while at USENIX to talk to him about the approach. I
> have a number of concerns about it -- I think the premise is very
> interesting, but that the results aren't yet there to prove the model. In
> particular, there's a huge volume of code in their system that has not
> been addressed, and a lot of complexity that will need to be handled
> before the SMP primitives they're using have proven that they offer the
> desired performance advantage. We have the opportunity of using a hybrid
> model, and have been exploring some of the ideas present in DFBSD (and,
> one should point out, many other SMP systems).
>
> A lot of other systems have opted to use elements similar to those
> primitives, but in a much more limited way due to the performance costs.
> For example, locking services into particular CPUs prevents the scheduler
> from balancing load between the CPUs in an service-transparent way. In
> the DFBSD model, load balancing must be implemented separately for each
> service, requiring extensive modifications to the services. I.e., the
> model may indeed offer benefits, but the cost of doing the work will be
> high, and the time to complete it long. We'll adopt elements of the
> design as they prove to make sense, as we do with all other open source
> operating systems (and they do with us!).

For your interest, Matt still posts occasionally to -current list, in fact, he even helps out a bit here and there. This troll's problem seems to be with DES, PHK, Bosko, but he is ready to extend his warm words towards anyone, even, it seems, to someone associated with the documentation project. Oh, btw: you'll see the same message by Doug-Furlong Smorgreff on Osnews as well. ~molnarcs