Overheard in Portland

Scene: Busy Portland coffee shop, Sunday afternoon. VAL, a workaholic programmer transplanted from the Bay area, is typing intently on her laptop. Enter four middle-aged men, talking loudly. They choose the table next to VAL and engage in much good-natured (and loud and annoying) shuffling around and unpacking of laptops. Their leader finally calls them to attention.

LEADER: Okay, let’s get started. So, should we hire more salesmen in Paris? Or wait till next quarter?

MAN #1: [European Spanish accent] Well, I don’t know. What’s our budget?

[VAL perks up and casts an interested look, as she comes from the Land of Start-ups and such conversations are relatively rare in Portland.]

LEADER: I guess it really depends on whether we ship both business softwares.

[VAL looks slightly affronted. How come these, er, average guys have a startup with international sales offices and they don’t even know the correct plural of software?]

MAN #2: [mutters as he struggles to pull out his laptop] I hate this laptop. As soon as I get a real job, I’m giving this to my son.

LEADER: I talked to the professor, and he says that we should focus on the markets that our competitors are doing well in – follow the leader, you know.

[VAL looks somewhat impressed that they are consulting with distinguished academics.]

MAN #3: [unidentifiable Eastern European accent] Should we have a cushion for unexpected costs?

LEADER: I don’t think the professor’s going to dock points for exceeding our budget that way, no.

[VAL makes “Oh!” face as she realizes these people aren’t in a start-up, they’re in business school. Immediately feels better about herself for having zero sales offices in Paris.]

Overheard in D.C., random sighting in Albuquerque

On Monday, I was running the StorageSS ’07 workshop, held just outside Washington, D.C. While riding in the conference hotel shuttle, I overheard two grad students talking:

“So, have you seen any of the sights yet?”
“No, but I want to go see the man in the chair.”

And today, I’m in a coffee shop in Albuquerque, and I randomly see a dreadlocked dude browsing through the books who is wearing, of all things, a Solaris 8 t-shirt. It asks if your company is “dot com ready.” Looks brand-new, too.

Amusing cryptography apocrypha – the Rip van Winkle cipher

While writing an article on cryptographic hashing for programmers, I stumbled across the Rip Van Winkle Cipher in Applied Cryptography:

James Massey and Ingemar Ingemarsson proposed the Rip Van Winkle cipher, so named because the receiver has to receive 2^n bits of ciphertext before attempting decryption. The algorithm, illustrated in Figure 17.10, is simple to implement, provably secure, and completely impractical. Simply XOR the plaintext with the keystream, and delay the keystream by 0 to 20 years – the exact date is part of the key. In Massey’s words: “One can easily guarantee that the enemy cryptanalyst will need thousands of years to read the plaintext, if one is willing to wait millions of years to read the plaintext.” Further work on this idea can be found in [references].

Fittingly, I have a Bruce Schneier sticker stuck to the lid of my laptop, courtesy [info]mjg59 .

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);