The Cafes

The Internet is 30 today. Exactly 30 years ago today on November 22, 1977 the first three networks were connected to become the Internet. These three were:

• ARPAnet
• A lossy packet radio network (the lossiness of this network greatly influenced the design of TCP/IP)
• The Atlantic Packet Satellite Network (a.k.a. SATNET)

There were computer networks before this, but this was the first network of networks that deliberately attempted to connect heterogeneous systems without regard for platform. It was the thing which grew into today’s Internet. Except for one brief discontinuity in 1983 when the entire Internet was turned off to switch over to TCP/IP, there’s a continuous progression from then to now.
Read the rest of this entry »

In an illuminating post (formerly at http://www.jroller.com/scolebourne/ but the domain was taken over by spammers) Stephen Colebourne demonstrates exactly why operator overloading is a bad idea. Now mind, you, he doesn’t think that’s what he’s doing. He actually believes he’s making the case for operator overloading. However the mistakes he makes are exactly the sort of mistakes likely to be made by almost anyone without at least an undergraduate degree in mathematics who tries to overload +, -, *, and especially /. If you don’t know the difference between a group, a ring, and a field, you have no business overloading operators.

Now I’m not saying that one has to take a course in abstract algebra before you can be a competent programmer. You don’t as long as the language you program in doesn’t support operator overloading (or as long as you’re wise enough not to use it if it does). However since most programmers are didn’t get beyond ODEs in college (if indeed they got that far–some of my comp sci friends struggled mightily with calculus and had to retake it repeatedly), one can’t responsibly design a language that requires mathematical sophistication in the 99th percentile for proper use. Probably one should stop with high school algebra.

Features that are guaranteed to be misused should be eliminated. In the specific case of operator overloading, I daresay, the feature will be misused far more often than it will be used properly. There are only about a dozen or so cases where operator overloading is called for, and only one is even remotely common. That one is complex arithmetic, and this single use case could be better handled by adding a complex type to the language. Arguably BigDecimal and BigInteger are a second and a third. The remaining cases are so incredibly esoteric that only a mathematician or an occasional physicist could possibly be interested in them. Can anyone name even one?

The following is a possible new chapter to be added to Refactoring HTML in the accessibility section. I’m throwing this in fairly late in the editing process, so I’d appreciate any thoughts, comments, or criticisms you might have about this. In particular, I’d appreciate any cases you can think of where autocomplete is not appropriate.

For what it’s worth, I’ve pretty well convinced myself that usernames and passwords are not such a case. That is, autocompleting usernames and passwords definitely increases accessibility and usually increases security. I don’t intend to explain why it improves security in this chapter, but if anyone wants to disagree with that, I’ll explain why in the comments.

Remove autocomplete=”off” attributes where appropriate.

<form action="/login" method="post" autocomplete="off">

<p><label>E-Mail Address: 
<input type="text" name="e1" autocomplete="off"/>
</label></p>

<p><label>Password: 
<input type="password" name="p1"  />
</label></p>

<input type="submit" title="Login" autocomplete="off"/>

</form>

<form action="/login" method="post" autocomplete="off">

<p><label>E-Mail Address: 
<input type="text" name="e1" />
</label></p>

<p><label>Password: 
<input type="password" name="p1"  />
</label></p>

<input type="submit" title="Register" />

</form>

Read the rest of this entry »

I missed a couple of important e-mails while I was in Norway this past week. Although I was checking my metalab.unc.edu e-mail at least once a day, several important responses somehow went to my GMail address instead, which I was not checking. I found them when I got home and opened my Gmail account yesterday.

At first I was perplexed, because I do not usually set my return address to GMail. Then I remembered that on the road I was using the GMail SMTP server to send, because the Speakeasy server I normally use only works from my local area network behind my router. Could GMail be rewriting my headers? So I did some experiments.
Read the rest of this entry »

I am getting quite tired of Mac OS X locking itself into the spinning beach ball of death due to failing hardware. In the last year or so I’ve had two LaCie hard drives go out on me, and a third seems to be going now. In each case, the Mac got thrown into a completely confused funk because the drive didn’t respond quickly enough or at all. Note that these drives were used strictly used as external backup device. They didn’t hold any operating system or application files.

Haven’t we learned by now that I/O is an unreliable operation, and that you should never assume that any read call will succeed, or will return data in the format you want? That’s true whether you’re talking about files or FireWire packets. Furthermore, critical components like the Finder should not block on synchronous I/O. Any I/O needs they have should be serviced asynchronously.

It’s hard to take the Mac seriously as a reliable server platform when it’s so easily brought to its knees by one misbehaving hard drive.
Read the rest of this entry »