Will Dyson has release version 0.92 of the Be FileSystem driver. He says of the driver, "It still isn't quite ready for inclusion in the mainline kernel (it doesn't yet conform to the kernel coding style, for one thing), but I use it all the time on my system and have yet to have any kind of stability issue with it".

The latest Kernel Traffic is out. Yes it's less then a week from the last one.

Richard Gooch released version 199.10 of the devfs patch today. His announcement email follows.

From the FAQ:

"Devfs is an alternative to "real" character and block special devices on your root filesystem. Kernel device drivers can register devices by name rather than major and minor numbers. These devices will appear in devfs automatically, with whatever default ownership and protection the driver specified. A daemon (devfsd) can be used to override these defaults. Devfs has been in the kernel since 2.3.46."

Anton Altaparmakov recently annouced the 2.0.0 release of NTFS for the Linux 2.5.x kernel. This version is targetted for 2.5 inclusion, and is claimed to offer around a 20% speed gain over earlier NTFS drivers. You can browse the source code here. Full details follow.

From the Linux-NTFS FAQ:

"NTFS is an abbreviation for New Technology Filesystem. 'NT' because it was originally used in Windows NT and a filesystem is just how the computer stores files on disk. Different operating system, stores files in different ways. NTFS is used by Windows NT, 2000 and XP."

Richard Gooch today released version 1.3.25 of the Device FileSystem daemon. A list of changes follows.

"Devfsd provides configurable management of device nodes using the Linux Device Filesystem". [*]

The latest LWN kernel report is out. Included is a discussion of the 2.4 VM patches from Andrea Arcangeli.

The latest kernel trap is out. A lot of discussion on SCM (not just BitKeeper) this week as well some notes about the SSSCA and the zlib security affecting the kernel.

Linux 2.5.7 is out. As usual, the changelog can be found here. Linus also points out that he'll be on vacation for the next two weeks.

Anton Blanchard posted on the lkml he had a kernel compile on 7.52 sec using a 32 way logical partition, 1.1GHz POWER4, 60G RAM

Marcelo Tosatti has begun using BitKeeper to keep a hold on the 2.4 tree. You can read the juicy details in the thread here.

LWN.net has posted this week's kernel update.

Alan Cox released the 2.2.21-rc1 kernel today. Today's patch is the first release candidate that should become 2.2.21-final, barring any unforseen issues. This puts him a little behind his earlier tentative schedule, but we expect to see the final release soon. This patch includes a few minor bug fixes, and the reversal of an earlier fix ("back out problem mce change").

The previous release of this stable 2.2 kernel series was 2.2.20 on November 2nd, 2001. The first release, 2.2.0, was on January 26th, 1999.

New Kernel Trafic digest #157 at http://kt.zork.net/kernel-traffic/latest.html

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).

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[1] 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".