Muli Ben-Yehuda's journal

Just bought 4 tickets to the Haifa Symphony’s “Beethoven’s 9th Symphony” concert on Sunday next week. Happy happy joy joy!

After reading this great motivational piece again, I have a barely controllable urge to buy The Complete Guide to Navy SEAL Fitness, Revised Edition, by Steward Smith.

(as seen on /.)

Some guy is forking gentoo Linux, as far as I can see, because he expected to make money out of his involvement and didn’t. His manifest, and drobbins’s rebuttal. I couldn’t care less[0] who’s right, but it’s certainly amusing to read.

[0] Uhm, maybe I could care a little – drobbins strikes me as an honest person, while that Zach person reminds me of Moshe Bar, full of his own perceived importance.

Reading lwn.net’s weekly kernel page (subscribers only for this week, sorry), I ran across a link to the Object Based Reversed Mapping patch, aka objrmap. To summarize, objrmap differs from Rik van Riel’s rmap by tracking pte entries by page->mappging->vma, instead of special pte_chains. That left me curious, as I know that wli’s tree includes Anonymous objrmap, aka anobjrmap, which extends the objrmap implementation for anonymous pages, which don’t have an associated mapping! how does it work, then? Some googling later, I found Hugh Dickins’s anobjrmap patches (scroll down to memory management). Putting it very roughly, anobjrmap tracks anonymous pages by a new struct, anonmm, which is attached to the mm, and serves as the page’s mapping.

While I’m in a kernel mood, two more things: Peter Braam, one of the intermezzo hackers, CC’d me on a mail to Chen Yang, asking him to integrate my intermezzo patch of last night and send it on to Linus. Neat! Also, I wonder if the folks at work or haifux would be interested in a series of lectures on the 2.5 VM. A prerequisite for such a lecture is writing at least one reasonably sized VM patch, though.

intermezzo-stack-lossage-2.5.73.diff is tonight’s work. This patch reduces intermezzo’s stack usage in three functions. The kernel has limited stack space for functions, and functions which use 4kb and even 1kb of stack space are unacceptable. Against 2.5.73.

I don’t really expect this patch to get in, as the intermezzo people seem to be ignoring 2.5 for the time being. However, wli said he’s interested in it, as his tree uses 4kb stacks, and maybe someone else will find it interesting as well? other than the grunginess of the intermezzo code, it was fun to write. I should write more kernel code.

It gives me great pleasure to announce that the esteemed, the one and only, the fabulous, ladypine, has joined us.

*wild applause*

I have an lj code, the kind you need to get a free account, which needs a new home. I thought Orna might want it, but she doesn’t. Email or leave a comment and it’s yours – first come, first served.

1. shared page tables support, based on Dave McCracken’s work. wli is planning to do it, question is, can I do it sooner?

2. remove the big kernel lock from trident.c.

3. continue ongoing work with “don’t let slab caches grow beyond a given size”, and sysfsication of slab caches.

More ideas welcome…

One patch to fix a memory leak on an error path in tpam_queues.c made it into the just release 2.5.73 kernel, via the ISDN maintainer. The same fix should also show up in the next 2.4-pre kernel, via the same route.

I sent another patch to Marcelo, the 2.4 maintainer, to fix a b0rked configuration dependency between CONFIG_SOUND_TRIDENT and CONFIG_INPUT_PCIGAME. No response yet, neither from him nor on linux-kernel, but no bk commit has happened since then, so the jury is still out.

Yesterday evening, I saw Orna tweaking her spam rules manually.
I opined that tweaking the rules by hand is rather inefficient,
and she opined right back that my setup is even less efficient.
My setup, in case you’re wondering, can be summed up as
“manually delete spam whenever it reaches my inbox”.

The reason I haven’t set up spam filtering so far is that I only
get a dozen or so spams every 24 hours. Since I read my email
compulsively (some would say obsessively), I rarely have more
than a few messages to deal with at a time, and so what if one
of them is a spam? I just delete it, just like I delete most of
the rest.

But yesterday I decided that enough is enough, and I’ll install a
bayesian spam filter. I googled for a bit, and settled on
bogofilter. apt-get install
bogofilter took care of downloading and installing, and then I set
out to read the man page and configure it. At first I was put off
by the fact that ESR wrote it (cf. the CML2 debacle), but then
I decided to give it a try anyway.

Bottom line: it works, once you train it. I use the following two
pieces of configuration that might prove useful, both of which are
adapted from the bogofilter man page:

In my .procmailrc:

# filter mail through bogofilter, tagging it as spam and
# updating the word lists

# Since I built the good list from all of my saved mail, and since
# bogofilter has a bug (which I will soon report to the approriate
# place) when called from procmail to update my very large good list,
# unlike the example in the bogofilter man page, I first run the
# incoming message through bogofilter, without registering its
# words. Then, if it's spam, the bad list gets updated.
:0fw
| /usr/bin/bogofilter -e -p

# file the mail to spam-bogofilter if it's spam, and update the bad
# list
:0
* ^X-Bogosity: Yes, tests=bogofilter
{
  :0 c
  | /usr/bin/bogofilter -s

  :0
  spam-bogofilter
}

And in my .muttrc, to ‘mark as spam and delete’ spam that makes it into my inbox:

# bogofilter integration, taken from the bogofilter man page
macro index \eD "unset wait_key\n\
bogofilter -s -l\n\
set wait_key\n\
" "delete message as spam"

A couple of other userful command lines:

# register every mail in the file mbox-name as spam
$ bogofilter -M -I mbox-name -s -v

# register every mail in the file mbox-name as good (ham)
$ bogofilter -M -I mbox-name -n -v

I used these two to build my good list and bad list quickly.