Back in 2004, your editor grumbled
about the state of electronic mail clients
, noting that much of the
wisdom encoded in the venerable MH system seemed to have been lost. Nearly
six years later, it often seems that the situation has not improved much.
Contemporary email clients are large, monolithic blobs which may look
pretty, but they do not play well with other tools and seem to get in the
user's way as often as not. So, when Dave Jones said
I'm convinced there's some contest to see who can make the worst
graphical mail client for Linux. I'm not sure what the prize is, or
who's winning, but the entries so far are horrific.
Your editor had no choice but to agree. Since then, the situation does not
appear to have improved much.
The Notmuch mail client has been on
your editor's radar for some months now. Recently, the opportunity to play
with this new tool came by; this review is the result. In short: Notmuch
looks like it is coming from the right place, but, as befits a program in
such an early stage of development, it has some ground to cover yet.
The core of Notmuch is a command-line client which, as they say, does not much.
One starts by running notmuch setup to put some basic
information into the configuration file, followed by
notmuch new to initialize the mail database. That process
involves reading and indexing every message you have (messages are stored
one-per-file, so Notmuch deals just fine with MH or Maildir trees). Even
though the program cheerily declares that you have "not much mail" at setup
time, the indexing process can take quite a while; it also doubles the size
of the mail store. This step is not optional, though; indexing is at the
core of how Notmuch works.
After setup, one can use the notmuch client to perform searches,
modify tags, display messages, and compose replies. In a sense, it looks
back to the early MH days, when everything was done at the shell prompt.
The Notmuch developers do not really expect that users will use the
command-line client directly, though; instead, it is assumed that some sort
of user interface will be layered over it. There are a few such interfaces
available now, but the interface of choice for the Notmuch developers at
the moment would appear to be Emacs.
The Emacs notmuch-mode looks, in many ways, like most other Emacs-based
mail clients. There are a few differences, though, starting with the fact
that folders are a completely alien concept. This is 2010, and folders
have been consigned to a dim, dusty, and hierarchical past; now we do
everything with tags. So there's no "inbox" in Notmuch; instead, one sees
the results of a search for the "inbox" tag. Something similar to refiling
can be done, should one so desire, by attaching different tags to the
message, but one gets the sense that's not expected to happen very often.
This is the era of search, so a specific view of the mail store is just a
Indeed, searches in Notmuch (powered by Xapian) are very fast and very flexible. The
syntax is reasonably straightforward and the results are nearly
instantaneous. There is an easy feature for further narrowing the results
of a search. It is a powerful and flexible way to deal with large
quantities of mail.
The process of reading through mail, though, is still in need of some work;
the Emacs interface is not, yet, at the level of usability offered by, say,
MH-E - and one would ideally set the bar higher than that. There does not
appear to be a way to look at the structure of threads in the
folder search results view; each thread is collapsed into
a single line with a few of the participants listed. Displaying that
thread dumps all of the messages into a single Emacs buffer, which can then
be paged through. Your editor would rather see the thread structure and
individual messages, preferably at the same time.
Working through mail, your editor notes, can be quite slow, with noticeable
delays between messages. That would appear to be a result of the removal
of the "unread" tag from each message as it is viewed. Tagging operations
in general seem to require significant index changes; it may well be that
storing mail on a solid-state storage device will be required to get
acceptable performance for this kind of operation.
Notmuch doesn't handle composition and sending of mail at all; it defers to
the standard Emacs message mode for that. It also doesn't try very hard to
display attachments; images, for example, are handed off to external helper
programs even though Emacs can display such things inline. When it comes
to HTML parts, notmuch-mode does not even try; this, of course, might be
seen as a significant advantage.
Is your editor switching to Notmuch? Not yet. Notmuch requires that all
mail be stored locally, but your editor likes having that central IMAP
server available. There are developers working on tools for synchronizing
mail and tags between stores; some folks are even seriously looking at
using git as the underlying mail store. There's also no support for
multiple email accounts; that is probably trivially fixable by adding a
command-line option allowing easy use of multiple configuration files. And
the interface remains a little rough.
In the longer term, though, Notmuch could well become your editor's mail
tool of choice. The fundamental approach looks right, and the
tool-oriented nature of the plumbing should enable the easy scripting of
operations on messages. There is an active and growing community of users
and contributors; Notmuch has the look of a successful project. This tool
looks like it could become a powerful utility indeed in not much time at
Comments (18 posted)
Paul Davis has an update on Ardour development
, which looks at the upcoming 3.0 version, as well as maintenance on 2.x. Ardour
is a "digital audio workstation" that runs on Linux and MacOS X.
"This work went along with a top-to-bottom revisit of the undo/redo mechanism with the goal of making it scale properly to operations involving large numbers of regions. The results? Operations that were taking an absurd amount of time (40 seconds) to undo can now be undone in less than half a second. The overall responsiveness of undo/redo has now greatly improved.
" Davis also points
to a recent ShotOfJaq podcast
on funding models for free software projects that uses Ardour as an example. The comments on the podcast page are worth reading as well.
Comments (none posted)
Version 4 of the DWARF debugging information format specification
has been released for public comment. DWARF is used by GCC, GDB, and other free and proprietary toolchains. "Michael Eager, Chair of the DWARF Committee, said 'we have made significant
improvements in Version 4 since the previous version was released in 2006. These
include improved data compression, better description of optimized code, and
support for new language features in C++. Debugging programs can be difficult.
Providing the best quality information to programmers can make this easier.'
" The DWARF committee is accepting public comments on the spec until May 31. Click below for the full announcement.
Full Story (comments: 2)
Version 7.1 of the GDB debugger is out. The big changes appear to be
multi-program debugging and the ability to work with PIE executables.
There's also a couple of new platforms supported and a number of other
Full Story (comments: 8)
Greenlet 0.3 is out. It is another Python implementation, based on
Stackless Python, but with a twist:
A "greenlet", on the other hand, is a still more primitive notion
of micro- thread with no implicit scheduling; coroutines, in other
words. This is useful when you want to control exactly when your
code runs. You can build custom scheduled micro-threads on top of
greenlet; however, it seems that greenlets are useful on their own
as a way to make advanced control flow structures.
This release adds some new features, a number of unit tests, and support
for Python 3.
Full Story (comments: none)
entry in the not403 blog
discusses OpenSSO, a single sign-on
project which Oracle acquired from Sun and has subsequently
shut down. "A Norwegian company called ForgeRock has stepped up to
give OpenSSO a new home and continue developing OpenSSO under a new name:
OpenAM (because of copyright issues with the name). They claim they will
continue with Sun's original roadmap for the product, and they have started
to make available again all of the express builds, including agents, that
were removed from OpenSSO's site, and a new wiki with all the content that
once was available at dev.java.net.
Comments (3 posted)
The Python 2.6.5
releases are out. Both
releases fix large number of bugs and are intended for production use.
Comments (none posted)
Udisks is the new name for DeviceKit-disks, a utility for the low-level
management of block devices. With the 1.0.0 release, the developers have
committed to ABI compatibility through the 1.0.x series; a number of
features have been added as well.
Full Story (comments: 6)
Newsletters and articles
Comments (none posted)
Joe 'Zonker' Brockmeier reviews
Claws Mail. "Modern mail user agents (MUAs) tend to hide as much complexity from the user as possible. Claws, bless its speedy little heart, doesn't. Claws is extremely configurable, feature-rich through the use of plugins, and can be keyboard-driven to satisfy users who want the speed of text-based mailers like Mutt with a decent GUI.
Comments (3 posted)
Dave Phillips continues
his coverage of Linux arpeggiators. "Part 1 of this series introduced arpeggiators in general and profiled the QMidiArp application. This week we conclude our survey with a look at two more arpeggiators for Linux musicians: Hypercyclic and Arpage.
Comments (none posted)
Luis Villa compares mailing lists and parties
on his blog. He is reacting to a blog posting
by Máirín Duffy that mocks up a web-based mailing list interface that incorporates feedback for readers and posters. Villa sees the feedback as being essential to reducing "bad conversations" on mailing lists.
"First, the similarities. At most parties, like most mailing lists, most people want to have interesting conversations, and they understand the shared social standards and interests of the other people at the party. And at most parties and most mailing lists there are a handful of people are boors who probably dont want to spoil the party, but who violate those shared norms- some in very mild ways (boring, talking too loud, posting too much), or maybe some less mild (the guy who doesnt think hes a racist, but really is.) If youve got similar mixes of people, why then do parties usually handle boors well, while mailing lists often fail and flame out?
Comments (36 posted)
Page editor: Jonathan Corbet
Next page: Announcements>>