Friday, December 12, 2008

Date with Death

In a fit of madness, I've signed up for the 2009 Tour of the California Alpes, AKA the Death Ride. I've also enlisted biking partners Keith and Bob to join me on this mad quest.

The Death Ride is a 129 mile, 15k feet of climbing, monster of a ride. This is as hard, if not harder, than any single Tour de France mountain stage. Total madness.

Registration was a disaster. They opened registration at 10am on Dec 11. At 9:45 the registration site was already returning Java server errors and "too busy" pages. It took 30 minutes of the three of us clicking reload to get though. No Linux browser support apparently.

Today I spent some time doing research on the route. The 2009 route has about 56 miles of climbing, 52 miles of descents, and 19 miles of "flats." I figure if we can average 8mph on the climbs, 18mph on the flats, and 25mph on the descents, and with about 50 minutes of stops that is 11 hours total. Ouch. Those averages are aggressive, but doable. Faster would be better of course, fewer hours in the saddle. The best way to make up time is climb faster. Simple eh? :)

I'm using the Motion Based site to research previous years routes. Good for looking at the ride profile, speed on the climbs and descents.

Needless to say, training is going to be tough. I'll need to loose some weight, work on endurance, and most importantly get my climbing legs. I'm looking forward to it.

Wednesday, July 16, 2008

Oh Deer!

On July 5th I hit a deer, a baby deer to be precise, while out riding in the Los Altos Hills. It would as my (un)luck would have it, happen at the fasted point of my ride. I was traveling at 36mph at the time as the ride data from my Garmin 305 can attest.

Below is the Google street view of the accident scene:

View Larger Map

The deer ran out from behind the tree on the left. I had little time to react, I only managed to swerve left and clip it in the rear. the impact from the handlebars broke my scaphoid bone in my wrist and the subsequent impact with the pavement cracked the radius head in my elbow. I rolled over my left side, over my head, destroying my helmet, and then managed to land on my feet facing up the hill. I managed to run backwards and avoid falling down again. Really wish I have video.

The cast stays on for another 3 weeks, then a removable splint.

Thursday, June 05, 2008

Laguna Seca June 4, 2008

I attended another BMWCCA driving school, this time mid-week at Laguna Seca. The A/B group (I got promoted back to the A group, yeah!) was uncrowded and I had many traffic free laps.

Just prior to this event I switched to more narrow tires. From 255s front and 275s rear, to 235 s front and 255s rear. The numbers are the approximate width of the tire in millimeters. That translates to about an 0.8 inches of rubber per corner. I did this because the larger tires were rubbing against the wheel wells and suspension under heavy cornering. While I was quite happy with the setup, the overall stress of monitoring the wheels during events was annoying.

The smaller tires had me running almost 4 seconds slower at Laguna Seca yesterday. Some of that time is was the fact that the tires were not shaved and brand-sticker-new. Turn in was a bit squirmy and slow to take a set. I had to completely rewire my turn-in style. With the fatter, mature RA1s I could do a very aggressive turn in and then gas it through/out of the corner. The new, skinnier RA1s needed a more gradual turn in to take a set, and a more gradual addition of throttle.

As a result of the smaller tires, I found the car responded best to slowly dialing in steering and throttle on the way to the apex, then unwinding the steering slowly on exit. Adding throttle and steering at the same time violates the general rule of never adding throttle (or braking) at the same time as steering input. And if I got the mix wrong the car would understeer, but if I got it right the extra throttle kept the car balanced and turning.

The smaller tires are definitely forcing me to be a better driver. The fatter tires were masking some bad habits, so yesterday was full of learning better and smoother steering.

M Coupe @ Laguna Seca from B Dole on Vimeo.

I saw a couple M Coupes at Laguna Seca: Bill, Julian, and Sweet. Nice meeting you all. Most pledged to attend
Dorkfest this year. Mark you calendar: July 13, 2008. Bryn

Wednesday, May 21, 2008

Random Fail

I must be out of the security loop. I first learned about the latest random number bug via a cartoon. Schneier has a short summary of the problem.

This is very disturbing because it went unnoticed since September of 2006 in a number of Linux distributions. Both SSL certificates and SSH keys generated on these systems are affected.

This reminds me of a paper I wrote on a similarly weak RNG in Kerberos, with Steve Lodin and Gene Spafford 11 years ago. In the case of Kerberos Version 4, it used a RNG that depended only about 20 bits of entropy. The maintainers of Kerberos knew it was weak and implemented a much stronger one for Kerberos Version 5 and backported the new RNG to Version 4. However, the old RNG code was left in the source tree and due to a somewhat convoluted Makefile and source code, the new RNG was never called. The failure was masked by the existence of the old, weaker RNG code.

While working at Sun Microsystems, on the groundbreaking, but commercially unsuccessful SPF-100, I did more work on RNGs. These experiences confirmed to me the difficulty in writing a good, cryptographically strong, RNG.

The RNG that our group at Sun used was based on the RNG for PGP (the gold standard of crypto at the time). The seeding and generation of random numbers were fine, except the developer had gotten too clever. The algorithm used md5 to generate random bits based on a entropy pool. If you requested fewer bytes than were generated by the md5 block, those bits would be wasted. So instead, the algorithm saved the extra random bits for later. This was where the bug was, it wouldn't make any more random bits unless you asked for more than one md5 block worth of randomness. Session keys just happened to be short enough to never trigger new randomness. So while the Diffie-Hellman key exchange was secure, the underlying session keys were very weak.

Thankfully someone was debugging and noticed that the session keys stayed the same, even after they were renegotiated. Maybe it was Rich, I can't remember now.

The moral is: be very careful building your RNG and don't forget to test the randomness of the output. The Dieharder test suit is a good start. Make sure you test the right way too. Generate the random test data exactly like the RNG will get called in the code. Same number of bits, same pattern of calls. Then don't forget to retest before you ship. :)

Good luck, and stay random.


Tuesday, April 22, 2008


I'm trying twitter. After one day, I think I see why its popular. It makes you more self aware of noteworthy and joyous events in your every day life. Events that otherwise would just be forgotten.

The down side is there is now a permanent record for every dumb, narcissistic, and trite thing you can thumb into your phone.

Wednesday, March 12, 2008

Sears Point March 8-9, 2008

The M Coupe is back in working order after this little incident at Laguna Seca last December. The coupe was mostly ok, except for a bent SSR comp rim and a bent frame.

Fast forward to March 8 and 9th with the Golden Gate BMW Car Club of America. I had two great instructors and made some solid improvements to my line. I think I now have a solid handle on the esses (turns 8 and 8a, 9), one of the hardest combinations I've driven. It is much easier with the new suspension on the M coupe (the new bigger anti-sway bars make a big difference).

A big shout out to Paul, who hustled his stock '99 M coupe around Infineon. I never mastered the esses with the stock suspension, but he just nails it. I could car never get settled before the next turn. Way to go Paul.

Also, props to my friend Hakan, who after just one track event, got bumped up to driving the the C group. I have not doubt he'll be promoted again soon. :)

Now for some video:

Monday, January 28, 2008

Year 2038 Bug

I was working at Sun Microsystems when the whole Y2K scare approached like an impending apocalypse. When the lights didn't go out as the big ball dropped, it was quickly forgotten. The real boogy man amongst UNIX programmers was the Y2038 bug. That is when UNIX time, a 32 bit number representing the number of seconds since Jan 1, 1970, would wrap back to zero.

At the time I took solace in knowing I would have long since retired from programming by 2038. No worries.

I was wrong, so wrong.

Fast forward to Jan 19, 2008. logins stop working while I'm on a two week vacation in Costa Rica. I am blissfully ignorant of any problem and don't learn about it until I'm home again plowing though my unread emails. As it happens I was setting the login cookies to expire in 30 years, no need to annoy users with constant logins (are you listening Yahoo!?). However as of Jan 19, Perl's CGI::Cookies module thinks that +30 years is 1901. All of's cookies being expired by the browser, and all logins fail. Epoch fail. Sigh.

Two hours of debugging and two characters changed in my code, I won't have this problem again for another 25 years. By then I'll be retired. (insert sounds of knocking on wood)