"Thousands of Neo FreeRunners have been loaded into planes and fired around the world," announced Sean Moss-Pultz, the Openmoko CEO, in a frequently philosophical email titled "let us impact the material world", posted to the Openmoko community mailing list. He continued, "many of our distributors have already begun shipping. In about another week, Steve and Harry will announce the opening of our own webshop." The CAD files for building the smartphone hardware are available under the Creative Commons, and the software has been released under the GPL, including a patched 2.6.24 Linux kernel. Sean continued, "whenever I talk publicly about Openmoko, or so it seems, the following question is asked: How can you compete again the giants of this industry? For most of us, I'd like to think, the answer is obvious. Instead of answering, I usually return their question: How can they compete against us?" He explained:

"Openmoko is the collective creation of amateurs working on exactly what we love. They are professionals, some doing what they love, most working towards the next paycheck. At certain times, the amateur has a distinct advantage over the professional. A professional knows what they can deliver, and rarely goes beyond it. An amateur has no concept of their limitations and usually goes well beyond them. Experience teaches us our limits. When we have learned that and become complacent, we are finished, because our work can be calculated and measured. Our work ceases to be a weapon."

"It hasn't been a week, I know, and this is a pretty small set of changes since -rc7, but I'm going to be mostly incommunicado for the next week or so, so I just released what will hopefully be the last -rc," began Linux creator Linus Torvalds, announcing the 2.6.26-rc8 kernel. He added, "or maybe not. It depends on how good you all are while I'm not looking." Regarding the latest release candidate, Linus explained:

"Most of the bulk of the changes here are to Xen and to KVM in particular, which shows up as a rather unusual dirstat: 65% is in arch/x86 (counting the asm-x86 changes too). The rest is mostly random stuff, the appended ShortLog gives a reasonable idea. Several bugzilla entries are hopefully now closed."

"HP has released AdvFS, a file system that was developed by Digital Equipment Corp and continues to be part of HP's Tru64 operating system," announced Xose Vazquez Perez, offering a link to the re-licensed source code. 2.4 maintainer Willy Tarreau replied favorably, "wow! That's awesome. I discovered it in 1999 and 9 years later, it probably remains the most advanced FS I encountered." HP's Linda Knippers explained:

"In case its not clear, this is a GPLv2 technology release, not an actual port to Linux. We're hoping that the code and documentation will be helpful in the development of new file systems for Linux that will provide similar capabilities, and perhaps used to make tweaks to existing file systems."

Interesting features found in AdvFS include, "simplified file system and storage management; flexible multi-device storage pools shared by multiple file systems, with or without a volume manager; exceptional file system availability (no need to take file systems off-line to expand, shrink or reconfigure; snapshots for consistent backups while applications are on-line; ability to recover deleted files); wide range of performance management tools (fine grain control over file system and file placement within the storage pool; on-line rebalancing of files and free space across the storage pool; on-demand or background file and file system defragmentation); and transaction log management, allowing choices for logging metadata and data asynchronously or synchronously."

"As part of the Linux Foundation Technical board, we confront the issue of closed source Linux kernel modules all the time, and we wanted to do something that could be seen as a general 'public statement' about them that is easy to understand and point to when people have questions," began Greg KH, explaining, "so, after working on this for a while, and asking some of the other major contributors and maintainers of the kernel, what we have is below." a FAQ on the Linux Foundation website provides more background on the statement, which was undersigned by nearly 140 Linux kernel hackers. The statement reads:

"We, the undersigned Linux kernel developers, consider any closed-source Linux kernel module or driver to be harmful and undesirable. We have repeatedly found them to be detrimental to Linux users, businesses, and the greater Linux ecosystem. Such modules negate the openness, stability, flexibility, and maintainability of the Linux development model and shut their users off from the expertise of the Linux community. Vendors that provide closed-source kernel modules force their customers to give up key Linux advantages or choose new vendors. Therefore, in order to take full advantage of the cost savings and shared support benefits open source has to offer, we urge vendors to adopt a policy of supporting their customers on Linux with open-source kernel code."

"Another week, another -rc," began Linux creator Linus Torvalds, announcing the 2.6.26-rc7 Linux kernel, "and as usual, it's mainly drivers and arch updates - over 90% of changes are in one or the other." He continued:

"A big part of it (about two thirds of the driver update, in fact) is a late-dropping AGP/DRM update that adds support for some new Intel and ATI graphics cards. And a big part of the arch update is the inevitable def_config updates, of course. I'm not all that happy about the timing of the support for the new cards, but at the same time I also hate delaying new drivers. Obviously the hope is that it can't cause any regressions, since the added code is almost entirely for stuff that simply wasn't supported at all before."

Linus concluded, "if you ignore the driver and arch updates, the rest is pretty minor. About half is in networking, and half of the remaining is filesystems updates (mainly ocfs2). And random smatterings elsewhere, like some scheduler updates."

Matthew Dillon continues to make significant progress on his HAMMER clustering filesystem for DragonFly BSD. He labeled the latest release 56c, noting that it, "represents an additional significant improvement in performance, [also including] bug fixes and most of the final media changes." A significant improvement in write performance was obtained by making the filesystem block size automatically increase from 16K to 64K when a file grows to larger than 1 MB. One remaining media change is required to optimize mtime and atime storage, at which point HAMMER will go into testing and bug fixing mode. Matt noted, "HAMMER's performance is extremely good now, and its system cpu overhead has dropped to roughly the same that we get from UFS", adding, "HAMMER is now able to sustain full disk bandwidth for bulk reads and writes. HAMMER continues to have far superior random-write performance, whether the system caches are blown out or not." Discussing future plans for the filesystem, Matt noted, "I could go on and on, there's so much that can be done with this filesytem :-)" Regarding one of these plans, he offered:

"I am not going to promise it, but there is a slight chance I will be able to get mirroring working by the release. I figured out how to do it, finally. Basically the solution is to add another field to the B-Tree's internal elements... the 'most recent' transaction id, and to propogate it up all the way to the root of the tree. The mirroring code can then optimally scan the B-Tree and pick out all records that have changed relative to some transaction id, allowing it to quickly 'pick up' where it left off and construct a record-level mirror over a fully asynchronous link, without any queueing. You can't get much better then that, frankly. "

"In the kerneloops.org stats, a new oops is rapidly climbing the charts, began Arjan van de Ven, referring to his website where he automatically collects kernel oops and warning reports from mailing lists, bugzillas, and a special client. Regarding the latest oops, he noted, "the oops is a page fault in the ext3 'do_slit' function, and the first report of it was with 2.6.26-rc6-git3." Linux creator Linus Torvalds took a quick interest in the issue, observing that all the oopses seemed to be on the i686 architecture, suggesting, "could this perhaps be an indication that it is specific to i686 some way (eg a compiler issue?)"

Shortly before Linus sent out his emails, Dave Airlie confirmed that this was indeed a known compiler bug affecting GCC 4.3.1. The bug report notes, "any ext* filesystem which enables the dir_index feature is likely susceptible". Linus caught up on his email and retorted, "gaah. I should read all my email instead of wasting my time trying to match up the code with what I can reproduce.." The reason the Red Hat bug report wasn't automatically picked up by the kerneloops website was because the oops was reported in a jpeg image, leading Arjan to quip, "maybe one day if I'm really bored I'll implement OCR into [kerneloops.org] ;)".