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 editorLetters 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 13, 2001 |
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 | ||
|