Your editor's desktop system is currently running Fedora Core 2,
mostly as a result of that distribution's combination of near-bleeding-edge
software and the x86_64 architecture. There is much that is good about
Fedora, but your editor was more than disconcerted to find out
that nmh, the current form of the MH mail client, was no longer included.
This is not an isolated point of view; a threat
to write a Grumpy Editor column on this topic still yields an occasional
message of support. This is, indeed, an ideal topic for such a column; the
MH mailer, which was first put together in the late 1970's, still has
lessons to offer the current crop of mail clients.
Your editor will have to request some patience, however. A proper review
of mail clients will take more than one column, along with a significant
amount of time. Those wanting an instant review of bleeding-edge graphical
mailers will have to wait a while; this column, instead, will attempt to
provide an introduction to the topic by looking at the standards set by MH.
MH was, at the outset, different from any other mail client out there, and
it remains different. Mail clients tend to be classic examples of monolithic
design; everything (one hopes) that a user might want to do with electronic
mail is built in to one single, large application. The designers of MH
concluded that this design did not fit well with the Unix way of doing
things, which is to have a relatively large number of small programs, each
of which does one thing well. As a consequence, MH is not one program, but
many: the current nmh distribution contains 39 separate utilities.
When dealing with MH at this level, the user is never "in" the mail system;
instead, all commands are typed directly to the regular shell. The
brings in new mail; scan lists a folder; show,
next, and prev display individual messages; repl
generates a reply; rmm, refile, and others dispose of
messages; and so on. There is a command (pick) which can perform
complicated searches through folders. All of these commands (and many not
mentioned) manipulate a global state, giving the full set the feel of a
single, integrated application.
MH folders, incidentally, are also unique: they are simply directories
containing each message in a separate file. A number of modern mailers
support MH folders, though usually not as the preferred format.
The result of this organization is that it is possible to build software on
top of the MH primitives with great ease. Over the years, developers have
created numerous interfaces for MH, including xmh (an old graphical
interface still shipped with XFree86), exmh (a Tk-based graphical client),
and MH-E (an emacs-based
interface favored by your editor). The scriptability of the MH primitives
also makes it easy to integrate the mail client into any other
task-oriented software that the user may need to run.
The availability of multiple interfaces to the same mail system is nicer
than one might think. A fancy, graphical interface may be useful when one
is in the office and near to the mail system. When one is stuck behind a
slow network connection (a GPRS link from a nearby mountain, say), the
command line interface may be the only way to work through a batch of mail
quickly and with minimum pain. There is great value in not being locked
into a single mode of interaction with the mail system.
Unfortunately, MH is showing its age in a big way. The nmh effort appears to have stalled
for lack of developers; it shows no commits to its repository since 2003;
the 1.0.4 release - the latest available - came out in April, 2000. A 1.1
release candidate was posted in January, but nothing has happened since
is support for MIME in nmh, but that support is awkward at best. The exmh
front end does MIME, but there has not been an exmh release in over a
year; it, too, is getting harder to find in distributions. MH works with
POP, but there is no IMAP implementation in sight. In general, MH is old,
unmaintained, and fading from the scene.
This is a shame, because MH got some things right decades ago that modern
mail client developers still seem to miss. Your editor does not want to
funnel his email into a single-interface black box. He wants to be able to
manipulate mail from his desktop, over a modem link, or running through
mindterm on a Windows "email garden" system in a remote place.
It should be possible
to do anything with email - even things that the developer of the mail
client might not have thought of. It must be possible to make connections
between the mail client and the LWN site code. It should be possible to
manipulate messages and folders with shell scripts and programs without
great pain. The client should be a powerful tool for working with
electronic mail, but it should be just the beginning point, rather than the
Your editor is now shopping for an email client which can replace MH. This
process could be a long one; understanding a mail client well enough to
write about it takes a significant amount of effort. The process may also
require delving into other parts of the larger email system, such as IMAP
servers. Watch for a series of upcoming articles over the (northern
hemisphere) summer as this journey unfolds.
As a down payment, here is a quick look at the MH-E interface. Your editor
has used MH-E for years; it does a nice job of combining the power of MH
with an efficient keyboard interface and the usual benefits of integration
with the editor itself. Your editor has long assumed that MH-E has
suffered the same fate as MH; the version shipped with the current
GNU emacs distribution dates from 2000. This version of MH-E has many
shortcomings; it does not even deal with simple things like mail in the
quoted-printable encoding correctly.
So it was interesting to find out that that MH-E hackers have, in fact,
been quite busy recently. Version 7.4.3, currently available from the MH-E site, includes a number of
new features. It performs threading, has proper MIME support (see
screenshot, right), indexed searching, and more. It uses the capabilities
of modern versions of emacs to display images and such within the editor
itself. There is also a general interface to spam filtering systems,
allowing the user to easily train the bayesian filter of his or her
It is, in general, a vastly superior implementation of MH-E, and the upgrade is
easy; if you are an MH-E user, you probably want to look at the current
On the down side, enough commands have been changed to drive a long-time
MH-E user nuts for a while, and the documentation is, um, missing. The
default colors show a distinct lack of restraint or concern for human
factors. It also
has adopted the gnus habit of replacing smileys and such with its own
built-in icons - behavior which is amusing for about two messages before
you realize you'd rather just see what the other person wrote.
Fortunately, this behavior is easily turned off with a configuration
The new MH-E is apparently slated for inclusion in emacs 21.4. It is good
to see that significant work is going into this mail interface; MH-E is too
good to allow to slip into obscurity and decay. The fact remains, however,
that MH-E is built on a foundation which has not seen any significant
maintenance in years.
(For more information on the history and philosophy behind MH, see the
classic (if quaintly titled) paper "MH: How to process 200 messages a day
and still get some real work done," available in PostScript format).
Comments (71 posted)
It was probably too much to hope that all Linux vendors would take the
same approach to their distributions for AMD's 64-bit x86 chips and
Intel's forthcoming 64-bit x86 chips, or x86_64. While the major
commercial vendors (SUSE, Red Hat and Mandrake, to name a few) are
shipping mixed distributions for x86_64, the recently-announced Debian
is a pure
64-bit distribution without 32-bit libraries.
A pure 64-bit distribution has the advantage of being simpler, and of not
having to worry about multiple versions on libraries and such.
Thus, while other distributions have relegated the 64-bit libraries to an
alternate location, such as
/usr/lib64, the Debian project
ships with 64-bit libraries in
/usr/lib and avoids the
problem of rewriting package creation rules to install libraries in
/usr/lib64 or a similar situation. However, this results in
a system that is unable to run 32-bit x86 binaries.
The original plan for Debian's x86_64 port was to be similar to sparc64,
where the default is 32-bit applications and libraries. However, the
tide turned in February, and multiarch support was put on the back
burner. As Goswin von Brederlow explains:
There was an attempt at doing a mixed port but the resistance by the
dpkg developers and the community in general was too big to get it under
way, esspecially with the sarge release looming over our heads. A full
mixed port means changing every single library package and affects
probably all packages. That's nothing one wants to do before sarge.
So instead of going full 32/64 bit mixed mode amd64 in one big step
pure64 was started to get 64 bit support fully available with minimum
impact to sarge. Merging is multiarch support for mixed 32/64 bit is now
step 2 planed for after sarge at the earliest.
This may not end up being a big problem, even for those users who need
to run 32-bit x86 applications.
As John Goerzen points
out, it is possible to run 32-bit binaries in a chrooted
The only reason I can see for even bothering to support 32-bit
applications at all is for binary-only proprietary software. And that
is not such a concern; it takes all of about 10 minutes to set up a
32-bit chroot with debootstrap to run those things in.
Some have voiced
concerns about Debian being incompatible with other x86_64
distributions. Since LSB-compatibility should be the main concern, we
wondered whether Debian, or any other Linux distributions, were
compatible with the LSB specification for x86_64 chips. Stuart Anderson,
lead developer of the LSB written specification, told LWN that none of
the distributions currently meet the LSB specification, but for obvious
That's because there has not yet been an official release of the LSB for
that architecture. There is a draft, and it will get released in the
very near future, but because it hasn't been, distros have not yet had a
chance to certify.
Anderson did say that a distribution can be LSB-compliant, without
running 32-bit binaries, since the specification covers only x86_64. He also said that they are working on a "multi-arch" specification, "but it's not really far enough along to say anything specific."
In general, I think a 64 bit distro should be able to support a 32 bit
runtime in parallel. It just does so as supporting two specs, and not a
single one that mandated both 32 & 64.
No doubt, it will be some time before x86_64 support is uniform across
all the various Linux distributions. The hardware is not yet in wide
enough use to truly force distributions to standardize, and it's
entirely possible that the 32-bit problem will disappear as x86_64
hardware becomes commonplace.
Comments (13 posted)
It has been a busy week in the SCO universe; time for an update.
The company released its second quarter results on June 10; those who are
interested can see the
press release or, for far more detail, the
10-Q filing. The results were as bad as expected; actually, they were
even worse. The company lost $15 million on $10 million in
revenue. The SCOsource program brought in all of $11,000 over the
quarter. SCO management says things will get better soon, of course.
About one year ago, SCO acquired a web services company called Vultus; this
acquisition, somehow, involved the transfer of some 300,000 shares of
SCO stock to the Canopy Group. Quite a few questions were raised at the
time; there did not seem to be any sort of legitimate business reason for
SCO to make this acquisition; it seemed, instead, to be a way of shifting
money over to Canopy. The questions have come back; this quarter's 10-Q
filing includes a $2.4 million writeoff acknowledging that Vultus is,
in fact, worthless.
Also found in the 10-Q is the fact that SCO has spent $2.4 million of
its scarce cash buying back its own stock. These purchases appear to have
done little to prop up the company's stock price, however.
The most significant news of the week was almost certainly the
the Novell case. Three separate motions were decided:
- Novell had tried to get the case dismissed on the grounds that SCO did
not show that Novell's copyright claims are false. Judge Kimball
denied this motion for now, though he noted that the question of
falsity remains open.
- Novell also moved for dismissal on the grounds that SCO did not plead
any specific damages. This motion was granted; as of this writing,
SCO's suit against Novell is officially dismissed. SCO, however, got 30
days to refile the case with the required pleadings; SCO claims it
will do so.
- SCO had moved to get the trial shifted back to Utah state court; this
motion was denied.
The most important ruling by far was the one keeping the case in Federal court.
SCO was hoping for a quick contract case where it could talk about the
"intent" of the agreement that transferred the Novell license
administration business to (old) SCO. State courts cannot rule on the
validity of actual copyright transfers, which are a Federal issue. Judge
Kimball has decided, however, that the existence (or lack thereof) of a
copyright transfer is a crucial part of this case. If no copyrights were
transferred to old SCO, then the current SCO Group has no basis for a
"slander of title" claim. And the Judge has his doubts on whether that
The Amendment also contains no transfer language in the form of
'seller hereby conveys to buyer.' Given the similarly ambiguous
language in the APA with respect to the transfer of assets --
seller 'will' sell, convey, assign, and buyer 'will' purchase and
acquire -- it is questionable on the face of the documents whether
there was any intention to transfer the copyrights as of the date
the amendment was executed. Moreover, the use of the term
'required' in Amendment No. 2 without any accompanying list or
definition of which copyrights would be required for SCO to
exercise its rights in the technology is troublesome given the
number of copyrighted works involved in the transaction. There is
enough ambiguity in the language of Amendment No. 2 that, at this
point in the litigation, it is questionable whether Amendment No. 2
was meant to convey the required copyrights or whether the parties
contemplated a separate writing to actually transfer the copyrights
after the 'required' copyrights were identified.
In state court, SCO would not have had to face this particular line in
inquiry. In Federal court, instead, the company will have to start by
proving that it does, indeed, own the copyrights it has been claiming;
furthermore, this proof will have to be made to a clearly skeptical judge.
One might well think that this whole issue is irrelevant. Beyond the small
bit of Unix code leaked into the kernel by SGI (and long since removed),
there has been no evidence that any proprietary Unix code has found its way
into Linux. Even if SCO wins its case against Novell, it loses against
Linux. But the fact that its copyright ownership claims are being
challenged in Federal court may yet be the factor that brings the whole
enterprise crashing down. Sales of "Linux licenses" will be even harder
than before, and, if the judge rules that SCO does not own the copyrights,
the rest of SCO's legal offensives will simply collapse.
Judge Kimball also issued some
rulings in the IBM case. SCO's motion to bifurcate the case (an
attempt to split IBM's patent counterclaims into a separate trial) was
denied by the judge. This motion was denied without prejudice, so it could
come back at some future time. SCO's motion to delay the case was partly
granted, however; the actual trial, should it ever happen, will be in
November, 2005. The judge has made it clear that he is not interested in
any further delays after this one.
In the AutoZone case, SCO has filed a
memorandum opposing AutoZone's motions to put the case on hold, or, at
least, to move it to Tennessee. Says SCO:
Granting a stay under the procedural posture of the cases that
AutoZone has relied upon would amount to giving AutoZone free
license to continue to infringe upon SCO's copyrights for the
foreseeable future, while preventing SCO from even obtaining
discovery concerning the breadth of such copyright infringements
and the damages such infringements may have caused.
In other words, poor SCO would not be able to go fishing through AutoZone's
files looking for actual evidence.
Finally, the SCO Group is, for the first time in a while, making a big show
of wanting to be a software company. One announcement
was for UnixWare 7.1.4, which includes a number of bleeding-edge features:
support for disks larger than 128GB, pluggable authentication modules,
MySQL, PostgreSQL, Apache 2.0.49, Tomcat, Perl, PHP, Samba 3.0, Sendmail,
and more. It seems that free software isn't such a bad thing after all.
SCO has also announced
an embedded offering, "SCOoffice server," and "Legend," an upcoming version
of OpenServer with support for "64-bit advanced computing." All told, it
looks like the company is truly putting some effort into its (still
proprietary and obsolete) Unix offerings.
One might well wonder why SCO is doing that. The company had been told by
BayStar that its litigation was its only worthwhile effort; why drain money
from the lawyers to prop up its software offerings? One clue was to be
found in the conference
call that accompanied the second-quarter earnings report. While SCO
claims to be staying the course (and doing great), the whole tone of the
conference was subdued. Those who sat through the "Chris&Darl shows"
of last year note that, now, the swagger is gone (and Chris Sontag,
SCOsource manager, has been just about invisible recently). SCO's
management may well have gotten past the denial and figured out that it has
lost. If so, they might just be thinking about trying to run a software
company once the litigation storm has run its course. That might even work
as a "plan B," but only if SCO can overcome a couple of small
obstacles: having any sort of company left after those it has attacked
are done with it, and offering software that people actually want to
Comments (7 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Metasploit; New vulnerabilities in Apache, chora, kernel, subversion, and webmin.
- Kernel: A nasty FPU bug; Online ext3 resizing; IP packet alignment.
- Distributions: LILO vs. GRUB, Debian x86_64 port is ready, the APODIO bootable CD,
BLAG10000, KNOPPIX 3.5 at LinuxTag.
- Development: Changes in the upcoming Python 2.4 Release,
new versions of Glom, phpMyAdmin, PostgreSQL, Botan, Bogofilter,
ht://Dig, Tiki, GOK, PythonCAD, GDM, KDE, FLU, Thunderbird,
GENIUS, Evolusync, Gnomoradio, Epiphany, Firefox, Quartz, Bif.
- Press: US Government releases GPL code, Munich moves to Linux, SCO Keeps Sinking,
Red Hat CFO resigns, writing spam filters, Cobind review.
- Announcements: New CrossOver Office, Red Hat quarter preview, SCO's quarterly results,
CCRMA summer workshops, LAMP at LinuxTag, OSDC Australia 2004 CFP,