Wine selection algorithm

All my wine knowledge was acquired “on the job,” so to speak – if I drink a wine enough times, a vague impression of the label sticks in my mind and I can sometimes find it again. But when I moved to Oregon, the wine selection leaned heavily towards Oregon pinot noirs. For a girl raised on California zinfandels, this was pretty tough.

I am happy to announce, though, that I have a promising new heuristic for choosing Oregon pinot noirs: Pick the one with the dog on the label. For a sample size of two, it’s been working quite well. The first wine I found this way was O’Reilly Pinot Noir. (Okay, I admit I partly bought it for the O’Reilly name, too.)


Kramer Vineyards Pinot Noir was quite nice too.

What next? Perhaps the dog-on-the-label rule extends to other varieties.

For your drinking pleasure, a list of the wines I do remember being good. For the most part, they are wines that Jeff Bonwick introduced me to, so he deserves the credit.

  • Ridge, Lytton Springs zinfandel
  • Ridge, Geyserville zinfandel
  • Sonoma Cutrer chardonnay
  • Ferrari Carano chardonnay
  • Frog’s Leap merlot
  • Cakebread (all whites)
  • Veuve Cliquot Brut champagne

The consequences of smart phones

While waiting for the bus outside Powell’s after Charles Stross’s book signing for his latest novel, Halting State, I finally decided to try to the new-fangled Transit Tracker phone thingy. You call a phone number, type in your Stop ID, and it tells you when the next bus/streetcar/train/people-mover will arrive. In reality, it seems to tell you when the next people-mover is scheduled to arrive, but given the mercurial quality of Portland transit schedules and the amazing decrepitude of the posted schedules (I recently saw one dated 2003 – at a “temporary” stop!), it’s sure as hell better than nothing. So I pull out my phone, dial 1-503-238-RIDE, and hear a pleasant, cheerful, clearly-not-sitting-in-a-call-center female voice say, “Hello?”

Have I mentioned that I finally succumbed to the allure of a smart phone? I picked the Blackberry Pearl after seeing Brad Fitzpatrick using some bleeding edge Blackberry model – which he promptly dumped for the iPhone. The Pearl has one of those half-keyboards, 2 letters per key. It turns out that R, I, D, and E all fit on the part of the keypad that double as numbers – they just don’t fall on the same numbers as the traditional keypad.

Back to the phone call. I haven’t figured this out yet, I’m just mildly confused. The nice lady says that she’s working with Trimet to fix this call routing problem, but that it usually only happens the first time you try. I hang up, instantly figure out the problem, and then am too embarrassed to call the nice lady back and tell her what the real problem is. Just think, there’s probably another person who gets all the calls made with the full keyboard smart phones. I wonder how many thousands of previously innocuous phone numbers are now unusable? Some friends of mine once accidentally had their phone number listed for U-Haul in the phone book one year, but at least that went away as people threw out old phone books.

For the unfortunate Blackberry user, the solution is – of course – to add another set of key combinations to your hopefully capacious memory for disconnected trivia (I’m a UNIX user, no problem!). Just hold down Alt and hit the key till you get the letter you want, it will use the correct number for you.

Now, the question: Call back the nice lady and tell her what’s going on, or assume that Trimet has figured it out?

Compiling lockstat with 2.6.x kernel

I wanted to use lockstat/lockmeter on a 2.6.16 kernel, but the lockstat userland tool wouldn’t compile.  I googled fruitlessly for a while and found a few posts from people with the same problem, but never any replies, which always means that you are doing something so mindlessly stupid that both the poster and the reader didn’t want to reply and embarrass anyone.  I resolved to post the answer even if it made me out to be an idiot.  Fortunately, only one part of the answer was mindlessly stupid, and the other was a minor header file issue.

For the mindlessly stupid part, it helps to define LINUX_INC_ROOT as the actual path to the include/ directory of your kernel source.  I managed to get this wrong about three times, so do an ls of it just to double-check.  The slightly intelligent part is that getsetdata.c wasn’t including the definition of CONFIG_LOCKMETER.  The current coolest way to include this appears to be using -include as part of compilation arguments, and it worked, so here ya go:

diff -ur lockstat/Makefile lockstat.new/Makefile
— lockstat/Makefile   2004-09-13 19:01:41.000000000 -0400
+++ lockstat.new/Makefile       2007-10-08 19:25:16.000000000 -0400
@@ -10,7 +10,7 @@

 PROGS  = lockstat
 CC     = gcc
-CFLAGS = -O2 -fomit-frame-pointer -I$(LINUX_INC_ROOT)
+CFLAGS = -O2 -fomit-frame-pointer -I$(LINUX_INC_ROOT) -include $(LINUX_INC_ROOT)/linux/autoconf.h

 default all: $(PROGS)

Fabulous!  And now I can run lockstat and get… a segfault!  Stay tuned!

Update:

The segfault appears to be because time_t was defined as something other than the one that ctime() would like to receive, and so ctime() was returning NULL instead of a nicely formatted string -> try to printf that -> boom.  The following fixed it:

diff -ur lockstat/lockstat.c lockstat.new/lockstat.c
— lockstat/lockstat.c 2004-09-13 19:01:41.000000000 -0400
+++ lockstat.new/lockstat.c     2007-10-08 20:34:13.000000000 -0400
@@ -36,7 +36,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
-#include <sys/time.h>
+#include <time.h>
 #include <linux/lockmeter.h>

 extern void    closeFiles(void);