Unfortunately, our SMTP frontend died Thursday afternoon, so some ofour usual stats are approximations or partial stats. Having said that,this week we:

• got 11,577 messages from 283 different IP addresses.
• handled 20,711 sessions from 1,929 different IP addresses.
• received at least 317,396 connections from at least 73,000different IP addresses.
• hit a highwater of 38 connections being checked at once.

In

One of the things I discovered when I came here was that while cable management arms camestandard with many of the servers we bought, we weren't using them; infact, when we moved servers that had them, we tended to remove them.This surprised me a bit, since they're generally a part of a wellorganized rack, and I recently got around to asking my co-workers aboutthis.

It turns out that there is a simple reason: heat dissipation. Ourracks are all

The corollary of who actually benefits from bug reports and yesterday's principle is that the more work you make people go through to report bugs,the less bug reports you get, and almost certainly the less good,detailed bug reports you get (because those are a lot of work ).

Here, 'work' includes all of the various bits of overhead that you makepeople go through to file bug reports, including creating accounts .Also, every question that you ask in the process of submitting the bugreport

I've mentioned this in passing before, but I should be explicit at leastonce. Here is a very basic principle of designing systems that realpeople will use:

The people that benefit should be doing the work .

Okay, there is one exception: the people getting the benefit can payfor the work instead of doing it directly.

You design systems that violate this principle at your peril, becausegenerally it doesn't work in the long run. You'd think that thisprinciple would be obvious,