One of our machines has recently started logging cryptic but verbosekernel messages about page allocation failures. Naturally I went diggingto try to find out just what the bits mean, how alarmed I should be,and what was probably causing the failures. I now know a certain amountabout decoding the cryptic reports, so that's what I'm going to coverin this entry.

Here's what I know so far about decoding, in the form of a walk-throughof a sample message:

imap:

The Linux kernel doesn't consider all of your physical RAM to be onegreat big undifferentiated pool of memory. Instead, it divides itup into a number of different memory regions (at least for kernelpurposes), which it calls 'zones' (to simplify slightly). What memoryregions there are depends on whether your machine is 32-bit or 64-bitand also how complicated it is.

The zones are:

• DMA is the low 16 MBytes of memory. At this point it

In the process of writing client side JavaScript to modify and validate forms, I've run into a number of tricky bits and gotchas. In my usualtradition I'm going to write them down here, if only so that I can lookthem up again in a year or two when I've forgotten them all again.

Like many web apps, ours has a core (server-side) form processing flowwhere we first display the initial blank form, then on form submissionwe validate it and if

Here's something important that I just realized about in-browser form validation: in-browser form validation lets people check their options out orto phrase it differently, in-browser form validation lets people changetheir mind.

Yeah, sure, technically plain forms let you change your mind too. Butthe problem with a plain form that asks people to make a choice, likepicking a login name, is that the only way you have to find out if thelogin you're considering is taken or available

Here's a little provocative question: why should mailers have timeoutson email delivery at all? Wouldn't it be more helpful to users to nevergive up on a message?

In practice, there are at least four reasons to configure your mailer toexpire sufficiently old messages:

1. some hosts or domains will never accept your email; they are permanentlyunresponsive (sometimes in general, sometimes just to you).

2. there's so much unexpired old email in the mailer queue that it startscausing problems for your mailer

I spent part of today adding more JavaScript to our account request system , in the form of some client sideform validation code. As part of this I wound up considering whichbits of form validation are worth doing in the browser.

Of course, for some people the answer is 'all of them'. This maybe justified or worthwhile in some environments, but my view isthat I don't have the time or energy to write a second copy of formvalidation code (and any needed backend services to

One of the immediate corollaries of there being lots of differentsorts of email and there being noreliable way of telling them apart is that different people can wind upbasically using completely different flavours of email. For example,some people in your organization may basically never use email for realtime conversations, at least not with outside people, while others mayneed to use it this way all the time. An important consequence of thisis that at least some anti-spam precautions on incoming email areintrinsically dependent on the receiver

A commentator on on my entry on mailer delay warnings suggested, in response to my view that repeateddelay notices are bad partly because after a day the sender isn'texpecting the mail to get through soon anyways:

I think the default for many mailers is to warn after one day, andgive up after five. Given the above sentence, in addition to a warningafter an hour (as you state), it seems that you opinion is that themail system should give up after 1-2 days.

Most Unix mailers have a feature where they periodically sendpeople warning notes about email messages that haven't beendelivered yet; Exim defaults to doing so roughly every 24 hours, forexample (this is the delay_warning configuration setting, cf ).I've come to believe that typical default values for when this happensare both too slow and too frequent, and should be rethought in today'sInternet mail environment.

(Actually it looks like Postfix defaults to not sending delaynotifications, so this may