Other LWN stuff:
 Daily Updates
 Calendar
 Linux Stocks Page
 Book reviews
 Penguin Gallery

 Archives/search
 Use LWN headlines
 Advertise here
 Contact us

Recent features:
- RMS Interview
- 2001 Timeline
- O'Reilly Open Source Conference
- OLS 2001
- Gaël Duval
- Kernel Summit
- Singapore Linux Conference
- djbdns

Here is the permanent site for this page.

See also: last week's LWN.

Leading items and editorials

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....

Other motivation is that janitor work doesn't require that you spend that much time, and for people too busy but willing to help, this can be the way to help.

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:

• The Gecko HTML rendering engine has brought a new level of speed and standards compliance to Linux-based web browsers. It is at the core of the Galeon and Skipstone browsers, both of which are coming along nicely and seeing increasing numbers of users. Gecko is also been picked for a number of embedded applications.

• Perhaps more to the point, the Mozilla browser itself is reaching a point of true usability. It now works well enough that people other than those hacking on the source may actually want to use it - especially when they find some of its nice features, such as its rendering speed, the ability to set minimum font sizes (no more squinting at obnoxious sites), and the ability to limit animated images. The Mozilla roadmap shows high hopes for a 1.0 release sometime quite soon. The 0.8.1 release, meanwhile, adds a number of new features, including the ability to browse Gopher sites, assuming you can find one still standing.

• A look at the Mozilla projects page shows an unbelievable amount of development activity. Mozilla has become the central point for a great deal of web-based development activity; expect no end of great tools to come out of there in the coming years.

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:

• Security: 2.2.18 security issue with published exploits, OpenSSH 2.5.2p2, FCheck, MySQL vulnerabilities.
• Kernel: 2.4.2 glitches; regression testing; the proper size for dev_t.
• Distributions: What's the most popular Linux distribution in Singapore?
• On the Desktop: KDE 2.1.1, Siag Office, Mozilla 0.81, Mahogany 0.62.
• Development: HappyDoc, Linux LVM, State Map Compiler 1.0, KDE Developer's Checklist.
• Commerce: ArsDigita Community System; OEone to build appliance environment with Mozilla; Privacy Foundation report on TiVo.
• History: Three years ago Mozilla was released; One year ago LWN was acquired by Tucows.
• Letters: The leading distribution; fair use; but no letters about socialism.

This Week's LWN was brought to you by:

• Jonathan Corbet, Executive Editor
• Elizabeth O. Coolbaugh, Managing Editor
• Michael J. Hammel, Senior Editor

Next: Security