One of the hottest home electronics products is the Sonos Digital Music System: a Linux-based wireless audio setup that works as a kind of iPod for the home.

Although other whole-home systems integrate with the TV and contain hard drives, the Sonos works strictly as a wireless distribution system. Your music and other audio files live on Linux, Mac or Windows PCs (or combinations of them—file sharing is through Samba) and are displayed in color on Sonos' wireless handheld controller. Each room has its own ZonePlayer—a small 50-Watt amplifier. You can choose the speakers or buy Sonos' own bookshelf units.

Writing in MadPenguin.org, Christian Einfeldt says, “It's the current state of the art for wirelessly controlling music in a large home or business where you need just the right music in the right room at the right time. And best of all, it's powered by GNU/Linux!” The Wall Street Journal calls it “...easily the best music-streaming product I have seen and tested. It's the Lexus of the category.”

When it comes to Linux adoption, educational institutes and government agencies around the globe continue to lead the way. We hear a lot about various countries mandating open-source and free software usage—China, Germany and Brazil are only a few. To learn more about some other international initiatives, check out these articles on LinuxJournal.com:

In other news, in case you missed it, we took your input to heart and created a searchable category system for the Linux Journal Web site. Check out the home page for a list of 16 categories to search—from Audio/Visual to Webmaster—for articles going back to Issue 1 and the early days of LinuxJournal.com.

As many of you already know, I have left Linux Journal to join SpikeSource. My first day at the new company, I looked up some people in the employee directory, which is a simple PHP interface on top of the LDAP server—no need to change someone's account info on the server and the person's employee directory entry separately. It all stays together, and employees can update their own info, such as cell-phone numbers.

DirectoryPages is not merely a handy way to keep everyone's info in one place and put an easy Web interface on it, it's also a good example of how to use LDAP data in a PHP script. A full article on how it works is bundled with it. Now all this thing needs is TeX integration to autogenerate business cards.

(Yes, the following is a link to my new employer, but I got Linux Journal executive editor Jill Franklin to approve it.)

Home page: www.spikesource.com/info/search.php?c=DIRECTORYPAGES

Support forum: www.spikesource.com/forums/index.php

Linus Torvalds has put together a git repository for the full 2.6 tree, going all the way back to the introduction of BitKeeper. Kernel development still takes place on a new tree, but the old tree now exists for reference or for any other purpose one might have. This is not the first time these patches have been incorporated into a git repository, but with all the work going into git during the last three months, this is the first time a git repository for these patches has been small enough to fit in a reasonable space. The progress git has made since its inception has been utterly amazing, and a 1.0 release is apparently imminent. Although people will want their favorite revision control feature in git before they'll start using it, these features can, for the most part, all be regarded as icing on the cake. The core functionality, the stuff that controls distributed development, exists in a robust, powerful form for the very first time in a free project.

It looks as though RelayFS will soon be going into the main kernel tree. It's had a long stint in Andrew Morton's -mm tree, and it has needed no major fixes in months. A good crop of users has found it useful for a variety of applications, and the only real objection to its ultimate inclusion has been the fact that DebugFS performs a similar function. But if for no other reason, a filesystem called DebugFS just doesn't seem to invite users to use it for anything other than debugging. Andrew has expressed a clear willingness to push the RelayFS code up to Linus Torvalds, especially as the RelayFS developers themselves feel the time is right.

Timothy R. Chavez and others have produced a patch to enhance the Virtual Filesystem (VFS) auditing support to be able to audit a filesystem object based on its location and name. In the current VFS implementation doing this is impossible. When Timothy first proposed the idea, there was a bit of resistance from kernel folks who pointed out that inotify existed and performed a quite similar function. But when Timothy's auditing project started, inotify was not very mature and existed only as an external patch, so it made more sense at that time to develop this auditing code as a separate feature entirely. Now that inotify is at least in the -mm tree, a better argument can be made to use inotify instead. But Timothy and the other developers of this patch, along with critics like Greg Kroah-Hartman, have hatched a plan to abstract the basic functionality common to both this auditing code and inotify and make these projects simply access the abstracted features directly to get what they need. When this actually will be done is still an open question.

Adrian Bunk has tagged a number of OSS sound drivers for removal. The decision as to which drivers to remove and which to keep is not an easy one. The goal is to preserve support for all existing hardware, and so before any driver can be removed, Adrian must determine whether an ALSA equivalent exists and works. This determination often can be made only by someone with very old sound hardware, and such users may be difficult to find. Each case must be confirmed individually, and Adrian does the legwork for each one, following up on e-mail and asking questions of users. Housekeeping patches like Adrian's are often thankless, if not downright unwanted by users afraid of losing support for their favorite hardware. It's nice every once in awhile to acknowledge the hard work of folks like Adrian, who put in many hours each week, just on kernel cleanups like this one.

Wireless Security Lock gadgets are finding support in Linux. These devices allow a wireless system to detect when it has traveled too far from a given location, in order then to perform some security function, like locking the monitor. Brian Schau, for his first kernel driver, coded up support for WSLs. In spite of the fact that a Bluetooth phone can provide similar functionality, and in spite of the fact that a user-space application might be better suited to the task than Brian's kernel driver, the project clearly has merit, because it supports an actual existing piece of hardware. One way or another, it seems, Linux will be supporting WSLs.

Andrew Morton has offered some clarification on whether users should prefer a swap file over a swap partition, and why. In 2.6, he says, the difference is virtually nil. Both in terms of performance and reliability, swap files and swap partitions are equally good, with one exception: if the swap file created is very fragmented, performance will suffer. But because swap file fragmentation does not increase over time, simply creating a nonfragmented swap file initially solves that problem completely. In 2.4, the situation favors swap partitions over swap files, because the partition can avoid certain memory allocations that swap files require.