The other day I had a problem; new gnome-session processes weren'tworking right on one of our major login servers. They didn't quitehang outright; instead, strace showed that they seemed to spend allof their time talking very slowly to one file descriptor instead ofresponding to other Gnome processes that were trying to talk to them.

(When this happens, the other Gnome processes are not very happy andyour entire Gnome session basically hangs.)

This left me with a big question: what

In the process of writing yesterday's entry I had one of those obvious inretrospect insights:

We all know (or at least have been told repeatedly) that just becausesomething about the code (such as where a name comes from) is clear toyou when you write the code, that doesn't mean it will remain obviouslater (or be obvious to other people). One of the core reasons for thisis context, specially how much context is in your mind.

When you are writing the

Every so often I get to re-learn vaguely painful lessons.

For whatever reason, Django has a distinct coding style, as expressedin things like their tutorial documentation. When I wrote my Djangoapplication recently I generally followed thisstyle, partly because I took bits and pieces straight from the tutorial(because it was the easy approach). One part of the Django style is aheavy use of ' from module import SomeThing ', or even ' from moduleimport * ', and I copied this for my own

Every so often, a well intentioned person will suggest that you shouldhelp out open source projects by contributing documentation (there areseveral variants of how this suggestion is made, but this is what all ofthem boil down to). The problem is that this is much harder to do thanyou might think, especially for significant technical documentation likeAPI details.

Setting aside all of the other difficulties of creating documentation,the core issue is that official documentation must above all be accurate . It is not enough to describe something

In a comment on an earlier entry , nothingsnoted:

One concern I have with web standards, which I first posted about in2004, is the fact that we keep getting new ones.

(See his comment there for the elaboration,and his other comment here has a pointer to hislonger writing on this topic, with some context.)

In thinking about where web standards come from, I think that there arefour broad explanations for them. So here is my outsider's two cents:

This is a rant.

First, do not include useful information about how readily exploitablethe bugs are. It is very well to tell people what subsystem the bug isin, but that's not enough. If there is a bug in the OSS code, can thatbe exploited from user level even on machines without any active soundhardware? If there is a bug in an obscure network protocol that themachine isn't using, is it still accessible to a user?

Relatedly, when you write that a

When confronted by the need to send email, many programs decide thatthe best way to do it is via SMTP to your mail server. As they say, nowthese programs have two problems.

The problem with having your program send email via SMTP is that SMTP receivers are not always available all of the time . Thereare a thousand and one reasons why the local SMTP receiver is notanswering right at the millisecond that your program is trying toconnect to it; perhaps the machine is rebooting, or perhaps a sysadmin

From a comment on an earlier entry :

What's surprising is not the failure of XHTML. Rather it's theenthusiasm for cargo-cult XHTML that persists to this day: HTML fileswith the XHTML 1.0 DTD decl and superficial XHTML features like
tags, but served without the XHTML mime type that would actually makethem XHTML.

I'm not surprised in the least. In fact, this is a great illustrationof the web authoring folkore that I talked about in that entry