Suppose you have a system with nodes and work items. You have to assignwork items to nodes somehow; one way to do it is to randomly distributework items around the nodes, but another is to assign them based onsome sort of fixed-outcome affinity function (like 'is topologicallynearest'). Now consider what happens when a node overloads or fails (oris just taken out of service) and its work has to be reassigned to newnodes.

In a random-assignment system, the failed

This used to be widely understood around Unix, but it's evidentlyslipped from common knowledge over time:

It's a mistake to log nonexistent usernames on bad logins .

(Corollary: it is an especially bad mistake to log them by default.)

To illustrate why I say this, let me tell you what happened tome recently. I normally leave myself logged in to my officeworkstation with the screen locked and blanked. This weekend, my officeworkstation crashed and rebooted because of some ongoing issues ; as

Here is a core principle of how and when programs should show error andwarning messages of all sorts:

Error messages should only go to the people who can do somethingabout them.

This goes double for warning messages.

(Sometimes you don't have a choice, at least in theory; if your programsuffers a fatal error and you have nowhere else to log it, dumping it onthe user does some moderate amount of good. Maybe.)

There's two reasons to be careful where your error messages

One corollary of Internet scale security is topoint out a lurking issue with microtransactions (one of the perennialInternet enthusiasms in some quarters). The problem is how you handleauthorizing microtransactions.

If you prompt the user every time they spend a cent, I think it's verylike that people will rapidly find this far too annoying and stop usingmicrotransactions at all. If you do not require the user to authorizetransactions you open yourself (and the user) up to attacks wherethe user's browser or other

Ten years ago or so, mass login and password guessing attacks wereessentially a non-issue; old news, an attack whose time had passed notonly because everyone knew how to counter them but because they had sucha low payoff that no one bothered doing the tedious work (and if someonedid, you pitied them).

Then the Internet happened and everything changed. Suddenly masspassword guessing attacks were not a theoretical issue; instead, theywere cluttering up your logs every day .This happened not because mass password

For the purposes of turning off the irritating blinking cursor , there are three generations of gnome-terminal (so far; the Gnome people may yet change their minds again), each ofthem with a different way to do this. So it goes like this:

• in the original version of gnome-terminal , there is a direct preferencefor this; in the General tab of each profile there is a 'Cursor blinks'option.

• in the intermediate version of gnome-terminal , there is no optionin gnome-

I've recently realized an attraction of planet-style blog aggregations: by design, they haveno way to go back in the feed history. You get one page of entries(however larger that is configured to be), and that's it.

This sounds like a peculiar thing to be an attraction, but it means thatcompulsive information junkies with not enough spare time have no choicebut to let things go. We cannot wind up sitting on several thousandunread feed entries that we are theoretically going to

Courtesy of Slashdot , we learn that Verizon is moving to authenticated email submission so that, to quote the Verizon spokesman:

[...] Verizon will be able to quickly identify spammers, includingthose using so-called zombie systems, and shut them down.

Sounds great, right? Not really. The problem is that this changeshouldn't be giving Verizon anything that they don't already have.

Verizon already has a perfectly good way of quickly identifying theirspamming customers, namely the spamming machine's

When we talk to people about passwords, especially about websitepasswords , generally what we teach themis some variant of 'do not write down your passwords and always usedifferent ones on each service'. Time after time, what happens is thatpeople follow half of this; they have only one common password, but theydon't write it down.

It has recently occurred to me that there is a sensible explanationfor this result (beyond the obvious one that it is the more convenientoption if you are only