Martin J. Bligh posted to LKML about a 23-second linux-kernel compile on a 16-way NUMA cluster with a heavily patched-up kernel. Ingo Molnar's O(1) scheduler was particularly crucial. says Bligh, "Appling Ingo's patch alone took time from 47s to 30s."
Read more for the full post (with information on which patches he used).
Dimitar Peikov recently posted a small tool to the FreeBSD-Hackers mailing list. The tool was intended to help him compare malloc between the FreeBSD and Linux kernels. This particular test was faster on Linux than FreeBSD, and he asked why.
The responses by Matt Dillon and Terry Lambert make for an interesting reading, explaining much of the differences between Linux and FreeBSD VMs.
Linus' earlier decision to test the BitKeeper source management tool with the 2.5 kernel tree has continued to create wakes of dissent. One group went so far as to start a petition against the usage of the tool, saying "We, the undersigned members and officers of the Open Source Club at the Ohio State University, are unhappy with the advocacy of the proprietary BitKeeper software for use in maintaining the Linux kernel." Details on the BitKeeper licenses that so many are opposed to can be found here.
The posting of this petition led to a frenzy of replies, in a thread that continues to grow. Many pointed out that the time spent protesting this tool could be much more productively invested into writing an open source alternative of at least equal caliber. All seem to agree that such an alternative does not currently exist.
Towards the end of the many samples from this thread that follow is a reply from Linus, making it clear that he is content using BK himself, but will in no way force it upon anyone else. In his email, he says, "And I personally refuse to use inferior tools because of ideology. In fact, I will go as far as saying that making excuses for bad tools due to ideology is _stupid_, and people who do that think with their gonads, not their brains".
Amidst the resulting discussion, Kevin Oberman explained that it was being redistributed as a meta-port, offering the advantage of being upgraded in pieces. Due to the extremely large size of XFree86, it lends itself well to this strategy.
Additionally, the XFree86 4.2 port was too new and thus insufficiently tested for inclusion in the FreeBSD 4.5 release.
Alan has added the O(1) scheduler to his -ac branch of 2.4 kernels, saying of the latest 2.4.19-pre2ac1, "This one is a bit more experimental. I've avoided putting too much in so we can see how the O(1) scheduler pans out".
There was a soft updates bug that crept into 4.5-RELEASE, and could cause corruption on shutdown if there was heavy disk activity before the shutdown took place. This hasn't shown up on any lists I read, but it seemed a bit more noteworthy than the latest security hole in some obscure port (no, not PHP).
Andrea Arcangeli, the author of the current 2.4 VM, has released 2.4.19pre1aa1. It contains his vm-28 which he hopes to push into the 2.4.19pre kernels. If you're feeling adventurous, download his patches, test it out, and provide Andrea with some feedback...
Alan Cox's infamous -ac tree has been ressurected in recent months, taking in lots of stabalizing patches above and beyond Marcelo's main 2.4 kernel tree. In a recent email to the lkml, he refers to 73 emails he sent to Marcelo, each with a different patch he feels is ready to be merged into the main tree.
Alan's email follows, with the complete changelog. Each patch is preceded by a symbol, indicating the status of this patch:
+ indicates stuff that went to Marcelo
o stuff that has not
* indicates stuff that is merged in mainstreem now
X stuff that proved bad and was dropped out
Marcello released the 2.4.18-final kernel today, then twenty minutes later apologized, "Ok, DAMN. I missed the -rc4 patch in 2.4.18. Real sorry about that". A steady stream of email began flooding the lkml, full of numerous suggestions on how to resolve "the problem". The story was quickly picked up by Slashdot, which only added to the confusion.
In reality, it was nothing more than a relatively minor mistake. 2.4.18-rc4, which quickly followed 2.4.18-rc3 (see this earlier story) included a small patch (to 'fs/binfmt_elf.c') that was then not included in the final 2.4.18. In other words, 2.4.18-final is 2.4.18-rc3, not 2.4.18-rc4 as intended. The missing patch (which you can add yourself here) was a fix for a bug introduced recently, around -pre6, affecting non-x86 ports. In Marcelo's words, "The patch which I missed only breaks static apps on _some_ architectures (not including x86)".
Some of the relevant emails follow, as does the 2.4.19-pre1 changelog. Released today, this -pre patch includes the fix dropped from 2.4.18-final, and many other changes.