Firefox 3!

Okay, I've taken the plunge and upgraded to Firefox 3, at least on one machine—my Windows XP workstation at home.

I thought I'd give it a spin among promises of better performance. So far, most importantly, I haven't experienced anything not working.

I had to re-install the Google Toolbar which was simple and not a surprise.

I read through all of the features, release notes, etc. Nothing among the features is particularly exciting to me. It seems like there's some overlap between Firefox functionality and Google Toolbar functionality. I hope that doesn't cause any conflicts or confusion.

So far I haven't experienced any problems. It seems faster, but that's very subjective. I didn't think to check my memory usage before upgrading but, quickly firing up Task Manager, memory usage doesn't look recognizably higher than normal.

I'll see how things go. If all is well, I'll start to upgrade on other systems. I suppose the MacBook Pro would be next.

Amazon EC2 Spam Problems

From this blog posting and this article on Slashdot, it looks like Amazon is having trouble with spammers creating machine instances on the EC2 and blasting out spam.

I think the approach of dealing with accounts is the solution. Amazon either needs to block email ports on an account basis (instead of by IP address or machine instance), or they need to limit, disable or otherwise slow down those accounts and their instances.

Summer Solstice at 23:59 UTC!

Happy Summer Solstice! It occurs today 20 June 2008 at 23:59 UTC = 19:59 EDT, almost exactly at 0:00!

Streetview for Metro Atlanta

How Google Maps has Streetview covering much of Metro Atlanta! For better or worse, they haven't quite made it to our house yet.

Phineas and Ferb

The funniest cartoon (joining Sponge Bob, The Fairly Odd Parents) is now Phineas and Ferb.

Missing Greeks

So here's a question that plagues me: What happened to Catherine Alpha Jones through Catherine Epsilon Jones?

Stargate Is Moving Again

I've been experiementing with Google Sites and decided to try implementing a Sites-based version of Stargate. Now the new Stargate is well on it's way to being done. I have to say, it's not bad and I may just move to Sites as the “official site” for Stargate.

I like the ability to update the site from a web browser from any location. This is in contrast the the current method where I log into a server where my source files are located, edit the source, regenerate the page or pages, then upload them to various web servers.

There are also some nice “free” features like the Site Map and Recent changes. The ability to add a blog made Site News trivially easy to implement. An additional advantage is that pages are organized into a hieararchy. And, of course, site searching is built in.

I really lucked out on the fact that there is a Theme that is a nice match for my previous color scheme so it almost looks like an intentional next step in site evolution. I miss the light yellow color though, which was taken from the core of the M100 galaxy in the picture I use as a logo.

I was worried about how to implement my Email Me form, but this also turned out to be a quick solution with Google Docs Spreadsheet and a Form (which is integrated right into Sites). Further, it's possible to have the spreadsheet to notify you by email when it changes so, voila!, an email form!

I have to reluctantly admit that the changes in the new layout, somewhat forced by the Sites style, is probably more usable.

The biggest downside is that I'm manually having to copy over and edit the data. I can semi automate it and by copying HTML and directly editing HTML on the sites pages, it does go faster for some lists and such. Most of the work involves editing out the CSS references from my HTML snippets.

The next question is: What do I do with the old site? Should I set it to redirect to the new Sites location? (Probably). I'll put up a this-site-has-moved message with the new URL then later maybe just code a redirect.

Google Grand Opening in Lenoir, NC

Google had their grand opening event for their data center in Lenoir, NC.

News article
TV Video (requires Windows Media)

More Sender-Stored Email

I was thinking about sender-stored email again. It occured to me how you could throw away SMTP and implement a whole new protocol pretty easily. The idea is partly inspired by OpenID.

It's also inspired by the fact that, instead of an email address, I've been using a URL for a number of years. If you want to send me email (and I don't know you) you go to that URL and fill out a form.

User A at Site S wants to send email to user B at Site T.

Previously, A@S would send email to B@T. It would go to an outbound email server at Site S, then be relayed to the exchange server for site T, then perhaps relayed through multiple servers inside T's location, until finally it was delivered to an inbox on an email server. At some later point, Users B would read their email and retrieve the message from the inbox.

In the new scheme, user B doesn't have an email address per se. They simply have a URL. It can be some arbitrary URL or such as http://b.email.myplace.com, or some generic email site like http://b.email.com, or a corp address maybe like, http://x.corp.com/eng/b.

Now, when A sends email to B, A's client simply POSTs a message to the URL using HTTP. The message contains these fields:

• From - The sender's name and possibly return URL
  
• (optional) To Name - Who the message it to.
• Subject
• Message URL - The URL of the message we are sending

This brief information goes into T's ``inbox.'' This is the only information required to be stored on the recipient's site. This inbox can be a simple table of data.

To read the message from A, user B accesses the URL in the message. This allows retrieving the email message with all of its headers. I've listed them before but here are some of the immediate advantages.

• The recipient immediately knows who the message is coming from (because they get it from the source site). Based on the URL, if they decide it's spam, they can choose not to read it.
• The message doesn't travel over the network until the last minute, when it's read. It efficiently travels directly to the recipient and completely under the recipient's control.
  
• The message is stored once by the sender A.
  
• However, the recipient does have the option of keeping their own copy if they want to.
• Any attachments are naturally additional URLs to retrieve them. The recipient can verify if the attachments are from the same site or not.
• Encryption is easy: (HTTPS).
• Authentication of the recipient is easy (B has to sign into A's site).
• This uses existing protocols and infrastructure. Most work is done by web servers.

And there's this big advantage.

There's no message store-and-forward or routing. The recipient's address is a URL and the sender connects to it directly.

The only new software required here is two pieces. There is the software that is posted to and that displays a list of messages. There is also software on the sending end that allows the sender to compose an email message. Then when they send it, the message is put up on the web server (for retrieval by the recipient) and that address is then sent.

Of course, it's possible to write email clients that do all of this behind the scene and make the email-reading experience completely indistinguishable from what currently happens.

Now look at what Site T needs in order for it's occupants to recieve email. In the current implementation of email, the site needs massive amounts of storage to handle all of the messages that arrive on an hourly basis. Messages are stored seperately (sometimes) for each recipient.

With the new scheme, Site T could simply give each user a browser and would only need to store a table of received messages.

This idea could easily be phased in along side existing email and with a bit of coding, it could be done transparently to the user. The cost savings and efficiency gains would be huge.

References: My previous Email Ideas posting and

Restructured Text

I'm not sure how I missed restructured text. This seems to be Python's answer to POD (Perl's Plain Old Documentation).

After five minutes of looking at it, it looks basically okay. The emphasis seems to be more on being readable in it's text (input) format. In other words, a marked up document is readable even before you render it as HTML, PostScript, etc. That's somewhat in opposition to POD and most Wiki markup (they are very similar to each other) where the emphasis is on easy typing.

I prefer the latter, but maybe with Emacs macros and such the former will be okay. I'm going to try it out.

I bet it doesn't have built-in support for the man page format the way that POD does. We'll see.

Google Innovation in Harvard Business Review

Susan A shared this interesting article in the Harvard Business Review (April 2008): Reverse Engineering Google's Innovation Machine by Bala Iyer and Thomas H. Davenport.

Fascinating.

Interesting China/Asias Article

This article in the Daily Mail is an interesting analysis of China's place in the world.

Carl's Table

Fascinating! Check out this desk and chair.

Xubuntu!

If you have a partition that's less than 3-GB and you want to install a recent Linux, the answer is Xubuntu! I installed the Gutsy version of Xubuntu and it's using 1.7-GB so far.

Compiling on Ubuntu

If you are running Ubuntu, try to compile a C program, and discover that stdio.h is missing, then you need to execute this command.

apt-get install build-essential

DTrace on Mac OS X

I recently discovered that Mac OS X Leopard includes support for DTrace tracing.

However, some searching uncovered this post which notes that DTrace is limited to not being able to trace some applications.

Star Wars by a Three-Year-Old

If you've had kids, particularly if your first is a daughter, then this will seem very familiar.

Explanation of Star Wars by a Three-Year-Old.

Impressive Warehouse Fire

I could see this fire as soon as I left our house this morning, over 40 miles away. Wow!

(Oh, click on the link under the picture that says Photos, that takes you to a photo album).

Primary Delegates Map

Here's a nice interactive map a the Washington Post of primary delegates and who has won them so far.

Here are some more.

• Time (but it's out of date at the moment)
• Newsweek (Caution, though they display delegate counts up top, their bar-chart seems to be counting votes and not delegates. ???)
• NY Times (also not up to date yet)
  

Bazaar

Okay, a guy I work with, Jon, told me about Bazaar (bzr), which is a version control system. I've been trying it out for several weeks, using at work regularly, and just playing with it at home. I've really come to like it a lot except for one shortcoming noted below.

The web site does a good job of listing the features but here are the ones that I like.

• Commands are similar to CVS.
• You don't need a central repository.
• It's completely written in Python and supports plug-ins.
• It's very easy to use.

My first version control system was RCS and then around early in this century I migrated to CVS, which was descended from RCS. This will be my third. (Well, not technically. I have used and do use others).

One big paradigm shift involves how version numbers are assigned. In CVS, each file has it's own series of version numbers. For example file1 might be at version 1.4 and file2 might be at 1.20. The only idea of a global version is achieved with tags.

With bzr, even if you only commit changes from file2, if that's version 25, then version 25 represents the state of all files in the project at that point. This has a few implications.

1. If you list the log of changes for, e.g., file2, you might see it was updated in versions 25, 23, 22, 10, and 7.
2. You can list the global log of changes which shows comments and which files were changed for ever version number.
3. It's trivially easy to commit changes since you don't have to list files, but can just do a commit which catches everything. This is more convenient than I ever imagined.

This idea of a global version number rather than a local version number for each file is the way most version control systems work so this represents a paradigm shift for me (hey, a change in thinking!) but I've quickly come to like it.

Bazaar has one shortcoming that is very annoying—it doesn't support RCS keywords. In RCS, you can place text like $Revision$, $Author$, and $Date$ in your file and they will be updated with the current values. I've depended on this over the years and miss it a lot when it's missing. I think files should have their identifying information when printed without having to refer to the on-line version control system.

It's pretty easy to write a little program that edits in this information, say just before committing changes, and indeed I've already written most of it. It could even be made a plugin for Bazaar so I may do that.

In the end, Bazaar is highly recommended for keeping versions of any important files (not just program code).