OStatic

Today, the Linux Foundation released its updated study of mainline kernel development. The report examines the slight variations in release frequency, the lines of code submitted, deleted and modified since the April 2008 study, new trends in subsystem patch signoff, and the remarkable diversity (and, perhaps, adversity outside the realm of kernel development) of the companies contributing to the kernel.

While the study is obviously pertinent to those working in kernel development, it covers so many aspects of the development process that everyone working with open source software -- developers, community managers, and even non-IT managerial roles -- can find something directly related to their positions.

It's also (perhaps surprisingly) engaging reading for those interested in the Linux kernel but a little foggy on how the kernel relates to the rest of the operating environment or how changes are approved and applied to the kernel tree.

While not a completely new concept, the Debian team introduced what it called a couple of new architectures over the weekend. Except the new architectures aren't really new, per se -- i386 and amd64 are already supported in Debian. They're already supported in the Debian Linux kernel. The new additions are FreeBSD kernels compiled for the aforementioned architectures.

The majority of computer users don't spend much time thinking about the file system their operating system uses. Granted, people installing alternative operating systems might give more consideration to the available file systems than the general population -- unless there's a specific need for a certain file system, many go with their distribution's default option.

While your file system type isn't something you should need to think about regularly, and making an informed choice for machines with specialized, dedicated tasks is important, usually choosing the default file system type for your operating system is fine. Several Linux distributions (including Fedora and Ubuntu) are planning to move their default file systems from ext3 to ext4 in upcoming releases, while a number of distributions already (or will soon) support ext4 as a file system option.

IBM has a (rather surprisingly) interesting look at what's different about the ext4 file system, including details on why some changes were made, and how moving from ext3 to ext4 works.

Alan Cox, long-time kernel developer at Red Hat, announced last week that he would be leaving Red Hat in January for Intel, where he can concentrate more on areas of low-level development.

As you'd imagine from such a statement, this doesn't end Cox's involvement with the Linux kernel or open source development.

On the O'Reilly Media site, there is an intriguing interview with kernel developer Greg Kroah-Hartman. Kroah-Hartman says he has evidence that Linux now supports more devices than any other operating system.

In the lengthy interview, he talks about why this is true now, and how hardware suppliers and open source developers can work together to bring more peripherals to life.

The Linux Foundation recently posted a video interview with Linus Torvalds that took place at September's Linux Kernel Summit. Torvalds, the man behind the Linux kernel, and the project's chief coordinator, is always interesting to hear and the ten minute video is well worth watching.

Torvalds' insights range from disarmingly truthful (email is a fine method for communicating, but the Summit is needed because it's good to see people) to keenly introspective (kernel and userland issues are rough, because no one sees things in quite the same terms).

The Linux Plumbers Conference may have ended last Friday, but the discussions -- and one discussion in particular -- will be analyzed, deconstructed, and argued for quite a bit longer.

Greg Kroah-Hartman's assertion is that Canonical doesn't contribute significantly to kernel development and the packages that make up the core of a Linux system. Canonical CTO Matt Zimmerman responded to this assertion. It seems at that point, much of the community, developers and users alike, took to examining their particular parts of the open source elephant.

Herein lies the problem.