Bringing you the latest news from the Linux World.
Dedicated to keeping Linux users up-to-date, with concise news for all interests
On the Desktop
Linux in the news
All in one big page
Here is the permanent site for this page.
See also: last week's LWN.
The janitors get organized. The last few months have seen a flurry of activity from a group of developers known, informally, as "kernel janitors." As suggested by their name, the janitors make it their job to clean up messes in the kernel code base; much of their recent work can be seen in the "ac" series of kernel patches. Recent contributions include fixing a mass of erroneous user space pointer dereferences, straightening out inconsistent treatment of kernel locks, and even hundreds of spelling fixes.
Thus far, janitorial work in the kernel has been handled the way much kernel work is done - a job gets done when somebody decides to do it. Some coordination happened by way of the kernel janitor's list, a web page maintained by janitor extraordinaire Arnaldo Carvalho de Melo, but the janitors have remained a spread-out group.
No longer. Arnaldo Carvalho de Melo has announced the creation of a separate kernel janitor's project. Like any self-respecting project these days, it has a SourceForge page, but there's not much there at the present. What does exist is a mailing list and a CVS version of the janitor's TODO list. The mailing list has already started to see traffic on janitorial techniques and kernel problems in need of fixes; one can read about the proper way to initialize string variables at compile time or plans for the death of spin_lock_irq(). The janitors are getting organized.
This project raises an interesting question. The need for janitorial work is reasonably clear. Any large body of code is going to have its dark, dusty areas in need of a serious sweeping, and the kernel is a larger and more complex body than many. And the janitors have noted an important point: an error pattern that is found in one section of code has a high likelihood of recurring in other places. Once a particular type of mistake has been found, it makes great sense to go looking for instances of the same mistake elsewhere. This is essentially the same approach as that used by the OpenBSD team to root out security problems before they are exploited.
But why would kernel hackers go in for this kind of work? The kernel is full of interesting jobs that need to be done; why would a talented hacker pass them up in favor of auditing some obscure driver's locking discipline? We asked Arnaldo that question, and got the following response:
Because somebody has to do it? :) For the kernel to be considered really stable it can't stop working even in the more uncommon situations, where lots of the janitorial work has been concentrated, and it also gives kernel newbies interested in getting into kernel hacking a good start, because we have to study code and see how parts of the kernel works so that we can start fixing these small bugs....
In fact, janitorial work can be a good entry path for aspiring kernel hackers. Performing major surgery on the kernel and getting the changes past the gatekeepers can be an intimidating prospect; small and obvious bug fixes are a much easier start. And they can lead to bigger things:
Look at me, now I'm being considered to become the kernel IPX networking stack maintainer, and this happened because I wanted to get rid of some cli and sti instructions, used for locking, and use more modern and SMP friendly locking techniques, namely spinlocks and reader writer locks...
Janitorial work, thus, is a good entry path for those wanting to build some experience and reputation capital in the kernel development community.
The organization of the janitors can be seen as another sign of "growing up" in the Linux community. As the kernel grows and evolves, organizations develop around it to keep things clean and ensure the quality and stability of the code base. At some point, the kernel may even have an organized patch management scheme, regression tests, and other tools that many development projects have taken for granted for some time. Certainly the janitors have already been greatly helped by the Stanford checker (discussed in last week's LWN kernel page).
The kernel, meanwhile, is far from the only large development project in the free software community. No doubt, many other projects should look at the kernel janitors organization and consider setting up something similar. The benefits, in terms of improved code and a better supply of new hackers, could be both large and immediate.
Writeup: Singapore Linux Conference/LinuxWorld Singapore 2001.
While the rest of us were dealing with Colorado snow, LWN editor Liz
Coolbaugh attended the Singapore Linux Conference/LinuxWorld Singapore
2001. She has now posted an
extensive writeup of the event, including a report from Donald
Becker's keynote and many pictures. It looks like a successful
conference, if not as heavily attended as its organizers would have
liked; it gives a good picture of the adoption of Linux in Asia.
Three years of Mozilla. Three years ago, with great fanfare, Netscape released the Mozilla source to the world. It was one of the defining moments in the history of free software: a large, proprietary product was being freed as a response to competition from Microsoft. To many, it was the event that brought free software (or "open source," a term which was born in the middle of all this) out into the open. It was a sign that the corporate world was beginning to see the value in free software.
Three years later, how does it look?
Mozilla has spent much of that time being presented as a free software failure. The "milestone" releases have, until recently not been up to even alpha-level quality. Mozilla has been seen as an example of features and bloat gone mad. The low point, perhaps, was when NTK sounded off in classic fashion:
Far be it for us to intimate that MOZILLA has been hijacked by the same naive completeness fanatics that collapse so many free software projects into development black-holes, but ... oh come on, two years and counting? Seventy megabytes of swap? Per *window*? Hello? Is there some kind of AOL/ crack cocaine stock-swap going down at Mountain View?
It is also the second anniversary of Jamie Zawinski's high-profile resignation from the project, which also did little to help its image. Finally, the Mozilla-based Netscape 6 release has gotten an unenthusiastic reception. Mozilla, at times, has seemed like an example of the worst that free software projects can be.
Not so quick, though. In the end, Mozilla will be seen as a slow-starting but highly successful software development project. Consider:
Mozilla is quickly approaching its goal of producing a great, free web browser. Along the way, it has taught us a number of lessons. One, certainly, is to look carefully at large piles of code when they escape from the proprietary world. Thus, for example, OpenOffice has been received with much more cautious and realistic expectations than Mozilla was, which is to everybody's benefit.
Another is that focus is important. Had Mozilla concentrated on producing just a web browser, it would likely have been further along at this point. Konqueror, while far from a small program, is an example of what can be done with a more realistic (though still ambitious) set of objectives.
Yet another thing we have learned is that bringing new developers into large projects is hard. For somebody new to a project, the code base is usually poorly documented and difficult to understand, and mailing list discussions appear to be conducted in Martian. Recognizing this, many large projects have tried to help new developers with special documentation, mailing lists, and so on.
The last lesson, perhaps, is this: don't write off a free software project too soon. A year from now, many of us will have Netscape-free desktops, and Mozilla will be the replacement on many or most of them.
Inside this week's Linux Weekly News:
This Week's LWN was brought to you by:
March 29, 2001