"Things really _have_ calmed down, and hopefully we've also resolved a lot of the regressions in -rc3," began Linus Torvalds, announcing the 2.6.27-rc3 Linux kernel. He noted that much of the patch size was from the inclusion of the new ath9k wireless driver, with much of the rest of the patch size due to the renaming of many arch include files in the ARM, AVR32 and m68lnommu architectures. Linus continued:
"All the small changes are where the regression fixes are, and other random improvements. And they're all over. The ShortLog (appended) probably gives a taste of it."
"I just imported ix(4), a driver for the Intel 82598EB 10 Gigabit Ethernet adapters. It is based on Intel's ixgbe FreeBSD driver, with many local changes for OpenBSD.
"I write to you to inform you that I have decided to join Atheros as a full time employee, as a Software Engineer, to help them with their goals and mission to get every device of Atheros supported upstream in the Linux kernel."
"In concrete terms, this adds support for WPA-PSK and WPA2-PSK protocols, both in station and hostap modes."
"People who had problems with unsupported Atheros devices (single chip variants found in recent laptops, macbooks, etc.) should get the latest code from CVS and test it..." OpenBSD Reyk Floeter announced regarding recent improvements to his reverse engineered HAL adding support for 11b mode. He noted that the new code wasn't without fault yet, adding, "hacked and tested in the Melbourne Museum during the AUUG 2007..." Reyk explained the changes in his commit message:
"The newer single chip Atheros wireless chipsets like the AR5424, AR2423 etc. are mostly compatible to the AR5212 but use a different algorithm to set the 2GHz RF channel, that's why they didn't work in OpenBSD. I figured out that the channels were set with an offset, setting channel 11 in the driver caused the hardware to set channel 5 etc. Because I didn't figure out the pattern to fix the algoritm yet, I fixed it in a workaroundish way by defining a small 'table' with offsets for the 11b channels to get the right results. For example, if we want to set channel 11 (2462MHz), we add an offset of -30MHz, and feed the result (2432MHz ^= channel 5) into the unmodified AR5212/AR5112 RF setup function.
"Long description for a commit message, but it needed some time to figure it out. It is still not perfect, needs some more work, and it doesn't work in all cases; but it allows to use newer chipsets in 11b mode restricted to 1 or to 2Mbit/s. 11a mode seems to work without problems so far."
"Incorporating the MadWifi project as non-profit entity is on our to-do-list since months, and I really would like to see it happen soon now," Michael Renzmann announced on the Madwifi development mailing list. He explained, "[the] main motivation for setting up a non-profit organisation is to be able to handle monetary donations from users in a clean way. So far, we are a bunch of interested and only loosely organised developers working on the driver." He went on to add, "we see a rising amount of users asking how they can donate money to support the ongoing development of MadWifi and ath5k. The money could be used for covering costs for our server, for setting up a small testbed installation, for providing developers with Atheros-based cards, and so on." He then noted that given the two options of either forming their own non-profit or joining a non-profit umbrella, they are choosing to pursue the latter.
Michael continued, "As far as I know, SFC and SPI are the only non-profit umbrellas that exist for open-source projects - or at least these are the two 'famous' ones." He went on to offer some comparisons between the 'Software Freedom Conservancy' (SFC) and 'Software in the Public Interest' (SPI), as well as listing some projects that are members of each. He noted the SFC's association with the SFLC and suggested, "I currently tend to vote for incorporating as non-profit by joining the SPI, and at the same time join the SFLC as client." Michael concluded by asking for feedback.
"It doesn't seem to pull any dependency nor affect any other external piece of code unless I'm missing something, so it's a perfect example of what we've been discussing back then: there is just no point not merging it at any time right ? :-)" Benjamin Herrenschmidt summarized his request that the iwl4965 driver be merged into the 2.6.23 kernel late in the release cycle, outside of the standard two week merge window. John Linville answered, "it is queued for 2.6.24. I'm not even sure it was originally posted in time for the 2.6.23 merge window, but even if it was there was a lot of opposition to merging it until fairly recently. In fact, I'm sure there are still some wireless developers that are less than happy about merging it now." When asked what the opposition was about, he referred to a discussion on the netdev mailing list and explained:
"There have been a lot of spats about how functionality has been partitioned between the driver and the firmware, issues with how the driver tries to do things that either ought to be in mac80211 or not done at all, and some random complaints about ugliness like '#include "../../../net/mac80211/blah.h"', etc. There is still plenty of work to be done on this driver, but as you point out we are better-off with it in the kernel than with it out."
"1.10 has been branched," DragonFlyBSD creator Matt Dillon announced, noting that the official release is expected soon, "no release date has been set yet but this coming weekend is looking real good now." Among the new features of DragonFly 1.10 are improved virtual kernel support, a new disk management infrastructure, improvements to wireless networking, and support for the new syslink protocol.
DragonFlyBSD has a stable release every six months. The current development branch is numbered 1.11, with the next stable release at the end of the year numbered 2.0. The 1.10 release has been delayed about a week while some final bugs were addressed. Matt noted:
"The 1.10 release is looking a lot better now. We are basically just waiting for a new pkgsrc bootstrap kit and a little more testing. All major issues except booting a machine with a USB root with EHCI loaded have been resolved."
James Ketrenos announced a new 80211 based driver for the Intel PRO/Wireless 3945ABG network connection adapter, "this new driver uses the new d80211 subsystem previously only available as part of the wireless-dev tree." An earlier incarnation of the driver code was much criticized for its inclusion of a userland binary-only daemon [story], prompting the OpenBSD project to create their own blob-free driver for the card [story]. "The [new] iwlwifi driver for the 3945 does not require the user space daemon, but does require a new microcode image," James explained, "over the past year we were able to make the necessary changes to the microcode used with the 3945 such that we were able to remove the regulatory daemon."
When the question was asked if the driver was going to be pushed for inclusion into the mainline kernel it was noted, "hmmm...I think we need to spend a cycle or so in -mm. 2.6.22 seems more likely for mainline." Pavel Roskin suggested, "iwlwifi is surprisingly good for a just announced driver. It worked for me from the first attempt, and that's the first d80211 driver to do so. In my opinion, it should go to wireless-dev as soon as possible so it can go to -mm together with other drivers."
The OpenBSD project has long been associated with security. Indeed, thanks to proactively and regularly auditing its code, the project's web site is able to boast "only one remote hole in the default install, in more than 8 years," and another page states "our aspiration is to be NUMBER ONE in the industry for security (if we are not already there)." However, security is not the only focus of OpenBSD, as reflected in the project's slogan which reads, "Free, Functional and Secure." All three of these words are strongly backed by OpenBSD developers.
If you speak with OpenBSD creator Theo de Raadt for any length of time, you will quickly realize just how important freedom is to the project. For example, freedom was the driving force behind the now ubiquitous OpenSSH, developed within the OpenBSD project. It has also lead to the development of OpenNTPD, OpenCVS, and the widely used pf Packet filter [story]. In recognition of these many contributions, Theo recently received the 2004 Free Software Award from the Free Software Foundation. The freedom that the OpenBSD team works so hard for comes without any strings, patents, or conditions, distributed under the BSD license.
Currently, the OpenBSD project is focusing on wireless networking technology, working to convince hardware manufacturers to make the firmware for their wireless cards freely distributable. It sounds simple enough, but the effort has taken much persistence and perseverance. Many of today's corporations require the signing of non-disclosure agreements and other legal red tape prior to making firmware or documentation available, requirements that don't measure up to OpenBSD's standards for freedom.
OpenBSD creator Theo de Raadt [interview] announced that Intel has refused his request to permit that the firmware for their wireless chipsets be made freely distributable. He explains, "I had asked for free terms under which we (and Linux, anyone) can redistribute the firmwares for their wireless chipsets. Without these firmware files included in OpenBSD, users must go do some click-through license at some web site to get at the files. Without those files, these devices are just bits of metal, plastic, and sand." Intel is one of several companies being approached by OpenBSD in a coordinated effort to try and free up the availability of firmware for wireless chipsets [story]. Several vendors including Symbol, Zydas, and Atmel have responded favorably, licensing their firmwares so that they can be distributed freely with OpenBSD.
As to the reason Intel refused to update their licensing, Theo explained that they referenced obligations to outside parties. Further clarification as to exactly what that means was not provided by the company. Theo went on to note that though this concludes his dealings with Intel, users are still encouraged to contact them and express their concern for this policy, "maybe they will listen to enough customers, or they will learn to not make this mistake again with future chipsets. I for one have already decided that I will never recommend an Intel product to anyone ever if there is choice. (There is almost always choice)."