See also: last week's Letters page.

Letters to the editor

From:	 Jim <jimd@starshine.org>
To:	 letters@lwn.net
Subject: MS Remedy, Br'er Patch
Date:	 Sat, 8 Dec 2001 19:20:22 -0800


 Since there is news (on your current "Daily" updates) about
 the latest absurdities in the pursuit of justice and free market
 balance (vis a vis the DoJ and various States Attorneys General
 versus Microsoft) I figured it would make sense to link to an
 editorial (op-ed) that I wrote for the Linux Gazette this month:

 	http://www.linuxgazette.com/issue73/dennis.html

 It should be blatantly obvious that a court-mandated "Linux version"
 of MS Office would be grudgingly delivered late, bereft of as much
 functionality as the courts could tolerate, and more or less deliberately
 "tuned" to offer the most abysmal performance possible.

 Microsoft's officers and management wouldn't have to encourage this
 result.  Their own rank and file rancor would *GUARANTEE* this
 result.  Hell, I'd feel the urge to sabotage the effort if I was
 one of their programmers --- despite my pro-Linux leanings!

 There is *no* effective way to compel a company to release a quality
 software product by government mandate.  The very notion is absurd 
 almost beyond belief.  
 
 It would be conceivable that third parties could be "licensed" 
 (by governmnet mandate) to port the sources to Linux (and other OS).  
 In other words, one could require MS to provide full source trees to 
 third parties (with proof of their comprehensive nature lying in the 
 requirement that they be able to build a fully operational copy of the 
 software for its native platform).

 Such sources would then be explicitly licensed for said third parties
 to create derivative works under a RAND (reasonable and non-discriminatory)
 royalty basis.  (In other words a company would have *no* up front 
 licensing fees --- they could freely get the sources --- but any commercial
 derivative works would provide a small *percentage* royalty that would be
 paid back to MS and/or to a federal licensing agency).

 I say that this is conceivable.  However it is probably not feasible.
 We cannot mandate that MS "open source" their products.  That would be
 too drastic a blow against traditional copyright laws (including the very 
 copyright which protects our right to "copyleft" anything).  A RAND
 for derivatives would raise all sorts of thorny issues.  What if I
 port these sources to Linux, FreeBSD, and even to back "MS Windows" 
 itself and *don't* charge any money for it?  What do you mean I've got to 
 make a minimum charge -- then we have a government mandated pricing
 structure on (some) software.  That way lies madness.

 I think the "public domain interoperable reference sources" proposal
 (in my article) is still the most reasonable and practical.  We need
 something simple, fair and unambiguous.  The hardest part of my proposal
 is to define a set of operations which must be covered for file formats,
 APIs and protocols.  
 
 The enforcement mechanism is relatively simple: injunctions on revenues 
 from sales until the court's mandates are satisfied.  (In other words, 
 the software can be sold, at locked prices, but the revenues beyond 
 minimum media duplication and distribution is held in escrow; with 
 fines exacted, until MS is in conformance --- until they have a 
 "interoperable set of reference sources" which an perform the designated 
 suite of operations on every file format, API, and over every protocol 
 used by MS applications and operating systems.  Thus the software 
 remains available to the public which has been rendered dependent 
 upon it by Microsoft's prior (and now proven) anti-competitive practices,
 but MS doesn't benefit from that available until remedies are made.
 Meanwhile MS is free to "innovate" (do anything they want with their
 software) so long as the release of these innovations is made concurrent
 to the required suite "interoperable references sources."

 As I've said before; this proposal says nothing about Microsoft's
 proprietary sources.  They are free to maintain them and develop the
 reference sources independently; or they are free to create a subset
 of them which provides the interoperability while keeping the UI
 and feature set (what they do with the data, or how they do it) to
 themselves.  All we (the injured public) care about is that we can
 open, parse, and modify *our* files as they are stored in designated
 MS application formats (.doc, .ppt, .xls, and the backend mailbox,
 and SQL Server table formats, for example) and that we have full
 access to the APIs and protocols used between applications and the
 OS, and among the applications.  As I say, the tricky part is defining
 the specific operations that constitute "interoperable."

--
Jim Dennis 

From:	 "Greg Owen" <gowen@swynwyr.com>
To:	 letters@lwn.net
Subject: Re: Contacts in Evolution
Date:	 Fri, 7 Dec 2001 10:24:08 -0500


> Most pointed out that there is, indeed, a way to generate a
> contact entry from a mail message; one simply clicks on the
> sender's address with the right mouse button. It's good that
> the feature exists, but the difficulty of finding it points
> out the need for continued usability testing for Linux desktop
> software.

    As a long-time Outlook and Outlook Express user (for work reasons,
honest!) right clicking to add to the address book was a no-brainer.  For the
vast majority of Windows users converting to Linux, Evolution's interface is
spot-on.

    I've plenty of nits with Evolution's usability, but that shouldn't one of
them.

--
        gowen -- Greg Owen -- gowen@swynwyr.com
        79A7 4063 96B6 9974 86CA  3BEF 521C 860F 5A93 D66D

From:	 Marius Gedminas <mgedmin@delfi.lt>
To:	 letters@lwn.net
Subject: Mutt or Evolution?
Date:	 Thu, 6 Dec 2001 16:08:44 +0200

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

That is the best recommendation for Evolution I've ever seen.  More
convenient than a highly customized Mutt setup?  I must take another
look at it.

I have to agree that Mutt doesn't really cope with huge folders (ones
with > ~ 5,000 messages, although I sometimes wonder if using Maildir on
Reiserfs partitions would help a bit there).  And it is a bit tedious
having to open another xterm with another copy of Mutt because of its
modality.  But I'm really surprised that the author of Emacs mutt-mode
doesn't know about ~b search pattern that allows just that -- searching
in message bodies.  And I see nothing clunky with adding one line to
one's ~/.mailcap and two to one's ~/.muttrc for automatic rendering of
HTML e-mails.

Cheers,
Marius Gedminas
-- 
Linux don't need no steenkin' viruses. The users can destroy the
system all by themselves....
		-- Peter Dalgaard in comp.os.linux.misc

From:	 Andrej Marjan <amarjan@pobox.com>
To:	 eric.kidd@pobox.com
Subject: Re: Evolution notes
Date:	 Fri, 7 Dec 2001 00:03:11 -0500
Cc:	 letters@lwn.net

Here are two minor nits to your drawbacks of mutt:

> * 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.

True, this can be annoying, however, mutt is lightweight enough to run
many instances concurrently. The only real shortcoming would be not
being able to run two instances on the same folder, though this might
not be an issue if maildirs are used.

It's simply a different approach to solve the same problem (dare I say
"paradigm").

> * Mutt can't search message bodies.

Just prefix your search with '~b' for a body search (ESC-b in Debian).
Of course, there is no text index to speed this operation, but it is
there.

The two big drawbacks of evolution for me personally are its primitive
thread handling and its gui-only mode. Unfortunately, not every machine
has an X server locally, and X over the Internet at large tends toward
unbearable. :)

Regards,

Andrej Marjan

-- 
-----------------------------------+-------------------------
Change is inevitable.              |  A n d r e j M a r j a n
Progress is not.                   |     amarjan@pobox.com
-----------------------------------+-------------------------

From:	 Eric Kidd <eric.kidd@pobox.com>
To:	 jhecking@netgaroo.com, lhecking@nmrc.ie, jzbiciak@dal.asp.ti.com,
	 marcus@blazingdot.com, rrw@hell.pl
Subject: Searching big gobs of e-mail
Date:	 06 Dec 2001 13:34:35 -0500
Cc:	 letters@lwn.net

Many thanks to everybody who read my letter to LWN and wrote me to say
that /~b will search message bodies in mutt.  This does appear to work
very nicely for ordinary e-mail usage, and would have saved me some
trouble in the past.

Still, this brings me back to my major difficulty with mutt--I have
close to 100,000 messages archived (for example, I answer questions
about an open source project with 13,467 mailing list messages since
1997), and mutt has simply broken down.  In mutt's defense, of course,
most other mailers broke down around a few thousand messages.

Don't get me wrong; I love mutt.  It's just breaking under the strain. 
For example:

* When opening a mailbox, Mutt appears to do a linear scan of all the
messages.  Since mailboxes tend to fragment nastily, this requires lots
of disk seeks.  The result: some mailboxes take nearly 45 seconds to
open.  And since mutt opens and closes mailboxes when you switch between
them, this gets rather tiresome.

* The aforementioned /~b feature walks me through search results one
message at a time.  But some of the queries I need to perform return
hundreds of hits (say, digging through automatically-generated CVS
e-mails from years ago).  So when I most need /~b, it turns out to be
nearly useless.

* Mutt has no ability to save search results in a virtual folder (a
feature which I've loved in Evolution and the original BeOS mail
client).  This is a lifesaver for research purposes--I use queries of
the form "all unread messages from the following mailing lists in the
past three days", "everything to or from the client who owes me money",
or "everything from this CVS repository in 1998 mentioning 'linker'".  I
can then perform secondary searches on these virtual folders.

All of this suggests that Mutt was never intended to handle the kind of
abuse I inflict on my mailer.  This is no fault of mutt's--it stands
head and shoulders above most mail clients in this regard.

Cheers,
Eric

P.S.  Yay vFolders!

Rule name: [Mutt stuff]

Execute actions if [all criteria are met]

[Message was sent] [after]    [Dec 05 12:00 AM]
[Message Body]     [contains] [mutt]

vFolder Sources
[specific folders only]
file:///home/emk/evolution/Inbox
file:///home/emk/evolution/Sent

;-)

(The BeOS was a bit nicer; it allowed structured queries with boolean
operators.  Evolution can only do this in a hackish fashion--you have to
build multiple layers of vFolders.)

From:	 "Jonathan Day" <jd9812@my-deja.com>
To:	 letters@lwn.net
Subject: Sourceforge, Linux Viruses, and Paranoia, Oh My!
Date:	 Thu, 6 Dec 2001 06:27:19 -0800

Dear Editors,

   Sourceforge can reasonably be treated with considerable suspicion. Why?
Because shortly after VA took over Freshmeat, a certain competing service
(Server 51) vanished. No warning, no notice, no site. More than a few
people complained, and I wrote a rather direct editorial on Technocrat,
explaining why VA was hardly engendering trust, by pulling this stunt. A
high-up VA employee replied that they were shocked, would look into the
matter, and absolutely guaranteed the code for Server 51 would, at the very
least, be up on Sourceforge "soon".
    That was a long time ago. Oh, I believe the employee was sincere. There
is no reason not to. But that makes VA's position very clear. They don't
want trust. They don't want the legitamacy of Open Source. If they did,
where is the source for Server 51? For that matter, where is the source for
Sourceforge? The updates are sporadic and rarer than Halley's Comet at a
blue moon.
    The only way to gain trust is to earn it. Silently killing the
competition and only paying lip-service to the very concept they claim as
the cornerstone of their business model... Well, in my book, that falls
short of earning anything.

   Now onto that utterly pathetic claim by Symantec that Linux viruses
should be more common, because the source is available. Sure, the source is
available. That's how the holes get fixed BEFORE the viruses get written!
Twit! Then, there's the very thing that commercial vendors have been
slamming Linux for, for years. Environments are not consistant. I guess
it's "heads I win, tails you lose". Viruses are far more susceptable to
changes in the environment, as they can't afford to carry the extra payload
needed to cope with variations.
   This means that compiled code isn't guaranteed to work. Are you using
a.out or elf? Glibc 2.0, 2.1 or 2.2? It matters. A binary for one won't be
guaranteed to run on any of the others. (Unless it's statically linked. But
while applications can afford to do this, viruses really can't.) Script
viruses are also getting common, but is csh installed? Python 1 or Python
2? Which Perl, and where is it?
   Then, viruses must make other assumptions. They depend on users not
installing LSM, SE-Linux, POSIX ACL's, or any other security software of
this ilk. It's hard to be unobtrusive, in a secure environment.
   Finally, there's the psychological aspect. "Proving a point", political
propoganda, or even just digital vandalism, are not only possible, but
encouraged, by the schizoid, paranoid world of the corporate market. In an
Open Source world, the only way to achieve the same intensity of feelings,
the same passionate rage, is to add to what is already there. Some of the
greatest creative works of humanity have been produced when insanity has
been allowed to vent for the benefit of all. That is a notion the
proprietary world has never understood. Throughout history, it's suffered
the consequences for that. You can't simply cage people up, and hope
they'll stay quiet, especially if their brains are half-broiled to start
with.

Well, enough of this rant. I'm off to beat some bugs over the head.

Jonathan Day