[LWN Logo]
[LWN.net]

Sections:
 Main page
 Security
 Kernel
 Distributions
 Development
 Commerce
 Linux in the news
 Announcements
 Linux History
 Letters
All in one big page

See also: last week's Letters page.

Letters to the editor


Letters to the editor should be sent to letters@lwn.net. Preference will be given to letters which are short, to the point, and well written. If you want your email address "anti-spammed" in some way please be sure to let us know. We do not have a policy against anonymous letters, but we will be reluctant to include them.

December 6, 2001

   
From:	 Eric Kidd <eric.kidd@pobox.com>
To:	 letters@lwn.net
Subject: Evolution notes
Date:	 29 Nov 2001 12:24:18 -0500

First, a minor nit:

"There does not, however, appear to be any straightforward way of
creating a contact entry from a mail message; one must start from the
beginning and type it all in."

Right click on an e-mail address and you'll be pleasantly surprised. :-)

Now, on to some arguably more substantial thoughts.

I've abandoned a highly customized Mutt setup (among other things, I'm
the author of Emacs mutt-mode), and switched to Evolution.  Why?

The Drawbacks of Mutt
---------------------

* Mutt can't handle big folders efficiently.  I have some mail folders
with 25,000 messages or more, and mutt insists on rebuilding the indexes
every time I switch folders.  And since mail files tend to be highly
fragmented, this can take close to 30 seconds on a 1.4 GHz box.

* Mutt is inherently modal.  I can't, say, compose two messages at once,
read a third, and poke around in a mailbox at the same time.

* Mutt can't search message bodies.

* Mutt can't read the HTML-only e-mails that some people insist on
sending me through Hotmail, unless I screw around with mimecap files. 
And even then, it's pretty clunky.

The Advantages of Evolution
---------------------------

* Serious support for huge quantities of mail: lightening full-text
search, virtual folders based on queries, support for mailboxes with
tens of thousands of messages.

* Support for receiving HTML e-mail.

* Excellent integration between the mail reader, contact database, and
my Pilot.

The main drawbacks of Evolution are poor integration with the
traditional Unix environment, and mediocre PGP support.

In particular,  evolution (1) is bad at noticing PGP errors, (2) doesn't
support rules like "always encrypt mail to so-and-so" and (3) replies to
encrypted messages with quoted, unencrypted bodies by default (a
*serious* security hole that it shares with Mutt).

I hope some of these bugs get fixed in 1.x.  But it's a dynamite mailer
in many ways.

Cheers,
Eric

   
From:	 tom poe <tompoe@renonevada.net>
To:	 letters@lwn.net
Subject: SVG and ADOBE
Date:	 Fri, 30 Nov 2001 21:19:34 -0800

Hi:  Just saw the announcement for Mozilla and Adobe and SVG.  

Criteria for Letters to the Editor:
Short, to the point, and possibly well-written.  

These criteria don't leave much room for "What the h%^&  is our W3C.org 
standards committee trying to pull?"  rants.  By all means, folks, go over to 
Adobe and download their proprietary product so you can view Open Source 
Standards on Linux, because our W3C.org standards committee thinks SVG should 
be a proprietary standard for all.  What happened to Batik?  Oh, that's 
right.  Adobe views Batik as second class citizens, and has no interest in 
Open Sourcing their work in collaboration.  Maybe someone has a clearer 
understanding as to why anyone would want to use proprietary products as a 
standard for Open Source.  thanks, Tom
   
From:	 Christopher Browne <cbbrowne@cbbrowne.com>
To:	 letters@lwn.net
Subject: SourceForge Concerns
Date:	 Wed, 05 Dec 2001 14:02:22 -0500

The concerns about Sourceforge.net are hardly new; people have long expressed 
all sorts of paranoia about all sorts of unfortunate possible scenarios.

I'm not overly concerned, but commend that people make sure that they're not 
putting "all their eggs in one basket."

There certainly are a number of negative outcomes that could lead to 
significant inconvenience.  I always like to characterize it with the idea of 
a large meteoroid striking Silicon Valley, as that takes a certain amount of 
"sting" out what might otherwise become accusations.  (The Python people have 
their classic line about Guido getting hit by a bus; same sort of story; I 
guess I am more into bad Sean Connery movies :-).)

Whatever the potential reasons for a loss of service, it is very important for 
people to have some backup plans should a "Big Gulp" happen.  It is already 
highly likely that interesting CVS archives will be widely mirrored, simply 
because ocean-crossing links can be slow.

Those that are running projects that they consider important should certainly 
seek to mirror the code elsewhere.

The following are a whole bunch of possible alternatives:
Savannah, GBorg, Berlios.de, Tuxfamily.org, Serveur Libre, SunSITE.dk, Vhffs, 
Subversions - GNU Project, SEUL: Hosted Projects, freepository, Lusis.org,
SourceFubar, tigris

It would seem logical for those projects that are actually active (most 
Sourceforge projects are NOT active) to consider mirroring at one or another 
of these sites.

Note that such mirroring is also systematically useful for keeping the folks 
at Sourceforge.net from being tempted to "do ill."  I remember many arguments 
taking place yesteryear with just _extreme_ paranoia that Red Hat (the typical 
"punching bag" for paranoid concerns) might be just about to do something 
horribly proprietary.  The presence of alternatives that are conspicuously 
free of "we might try to take this private" interests represents a powerful 
quencher of temptation.  Debian is a crucial alternative, in the distribution 
arena; even if you never use it, the fact that it's out there helps to keep 
Linux distributions freely available.

If you care about your project, mirror it, and the risks dissipate.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www3.sympatico.ca/cbbrowne/linux.html
Any programmer who fails to comply with the standard naming, formatting,
or commenting conventions should be shot.  If it so happens that it is
inconvenient to shoot him, then he is to be politely requested to recode
his program in adherence to the above standard.
-- Michael Spier, Digital Equipment Corporation


 

 

 
Eklektix, Inc. Linux powered! Copyright © 2001 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds