BSDForums reports that the FreeBSD Release Engineering Team has posted the schedule for the Release of FreeBSD 5.1 late spring. FreeBSD roadmap, posted earlier at BSDForums.org, outlines the future of FreeBSD-5 stable releases, specifically 5.1 and 5.2. Also, Maksim Yevmenkin has announced another set of updates to Bluetooth stack for FreeBSD. He has made many code fixes, added new firmware driver support for Broadcom BCM2033 based devices, updated man pages and more. The Bluetooth stack is developed only for the 5-CURRENT branch. OSNews featured an in-depth interview with the FreeBSD Core team a few days ago discussing the 5.x branch among other topics.
FreeBSD 5.1 Release Schedule; Bluetooth Stack Update
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Personally I think that the gap between 5.1 and 5.2 is insufficient to finish off the KSE and libpthreads. Unless those two are finished then the whole purpose of developing 5.x in the first place is lost. If it were be in charge I would move 5.2 release to around November-December so that the core components are finished. Things like SMP can be gradually completed through the 5.x series.
I’m sorry, it appears I’ve been very wrong with regards to Giant’s presence in the various kernel subsystems. Reading that page long list of subsystems from which Giant is yet to be removed drove a steak through my heart. This is looking bad for FreeBSD in regards to SMP performance for at least the next kernel generation, possibly what the Linux 2.2 developers were looking at several years ago.
I’ve loved everything I’ve read about the new locking design, which is much more elaborate and refined than Linux’s current situation (with locks haphazardly inserted as development work towards removing the Big Kernel Lock progressed) However they are looking at at least another few years of development before they can even think about eliminating the Giant lock from the kernel, and until this happens the beauty of the SMPng locking design will never be realized.
Meanwhile, where will Linux go? By then it will have a next generation VMM and will hopefully have ironed the kinks out of its O(1) scheduler (which seems to be having horrible stalling problems at the present time) and will have undergone regression testing on a variety of platforms, including big iron. It will have a wonderful, scalable threading implementation that uses scheduler activations (well, it does already in RedHat 9, with a lot of bugs manifesting themselves in userspace applications) I’m afraid Linux has permanently relegated FreeBSD to its position as “a secondary choice for backoffice system administrators.”
I hate to sound so critical of FreeBSD… I think anyone who reads and posts on these comments regularly will know me, specifically my position regarding FreeBSD. But that’s just the way I see it.
Linux has many small kinks to work out, some of which I’ve already mentioned. But FreeBSD has significant development work yet to go before it can reach where Linux is at the present time. Certainly it’s a much more refined design, but in terms of its overall goals the development work still remains largely incomplete, and consequently it can only play catch-up to Linux at this point.
Personally I think that the gap between 5.1 and 5.2 is insufficient to finish off the KSE and libpthreads. Unless those two are finished then the whole purpose of developing 5.x in the first place is lost.
Yes, using 5.0-RELEASE now is like taking a trip into a National Park that just opened, but taking it on a dirt road. As you drive you can stare at the magnificent highway they’re constructing, and the majestic bridge it will cross… when they complete it in 2 years, but meanwhile you’re putzing along on the dirt road wondering why you didn’t just go to a better National Park…
I am not really concerned as in the next month or two I am moving to getting an Apple eMac. FreeBSD had it chance in my books. Instead of fixing up the issues they stuffed around blaming the slow progress on “economic issues” and not actually implementing the things that actually matter, namely, KSE, libpthreads and SMP.
Even though the results of 5.1 might not be as good as some would like them too, it doesn’t mean there is no hope.
From what has been witnessed, at least in comments here, more people are moving to BSD (especially FreeBSD) from other platforms and the community is growing. With that said I think we can expect more devpower than before and that might speed things up if we’re lucky.
Let’s say that during 2003 the userbase of FreeBSD will grow maybe 25%, which is indeed a lot… what consequences might this have when these new people go from getting knowledge of the system –> enhancing the system???
Hopefully something good will come out of this =)
when it comes to the stuff you guys were mentioning.
but i have a few questions:
if freebsd’s smp efficiency is not so great, how does apple’s os-x rate?
does it have similar issues? is this where osx and freebsd part company?
can apple help freebsd in this area?
thanks for any insight.
OSX uses the mach kernel, so it doesn’t share this issue
if freebsd’s smp efficiency is not so great, how does apple’s os-x rate?
That’s an interesting question. OSX uses the Mach kernel (in it’s monolithic guise) so SMP performance should be quite good (although the in-kernel BSD server might be a significant bottleneck). It’s impossible to actually demonstrate this though as there are no >2 processor OSX machines available.
in regards to BSD and Mach, yes, Mach does have a *BSD personality, however, that is where the simularity ends. IIRC, the original Mach was based on BSD (Not freebsd) 3.2, however, the latest is based on BSD 4.4 which is what FreeBSD is based upon, however, there are differences between MacOS X and FreeBSD.
er, yes, I’m aware of that.
However, a lot of software, especially ported server apps, makes use of functionality provided by the in-kernel BSD server. Hence the bottleneck comment.
BSD still has a lot of things going for it, even if KSE and pthreads aren’t fully implemented for another 2 years.
First of all, administratively, a FreeBSD machine is considerably easier to work with. Software installation and maintainance under the ports system remains unmatched in Linux. RPMs DEBs and Portage are all second rate systems in comparison. (Yes I’ve tried all of these except Portage, which I’ve heard causes considerable breakage.)
In addition, I find the file system hierarchy to be much more logical than any Linux I’ve tried.
The kernel and userland build process is much nicer to work with.
FreeBSDs stability, even under the “UNSTABLE” 5.0 release is still unrivaled by any Linux distribution I’ve ever seen. Performance is excellent on non-SMP machines. I don’t own an SMP machine so I can’t comment on that.
FreeBSD has the best Linux emulation layer in the business. Arguably causing some programs to actually run BETTER than on native Linux.
Then there’s OpenBSD, whose security paranoia is something Linux or any other OS can lay a candle to.
NetBSD has portability that Linux could only dream of.
Don’t put nails in *BSDs coffin yet.
-bytes256
I understand what you mean, however, the main bottle necks in FreeBSD have always been threading and poor scalability due to the Bloody Huge Lock (BHL).
When I mean it is based on BSD, it doesn’t mean necessarily that the operating system is a direct line by line copy of BSD. It would be like me saying that UNIX is terribly inefficient then point to a random UNIX vendor.
*BSD is like a UNIX, it can either be implemented well, or really crappy. Considering that the first Mach was based on BSD 3.2, one can assume that the issues faced by FreeBSD and so forth have already been addressed.
As for SMP performance, it is pretty good from my experience, however, that is only on a dual CPU installation, however, since Apple don’t sell systems with more than 2 CPU’s, I can comment on Quad configurations.
OSX uses the Mach kernel (in it’s monolithic guise) so SMP performance should be quite good (although the in-kernel BSD server might be a significant bottleneck).
However, a lot of software, especially ported server apps, makes use of functionality provided by the in-kernel BSD server. Hence the bottleneck comment.
For the record it’s not really a server, especially in the case of the VFS. Apple more or less imported the FreeBSD Unified Buffer Cache to XNU and managed to connect it to the Mach VMM, and then proceeded to build the FreeBSD VFS on top of the UBC.
A Mach server would traditionally communicate over a Mach message port. Since there’s no message passing involved it’s not really a server. (although this is just arguing semantics)
XNU is just an odd kernel… it’s a monolithic kernel built out of the components of a microkernel architecture.
Instead of fixing up the issues they stuffed around blaming the slow progress on “economic issues”
FreeBSD’s slow progress may be blamed on several issues, including its unified development model. This becomes a significant problem when there’s a great deal of in-fighting amoung the FreeBSD developers. Technical issues soon become personal ones, and it isn’t possible for one developer to temporarily fork a project component in the same way that Alan Cox is able to do with the Linux kernel… no, such a fork would lead to something like what happened between NetBSD and OpenBSD.
FreeBSD is desperately in need of leadership and direction at this point…
When I mean it is based on BSD, it doesn’t mean necessarily that the operating system is a direct line by line copy of BSD. It would be like me saying that UNIX is terribly inefficient then point to a random UNIX vendor.
Let me explain myself even more clearly.
XNU has a large chunk of fairly old BSD code (I’ll refrain from calling it a “server” because, as Bascule correctly points out, it doesn’t function in the same way as traditional Mach servers) running in kernel space which provides certain elements of critical functionality. This is poorly locked and not completely reenterant so it’s protected by something called a “funnel”. Funnels, of which there are two in OSX [filesystem/kernel and networking], serialise access to the BSD code.
Whilst this is fairly adequate for dual processor machines, it would seem to be a significant bottleneck when scaling upwards.
I will have to agree with Bascule. Personally, I prefer FreeBSD to Linux for server and some other tasks, but what Bascule described in his “Ouch!” comment seem to be on par of what’s going on. FreeBSD can only play catch-up with Linux at this point.
Driver support is already behind Linux, and kernel enhancements seems to be slower than how Linux is getting them from IBM, SGI and other people who work on Linux for a living…
In fact, I posed this question to our freebsd interview linked above, but I don’t think many people understood its importance for the FreeBSD future as a viable server OS.
That’s one of the things i liked about the Linux development system, the fact that Linux has no problem withsome maintaing a forked tree to test new features, and then to accept in patches from this tree. At the moment there’s at least 4 other 2.5 trees out there, each them synch with Linus’s tree on a regular event.
Andrew Morton’s one mainly where all the VM + scaling work gets add in first, once it’s tested and shown to work tend’s to end up Linus’s tree
Alan Cox tree is where all the PCI development is going on
Dave Jones one is mostly to do with forward porting stuff from 2.4 as well as hardware issues.
ODSL have a tree with is to do with scalability and such (NUMA etc.)
there’s prolly a couple more of them out there.
From what i can tell FreeBSD’s centralised system (core) is both an advantage in some ways and a disadvantage in others.
Anyway i’ve downloaded the FreeBSD 5.0 iso’s and going give it a run on my spare disk.
I sincerely doubt most of us using FreeBSD are doing so for performance reasons.
I am. Among other reasons.
But what other alternatives are you thinking of where FreeBSD offered a significant enough performance advantage to be compelling ? Of all the compelling reasons I prefer FreeBSD, performance isn’t even on the list.
I should probably clarify that when I said “reasons” in my original post I was thinking of reasons that were decisive in choosing one platform over another, not the “this is a nice added bonus” type of reasons.