The git phenomenon continues. Self-hosting and fast as lightning at three days old, git and its favored set of wrapper scripts Cogito have continued to improve and have already had a huge impact on kernel development. Projects left and right are migrating from BitKeeper to git. Net driver development and libata development have switched. JFS and NTFS have switched. And the stable w.x.y.z kernel tree, maintained by Greg Kroah-Hartman and Chris Wright, has also converted recently to git. Some kernel hackers find git to be such an improvement over BitKeeper that they are able to produce much more work than they had before, to the point that Linus Torvalds is having to rethink the way he handles patches in order to accommodate them. BitKeeper documentation has been removed from the kernel sources, and mailing lists such as bk-commits-head that originally were intended to receive announcements of new BitKeeper changesets, receive git kernel patch notices instead.
However, git is not for everyone. When asked, Andrew Morton said he did not intend to use git for his -mm kernel tree, because his set of patching scripts are still sufficient for his needs. Also, Matt Mackall has been working on his own fast-as-lightning version-control system, Mercurial. This is also an excellent tool and shows itself to be the equal of git in a number of ways, especially speed. In fact, as Linus has pointed out, the two are actually quite similar in their underlying behaviors. Clearly, both of these tools represent an entirely new look at version control, and projects like arch that had previously been in the lead are finding themselves struggling to catch up.
Markus Klotzbuecher has produced an interesting new virtual filesystem called mini_fo (fanout overlay). It allows users to write to files on read-only filesystems, by creating a writable area elsewhere and layering the user's changes from that area on top of the read-only data. To the user, the effect is transparent. What had been read-only, now appears writable, although in fact the read-only data is never actually modified. The mini_fo tool is intended to allow software upgrades on embedded systems, but other uses have already been found and more undoubtedly will appear.
Alan Cox and Bartlomiej Zolnierkiewicz, two big-time IDE developers, are having trouble pooling their efforts. While Bartlomiej is the current IDE maintainer, Alan did much of the initial work to convert the old IDE code into a maintainable state from the unutterable corpse-strewn nightmare it had been for years. Although Alan has been somewhat out of the Linux picture lately, he returned to check on the progress of IDE and didn't like some of the changes Bartlomiej had made. There does seem to be some bad blood between them, as there seems to be between any developers who have at one time or another worked on IDE. Bartlomiej invited Alan to fork the code and do things differently if he pleased.
It's sad that IDE is still able to inspire enmity among developers. For this we should blame the IDE disk industry itself, which has so warped and destroyed any possible standard, creating exception upon exception upon exception, compounding all of it with trade secrets and proprietary documentation, that anyone would have to be insane even to attempt to maintain the IDE kernel code. That folks like Bartlomiej and Alan, and those that came before them, like Mark Lord and Andre Hedrick, have done so is a tribute to their generous natures. Without the IDE code, most of us would not find Linux nearly as useful.
Benjamin LaHaise recently tried to simplify and make more maintainable the implementation of semaphore locking across kernel architectures. The current code is complex and difficult to read, with many architecture-specific details. These nuances have grown with the number of supported architectures, and the natural inclination is to create a generic semaphore system that compiles and works on all architectures uniformly. However, semaphores run deep, and the need for blinding speed in that code is difficult to compromise on. Given that any slowdown would have a noticeable impact on kernel performance, it's likely that any attempt at code unification will meet strong resistance by the maintainers of the various architectures. This is in fact how Benjamin's work was received. And so, while some improvements certainly may be made, it seems unlikely that the semaphore code will ever become truly generic and simple. Speed is just too strong an incentive.
Linux audio developers and musicians came together for the third annual Linux Audio Conference, held April 21–24 at the Zentrum fur Kunst und Medientechnologie (ZKM, the Center for Art and Media Technology) in Karlsruhe, Germany. This event included topic presentations on sound and music software, such as hard-disk recording, sound synthesis languages, music composition, softsynths, MIDI technologies and audio-optimized Linux distributions, along with two concerts and two more music programs. The entire conference was broadcast and recorded in audio and video formats.
Ivica Bukvic stressed the need for a coordinating effort to ally developers with manufacturers, vendors and possible sponsors more closely, while Christoph Eckert focused on the need for greater concern for usability issues. The conference also included an update from Maarije Baalman regarding her WONDER software and a report from Georg Bonn on free software for music composition.
A presentation on FireWire as an audio interface created quite a stir among developers, particularly since no manufacturer has yet disclosed driver code for any available FireWire audio interface. Track 2 covered software, including the MusE audio/MIDI sequencer, the ZynAddSubFX synthesizer and the Ardour digital audio workstation.
Linux sound and music applications have become a real choice for musicians and sound researchers, and the music at both concerts put the issue to rest. Participants and guests also enjoyed Linux Sound Night, during which developers of Linux music performance software got to show us what their programs could do. The Sound Night shaded imperceptibly into Linux Chill Night, ending an exhilarating day with more music, dancing, drinks and conversation.
Standout presentations included the FireWire and Ardour demos already mentioned, as well as Julian Claasen's presentation on his text-based studio. The Ogg Vorbis and Ogg Theora audio and video streams were set up and managed by conference stalwart Joern Nettingsmeier and newcomer Erik Rzewnicki. The A/V streams were themselves a demonstration of the power of free and open-source software. I am happy to announce that LAC2006 will be held again at ZKM.
The motley crew (photo by Frank Neumann).
Resources for this article: /article/8410.
GNOME users and developers alike descended on Stuttgart, home of Porsche in southern Germany, for the sixth annual GUADEC—the GNOME User and Developer European Conference—to discuss the future of GNOME development, hear about business and government migration to Linux desktops, marvel at the latest cool applications and cunning hacks, and witness Nokia's awesome announcement of its GNOME-powered 770 Internet Tablet and developer's program.
Keynote speakers at the May 29–31, 2005 conference included Miguel de Icaza, GNOME founder and Vice President at Novell; Mark Shuttleworth, Canonical founder and one-time cosmonaut; and Nathan Wilson, Software Lead at DreamWorks Animation Studios. Miguel gave, as usual, a rousing talk on the future of GNOME, Mono and Linux as a whole, and Nathan discussed DreamWorks' transition to a GNOME-based Linux desktop. Madagascar, DreamWorks' next animated feature film, was made with GNOME!
Quality speakers abounded too, including Owen Taylor, Gtk maintainer; Keith Packard, X supreme commander; and Jon Trowbridge, Beagle maintainer. Anna Dirks and Pete Goodall, both of Novell, presented results from their in-depth Windows Migration Study. Glynn Foster of Sun gave a moving introduction to the GNOME Project. They even let me speak, against better judgment, on optimal GNOME programming techniques.
The most valuable part of the conference, however, was the informal hallway chatter and the widely attended hackfests, where GNOME hackers could meet (many for the first time), debate hot topics and then sit down and hack out elegant solutions.
GUADEC veterans such as Nat Friedman remarked that “this may be the best GUADEC ever.” While I was without reference—this was my first, but hopefully not my last GUADEC—it was certainly time well spent, in a beautiful city with some smart folks.
Matthew Gast, author of this month's article on xsupplicant, spent part of his summer co-teaching a class in Australia with Chris Hessing, lead developer of the xsupplicant Project. Lucky for us, the LJ Web site got an “Interview with Chris Hessing, Lead Developer of xsupplicant” article out of the deal (www.linuxjournal.com/article/8388). Read what Chris had to say about developing one of the two major 802.1x client packages for Linux, including some of the challenges of developing on Linux, keeping up with the relevant standards and why it is difficult to build WPA(2)/802.11i support for Linux.
In an upcoming article, Michael George will be covering “Building a Call Center with LTSP and KPhone”, including some of the problems he ran into when installing and configuring KPhone, such as a configuration option that doesn't seem to change anything and icons not being found. Because of these factors “Building kphone was a bit more complicated”, and our Editor in Chief asked Michael to follow up with the KPhone developers by submitting a bug report. In his LJ Web site article “Filing a KPhone Bug Report” (www.linuxjournal.com/article/8389), Michael updates us on what, if any, progress has been made.
...how are you arranging your conclusions so that your current experiences fit into your scheme of complacency?
—Carlos Casteneda, The Power of Silence
The greatest mistake we can make is to be continually fearing that we will make one.
—Elbert Hubbard, www.downtheavenue.com/2005/05/random_reflecti.html
The lack of any concrete numbers at all shows the typical academic hand-wavy “our asymptotic is good, we don't need to worry about reality” approach. Good asymptotics are one thing, but constant multipliers can be killer, and it's necessary to work out constant multipliers for all potentially problematic constants, not just the easy ones like CPU.
—Bram Cohen, www.livejournal.com/users/bramcohen/20140.html
He is no fool, who gives what he cannot keep to gain what he cannot lose.
—Jim Elliot, www.tonywoodlief.com
The true lesson of the Internet is in the end-to-end argument. It gives us a real working model of how individual efforts can composite into a valuable whole.
—Bob Frankston, www.frankston.com/public/writing.asp?name=DIYConnectivity