The blue dragon was misbehaving once again. To repeat, it’s a 1987 Oldsmobile Cutlass Ciera with the Tech-4 variant of the 2.5L Iron Duke engine. She was idling really rough, had a lot of vapor coming from the exhaust, and was drinking coolant at an alarming rate. After replacing the faulty radiator, the coolant leakage got better, but didn’t stop. Sounded like a head gasket issue. Someone told me to check the oil, if it’s a milky color, that means there’s coolant in it, which signals a blown head gasket. So, when I popped the valve cover off, I saw this:

I think that qualifies as a “milky color”. Yikes. Ok, so time to start pulling the engine apart to get to the head gasket. After about 4 more hours of labor and a few smashed arm incidents (those head bolts are tight!), I finally got the head off, and saw this:

Now, a lot of this coolant got in there while I was taking the head off, so it’s really not as bad as it seems. But, notice that cylinder #1 (leftmost) is slightly more full than the others. After drying the water out, the problem became much more apparent:

Yikes again! And so was it really the gasket? I inspected the head and didn’t find any cracks. Then, taking a closer look at the gasket, I found the problem:

So long story short, it was another 5 hours of labor to get everything back together into good working order. I think the total job ran me about $285, which isn’t bad considering I did pretty much an entire upper engine rebuild. That price includes new head bolts (which you should always do – if you reuse, they can snap. If they snap, you’re done), two oil changes, new exhaust manifold, more coolant, and all the associated gaskets.

Photos from my phone from Sunday, 8/28, the day after the storm went through.

Photo of the lake behind my apartment, the water is supposed to stop a few feet short of that fence you see sticking up.

The crushed stone is supposed to be a dam all the way across the end of the lake, with probably a good 10-foot drop-off. As you can see, the water does no dropping. Houses past this dam had at least two feet of water against their walls.

River, errr, Route 1. This is the view from the Route 95 overpass. Looking north, there were a few cars that had gotten stuck. The water was halfway up their windshields.

I do have a droid 3, and have been waiting anxiously for a rooting mechanism. Yesterday, when someone on a mailing list I frequent posted a link to a forum announcing a droid 3 root, I had to get in on it. But the mechanism was in the form of a Windows binary-only application. Below the link were several people complaining that the file was tripping up their antivirus software. Running strings on the file, I was able to see that it was creating outgoing TCP connections to port 6667 (IRC). You do the math on that one. I was also able to extract the rooting method, though, and I’ll reproduce what I did for others:

Run “adb shell” on a computer connected to the droid to enter these commands.

mv /data/local/12m /data/local/12m.bak
ln -s /data /data/local/12m

Now, reboot the phone. When it comes back up, adb shell into it again and run:

rm /data/local/12m
mv /data/local/12m.bak /data/local/12m
mv /data/local.prop /data/local.prop.bak
echo ro.sys.atvc_allow_netmon_usb=0 > /data/local.prop
echo ro.sys.atvc_allow_netmon_ih=0 >> /data/local.prop
echo ro.sys.atvc_allow_res_core=0 >> /data/local.prop
echo ro.sys.atvc_allow_res_panic=0 >> /data/local.prop
echo ro.sys.atvc_allow_all_adb=1 >> /data/local.prop
echo ro.sys.atvc_allow_all_core=0 >> /data/local.prop
echo ro.sys.atvc_allow_efem=0 >> /data/local.prop
echo ro.sys.atvc_allow_bp_log=0 >> /data/local.prop
echo ro.sys.atvc_allow_ap_mot_log=0 >> /data/local.prop
echo ro.sys.atvc_allow_gki_log=0 >> /data/local.prop

Reboot the phone again. When it comes back up, adb to it a third time, but this time notice that you have a root prompt! Setting atvc_allow_all_adb to 1 disallows adb from dropping its root privileges. Now, to make this accessible to the device, run:

mount -o remount,rw /dev/block/system /system
cat /system/bin/sh > /system/xbin/su
chmod 4755 /system/xbin/su

Now, go into the market and search for the “superuser” application. Install the one with the jolly-rogerish logo, then run it and have it install its su binary. Once that’s done, we need to remove the su application we created, so in the adb shell you still have open, run:

rm /system/xbin/su
mount -o remount,ro /dev/block/system /system
sync

That’s it! You’re all set. Enjoy having root on the droid 3!

I took several classes in college that were all about corporate buzzwords, but all of them failed to mention a trend that is huge in corporate culture – that of the “best practice” document. In theory, these documents are great, and help you get the most out of your product, methodology, or technology. However, there are a few problems that these documents tend to create, and it is up to the reader to take them with a grain of salt. Listed below are a few of the pitfalls of adhering directly to one of these documents.

1) No one is perfect
“Best practice” documents are generally written by an idealist. This person has the responsibility to make the product or technique about which they are writing perform optimally. This means there is very little consideration for outside variables. Points in best practice documents tend to be very black and white – Do this, do not do this other thing, etc. Yet, how often is it the case that a reader is concerned with making only one piece of a puzzle work flawlessly? The answer is a resounding “never”, it takes the other 499 pieces of the puzzle working in tandem as well to produce something worthwhile and appealing.

2) Context is key
While we’re on the subject of black and white bullet points, we should discuss context. While adhering directly to a “best practices” document, it becomes easy to miss apparent pitfalls right in front of you. The document might say, “XYZ should look like ABC.” It becomes increasingly easy to see only the fact that XYZ != ABC, and even easier to miss the circumstances that made XYZ a little different than ABC. As mentioned in point #1, the writer of the “best practices” document is concerned only with making XYZ the best it can be. Often it is the case, however, that the overall quality of a product can be increased by decreasing the effectiveness or simplicity of a single component in the equation. Hence, context really is everything.

3) Stagnation is an enemy
“Best practice” documents literally define the status quo. Anyone who uses the same product or technology that you use will have access to this document. Therefore, it follows that they will have the same setup, the same features, and the same problems as you. At this point, what sets you apart? Where is the innovation, the fresh ideas to shake up the ordinary? As I remember reading elsewhere, what would have happened if Google followed the search engine “best practices” set forth by Yahoo and Alta Vista? Where would Apple be today if they took pages from IBM’s book about personal computers? This all lends itself very nicely to the next point.

4) Opinions become squelched
Now suppose you or a member of your team has an idea that challenges something stated in the “best practices” document. Which do you follow? Who do you trust? Odds are that you or your team member has much more insight into the issue than a document. However, when adhering directly to one of these documents, it becomes way too easy to ignore the opposing opinions altogether and do what is recommended in the document.

Now, I’m not saying that “best practice” documents are complete garbage. Often they contain many helpful tips and tricks for getting the most out of whatever they are written about. Yet, it is important to remember they are not the bible. To summarize my feelings on the subject, context is everything, and if there’s one thing “best practice” documents lack, it is context.

Mother nature’s kicking in some serious wattage via rainbow.

There, I updated.