Friday August 13, 2004

Second Wind

Dear Diary, been busy.

The Good

This weekend I'm diving in Lake Travis to finish up my PADI open water diver refresher course. I am not an experienced diver ( 7 dives with about 2 hours of bottom time ), but I looking forward to the check out dives and starting again. My friend and cow-orker Roy and his wife have just recently completed the PADI open water diver course and are taking the advanced open water course this weekend.

I'm almost all kitted out, just missing a regulator/first stage and a dive computer. I think I've made up my mind on both, but I'm easily swayed. For regulators, I've been considering the Aeris Sport Pro, the Atomic Z1, and the Mares Abyss. All are solid regs, but lacking an opportunity to try them all I have to fall back on recommendations and reviews. So far I'm leaning towards the Aeris Sport Pro.

The dive computer I've decided on is an Aeris Atmos Elite, which is a hose-less wrist mounted computer with a tank-mounted transmitter ( not a radio apparantly, but something that can wirelessly transmit tank data to the computer ). I considered other air-integrated comptuers as well as other wrist computers. The Aeris appears to give the biggest bang for the buck. The dive instructor I'll be with this weekend uses an Elite, so I'll get a chance to play with it (maybe). The wrist mount seems to be the most conservative place you could put your expensive computer, as well as putting it in a position where it can be checked more often. ( You can always find your wrist, sometimes it's hard to find your console if it's not clipped in. ). It's a lot of cash for an initial purchase, but I'm hoping to avoid having to re-buy gear in the future by going alittle overboard to begin with.

I transitioned from Redhat 7.1 (ancient) to Fedora Core 2 on my machine at home, so I had to spend alot of time migrating services that had I had setup long ago and forgot about. DNS and mail via postfix were the first things to be setup, followed by postfix and spamassassin. I only just now got around to setting up the cron jobs which control all the X-10 lighting around the house, and it feels good to not have to turn lights on and off now. I use a X10 Firecracker serial port dongle to send X10 commands wirelessly to a wall-plug mounted receiver. The Firecracker is pretty neat, but uni-directional so you can't query device status. I just ordered a bi-directional dongle from X10.com, but haven't had a chance to play with it yet.

My wife recently got our new fish tank set up, so I thought it would be convenient to plug the tank light into an X10 appliance module. After all, that worked pretty well with the last tank. Wrong. It turns out that run-of-the-mill X10 appliance modules have a feature called "local control" which monitors the draw of the plugged in device somehow (I'm not an electrical engineer and don't pretend to be ) to see if you are trying to turn it on when the module is off. When it sees a draw or whatever, it obliges you and turns power on. This is all well and good for regular appliances, but florescent lights are a whole different animal. You can turn them on and then turn them off, but after a 2 second pause they turn right back on again. It's like having a very annoying ghost. Well, on www.smarthome.com they have a convenient FAQ which addresses just this question. On the particular module I have, you can disable the local control circuitry by opening the module and cutting a trace on the backside of a small circuit board. I gave it a try, and what do you know, it worked. Of course I managed to damage my thumb while doing this, but I like to think that spilling my own blood somehow enhanced the probability that it would work on the first try.

The Bad

Luckily, this section is sparse. My dog Sam is still limping since getting accidently trampled over the 4th of July, but seems to be getting slowly better. She has always had trouble with her right rear leg, but she's not getting any younger and doesn't bounce back quite as fast. She is mostly a three-legged dog now, but every day she seems to be putting alittle more weight on it.

I cut the dickens out of my thumb cutting the aforementioned X10 circuit board trace. I knew I was tired, but I wanted to see if it would work. As I was digging into the board with my pocket knife, I remember thinking to myself "If the blade slips, I'm gonna cut the snot out of my thumb." And then the blade slipped. So the moral of this story is: If you are tired and it involves knives, wait until you aren't tired. And if you think you are going to cut yourself, you probably will. My previous serious injury with a chef knife started with me being tired and thinking that I was about to cut myself. Well, it seemed serious to me; the finger nail eventually grew back.

The Ugly

I can't put the instruction tracing thing away quite yet. DTrace is slower at instruction tracing than my user trap handler tracing tool, but the amount of effort that I had to invest using DTrace was significantly less. Since the DTrace pid provider allows you to specify probes by offsets into functions (rather than by pattern matching instructions or mnemonics), I thought it might be fun to write a perl script which takes a victim object and generates a DTrace script with probes for just the control transfer instructions (CTIs). It's not quite done yet, since I haven't written any perl in quite some time and have forgotten alot more than I expected :). Firing a DTrace probe every 5th instruction on average should go a long way towards reducing the DTrace impact on the program under test. Whether it's interesting to anybody is a whole 'nother question!

-ejo

(2004-08-13 10:58:40.0) Permalink Comments [1]