Blogwell’s Black

"To prevent damage ... please remove the device from your pants pocket before sitting down"

-- HTC / Google Android phone packaging

Loading mentions Retweet

Despite Lilienthal's fate [died when his glider crashed], the brothers favored his strategy: to practice gliding in order to master the art of control before attempting motor-driven flight. The death of British aeronaut Percy Pilcher in another hang gliding crash in 1899 only reinforced their opinion that a reliable method of pilot control was the key to successful—and safe—flight. At the outset of their experiments they regarded control as the unsolved third part of "the flying problem". They believed sufficiently promising knowledge of the other two issues—wings and engines—already existed. The Wright brothers thus differed sharply from more experienced practitioners of the day, notably Ader, Maxim and Langley who built powerful engines, attached them to airframes equipped with unproven control devices, and expected to take to the air with no previous flying experience. Though agreeing with Lilienthal's idea of practice, the Wrights saw that his method of balance and control—shifting his body weight—was fatally inadequate. They were determined to find something better.

YC: Why will users prefer you over Craigslist?

Founders: We'll be more localized. Craigslist has listings from all over the city, but we'll just show you listings from your neighborhood.

YC: Maybe Craigslist would be better if it were more localized, but until you're popular you'll have to be *less* localized in order to have any listings show up at all.

Founders: So we won't turn on localization at first.

YC: But then you won't be much different from Craigslist, and there's no reason for people to switch. Your special sauce only works after you're already successful. You need a way to get there.

YC: Why will users use your software instead of Quickbooks?

Founders: Our software will be easier to use.

YC: Are there a lot of people who find Quickbooks too hard?

Founders: Yes.

YC: But a lot of people already know Quickbooks, so it's easiest for them to not change.

Founders: Sure, we won't take away their users. We'll get new users.

YC: How will new users find out about you?

Founders: Their friends will tell them.

YC: Do people tell their friends, "Say, I just found this really easy new accounting system!"

Founders: No, but when people start a business they'll ask their friends what they should use.

YC: But they're going to ask their friend who knows the most about accounting. Won't that person be a Quickbooks user? Won't they recommend what they know?

Loading mentions Retweet

Paul Graham - Startup School 2009 - partial from Alexa Lee on Vimeo.

Twitter Founders - Early experiments, Use Cases for Startup School from Alexa Lee on Vimeo.

Paul Buchheit - Been at your job too long? QUIT! - Startup School 2009 from Alexa Lee on Vimeo.

Loading mentions Retweet

From FailBlog, under the title "Business Plan Fail":

Yes, it's kind of funny. But it might be the right thing for the neighborhood.

I spent some time in a small town far from anywhere, which had 3 retail establishments. 1 department store, 1 restaurant + laundromat + video rental store, and 1 fishing/hunting store + gas station. It was an efficient solution for providing essential retail services. Out of the 1000 people in the town, less than 20 were devoted to retail. That's 2% of the population, or maybe 5% of the local labor force.

I know the modern trend is towards highly branded, tightly focused businesses. But would this town be better off with a standalone beauty salon, specialty chain saw dealer, and an Applebee's? Sounds like a lot of wasted retail labor for a doubtful increase in quality.

Loading mentions Retweet

Here's an idea for Facebook. Get rid of subject lines in messages. They almost never have any content in them other than "Hi". Nobody ever changes subject lines in threads, because it seems like you're trying too hard, so they're usually unrelated to recent conversation. And it makes it seem like when you're writing to someone, you have to have something to say that can be summarized. But often what people want to say is just one sentence, "Hey, nice to see you last night at the club" or something. There's no short version of that. Getting rid of the Subject: field would lead to a lot more messages since it makes it so much easier.

Typical subject lines contribute nothing:

But two lines of body would have been the whole message.

One of Twitter's virtue's is not requiring a subject line. Even better, it doesn't require a concluding paragraph with a call to action like blog posts are supposed to have.

Loading mentions Retweet

Wondering about bit patterns that cause my DSL line to fail, I was curious what order the bits are sent in: LSB-first or MSB-first. According to the published ITU spec:

Outside the LSx serial interfaces data bytes are MSB transmitted first. All serial processing in the ADSL frame (e.g. CRC, scrambling, etc.) shall, however, be performed LSB first, with the outside world MSB considered by the ADSL as LSB

which brought back fond memories of working on network protocols.

Loading mentions Retweet

For my Apple TV to download

-- Trevor tlb@tlb.org
Sent from my iPhone

Loading mentions Retweet

I've been having trouble with my DSL at home. Basically it works, but large downloads frequently stall part way through. It seems to happen every several tens of megabytes. I noticed that for a given file, it would typically stall in the same place. Occasionally it would keep going, but mostly it would fail indefinitely.

Using tcpdump showed that a particular packet of the download stream never came through, even though it was retransmitted several times by the sender. Could a particular sequence of data in the packet be causing it to fail? I wrote a script to try pinging my ISP's router with different random data. The ping command has a -p option to specify the data in the packet, for just this purpose. The vast majority of data patterns had 0% loss rate, but it finally found one that consistently caused nearly 100% loss:

cesium robot$ ping -p 2120fefe [ISP router]
...
111 packets transmitted, 2 packets received, 98% packet loss

Note that the bytes have a pattern: the first 2 bytes are mostly zero and the last two bytes are mostly 1. I'll get back to this. First, here's a summary of results:

Basic patterns have no loss:

Bad pattern discovered:

Many similar patterns have high loss rates:

Random patterns have no loss:

Why does this happen? I'm not sure I understand DSL well enough to explain it. In simpler network protocols, there were obvious ways in which long runs of zeros or ones could cause trouble under marginal conditions. The pattern here has a large low-frequency component (mostly zeros in the first 2 bytes and mostly 1s in the last 2 bytes) so it's plausible that it causes problems.

However, my DSL uses a very complicated discrete multitone modulation system. There are actually 256 separate channels, each using 4 kHz of bandwidth at frequencies ranging from 0 to 1 MHz. The bottom few channels are for voice. Typically 25 channels are for uplink and 224 for downlink. According to the spec, it uses complicated interleaving and Reed-Solomon error-correction coding (the same system used on CDs). So it's a little hard to imagine how such a simple data pattern can cause total loss.

The DSL router doesn't give much diagnostic info. It does report a signal/noise level for receive of around 8 dB, which is lower than the 12 dB suggested for reliable operation. And my ISP told me that my line was longer than recommended for the 6 Mbit speed. So I'm probably getting what I deserve.

It's interesting that TCP doesn't handle this situation very well. Retransmission is really driven by the sending end. It will try several times, never receiving an ACK, then give up. When it gives up, it doesn't seem to send a connection close (Fin or Rst) so the receiving end listens forever or until a very long keepalive timeout expires.

Loading mentions Retweet