Recently in FAIL Category

This testing is getting pretty tiresome.

So Devin posted about Z-Push, the cool-sound open-source implementation of Microsoft's Exchange ActiveSync (EAS) protocol. Here's the problem: the Z-Push folks kinda forgot to buy a license for EAS, and I have a problem with that. After years of complaints that Microsoft wasn't being open and sharing its protocols, they started to document the behavior of their protocols and offer some of them for licensing, EAS included. That's good, right? It's good enough for Apple, Google, and the many other companies that licensed EAS, anyway. However, apparently Zarafa wanted the benefit of Microsoft's labors without being willing to pay for it, so they built their own implementation. I don't think that's fair, and I don't think the technical coolness of Z-Push should obscure the fact that Zarafa is stealing something that isn't theirs.

This is what I said in 2002:

Hey, Linux guys: if you want to beat Microsoft, do it by making something better, not by copying their investment.

What happened to Lemonade? How about Funambol? It's not as though the FOSS world lacks for sync protocols; they just decided that Microsoft's commercially successful, fully licensable protocol would better suit their needs, so they took it. It boggles the mind. It would be one thing if the protocol were fully open to all implementers, but it's not. If you don't like the licensing terms, build your own protocol-- that's not hard to understand, is it?

This is a simple test to see whether MT properly runs the MT-Twitter plugin when I post a new item. (I know that Ecto's plugin works already.) (Update 1: nope, it didn't work.)

Hopefully this will magically appear at the correct time.

I'm trying to sign my oldest son up for the Church of Jesus Christ of Latter-day Saints' summer youth program, Especially For Youth. Frankly, I'm jealous that he gets to go. It's sort of a combination summer camp and mini-seminary, and everyone I know who's attended it (or whose kids have been) has raved about it. However, the signup process is giving me a headache. Here's what's on my screen right now:

So let me count the ways that this reeks of FAIL.

First, it doesn't tell you what your queue position is. Having a queue length is meaningless; all it does is tell you the total number of people who may (or may not) be waiting for the service. Without some estimate of where you are, knowing the number of people in line or the wait time isn't helpful.

Second, what does "the average wait time for the entire line" mean? If it's for the entire line, is it really a total time, or is it the average time that someone has to wait in the queue? It can't be the latter, because it keeps bouncing up and down. I've seen it as high as 130 and as low as 85-- during the 240+ minutes that I've been waiting.

Third, how about an estimate for when it will be my turn? Is that too much to ask?

Here's the best part: the registration isn't first-come, first-served! There's no hurry to register, but that little detail is several clicks beneath the actual registration screen.

Managing signup queues for high-demand events like EFY is a well-understood problem. If you've ever used Disney's FastPass system, you know about one possible solution (and one that would certainly apply here). The LDS Church does such a good job with its use of technology in general that it's a real disappointment to see this kind of junk.

Suppose you want to buy an additional license for your existing Microsoft Dynamics CRM Online subscription. This sounds like it should be easy, and it is-- once you know the trick.

Don't make the mistake of thinking you can just do a web search for "buy dynamics CRM license". That way lies madness, not to mention a big steaming pile of fail.

In related news, don't think that because the Microsoft Online Services page says you can buy a Dynamics CRM Online subscription there that you can buy licenses for an existing subscription. You can't.

You might think that the sales chat window that opens on several of the Dynamics CRM pages would help. The sales chat person suggested calling 877-276-2464, option 2. I did, and the phone rang and rang and rang without answering for about 90 seconds. Tom then answered and gave me the magic solution, which I include here so you won't have to go through this same process:

1. Log in to your existing CRM page.
2. Click "Settings" in the lower-left corner of the page.
3. Click "Organization Notifications and Status".
4. In the right-hand section of that page, click "Buy Licenses".

Now for a brief editorial: this is a great case of an application that makes it needlessly hard to do something simple. Why not have a "buy licenses" link on the page where you add new users? Does "Organization Notifications and Status" sound like the solution to "I want to add a license"? Not to me it doesn't. This is an area where the Business Productivity Online team at MS has far outdone the Dynamics crew. I sure hope that as these two services are unified that the BPO approach and design win out.

This year's edition of the annual Ohio State-Michigan game has been cancelled. The Wolverines were on their team bus headed down to Columbus, but unfortunately they couldn't get past Toledo. (But hey, neither could the Marines, so don't feel bad, UM fans!) All kidding aside, the boys and I will be watching tomorrow, probably with a plate of boudin in front of us. Go Bucs! (oh yeah, then LSU plays, and then the Saints are on Monday night!)

Ecto has a twitter plugin, but it doesn't seem to be working.

Ecto has a twitter plugin, but it doesn't seem to be working.

I got some mail yesterday from Google about their recent Google Apps service outage. Here it is, along with my editorial comments.

We're committed to making Google Apps Premier Edition a service on which your organization can depend. During the first half of August, we didn't do this as well as we should have. We had three outages - on August 6, August 11, and August 15. The August 11 outage was experienced by nearly all Google Apps Premier users while the August 6 and 15 outages were minor and affected a very small number of Google Apps Premier users. As is typical of things associated with Google, these outages were the subject of much public commentary.

Well-deserved public commentary, at that, mostly focused on the question of why Google thinks that Google Apps is an enterprise-grade service. Three outages in a nine-day period is not confidence-building.

Through this note, we want to assure you that system reliability is a top priority at Google. When outages occur, Google engineers around the world are immediately mobilized to resolve the issue. We made mistakes in August, and we're sorry. While we're passionate about excellence, we can't promise you a future that's completely free of system interruptions. Instead, we promise you rapid resolution of any production problem; and more importantly, we promise you focused discipline on preventing recurrence of the same problem.

Notice what's missing here: any commitment to a particular level of availability, or any information about the cause of the outage, or any information about how they applied "focused discipline" to keep it from happening again.

Given the production incidents that occurred in August, we'll be extending the full SLA credit to all Google Apps Premier customers for the month of August, which represents a 15-day extension of your service. SLA credits will be applied to the new service term for accounts with a renewal order pending. This credit will be applied to your account automatically so there's no action needed on your part.

So let me get this straight: in exchange for three days of outages (in fairness, not three complete outages), you're going to give me a credit for $25/user. That's not a bad start, but I daresay for most Google Apps customers it's only a small fraction of their lost productivity. Not to mention that I might not want a service credit in the first place.

We've also heard your guidance around the need for better communication when outages occur. Here are three things that we're doing to make things better: We're building a dashboard to provide you with system status information. This dashboard, which we aim to make available in a few months, will enable us to share the following information during an outage:

• A description of the problem, with emphasis on user impact. Our belief is during the course of an outage, we should be singularly focused on solving the problem. Solving production problems involves an investigative process that's iterative. Until the problem is solved, we don't have accurate information around root cause, much less corrective action, that will be particularly useful to you. Given this practical reality, we believe that informing you that a problem exists and assuring you that we're working on resolving it is the useful thing to do.
• A continuously updated estimated time-to-resolution. Many of you have told us that it's important to let you know when the problem will be solved. Once again, the answer is not always immediately known. In this case, we'll provide regular updates to you as we progress through the troubleshooting process.

Positive steps, but note that there's no definite delivery date. Note also the weasel language around how "assuring you" is the useful thing to do. No, fixing the problem is the useful thing to do, followed closely by timely and informative status reports. Just look at what Twitter does, then do the opposite. (Actually, for a decent model, check out how the Xbox Live service folks handle outages.)

In cases where your business requires more detailed information, we'll provide a formal incident report within 48 hours of problem resolution. This incident report will contain the following information:

1. business description of the problem, with emphasis on user impact;
2. technical description of the problem, with emphasis on root cause;
3. actions taken to solve the problem;
4. actions taken or to be taken to prevent recurrence of the problem;
5. e. time line of the outage.

This is more like it! However, my business always requires this detailed information. Who says so? I do. I'm betting that Google will closely control this information, and that they will only provide it if they think your business requires such information.

In cases where your business requires an in-depth dialogue about the outage, we'll support your internal communication process through participation in post-mortem calls with you and your management team.

Translated: "if you take heat for our outages, we'll be happy to get on the phone and help spin the problem so we don't lose your account."

Once again, thanks for you continued support and understanding. Sincerely, The Google Apps Team

I got some mail yesterday from Google about their recent Google Apps service outage. Here it is, along with my editorial comments.

We're committed to making Google Apps Premier Edition a service on which your organization can depend. During the first half of August, we didn't do this as well as we should have. We had three outages - on August 6, August 11, and August 15. The August 11 outage was experienced by nearly all Google Apps Premier users while the August 6 and 15 outages were minor and affected a very small number of Google Apps Premier users. As is typical of things associated with Google, these outages were the subject of much public commentary.

Well-deserved public commentary, at that, mostly focused on the question of why Google thinks that Google Apps is an enterprise-grade service. Three outages in a nine-day period is not confidence-building.

Through this note, we want to assure you that system reliability is a top priority at Google. When outages occur, Google engineers around the world are immediately mobilized to resolve the issue. We made mistakes in August, and we're sorry. While we're passionate about excellence, we can't promise you a future that's completely free of system interruptions. Instead, we promise you rapid resolution of any production problem; and more importantly, we promise you focused discipline on preventing recurrence of the same problem.

Notice what's missing here: any commitment to a particular level of availability, or any information about the cause of the outage, or any information about how they applied "focused discipline" to keep it from happening again.

Given the production incidents that occurred in August, we'll be extending the full SLA credit to all Google Apps Premier customers for the month of August, which represents a 15-day extension of your service. SLA credits will be applied to the new service term for accounts with a renewal order pending. This credit will be applied to your account automatically so there's no action needed on your part.

So let me get this straight: in exchange for three days of outages (in fairness, not three complete outages), you're going to give me a credit for $25/user. That's not a bad start, but I daresay for most Google Apps customers it's only a small fraction of their lost productivity. Not to mention that I might not want a service credit in the first place.

We've also heard your guidance around the need for better communication when outages occur. Here are three things that we're doing to make things better: We're building a dashboard to provide you with system status information. This dashboard, which we aim to make available in a few months, will enable us to share the following information during an outage:

• A description of the problem, with emphasis on user impact. Our belief is during the course of an outage, we should be singularly focused on solving the problem. Solving production problems involves an investigative process that's iterative. Until the problem is solved, we don't have accurate information around root cause, much less corrective action, that will be particularly useful to you. Given this practical reality, we believe that informing you that a problem exists and assuring you that we're working on resolving it is the useful thing to do.
• A continuously updated estimated time-to-resolution. Many of you have told us that it's important to let you know when the problem will be solved. Once again, the answer is not always immediately known. In this case, we'll provide regular updates to you as we progress through the troubleshooting process.

Positive steps, but note that there's no definite delivery date. Note also the weasel language around how "assuring you" is the useful thing to do. No, fixing the problem is the useful thing to do, followed closely by timely and informative status reports. Just look at what Twitter does, then do the opposite. (Actually, for a decent model, check out how the Xbox Live service folks handle outages.)

In cases where your business requires more detailed information, we'll provide a formal incident report within 48 hours of problem resolution. This incident report will contain the following information:

1. business description of the problem, with emphasis on user impact;
2. technical description of the problem, with emphasis on root cause;
3. actions taken to solve the problem;
4. actions taken or to be taken to prevent recurrence of the problem;
5. e. time line of the outage.

This is more like it! However, my business always requires this detailed information. Who says so? I do. I'm betting that Google will closely control this information, and that they will only provide it if they think your business requires such information.

In cases where your business requires an in-depth dialogue about the outage, we'll support your internal communication process through participation in post-mortem calls with you and your management team.

Translated: "if you take heat for our outages, we'll be happy to get on the phone and help spin the problem so we don't lose your account."

Once again, thanks for you continued support and understanding. Sincerely, The Google Apps Team

But you probably knew that already.

A survey out today by the organizers of the tech-security conference Infosecurity Europe found that 21% of 576 London office workers stopped on the street were willing to share their computer passwords with a good looking woman holding a clipboard. People were offered a chocolate bar in exchange for the information. More than half of the people surveyed said they used the same password for everything.

There are a lot of skeptical comments over at the WSJ blog. However, a friend of mine who is a well-known figure in the security community said this in e-mail:

...we did a similar chocolate bar or $2 pen hand out in London to collect passwords. Our gathering password rate was 84%. We then contacted each security domain (we asked for their related email address to send them a free voucher entry for more candy bars). We asked the domain administrators (ISPs, businesses, etc.) to simply review the list and send back the percentage of correct collected passwords. Our response rate from the domain administrators was only 30% or so…I can’t remember the exact number…but it was less than half and more than a quarter. The ones that did respond confirmed that over 60% were the actual passwords.

To this day, if I hadn’t participated in the survey and collected the results myself, I would not have believed it.

So, clearly if you want to fish for passwords, your odds of getting something useful in exchange for a chocolate bar and a few minutes of face time with a good-looking woman are pretty darn good. Scary!

A federal magistrate just hammered six Qualcomm lawyers for failing to properly handle and produce evidence in the long-running Qualcomm vs Broadcom patent dispute.

The judge concluded that their declarations and other evidence lead to "the inevitable conclusion that Qualcomm intentionally withheld tens of thousands of decisive documents from its opponent in an effort to win this case and gain a strategic business advantage over Broadcom," according to 48-page order released late yesterday.
"Qualcomm could not have achieved this goal without some type of assistance or deliberate ignorance from its retained attorneys," she added.

Ouch! I've written about this issue before, and it's not going to go away! You'd better have an effective discovery strategy in place before your organization ever gets involved in litigation, and this strategy should probably extend to making sure your inside and outside counsel aren't stupid enough to try to "lose" e-mail messages. That trick never works.

Technorati Tags: Unified Communications

Today's mail brought a welcome surprise: the 2007 Despair.com catalog. (Despair offers a collection of very funny faux motivational posters like this and this, and my current favorite). I've never ordered anything from them, so I checked the address on the catalog. It was addressed to me at my home address, "Suite I".

Now, let me explain. I don't actually have any suites (well, unless you count the kids' rooms) but I often assign one-letter suite codes when doing business with a new company. Guess who the letter "I" belongs to? Yep: IBM. So, someone at IBM apparently decided to sell customer data to these folks (or, more likely, to a broker who resold them). Perhaps I should start ordering Despair products for the Notes customers I occasionally work with? Now there's an idea...

Charles posted a list of etiquette suggestions based on his recent visit to Lotusphere, and Josh Maher posted a list of cell phone use social norms. Unfortunately, neither of these address a real problem I encounter when traveling: people who talk on the phone while in the men's room. I've seen a wide range of offenders, from CEO-looking types in Armani to flannel-shirt-clad, John Deere-cap-wearing rustics. It amazes me: if you wouldn't talk to your boss through a bathroom door, why on earth would you do it with a cellphone?

Let me make this perfectly clear: under no circumstance would I make a phone call while in the restroom, unless perhaps someone needed immediate medical help. Nor would I stay on the phone, chatting away, while I stood in front of the urinal doing my bidness. I'm pretty sure none of my friends, customers, family members, or co-workers want to talk to me that badly.

So, to summarize: no phone use in the bathroom. Thankyouverymuch.

For the last few weeks I've had an odd problem with mail sent from my Treo. The solution ended up being unexpected.

I carry a Treo 700w pretty much everywhere I go. It's connected via Exchange ActiveSync to my home Exchange server and via IMAP to my server at 3Sharp. Combined with Entourage (and Pocket Outlook's ability to accept a meeting invite on an IMAP account and put it in the main calendar) this gives me on-the-go access to pretty much everything I need. However, since December or so I haven't been able to send from my 3Sharp account to some recipients, or so I thought.

This morning I finally got irritated enough to figure out what the problem was. Turns out it was the GRYNX greylist tool Devin implemented back in November. For some reason, it had decided that mail coming from some IPs (including the entire Verizon Wireless network) should be greylisted if the message contained more than one recipient. I guess this was expected behavior, since that's what a greylisting tool does.

The oddest thing is that I'd get an NDR message on my Treo telling me that there was an invalid recipient and that the message had been filed in the Drafts folder. This was a result of Pocket Outlook attempting to be helpful, but its message didn't really tell me what I needed to know.

I verified that this was the problem by using telnet from my desktop to log in, issue AUTH LOGIN, and try to send a message with one recipient-- worked great. I then did the same thing with two recipients and boom! I got grey. The fix was trivial: I had to add my sender address to the greylist whitelist (huh? did I just say that?) and now mail is working properly.

I'm shopping for a new laptop; I need one that has a TPM chip that can run Windows Vista's BitLocker disk encryption software. I've been very pleased with my series of ThinkPad machines, so I went shopping for a new one. Lenovo was kind enough to offer me a discounted copy of Microsoft Office as part of the deal, too.

Only $1,000? Wow, for that price I wish I could buy one for each of my computers!

From Devin, my cow orker:

Windows PowerShell could, with an unfortunate bit of whitespace, becomes "Windows Powers Hell"

Let's be careful out there. (btw, congrats to Devin on his 100th 3Sharp blog post!)

A friend at Microsoft just e-mailed me to ask if I had a brother... named Julian.

From this morning's New York Times, a fascinating article on Dr. Brian Wansink, a professor at Cornell who studies food psychology . No, he's not a dietician; he's a marketing professor. He studies factors that influence what, and how much, people eat. Check out his popcorn experiment for a sample of his findings. He also has a new book out, Mindless Eating: Why We Eat More Than We Think, that I'm just ordered from Amazon-- sounds really, really interesting. (Sample: if M&Ms all taste the same, why will people eat more of the colored ones?) (nb. Dr Wansink has a blog, but it's worthless so far.)

From the "Only In Toledo" department, news that a recent crash on I-75 was triggered by... a red bra.

Emily Davis, 17, of Bowling Green admitted that it was her bra that broke and later flew from the car’s antenna on Sept. 26 along I-75 in Middleton Township, according to a 24-page state patrol crash report released yesterday. Two Toledo men in a trailing 2006 Dodge Neon were injured when driver James Campbell told troopers he swerved to avoid the flying bra and his car flipped several times in the grass median.

I thought competitive eating was a crazy sport, but little did I know that there was something crazier. Check out this video of a competition that revolves around opening beer bottles with a helicopter. I think I'll stick with playing soccer.

Back to the cubicle? Never, I say.

I posted about NewsGator's outage on my personal blog, and got a comment pointing me toward the official explanation. If you're interested in messaging and collaboration HA, it's worth a read. The money quote:

Frankly, this was a pretty frustrating experience. We have a lot of redundant systems - pretty much any piece of hardware in our data center could fail, and we can absorb it without a significant outage. For example, if an entire SQL box would have lost power, fallen on the floor, and broken into pieces, no problem, we'd have an approximately 10 second outage. But this case, where the database gets into an inconsistent state, wasn't helped by the redundant systems.

If I want to open some certificate of deposit accounts for my sons, I'm not going to drive all the way to one of your branches just to see what your rates are. Forget that. BankRate is much more convenient. There's this new thing called the Internet.. you should check it out sometime.

My hosting provider reports that their hosts-- or, more precisely, my blogs-- have been under a comment spamming attack. They've disabled my comments executable until further notice; I'll probably have to either rename it or figure out some way to prevent drive-by comment spams before they're willing to turn it back on.

Update: we've applied some prophylactic changes that will hopefully tamp down the spammers. Comments are now back on.

I just got a mail message from my agent. Here's what it said:

Hi Paul, A direct deposit request has just been sent to our bank for you. Your money should be deposited into the account you have on file with Studio B within 2 business days. The amount of the deposit is: $1.11 The payment is for: Digital Think royalties Q1 2005 - Windows NT Server 4.0 in Enterprise

w00t! 'Scuse me while I run down to the store and buy a candy bar.

Note: if you're troubleshooting an Internet problem, and you use your BuckeyeTel line to call Buckeye's support number, don't power-cycle the modem while you're still on the phone.

Over at BackupBrain, Tom asks people to donate to the Red Cross, then gets countermanded by comments.

First: the American Red Cross (ARC) cut off its dues payments to the International Red Cross over the Magen David Adom issue (see this link). In that light, it is shameful to withhold help from hurricane victims for this reason. I'm quite surprised that Dori, who certainly knows how to use the Internet to find stuff out, apparently didn't in this case.

Second: it's certainly true that other organizations handle their funds differently than the American Red Cross does. It's also true that the ARC has made mistakes in the past. Having said that, though, they are far and away the most efficient disaster relief agency for crises of this magnitude. Many other relief agencies do a great deal of valuable work in situations like this, but none has the institutional experience or resources that the ARC does.

Third: why all the searching for a secular relief agency? You've got one: ARC. Is it really so bad to give money to a religiously-based organization like the Catholic Charities? Organizations like CC, the LDS Church's Humanitarian Services wing, and others do their work because of religious motivations. You may dislike or distrust those motivations, but there's no denying the goodness of their results.

Update: this morning's Al's Morning Meeting has a terrific summary of relief organizations and what they're doing (drawn, ironically enough, from the Christian Science Monitor). Among the charities that might fit Dori's criteria: Habitat for Humanity and the United Way. Check GuideStar.org for more potential charities.

I wrote a column last week on the public folder management improvements in Exchange 2003 SP2. As a guide, I used Dave Whitney's post on the improvements, since none of the other SP2 documentation has been made public. Unfortunately, I didn't include a link to his original article in my column. I always do this when I link to the Exchange blog, because it's a terrific resource, but this time I plum forgot. This is unfair to Dave, who wrote the original post, so I'm posting this apology. Sorry, Dave; it won't happen again.

Ouch! This story from yesterday's Wall Street Journal details how problems with Morgan Stanley's e-discovery process are going to end up costing them a lot: perhaps $360 million, or even more. The judge in the case labeled their actions as bad faith, and that's going to cost them.

Morgan Stanley is in serious trouble because of the way it mishandled an increasingly critical matter for companies: handing over email and other documents in legal battles. Lawsuits these days require companies to comb through electronic archives and are sometimes won or lost based on how the litigants perform these tasks. Morgan Stanley kept uncovering new backup tapes, couldn't perform full searches because of technology glitches and gave material to the other side that was sometimes incomplete or late.

The Morgan Stanley folks made a number of poor decisions and mistakes-- ones that you should be sure not to duplicate in your own environment.

Update: this WSJ story says that the jury hit Morgan Stanley for $604 million. As the story also points out, the jury was instructed by the judge to put the burden of proof on Morgan Stanley, not the other way around, so it's reasonable to expect that this will be appealed, and that it might be overturned. Still, $604 million is a high price tag.

Update: the WSJ just reported that the jury awarded Perelman another $850 million in punitive damages. That brings Morgan Stanley's total tab to $1.45 billion.

I hate it when this happens: "Orthopedists say they are seeing an increasing number of patients with similar symptoms, a condition known as 'overuse syndrome' or 'BlackBerry thumb.'" I guess I'd better worry about using my Treo with SnapperMail.

So, on the Treo 650, when you enable a mail account for Exchange ActiveSync, it warns you that creating the account will empty your calendar-- if you use EAS, you have to use it to sync your calendar. I knew that, and had been manually forcing my desktop to overwrite the handheld calendar. This worked fine until (drum roll) I forgot to set the "desktop overwrites handheld" flag as a default. This morning, I synced the device and-- oops-- almost all of my calendar data is now gone. This is not the end of the world, since we're coming up to a slow time of year. I still have all of my contact and task data, but it'll be a hassle to re-enter the events I do have (including kids' holiday parties at school and my regular weekly team concalls).

I think all of the major problems are fixed, except that there are still some CSS uglinesses around. Too bad. Comments are on, except that I have to manually moderate them-- MT-Blacklist still isn't working, but I'm too aggravated to work on it right now.

75,000 pieces. Seats 1,438. Large enough to put my wife in. What is it? The Abston Church of Christ, of course, made entirely of Legos. (Hat tip: Julie)

There's been a running discussion of election fraud on the IP list for several months now, mostly focused on electronic voting systems (here's a sample). Recently, Jonathan Goldstein invited IP readers to come work with him on Election Day in Philadelphia to see what kind of non-electronic shenanigans go on. In that vein, I was surprised to see the Blade report on a New York Daily News story claiming that an analysis of the NY and Florida voter registration rolls found 46,000 voters who were registered to vote in both New York and Florida. The full story has some great quotes from several of the criminals (my favorite: "I'm not here right now"). In summary, there is no current means of detecting dishonest (or stupid) people who register, or vote, in multiple states; the process relies entirely on the honor system. Oddly, of the 46K duplicates that the NYDN story found, 68% were registered Democrats.

Inaugurating a new category for security mistakes, we have this story from Computerworld. Seems that the Los Alamos National Laboratory has had a little email security problem, on top of their other recent problems:

In the latest incident, lab spokesman Kevin Roark late yesterday confirmed a Los Angeles Times report that the lab recently discovered new incidents of classified information being sent through a nonclassified e-mail system.

"We have had occurrences recently, yes," Roark said. "We have had them in the past. It's anticipated we will have them in the future."

From my friend Pete, a microbiologist who works in the test lab of a nutritional-supplement company:

We just got in a customer complaint for us to test in the lab. I just wanted to share.

Explanation or Description: Customer complains that the product made him/her "into a Zombie". Please assay for any "zombifying" characteristics, including GABA potency, organoleptic inconsistencies, and micro contamination.

I thought LDSSingles.com was a niche site, but if you scroll down the right side of this page, Google is currently serving up an ad for MarineCorpsSingles.com. So, all you single people out there... remember, our motto is Semper fidelis, or "always faithful".

A revised version of House Bill 1640 by Rep. Derrick Shepherd, D-Marrero, would mandate three eight-hour days of community service for anyone who publicly wears clothing that intentionally exposes undergarments, or any portion of his or her pubic hair, cleft of the buttocks or genitals.

Fortunately, the ACLU, the governor, and at least one state lawmaker understand that this problem is best addressed at home. Now, if they'd ban public wearing of bicycle shorts, I could get behind that.

This is very cool: concrete with embedded optical fibers that transmit light. It's not transparent (see this picture), but it's still pretty neat.

When you're writing a book about a new product, it's difficult to get everything right. In this case, chapter 6 of the Exchange 2003 book omits any serious mention of the Exchange 2003 security hardening guide. At the time I wrote the chapter, it was unclear whether MS was going to produce it or not; I based the material in the chapter on a draft version that was circulating. After a cursory review, I don't see anything explicit missing from the chapter except details on the security templates that are included; I'll update this post after I've had a chance to do a more thorough reading.

If Julie ever suddenly disappears, I know who (or, rather, what) should get the blame: cannibal death cats from hell™. (Note to self: make sure John's cat gets E_ACESSDENIED when trying to enter my room when I stay there...)

It's a small world. Today at the Rotary Club meeting, I learned that the Rotary chapter in Kabul has been reopened. It was founded in 1968 and remained active until 1979. It turns out that a Rotary chapter near LA whose membership is mostly Afghan immigrants is cosponsoring the new club, along with a Rotary club in Peshawar. Good stuff. (And, speaking of which, I just got dragooned into the Perrysburg club's technology committee, so I expect to be tuning up their web site over the next couple of weeks. Stay tuned!)

This week's Economist had a terrific article on the geographic makeup of the US armed forces. It's only available to print subscribers, but I'm furnishing a commented excerpt (my comments are in italics):

WHO are the young men and women now going to war? A look at where America's armed forces come from reveals the continuing variety of the country. Two states, Texas and Florida, account for nearly a quarter of the total (Well, that explains the tans): Texans alone make up 18% of the army. (Let's see: 18% of 750,000 is 135,000; that means according to page 11 of this report Texas has more troops than Australia, Libya, or Saudi Arabia, and nearly as many as Israel and Greece), California (which provides 12% of the navy and 11% of the marines), New Jersey and Pennsylvania round out the top five states. In general, the navy gets a surprising number of recruits from the mid-west (I don't know why this is surprising; the cliché about farmboys joining the Navy has been with us at least since before WW II); the air force hails, on the whole, from the west (The west, or California?), and from Alaska; marines come from all over. Soldiers-- the people who do the hard work on the ground-- tend to come from the obvious places. The harder-jawed a region, the likelier it is to put its young into the army. The generally Republican, pro-gun south contributes a lot more soldiers than the Democratic north-east, both in absolute numbers and percentages of the regional population. A Texan is eight times more likely to be in uniform than a New Yorker. (Again, this is perfectly unsurprising, except that I might have guessed it to be ten or more times more likely to find a Texan in uniform...) The presence of military bases and arms-making firms also has an effect. Again, the south leads the way. Virginia has five army bases, Georgia four; Texas has eight air-force bases, Florida five, South Carolina and Georgia two each. Seven (actually, there are nine by my count, including reserve units) southern states have marines stationed on their soil (OOH RAH! Conquering from within, that's the USMC way!), including at Camp Lejeune in North Carolina, Camp Albany in Georgia and Quantico, in Virginia (which is shared with the FBI, the Presidential helicopter detail, and a number of other functions). The arms-industry factor may help to explain why Washington state, which in politics leans to the Democrats but until recently was the home of Boeing, a huge defence contractor, offers many of its young people to the armed forces. (Doubtful; after all, look at Grumman (Bethpage, LI, NY) or the various California-based contractors for counterexamples. Arms factories ended up in the South for two reasons: political patronage and the availability of cheap land and labor.) The number of troops a state provides is not always a clue to its political opinions(not least because the political opinions of those who volunteer for the military are often quite different than those of the "average" American): New Jersey's contribution, large for its size, has not prevented President Bush's approval-rating there from sinking back to pre-September 11th levels. But Mr Bush can take comfort from the fact that most of his men (and women) at arms come from, or are based in, friendly states, not least his own, almost-a-fifth-of-the-whole-army Texas. And he does not have to rely entirely on native-born Americans. The air force says it has more men born in Britain than in admittedly tiny Delaware. (Wow. Does that mean that low-population, low-growth states like Delaware are in danger of being delisted?)

I don't have any errata yet, but instead of maintaining a separate static page, I've decided to create a new category for errata. What prompted this? I got mail from the guy at Microsoft Press who heads the support team for their security books, asking me if I'd answer reader email. "Shell, yes", I told him; the new category is preparation.