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.

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.

Sometimes porting a bit of code to another platform or piece of hardware isn't about the ported code delivering new features to the device. Sure, sometimes it's about opening the device to a specific application, and sometimes it's just about opening the device up to a new development approach. Sometimes the idea is to push the code (and the device) further, to learn -- because you can.

Sometimes these ports don't get all that far. Four years ago I managed to get Linux running on an iPAQ through online tutorials. I've long since sold the hardware, and running Linux meant a command line, and a basic X windows environment. Functional? Not really. Fun? Wouldn't have done it otherwise.

More recently, the 2.6 Linux kernel has been ported, and is running with some basic functionality on the iPhone. The Linux on the iPhone Project says that while this port is a first draft missing many drivers, the kernel boots on first and second generation iPhones and first generation iPod Touches.

I've been doing some thinking since writing about kernel developer Greg Kroah-Hartman's statement that Linux supports more devices than any other operating system. Readers made some good comments, and after some time spent wrestling with my (yes, supported) webcam, I can venture an additional suggestion as to why it doesn't always seem that way, beyond Kroah-Hartman's theory of a non-supported device becoming personal.

In the case of my webcam, and in the case of one commenter, it seems the problem isn't necessarily the device driver. At lower levels, the drivers work. It's the layers of programming, interaction, and demand piled on the driver that makes the device feel broken. It is difficult to tell for sure, though, exactly what is causing that break.

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.

VIA Technologies announced that it's moving forward with its commitment to open source software by collaborating with the openChrome Project to improve support for VIA integrated graphics chipsets.

VIA and openChrome have been focusing on multi-head support and improving the implementation of the RandR (resize and rotate) extension. The VIA framebuffer driver source has been checked into the 2.6.28 mainline kernel. Perhaps most significantly, VIA has opened the documentation for the VIA CX700M and VX800 chipsets.

A bug surfaced recently in the pre-release versions of the 2.6.27 Linux kernel (up to 2.6.27rc7). The bug affected the e1000e driver module, which supports a number of onboard Intel ethernet adapters. The driver would corrupt the EEPROM/NVM of adapters with ICH8 and ICH9 chipsets, rendering them useless.

The silver lining was that since the kernel is a pre-release, only distributions with releases in the alpha or beta stages, or custom compiled testing kernels, were affected. The Intel team released a patch Wednesday to prevent further damage.

Video editing software for Linux is, to put it nicely, quirky. Some editors only work with specific file formats, some work nicely for basic video editing but can be wildly temperamental on seemingly identical machines, and some are powerful to the point of overkill for the average user.

PiTiVi is a non-linear video editor based on the GStreamer multimedia framework. After hearing some positive comments, and seeing development efforts really picking up on the project, I decided to take it for a spin. It is very much in development, but not in the traditional sense. It feels very stable, and the interface isn't confusing or a hindrance. It is, at the moment, very basic when it comes to functionality. There are not plugins or extensions currently available (though feature requests are welcome). However, the project has taken the time to plan its path forward -- and with the basics down, I can't see why real headway won't come quickly.