grack.com

Bugzilla.NET version 0.1 has been released!

Bugzilla.NET is my Visual Studio.NET <-> Bugzilla integration project. So far it has the ability to query Bugzilla from within Visual Studio and synchronize a set of tasks with a given set of server-side queries.

Requirements:

• Bugzilla 2.16.1 or later
• Visual Studio.NET 2003 (2002 may work, but is untested)

Downloads:

• For downloads/source code access via CVS, please visit the Downloads Page at Sourceforge.

Here’s a screenshot of the Bugzilla query window:

I didn’t expect to get a response to my Linux for Travel Systems article so quickly, but it’s clear that Robert Scoble either missed the point or has decided to fabricate a great deal of my argument to suit his own:

Matthew makes a mistake, though. He tries to use this as an example of how a company has fired Microsoft. Instead, though, you need to look at what Travelocity used before. Unix. So, what Travelocity really decided was to replace its Unix-based systems with Linux.

In this case, Robert is the one who has made a mistake.  Nowhere in my article did I even mention “firing Microsoft”.  In fact, the only reference to Microsoft in my article is referring to Robert’s role as evangelist.  My goal was simply to match his “Windows Success Story” with a story of how a company evaluated its options and came up with the conclusion Linux Works Better For Them.

This is where Robert believes his “switch story” is more convincing:

My Morton Thiokol example was more of a real win. Why? Because Morton Thiokol switched from Unix to Windows (that’s a real jump over the fence – Unix to Linux isn’t as big a difference as Unix to Windows).

I’m finding it hard to give this point any credit for two reasons:

1. Robert hadn’t positioned his article as a Unix to Windows switch.  In fact, I have no idea what really went on at Morton Thiokol.  Looking back at Robert’s previous two mentions of the company, this is the most information I can get out of it:

   On the other hand, ask yourself why no one has written about Morton Thiokol lately. They just changed computer systems for their engineers.

   “Changed computer systems,” eh?  From what to what?  I can assume that the “to what” part of that is Windows, but nowhere in this article does he mention that it was from something else.  They could have been running AutoCAD on Windows ‘95 for all we know.  For the record, I have seen people run those two together.

2. In the original case study I referenced, we don’t know what the architecture history of Travelocity was.  At the time, I was positioning the story only as one in which Linux was chosen over other alternatives.  I did manage to dig up another article that describes them switching from C++/SGI to Java/Linux.  The Unix-to-Java/Linux switch is not any less valid than Robert’s Unix-to-Windows switch.  I would consider Java to be a platform of its own and the change to it significant.  If you read the other article describing the switch, you can see how they switched to Apache Tomcat (a Java Enterprise hosting environment) with Struts (a web-page rendering environment).  That’s not a trivial change, Robert!

So you can see, my Travelocity switch story is just as valid as Robert’s Morton Thiokol story.  Either switch would be a major undertaking for any organization.  Switching from Unix to Linux, however, is a win for Linux (and a win for Open Source at the same time).  You can’t discount this switch just because both operating systems end in the letter “x”.

If you look at the stories and how they would affect a normal working-class Joe, you’d probably find that the Travelocity story has greater influence.  Not everyone flies to the moon, but pretty much everyone flies between cities at some point in their life.  Linux now helps you get your ticket cheaper and faster.

Since Scoble has been pushing Morton Thiokol stories over the last few days, I thought I would counter with a Linux success story from this article (first page here). 

“Sabre Holdings Corp., based in Southlake, Texas, is a $2.1 billion holding company with four technology-based travel business units: the Travelocity online travel site; the Sabre Travel Network, which operates the Sabre reservations system for travel agents, suppliers and travelers; GetThere, a Web-based corporate travel service; and Sabre Airline Solutions, which provides software and consulting services to airlines.”

Here’s the great quote: “We’ve got to get faster, better, cheaper solutions into our infrastructure, and Linux lets us get there”. 

Sabre Holdings Corp. isn’t designing the space shuttle engines, sure, but the next time you book your Travelocity holiday online, picture all of that open-source, finely-tuned machinery ticking away in the background.  And they can scale up any part of their system for the cost of the new hardware.  No Microsoft Licensing 6.0 yearly payments and no random license audits from the BSA.  Just re-image the new machine and add it to the cluster!  Like the Murphy, the CTO, says:

“Your cost at the scaling point, after the initial implementation, is essentially zero, and you’re getting a robust environment that delivers the intangible benefit that your technicians love to work on Linux.”

I imagine that seeing all of these Linux stories in the trade press is making Microsoft’s star evangelist a little jealous.  I’m happy to see all of the attention that open-source products have been getting lately.

The latest Google Zeitgeist is out.  Using the approximate readings from this forum post, it looks like the new (very approximate) browser shares for Google are:

• MSIE 6.0: 68.5%
• MSIE 5.5: 10%
• MSIE 5.0: 11.5%
• Netscape 6+ (Mozilla): 5%
• Other: 5%

The total is 100%, but that luck more than anything.  I didn’t fudge any numbers, but I eyeballed most of them.  Each of those Google major ticks are 15%, from what I can tell. 

Good news: Mozilla is now 5% of the web (according to Google). 

Bad news: MSIE total is approx. 90%, compared to 85% in Dec. of 2002.  Where they’ve taken browser share from, I don’t know, but it’s likely from older Netscape 4 installations that have moved on.

Good news: at least 95% of the web can handle a good deal of CSS, even if 11.5% is fairly broken and 10% is only somewhat broken.

UPDATE: Perhaps I don’t know my procmail as well as I thought. There was something wrong with this setup and I don’t know what it was. I ended up with major mail loops as sendmail tried to redeliver messages to my local address over and over, which were then forwarded to the unpublished account (which refused it because it was an invalid address!). Any ideas?  For now, I’ve updated this setup to deliver locally–something that’s fairly straightforward to do for most people.

And now, back to our regularly scheduled entry:

I’ve got Spamassassin running against one of my POP3 mail servers via fetchmail.  It cleans the mail, marks spam, junks anything that rates extremely high (I’ve set a score of 15 as “extremely high”), then redelivers it to a non-public filtered email address.  It’s working great so far!  Here’s the description of how I managed to get this working:

For this HOWTO, I’m assuming you have the following packages installed and working:

• Fetchmail
• Procmail
• Spamassassin

First of all, I set Fetchmail up to run against my POP3 server.  This is the easy part:

poll mailserver
 uidl
 protocol pop3
 user "username"
 password "password"
 mda "procmail ~/.procmailrc-fetchmail -f %F -m"

This file instructs Fetchmail to grab mail from the given account and process it in procmail using the .procmailrc-fetchmail file. I’ve set it up to use .procmailrc-fetchmail so that regular mail delivery to my Unix user won’t get run through the procmail file again, causing a potential mail loop in some cases. While you’re at it, set up hotwayd and get your Hotmail mail cleanly delivered to your main POP3 account.

To start fetchmail, run this command as your user:

fetchmail -d 120

The contents of this procmail configuration file are:

:0B
* ^this is the latest version of security update.*
{
  :0fwh
  | formail -I"Subject: [SPAM] Virus 1"
}

:0B
* ^ZGUuDQ0KJAAAAAAAAAB\+i6hSOurGATrqxgE66sYBQfbKATvqxgG59sgBLerGAdL1zAEA6sYBWPXV
{
  :0fwh
  | formail -I"Subject: [SPAM] Virus 2"
}

:0fw: spamassassin.lock
* < 256000
| spamc

:0
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
$HOME/major-spam

Note that in this file, I’ve used procmail to filter out a couple of viruses. This is to stem the tide of the latest email viruses being sent around. I was getting more than 100 a day at its peak!

To summarize the procmail file, the steps are:

1. If the virus matches the first virus’s signature, mark the subject as “Virus 1” using formail.
2. If the virus matches the second virus’s signature, mark the subject as “Virus 2” using formail.
3. Filter the message through Spamassassin, but only if its size is less than 256,000 bytes.
4. Dump any messages with a spam level > 15 into the mail folder “major-spam”. You can use /dev/null here to ensure that it doesn’t get saved anywhere. Any message that matches this test does not get sent on.
5. Any messages that survived Step 4 will be delivered to the local mailbox.
6. Extra credit: If you’ve got the University of Washington IMAP packages installed, you can get yourself an SSL-enabled POP3 server to your local machine. Make sure you’ve created (or obtained) a proper certificate for /usr/share/ssl/certs.

The mail feed you get from this filter chain tends to be fairly clean. On most days, 5-10% of spam might make it through. It’s much better than 100% and Mozilla is pretty good at picking out the remainder with its Bayesean Junk Filter.