The newest addition to my stable of laptops, the Thinkpad T430s. I replaced the factory hard drive with a Samsung 830 SSD, 256GB, so I’ll review that too.

more...

After deciding a 3G tethered internet connection wasn’t enough (though honestly it kind of was, I just miss Amazon videos), I signed up for Comcast xfinity cable internet service. (Sidenote: I like the name xfinity. It’s a little cool, not trying too hard, suggests the future is now. That kind of thing.) I bought my own modem (uBee 3513) to avoid the bonus rental charge. Waited for my self install kit to arrive. Open it up to discover it’s... 3 feet of coax cable. Thanks. I could have gotten the ball rolling days ago if I knew that’s all you were shipping me.

more...

No, it’s not a game. LevelUp is yet another payment system to compete with credit cards. The competition is more on the merchant side, since clients still need a credit card to pay, but the way it works is you link a credit card to your account, get a QR code, and then flash that at the camera phone next to the register to pay. It’s very fast, especially when compared to any transaction involving a rewards card. I like it a lot, even more so since I carry my phone more places than my wallet. (I think you could even just print out the QR code and carry it around on paper, but I haven’t tried that.)

more...

Finally gave in and ordered a new Thinkpad T430s. Hasn’t arrived yet, but man what a frustrating experience. First, as mentioned before I was kind of waiting for the X1 Carbon, but that gets old after a while. The slim T model seems like a reasonable compromise and the price has come down some recently. (I’m expecting the X1 to cost a fortune and have a month long wait for shipment even then.)

Speaking of price, the worst part was that every couple days Lenovo changes their prices. The “web” price is always about half the retail price, but then there’s some “day ending in a y” 15% promotion code that changes. And then various discounts on this component or that component. This time around, I got the bay battery, but had to buy it separately because the battery sale only applied in the “Accessories” section, not on the regular configuration screen.

Also, as I discovered only after purchasing, and only by reviewing the service manual, the i7 upgrade apparently also gets you a Thunderbolt port instead of DisplayPort, but nowhere is that mentioned on the web site.

Almost went with the 15-inch Samsung 9 series, but decided that a full power CPU is nice, and full sized VGA and ethernet ports are necessary. The extra half pound shouldn’t be so bad, and I remain suspicious of Samsung’s keyboard. Even if I haven’t yet tried the all new and improved Thinkpad keyboard, I think it’s a change I can live with.

I recently spent a little time fixing and improving realloc in OpenBSD. In addition to the short commit messages, here’s a longer explanation of the changes that gives more background and a better understanding of both malloc and OpenBSD.

more...

Lots of fuss recently over how one should store users’ passwords in a database. One angle that hasn’t received much attention, and which I myself hadn’t thought much about, is how to store cookies such as auth tokens. I’m assuming for this post that we’re using the technique of generating a random string, setting it as a cookie, and then saving a copy in the database. When the visitor returns, they send the cookie and you compare with the value stored in the database. (Some frameworks set an HMAC signed token instead; they should be safe from the problem I’m about to describe.)

The problem is that these tokens are equivalent to passwords. They let anyone who has one login. If someone steals your auth token database, they can login as any user, just as if they had stolen a plaintext password database. They also may be vulnerable to a timing attack during comparison, depending on what you do and who you believe. The solution is to treat them just like passwords. Hash them before storing in the database. Just once should be enough; if your tokens aren’t at least 128 bits of random data, you have other problems. Then every time you get a cookie from the user, hash before looking up in the database. Now if someone steals your database, they have a lot of work ahead of them trying to recreate the token they need to submit to login.

Alternately, using HMAC signed cookies should be sufficient, but there have been several vulnerabilities related to their implementation, so I remain cautious.

The new Apple Macbook Pro released today reminded me I want a new Thinkpad. Unfortunately, Lenovo seems determined to convince me I’d rather have a Mac. I currently own and use two Thinkpads, a big T60 and a tiny X200s. I’d consider replacing either one or getting something in between. My first concern is that the Thinkpad’s legendary reliability is slowly becoming the stuff of legend not reality. And there’s nothing either with a nice 1400x1050 screen or as lightweight. But I’ll probably get by, even with the new keyboard.

more...

With the conclusion of the rthreads hackathon a short while ago, the OpenBSD Journal ran a series of interviews with some of the participants. I figured I’d add a little more to the story, although there’s not really anything new to say. My involvement with rthreads has been pretty minimal recently, but I’ll start from the beginning. Like I said, nothing new, but sometimes it’s nice to have the whole narrative in one piece.

more...

Timezone support in software is tricky. A lot of the time when you’re sharing information, there are several timezones involved. But it would horribly clutter the UI to display all of them, so one is picked. For instance, with email should we display the time formatted according to the local timezone or sender’s timezone? Do we care when we received it or when they sent it? For Mailtanium, I chose to display all local times in list view, so emails sort in some semblance of visual order, but to display in the native sender timezone in detail view, to remind me it’s really 3:00am in Europe. I don’t think this is an original idea, I copied it from any number of other clients.

A more perplexing case is the iPhone calendar. The calendar is unfortunately timezone aware when I don’t want it to be. My typical (practically only) use case is to enter my flight info in the calendar. I would like to enter the local time my flight leaves, as that’s the time I get from the airline website. But then my phone assumes that’s when the event occurs in my current timezone, such that when I’m two hours away, it has now “corrected” the time to be two hours different. There is a menagerie of options controlling whether my phone’s time should auto update (Yes, please! I need to know when lunch is.) and how the calender should adjust. The best I’ve found so far is to keep the calendar always pegged to a single timezone, but this means alerts go off at the wrong time because the phone still knows where it is. I would really like a simple option to say that all events take place in the “right here” timezone. I can understand that timezone correction is a nice feature for travelers who need reminders about the weekly sales call on Monday, but that’s not me. All of my events are occurring locally, I want to enter exclusively local times.

I’ve been trying out OKCupid recently, and while entire essays, if not books, could be written about the experience, the questions it asks, and the way it asks them, is an issue for me. It’s not that the questions are weird or repetitive, or seem bizarrely unlikely to result in reliable rankings, all of which is true, but that the manner in which the questions is phrased is technically poor.

First thing to review is how OKCupid asks questions. There’s a bunch of questions, you pick one answer for you, then pick as many answers as you like that are acceptable for a potential match to give. My first issue is simply with the phrasing. Many questions ask if I would “consider” doing something. There seems to be a wide range of interpretations of what consider means.

The next issue is that many questions are too indirect, like “Would you date a smoker?” I don’t smoke, but I may say yes. But another non-smoker may only put no as the acceptable answer, rejecting me even though I don’t smoke. The direct version, “Do you smoke?”, seems like a major improvement. Lots of questions are like this. They seem designed to determine not just how intolerant I am, but how intolerant my match must be. The fact that people who are 100% compatible but differ only in their tolerance for incompatibilities could be rejected seems like a flaw to me, but maybe that’s the magic to a good matching algorithm.

Another drawback of some questions is the frequent necessity to invert the question when picking acceptable answers. A question about height that can be answered “I like to be taller” or “I like to be shorter” is a good example. The acceptable answer should be the opposite of the picked answer. In fact, there shouldn’t be a need to identify acceptable answers for such questions. People don’t seem to do a good job with the logic here. Arguably, I shouldn’t be concerned because I’m not much interested in people who fail at logic, but it clearly reduces the efficiency of the matching system as a whole.