Submitted by “Though the open source FreeBSD operating system has changed in many aspects over the last 16 years of its life, one item that has remained relatively static is its underlying network routing architecture. No more: It’s getting an overhaul with the upcoming FreeBSD 8.0 release. FreeBSD 8.0, due out next month, will include a new routing architecture that takes advantage of parallel processing capabilities. According to its developers, the update will provide FreeBSD 8.0 with a faster more advanced routing architecture than the legacy architecture.”
I think this is going to be a great improvement. Solaris has done something simillar recently with Project Crossbow, will be interesting to see both these projects mature.
No crazy name means it has to be good. Not to pick on any vendor, or OS project, but low level parts of systems don’t need marketing names. It inspires more confidence in me when they don’t.
Surprised this is just getting posted now considering it is from 2 and a half weeks ago. I would suggest reading freebsdnews.net all the time as a good resource for articles or news like this for anything to do with FreeBSD in general.
I wonder if this is in the haiku wifi stack… since It uses the FreeBSD drivers indirectly through a compatibility layer
colin the GSoC student working on it did post in his blog that he is synced with the freebsd 8 drivers for the cards he is working on supporting.
I guess I will have to try out BSD sometime supposedly I hear it is similar to Archlinux which like a lot.
FreeBSD 7.0 is very limited in what it supports. According to this:
http://www.clearchain.com/blog/posts/iwn
4965 support is being added to FreeBSD 8.0 – hopefully that along with other enhancements will make their way into it.
I think the word “very” is misplaced.
Not so long ago BSD had better wireless support than Linux. Who knows, might be still true.
Kudos to Damien Bergamini from the OpenBSD project.
Could you specify “not long ago”? You’re surely talking of OpenBSD. OpenBSD has got some fine WLan drivers (most of it are working like a charm compared to those ports in FreeBSD), but even if you e.g. get support for 802.11n devices in terms of drivers (for example iwn), there is no infrastructure to actually use the higher performance (FreeBSD has got this infrastructure but actually no drivers to support it). FreeBSD itself is compared to the Linux kernel in terms of WLan drivers just a pain in the backside. There are even today many drivers with problems regarding WPA/WPA2, like if_rum (see last PRs), severe performance issues in rum, ral and wpi etc. Last not least there are just a couple of drivers compared to the plethora of wlan drivers in Linux.
Okay, Linux has got different problems, but if you’re eager to use something WLan, even most of the devices nowadays, then Linux is the way to go. I’m sorry but OpenBSD only is comparable in terms of Wlan to Linux. FreeBSD has got its merit in huge networks only.
No, I was talking about BSDs generally.
No, the situation is broadly similar across all BSDs.
Yes, suppport may be limited (but not *very limited*).
Yes, as a rule of thumb, Linux supports new hardware faster, which may not be entirely a good thing.
Yes, there are bugs, but my perception is [was] that there are [were] more bugs both in Linux driver stack and in the (third? fourth?) Linux IEEE 802.11 stack. (Note particularly the past tense.)
Yes, support for 802.11n is limited but I find it ridiculous to even suggest otherwise in the open source world for a new *proposed* amendment.
No, in more broader terms, the situation is highly similar in all open source operating system; if you want proper support, you use closed drivers supplied by vendors.
No, you can succesfully deploy 802.11 solutions with all mentioned operating systems; I have done so, and it is not “pain in the ass” if you are not building the netowrk with Dell laptops, so to speak.
No, all BSDs are multi-purpose operating systems whose merits are not only in “huge networks”.
No, although I write to OSAlert, I really hate to compare operating systems because it always leads to “pain in the ass” discussions.
>No, the situation is broadly similar across all BSDs.
Just no and I can proof it as every hardcore FreeBSD user. Some people even call me sometimes “BSD zealot” on osnews But well, I do know the strengths of other operating systems too or those among the BSDs. That’s the difference to an operating system zealot. BSD has got different strengths, WLan isn’t one of it and especially none of FreeBSD.
Agreed absolutely.
There is a discernable difference of philosophy. The notion that the documentation is an important part of software is a part of BSD culture. In my experience of Linux some allegedly supported devices are nigh on impossible to get working.
I like and use both – don’t get me wrong! BSDs seem to have a much clearer cutoff for hardware support that wastes little of my time.
If you read what I wrote I was talking explicitly about FreeBSD and nothing else; you’ve started off on a tangent that I never initiated. The issue is that the vast majority of laptops out there ship with Intel wireless of which the support from FreeBSD is either basic or non-existant. Bringing in OpenBSD, NetBSD or some other BSD that I’ve left out.
Even with OpenBSD it has taken till now to finally get WPA/WPA2 support working. For a person like me, I don’t want to setup servers, VPN’s and all the other crap; I just want a router set to WPA2 that I log onto.
Back on topic; the fact of the matter is that FreeBSD has very limited support for wireless and even the wireless drivers it does have, the support for the required wireless technologies are limited in scope as well. Personally, instead of trying to be everything to everyone; have a limited pool to focus on and thats it. 90% of laptops sold have Intel wireless chipsets so why focus on the remaining 10% that is split between a dozen different companies?
Edited 2009-09-12 01:39 UTC
FreeBSD development is focused on the server, and in that area hardware compatibility isn’t a problem.
Using it is a laptop OS is a waste of time.
Run it in a Windows VM or proceed at your own risk.