LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for June 17, 2004The Grumpy Editor's guide to mail clients: introduction
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 inc command 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 then. There 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 final destination. 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.
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 option. 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).
The 64-bit questionIt 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 x86_64 port 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 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 environment:
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 reasons:
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.
Time for a SCO updateIt 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 rulings in the Novell case. Three separate motions were decided:
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 transfer happened:
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 buy.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||
![[MH-E screenshot]](/images/ns/grumpy/hot-nude-geek-sm.png)