That review mentioned a client called sylpheed-claws; at that time, this client was being managed as a sort of development branch for sylpheed, with every intent of getting changes back into that system. Since then, sylpheed-claws has evolved into a full fork intended to create an independent application; it's new name is Claws Mail. In 2004, your editor had found sylpheed-claws to be an unstable platform at best; in 2008, it seemed like time to go back and see what the developers had accomplished in the last four years. To that end, Claws Mail 3.4.0 was installed and put through its paces.
The good news is that this client has, indeed, stabilized over time. Your editor was unable to make it crash - always a nice feature in a mail client. Many of the features which were under development four years ago are now stable and supported - and, generally, well documented. Claws Mail has come a long way.
The Claws Mail developers emphasize configurability, so there's a wide variety of options to wander through. The layout of the window is highly configurable, allowing the user to make the best use of the available screen space. Most aspects of the client's behavior can be tweaked. For somebody who is willing to wander through a long series of configuration screens, Claws Mail offers the ability to adapt the client to just about any set of needs.
Dealing with email is a keyboard-intensive activity. One of your editor's biggest complaints with graphical clients has been the need to switch constantly between the keyboard and the mouse - a transition which breaks focus and steals time. Claws Mail has improved things in this regard, in that a wide variety of actions can be handled without the mouse. And, unlike some other graphical clients, changing the keyboard bindings is easily done.
For some simple operations - plowing through a mail folder, reading and deleting messages - Claws Mail can be visibly slow. Working over IMAP does not help, of course, but it is slower than with, for example, Thunderbird. In addition, by default, Claws Mail will not display a message which becomes selected as the result of, say, deleting the message before it. So the cycle of deleting a message and viewing the next one requires two keystrokes or clicks. That particular problem can be configured away, of course. Much of the remaining slowness can be mitigated by turning off the "execute moves and deletes immediately" option - a change which also makes it easier to recover from overzealous "delete finger" reflexes.
One common bit of workflow for your editor involves feeding a message to an external program. As a general rule, graphical mail clients do not make this possible, though this feature is almost universal in non-graphical clients. Claws Mail includes the concept of "actions," which are, essentially, external programs which act on messages. This feature almost solves the problem; actions can be set up with quite a bit of flexibility, and they can be bound to keystrokes. But there is no equivalent to the "|" operation provided by textual clients, meaning that it's not possible to pipe a message into an arbitrary command. Claws Mail only passes through the mail headers which are visible on the screen - and there appears to be no way to configure that behavior.
HTML mail appears to be an unfortunate fact of life on the contemporary net. Claws Mail will render such mail as text by default; there are also a couple of plugins which can render HTML mail as intended by its sender. It warmed your editor's heart to note that Claws Mail (unlike certain other clients) does not send HTML mail by default. In fact, it lacks the ability to send HTML mail at all. These developers seem to have their priorities in the right place.
Offline operation is another nice feature in a mail client. Claws mail has such a feature, but your editor was only able to get it partially working. The client can gather up mail for offline reading, but changes and sending of mail lead to a series of "I can't do this" dialogs. Some more configuration (e.g. setting up a local drafts folder) helps in this regard, but this area looks a bit like a work in progress.
There's no end of other features, of course. Claws mail supports encrypted mail, spelling checking, filtering of messages on arrival (with an optional Perl plugin for those especially complicated filtering jobs), a mail template facility, color-labeling of mail, tagging, scoring, watching of threads, and more. There are plugins which will turn on a laptop LED when mail arrives, strip attachments, view PDF files, track RSS feeds, deal with vCalendar messages, etc. There is a complex search mechanism which can do a lot more than just string matches. It is, in summary, a highly capable tool with more features than just about anybody is likely to use.
So has your editor made the change? Not yet. Ways around some of the speed issues will have to be found, and it may be necessary to write a plugin to make Claws Mail work with some LWN processes. A few other details need to be made to work correctly. But it can be said that Claws Mail has gotten closer than any other graphical mail client that your editor has tried to date.pointed to a weblog entry describing the Firefox 3 fsync() bug, the result was (at last count) over 90 comments. Clearly something is going on here to stir up this level of conversation. It's not clear that all participants are taking away the right conclusion, though.
Firefox 3 uses the sqlite database, as do a number of other applications. In this case, the database is being used to store the user's browsing history; an active user can create quite a bit of database traffic in a short amount of time. As part of updating the database, sqlite will call fsync() to ensure that the data gets to the disk. All fairly normal stuff which shouldn't create trouble for anybody.
Except it does create trouble because (1) these fsync() calls are made frequently, and (2) Linux filesystems do not handle fsync() as well as they should. As a result, heavy use of Firefox 3 on a Linux system can cause the system as a whole to perform poorly. It's clearly an issue that the Firefox developers need to fix, even if it's not entirely their fault. And it appears that they do, indeed, plan to fix it.
One could argue that Firefox 3 should never have gotten as far as a release candidate with this sort of bug unfixed. The problem was first reported in early March, but the conversation did not get going in earnest until late April. So there was not a whole lot of time to figure out a fix for the release candidate.
More justifiably, it could be said that the developers' consideration of shipping the final release with this problem unfixed was insensitive to the needs of Linux users. The notion that they would bless distributors who patched the problem themselves does not help much in this regard. That thought does raise an interesting question, though: what would have happened if Mozilla did not bless a patch, then denied use of the "Firefox" trademark to distributors who fixed the problem anyway? But all of this is moot; it appears that the Firefox developers have decided to do a second release candidate which includes a fix for this problem.
The other common complaint has to do with why Firefox is using a relational database in the first place. It is, arguably, a significant bit of bloat for an already large application. The answer from the developers is that a real database is needed to provide the kind of features that Firefox users are asking for. As the discussion on LWN showed, there really are users who want quick access to significant amounts of history. Your editor has, so far, not had his socks knocked off by the "awesome bar," but other users clearly have.
There is value in adding features that your users will call "awesome." There is also value, of course, in the creation of a small and fast application. The Firefox developers have had to chart a course between the addition of features and keeping the overall size reasonable, and they have taken grief for their decisions on both sides. One user's bloat is another user's indispensable tool; it's hard to keep everybody happy. But one generally keeps more users happy by including the features they want.
Despite all of that, Firefox 3 clearly shows the results of some attention to performance and memory use. Your editor has not done any sort of formal benchmarking, but a few months of use of the beta releases leads to the conclusion that Firefox 3 is more responsive than its predecessor, and that many of the worst memory usage problems have been addressed. It has been a while since the days when regular restarts to combat the effects of memory leaks were required. Firefox will never be a lightweight program - or even a middleweight program - but it does appear that, for now, the monster's growth has been restrained.
Firefox 3 also includes greater GTK integration, which has inspired complaints of its own. But better integration with the Linux system has been something users have been requesting for a while. It is hard to fault the developers for trying to satisfy that request.
All told, it would appear that the Firefox community is trying to follow through on its promise of better support for Linux users. They seem to be doing what has been asked of them. In so doing, they have produced a new major release which, for whatever faults it may have, is a real improvement on what came before. The development process which helped to rescue the net from proprietary software and standards continues in full swing. There will, beyond doubt, be no shortage of things to criticize the Firefox developers for in the future. But, before we do that, it's worth taking a moment to back off, let them get the 3.0 release out the door, and congratulate them for a job which is truly, in many ways, well done.
Most free software projects encourage contributors—it is the rare project that has an overabundance—but contributions vary greatly in quality. Encouraging good submissions, or those likely to lead to useful contributions down the road, is an important part of any project. But it is a delicate balance. It can be difficult to determine the kinds of tasks suitable for new contributors that will lead to more important contributions later.
The flip side of that coin is how to handle contributions that appear to lead elsewhere. Just wading through the significant submissions on a large project's mailing list—linux-kernel being an excellent example—is extremely time consuming; adding noise, in the form of less-than-completely-useful patches, only makes that job harder. New contributors generally want to start with something relatively easy, though, which leads to the tension.
Discouraging patches that aren't particularly useful in a way that won't chase off prospective kernel hackers is hard. Al Viro's rather intemperate call for discussion of a linux-wanking mailing list on linux-kernel is probably not the right approach. He was responding to a patch that reformatted a kernel header file to line up the arguments. Viro is not known for his diplomatic skills, but he was responding to a problem that he and other kernel hackers see. There is an increasing amount of trivial cleanup work being submitted that is not translating to more substantial, useful contributions later on.
In a followup post, Viro explains his concern:
There is a real cost associated with posts to linux-kernel. It is the main communication mechanism for kernel development so those involved need to work through the posts there. David Miller laments the time he spends sorting through it all:
Wouldn't you like me to instead have the energy left to review some useful patches?
The kernel project provides a number of resources for people who are interested in getting involved but don't know where and how to start. The Kernel Newbies effort is specifically designed to help people get started with the kernel by running a wiki, mailing list, and IRC channel that are focused on the needs of, well, newbies. The idea is to provide information and mentoring that will lead to useful contributions to the kernel.
A subproject is the Kernel Janitors who focus on cleaning up kernel code:
Both of these efforts are targeted at getting people up to speed so that the kernel as a whole improves. All of the work is important, but there are many other kernel tasks that are not getting done, possibly because contributors are concentrating on cleanups. Andrew Morton has some suggestions for interested folks:
One problem, though, is that much of that work is more difficult than a whitespace cleanup. For those who are interested in getting their name "up in lights"—in the form of a kernel commit message—the trivial patch path appears easier. Responses like Viro's may deter them, but it risks making linux-kernel look like a hostile place that does not encourage new developers.
Some extremely important kernel tasks often do get little or no recognition. Submitting detailed bug reports, bisecting the kernel to find the patch that broke things, or testing proposed fixes go unrecognized—at least in the kernel commit log. There have been thoughts of adding tags to the patches that would note these contributions, but no concrete proposal has been made.
Two other documentation efforts are underway to assist new kernel developers. Jesper Juhl is working on a Kernel Newbies Guide to be included into the kernel Documentation tree. It may get folded into Documentation/HOWTO or as a separate file, but the idea is to steer folks in the right direction—and away from the kinds of patches that raise the ire of kernel hackers. LWN's Jonathan Corbet also mentioned a longer document he is working on with support from the Linux Foundation that should be ready for review in June.
There may be some rudeness or hostility towards new developers on linux-kernel, but it rarely rises to the level seen on the openbsd-misc mailing list last October. In response to a query about a list of less complicated tasks for OpenBSD—similar to what the Linux Kernel Janitors maintain—project leader Theo de Raadt, who is really not noted for his diplomacy, blasts:
I'll say it again more clearly -- all of you whiners just plain suck. We know you'll never write diffs, and it is up to you to prove us wrong. If you don't write diffs, we have a difficult time feeling any loss.
This is sort of the extreme end of the "show us the code" attitude, but, in his own inimitable way, de Raadt is reacting to the same problem. It takes time and effort to shepherd new kernel hackers. Spending time mentoring folks who will never end up contributing is a waste; that time is better spent finding, fixing, or adding bugs. As Linux hacker Ted Ts'o puts it:
How does a project determine which newly interested people will end up being useful contributors versus those that will not? It is a difficult problem that warrants some thought. It surely isn't just kernel projects that have it, as any large, high-profile project will have both a fairly high barrier to entry along with some developers who should be discouraged.
Obviously there will never be a clear-cut "future contributor" test, but there may be ways to get a better idea. In the meantime, flaming well-meaning folks to a crisp is unlikely to get there. Referring inappropriate patches to Linux Newbies or something similar—on the off chance the person can be redirected—might be a start.
Page editor: Jonathan Corbet
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds