The Grumpy Editor's guide to
graphical email clients
was published almost exactly four years ago.
At that time, your editor was looking for a client which could replace an
MH-based setup which, for all its age, provided a degree of speed and
flexibility which was hard to match. Your editor gets a lot of mail - even
before lists like linux-kernel are factored in - so there is a real need
for a mail client which can process messages without adding even a few
seconds of overhead. At that time, none of the clients reviewed were up to
the task; it seems that developers of graphical clients value a number of
features above speed and flexibility.
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
Comments (22 posted)
Normally, one would not expect a posting about a performance-related bug in
pre-release software to generate a great deal of interest. But when LWN 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
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
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.
Comments (38 posted)
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
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:
We are getting another self-contained area. Namely, "pick a
pointless mechanical work out of ever-growing pile, do it, learn nothing,
pick more, maybe look into finding new classes of such mindless stuff".
Of course it always had been there; what changes is that now it's not
just a transient state one might hit on the way in to be slightly
about years later. It gets more visible, it gets self-sustained and it
gets more and more sticky - it became a subculture in its own right and
as far as I can see it is offering more and more incentives to stay in it
instead of moving on.
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
After deleting all of the noise posted here, I'm often too burnt out
to do real work with what's left and just delete that too. :-/
It's worse than the postmaster and list owner mail I process each
day for vger.kernel.org
Wouldn't you like me to instead have the energy left to review some
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:
We go through the Linux kernel source code, doing code reviews, fixing up
unmaintained code and doing other cleanups and API conversions. It is a
good start to kernel hacking.
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 could understand a developer deciding to write a do-nothing
whitespace patch as a general throat-clearing exercise, but when asked,
I recommend against that. I generally recommend that people just
download and test the latest -rc, linux-next and -mm kernels and build
and run them. Because they surely will find things which need fixing.
Often simple little things like compilation errors, sometimes things
which need a bisection search.
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
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:
Surely they are too busy whining at us for lists, to actually search
for the lists.
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
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:
The real question is whether people who are wanking about whitespace
and spelling fixes in comments will graduate to writing real, useful
patches. If they won't, there's no point to encouraging them.
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
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.
Comments (45 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Attacking network cards; New vulnerabilities in emacs, kernel, php libcurl, samba,...
- Kernel: Responding to ext4 journal corruption; Using the firmware loader for static data; GEM v. TTM.
- Distributions: Fedora's Packager Sponsors Responsibility Policy; Red Hat Enterprise Linux 5.2; Thesis on openSUSE Published; FAN (Fully Automated Nagios); Freezy Linux; Wicker
- Development: The Open Graphics Project prepares to release hardware, Multi-pointer X is coming, coding rules checker for GCC, new versions of DbUnit, pgDesigner, Samba, OpenSSL, CommSy, Contineo, Audacious, XCircuit, Stella, CSSBox, GIT.
- Press: Debian openssl aftermath, KDE at LGM, YAPC::Russia, Wind River and Intel partner, Linux for the London subway, new trade agreement may affect copyrights, Mark Shuttleworth interview, second generation OLPC, Red Hat and Novell enterprise upgrades.
- Announcements: GPL-Violations.org and FSFE FTF work together, Facebook supports XMPP, Gentoo Foundation reinstated, ELC-EU cfp, NLUUG cfp, Low Level Virtual Machine Developers' Meeting.