I’ve been moving into a new (to us) house over the last week and will probably be tied up another week or so before things settle down and the Internet connection is installed. I’ve gotten a lot of new stuff lately, ranging from a new phone (the Motorola v710, more on that when I have time) to a new coffee-maker to a new (electrical cordless) lawnmower. It’s been a long time since I was in the market for “new” (my last phone was a 1992-era Nokia) and — despite the wastefulness and consumerism of all this new stuff — I have to say a lot of stuff has improved noticeably in the last decade.

Anyway, expect more regular blog entries again in a week or two.

Ken Lavender Is A Fraud

A few weeks ago, security guru Bruce Schneier wrote a blistering critique of the “Tree” security system· in the “doghouse” section of his newsletter, Crypto-Gram· (at the moment, the website for the product reports “the website you have requested has exceeded its daily bandwidth quota of 56MB and has been temporarily de-activated”). Ken Lavender, apparently an executive of the company, wrote the following retort, which I reproduce in full to insure with the hope that it will be widely disseminated:

 From: "Ken Lavender"  Subject: ICS Atlanta I am APPAULED at your "comments" that you had made on your website: ·> You have statements are nothing but slander & defamation. They shall be dealt with accordingly. Lie #1: "How do they demonstrate Tree's security? 'Over 100 professionals in mathematics & in computer science at Massachusetts Institute of Technology & at Georgia Tech, had sample encoded messages submitted to them. Not a single person could break this code!'" That is not the ONLY way we prove it. We have examples & offer to allow people to submit their OWN messages to have encoded to SEE how good the code is. So there are THREE methods, NOT just ONE as you IMPLY. Lie #2: "These guys sent unsolicited e-mails..." HOW do you KNOW that this was the case? Have any PROOF of such? NO! Lie #3: "And if all that isn't enough to make you run screaming from these guys, their website proudly proclaims: 'Tree Encoded Files Can Be "Zipped."'" Because they can be "zipped" does NOT mean that it is "bad encoding." The "code talkers" of ww2 used LANGUAGE to "code" the messages, and THOSE COULD BE "ZIPPED"!!! And that code was NEVER BROKEN!!! Lie #4: "That's right; their encryption is so lousy that the ciphertext doesn't even look random." AGAIN, HOW would you KNOW??? Did you break it? NO! And what is "random"??? random : without definite aim, direction, rule, or method "So lousy"? HOW WOULD YOU KNOW??? You would have to KNOW how we encode BEFORE you can make such a statement, & YOU DO NOT KNOW HOW!!! If it is SO LOUSY, how come NOBODY HAS BROKEN IT YET??? And we have people ALL THE TIME trying to, with ZERO SUCCESS. I do not like you slandering something that you do not understand. ATALL!!! The ONLY question you asked was "how long is the key" AND THAT WAS IT! HOW long was the key that the 'code talkers' used? ZERO!!! JUST AS OUR IS. The encoding routine was created, tested, & verified on PAPER & PENCIL WITHOUT COMPUTERS! A child could encode data using our routine. The computer is merely used to "speed-up" the process, NOT TO CREATE IT. Our routine is based on LANGUAGE, NOT MATH. So all of you "comments" are just false, misleading & just plain ole lies! SHOW & PROVE that it is NOT random. What is the PATTERN THEN??? I am DEMANDING A FULL RETRACTION OF YOUR COMMENTS & A FULL, COMPLETE APOLOGY TO THESE AND ALL STATEMENTS. I am a person who tries to work with people as a man w/o having to "drag" others into the mess. Others? THE COURTS. You have violated Calf law by your statements. [Text of California Civil Code Section 46 deleted.] Your LIES have damaged my respect in my job & has damaged any sales of this routine. You have ZERO proof of your "comments," ANY OF THEM!!! I beseech of you, do the RIGHT THING and comply. I DO NOT wish to escalate this matter any higher. And remember this, Tree is based on LANGUAGE, NOT MATH!!!!!!!!!!!!!!!!! [Phone number deleted out of mercy.] 

The Real Alpaca

Oops! My sources inform me that the animal I identified as an alpaca is actually a llama. In the interest of accuracy and completeness, here is the real alpaca, who was not helpful with the RAID problem, either. This award-winning alpaca’s owner’s face has been clumsily obscured for her own privacy.

The Alpaca

In case you were wondering, this is the alpaca I was standing by while troubleshooting the RAID issue. (click for the full-sized image).

The alpaca did not have any ideas why the hard drives were failing, although it did suggest that perhaps I check to see if the the drives were too hot with the S.M.A.R.T. tools.

Update: my sources tell me this is a llama; I’ve fixed the image name accordingly for the benefit of Google images.

On Vacation In Michigan, RAID problems

I’ve been in Michigan for a few weeks now with my wife and her family and will be here another week. Internet access is at best intermittent, so I haven’t (and won’t) be blogging much.

The technical highlight so far has been trying to troubleshoot problems with the RAID on over a cell phone while at the county fair, surrounded by pigs and alpacas.

Speaking of RAID problems: can anyone suggest why more than half of our 200G drives would fail in various ways within a year of installation? They are from various manufacturers (WDC and Maxtor), and have failed differently, and some are giving SMART errors only days after installation. Almost all of the other equipment is new as well. Most commonly the failure shows up as kernel DMA errors, which as best I can tell don’t really point to any particular cause. We suspect temperature problems—is 50-60 celsius enough to be a serious problem?

In particular, I’d appreciate any suggestions as to how to limit the problem to hardware vs. software, hard drives vs. controller(s) vs. motherboard vs. memory… And so forth.

Cupsys Fixed

At long last, my bug #184361 is fixed and my one line patch has been accepted! This is a happy day for me. I receive dozens of hits per day related to this bug, which prevents users from cancelling their own print jobs without authentication. I’ve also had to respond to a lot of email over the last couple of years helping people rebuild cups with this patch.

My only regret is that my useful linux page is slightly less useful now that my patch has been accepted.