Reach a real human

Tired of IVR systems that make it hard to talk to a real human? Paul English has come to the rescue.

Discovering Sherlock Holmes

After the success of serializing Dickens, Stanford will mail you Sherlock Holmes novels, in their original format. Starts January.

Crazy Mathematical Fact of the week

If you don't get the elegance of this, you may continue your life normally. Otherwise, prepare to lift your jaw from the floor.
Syntience Inc.:

“Our logo shows a solution to the famous eight queens problem:

How do you place eight queens on a chessboard so that none can capture any other?

To arrive at this solution you can compute (2⁸ - 1) / (8 - 1) which equals 255 / 7
which equals (rounded to 6 decimals) 36.428571

The eight digits making up that number are the numbers of the rows in which to place 8 successive queens.”

Here's proof that it works:

1   • • • • • • • X
2   • • • X • • • •
3   X • • • • • • •
4   • • X • • • • •
5   • • • • • X • •
6   • X • • • • • •
7   • • • • • • X •
8   • • • • X • • •

The ultimate CSS compatibility table

Lots of CSS hacks, and an indication (for each hack) of whether it is applied by each browser.

Instant gratification

My buddy ADH sent me the answer to my OSX download slowness. According to macosxhints, delayed ack sending is on by default, and you can turn it off both permanently and instantly. Yay!




This work is licensed under a Creative Commons License.

Your tax dollars at work

Residents of Palo Alto: your local governments have made many interesting nuggets of information available about properties within it, given either the address or the parcel number:

Owner's name and address, parcel size and zoning, building permits
Assessed value, transfer date, billing address
Property tax payment history
Local sex offenders

Curiouser and curiouser

I decided I had to figure out what was going on with my Windows-to-OSX network slowness. This time I did nc dest 2222 < /dev/random at the source machine and nc -l -p 2222 > /dev/null at the destination. Ethereal told me something quite interesting. The TCP conversation runs thus, repeated ad infinitum:
1. Windows → OSX: 1460 bytes data
2. Windows → OSX: 1460 bytes data
3. Windows ← OSX: ack for packet 3
4. Windows → OSX: 1460 bytes data
5. Windows → OSX: 1460 bytes data
6. Windows ← OSX: ack for packet 5
7. Windows → OSX: 1460 bytes data
8. Windows → OSX: 892 bytes data + push
0.2 second delay
9. Windows ← OSX: ack for packet 8
So, Windows sends 8192 bytes and then requests a push. Nothing wrong with that, it makes sure the data got delivered before continuing - but why does it take a fifth of a second for OSX to send the achnowledgement?

Let's try things in the opposite direction. This time we get 8.5MB/sec (70% utilization). That's more like it! Looking at the Ethereal trace, things are quite different:
1. OSX → Windows: 1448 bytes data
2. OSX → Windows: 1448 bytes data
3. OSX → Windows: 1448 bytes data
4. OSX → Windows: 1448 bytes data
5. OSX → Windows: 1448 bytes data
6. OSX ← Windows: ack for packet 2
7. OSX ← Windows: ack for packet 4
8. OSX ← Windows: ack for packet 6
9. OSX → Windows: 952 bytes data + push
There are no major delays here. As before, there's a push every 8192 bytes. This was measured at the OSX end, I expect Windows would have a different opinion about the order of the packets, but that's irrelevant.

I smell a bug here. Either it's in the OSX port of netcat, or it's in the OSX TCP implementation. Given that SSH performs no better than netcat, I'm inclined to believe the latter.




This work is licensed under a Creative Commons License.