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.

In February, Microsoft filed suit against TomTom, claiming that the portable GPS manufacturer had violated eight of its patents. Three of the patents in question dealt in some manner with TomTom's implementation of the Linux kernel.

While Microsoft's Horacio Gutierrez stated the lawsuit is between TomTom and Microsoft, and not an attack on the Linux kernel as whole, many in the open source world are wary. The Linux Foundation's Executive Director, Jim Zemlin, has said that it would be prudent to keep an eye on the situation, but there was no reason to get overly excited, yet.

TomTom has made the next move, lending some credence to the Gutierrez's it's just between the two of us claims. On Monday, TomTom filed a countersuit in the US Court District Court for the Eastern District of Virginia. TomTom alledges that Microsoft violated its intellectual property (though sources vary on the number of patents involved) in its Streets and Trips products.

If you happened to be perusing the recent commits to the upcoming 2.6.29 Linux kernel release (and why wouldn't you be?) you probably noticed Linus Torvalds' stamp of approval that cleared Tux to go on walkabout this release cycle, and welcomed Tuz as Linux's substitute mascot.

Tuz is a Tasmanian Devil cleverly disguised as a penguin. Assurances abound that Tux is on sabbatical, and the screeching, meat-eating endangered marsupial from Australia hasn't devoured him. How did Tuz get from the forests of Tasmania to the Linux kernel tree? It started at a conference...

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.

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.

Recently, Matthew Garrett, a developer who works with a number of open source projects, including Debian and Ubuntu, wrote a guide for good power management practices. Though he states the guide is mainly for those working with desktop environment implementation and power management interfaces and utilities, he points out a few hardware/software relationships that might interest the casual end-user.

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.

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.