2008-05-15: jwz's collected bicycle wisdom

jwz has a remarkably insightful article about bike ownership. Notably, item #6 makes me feel better about getting my own bike stolen last summer:

Get a u-lock. Lock through the frame and the back wheel. Your bike will be stolen, so don't get too attached to it. This also means, don't waste your money on junk like baskets and lights. Just get a backpack. It doesn't matter how crappy your bike looks: any bike is worth stealing for $2 worth of crack. Your bike is temporary. Accept this and move on.

Syndicated 2008-05-14 20:57:05 from apenwarr - Business is Programming

2008-05-13: A note on market research

I left one company after several years of faithful service. The CEO himself was elected to get me a going-away present on behalf of everyone. He got me... cuff links. (I include the wikipedia link to help out those of you who know as much about cuff links as I do.)

By comparison, where I work now, an office manager was elected to buy me a wedding present. She didn't know what I would want, so she went through my emergency contact information (the privileges of being an office manager!), called my parents, and asked them what I would want. My parents didn't know, so they sneakily called me under false pretenses, got the information out of me, and reported back. What I got, among other things, was a shower squeegee. (I include the patent office link so you can truly understand what an amazing gift that is.)

So what's the moral of this story?

Well, sometimes your office manager knows a lot more about pleasing customers than your CEO does. <!-- end of entry 200805/13 -->

Syndicated 2008-05-13 01:06:57 from apenwarr - Business is Programming

2008-05-11: Engineers without Borders

I went to an Engineers Without Borders conference in Montreal a while ago, and I was very impressed; these people seem to have their goals straight. And little did I know that it was founded in 2000 by University of Waterloo students who were in school at the same time I was. Considering it now has 25000+ members, that's incredibly fast growth.

Anyway, as a sample of the sort of things they do, here's a report of a field study of how a proposed drought-resistant crop worked out in a heavy rainfall season. Summary: not so well. But that's not the point; the point is that they actually went to check, and then reported the results honestly, just like you'd expect engineers to do. I really respect that. <!-- end of entry 200805/11 -->

Syndicated 2008-05-08 18:57:02 from apenwarr - Business is Programming

2008-05-09: Great moments in probability

Years ago (around 1999) when dcoombs and I were debugging the first versions of our "weaver" Linux-based server appliances from our apartment in Waterloo, we used to test on the cheapest hardware we could obtain for cheap.

One of these boxes absolutely refused to boot weaver, but the symptoms were strange. We had three ways of booting: boot from a CD, install an image on the hard drive and boot that, or load Etherboot from a floppy and use that to network-boot the kernel over tftp.

The symptoms were as follows:

1. Booting from CD worked fine.
2. Installing from CD to the hard drive and booting that worked fine.
3. Booting a weaver image from the hard drive (with a kernel downloaded via ftp) always gave kernel decompression error.
4. The etherboot TFTP process would always abort with a timeout after a few packets. (Etherboot of the era would do that occasionally even on a good day, but here it happened every time.)

The obvious conclusion here was that our weaver kernel image was broken, because you could boot the Debian kernel from either CD or hard disk without a problem. Right?

Well... as it turned out, no. The actual problem was a horribly broken network card that would randomly corrupt bits. About 9 out of 10 packets would be corrupted. You'd think that would be obvious, right?

Well, no. In fact, TCP/IP is specially designed to deal with the occasional corrupted packet. TCP and UDP have a 16-bit checksum on every packet, and if it doesn't match, the receiver simply throws the packet away; the sender is supposed to resend (and it does!).

I had noticed the FTP transfers were surprisingly slow, but not *that* slow, and back in those days, you could never quite remember if your network card was 10 MBit or 100 MBit. This happened to be a 100 MBit card, but 9/10 packets were getting thrown away, so we got around 10 MBit performance from ftp.

But here's what killed us: a 16-bit checksum can only detect 65535 out of 65536 possible errors. A 9/10 error rate means you're sending 10x as much data as you think you are, so a 12MB kernel+rootdisk package is actually about 120MB of packets; that is, about 80000 packets at 1500 bytes each. Thus, virtually every transfer was destined to have a tiny number of incorrect bytes! Ha!

Of course TFTP is extra dumb and doesn't deal well at all with packet loss, so it would just time out. But I remain very impressed at how well TCP managed to paper over a 90% broken network. That's the power of the Internet for you, right there.

(Thanks to jwz for having a hopefully-unrelated problem that reminded me of this.) <!-- end of entry 200805/09 -->

Syndicated 2008-05-07 18:22:52 from apenwarr - Business is Programming

2008-05-07: Oil usage trends

Every now and then, you see a trendline that actually tells you something cool.

Check out the average number of vehicle-miles travelled in the U.S. since 1983... and how it's finally stopped increasing. Via Paul Kedrosky.

<!-- end of entry 200805/07 -->

Syndicated 2008-05-07 17:11:58 from apenwarr - Business is Programming