While sitting on a bench in Hyde Park, watching the leaves fall from the trees, thinking that fall is just around the corner, I started to write on the back of an old receipt. One that says 108,- for a Banana Passion Split and a bottle of Coca Cola. It’s just something I do when I’m nervous, excited, lonely, happy or all of the above. Sometimes I spend so long thinking about how to express myself, that I forget what I was going to write. I spend too long trying to find the right adjectives. And I wish I could find the right words to describe some of the best moments. My trip to London was more than just Big Ben, The London Eye, Madame Tussauds and Oxford Street. A lot more. Another receipt says 590,- for a haircut. It’s from July 15th, 2008. My ramblings on the back, blue ink, some words crossed out, some misspelled; at least 1 of the 268 Underground stations has a staircase with 78 steps, a shop on Oxford Street sells salt from the Dead Sea, and some very big soap bubbles were seen in Camden Town. There are some keywords at the bottom of the second receipt. Just to remember all the other things that happened. Like the time we almost got lost on the Underground, the elevator with no buttons, the Kanye West sunglasses in white and pink, and the lack of a proper breakfast - even though I don’t mind white bread and strawberry jam. There was just one small thing I wasn’t too happy about; you can’t write on receipts from Tesco. They have THANK YOU FOR SHOPPING WITH US printed all over it. And it took me a while to find that piece of paper in my bag. This time I saw fall in London, and a white pigeon. I will make sure I have my notebook with me next time.

I finally got around to releasing eweouz 0.2 tonight. It is still a bridge between emacs and Evolution Data Server, now with both gnus and wanderlust support. Changes include:

• Actually works now, sans stupid typo
• A bit more documentation
• Now handles non-ASCII names, thanks to setlocale.
• Be a bit more paranoid and fail if opening addressbooks and such fails.

eweouz now also has a mailing list and a git and gitweb repositories.

I bumped into this while reading various things: http://beebole.com/blog/2008/09/02/web-application-on-erlang/ And was interested, because it fits nicely with a half-formed idea of my own: Erlang is never going to be a nice language for doing HTML templates, but getting JSON into and out of it is pretty easy, so it could potentially work very well where your application is divided between Javascript for all the template/rendering/frontend duties, and Erlang on the server, with something like Mnesia, Couchdb or Postgres as the data store. That sort of application wasn't really possible several years ago, but with the right target audience, you could probably get away with doing an app that requires Javascript to function these days.

Everybody is talking about that these days, since information on Google Chrome leaked. But the fact is, this is what is going to happen with Google Chrome: stupid people proving that 2 + 2 = 5. I haven’t tried IE8 nor am I willing to, but one of the rare things I read about IE8 when people were discussing how not innovative Google Chrome was, is that it uses a process per tab. Now let’s assume IE binary code + libraries fit in 10MB (which is probably a small estimate), and you open 10 tabs. Here you are : 100MB RAM consumed. OH MY GOD! Except that memory is shared between the processes. That’s 100MB virtual memory. Reality is that you’ll have a hard time calculating the actual amount of memory used. Update: It has already started.

Last week I started my personal RC bug quest, to get the RC bug counter down and Lenny released some time this year. Sadly, a release in September 2008 is not possible anymore.

Since last week I've been mostly with other stuff, like coming back home after DebConf8 and catching up on some real life issues... So I wasn't very productive and only downgraded 496967 and verified that 484045 can really be closed by now. But at least it brought the counter down a bit :-)

Last week we were at 428 open RC bugs, today it's "only" 383. If we keep this speed, Lenny will be released in 15 weeks. So I certainly hope for some removals to happen soon..! ;-)

Using the alternative BTS view, I see 359 RC bugs effecting lenny, or 339 if I exclude contrib and non-free. So "only" 13 weeks...

While writing this blog post I thought that rc-alert should be able to list only bugs, which effect a specific distro and much to my joy, rc-alert from devscripts in lenny and sid has a "-d" option :-)

When Graham Bell invented the telephone in 1876, he probably didn t expect the rise of the cellphones we ve been seeing over the last 20 years. At first, there were C-net phone too huge to carry, but mobile still, as they communicated wireless. Then, devices became smaller, networks faster and ubiquitous, and today, the number of cellphones sold worldwide has exceeded the population. Much like everything else, it used to be better back then . When phone calls were still ridiculously expensive, people were able to enjoy their peace and life progressed slow for everyone to think enough, not do or say without engaging their brains. Then, when the first cellphones stuffed people s pockets, they did their job pretty much from the start: you could make phone calls. Some genius discovered SMS as a splendid tool to rip off customers, so phones grew pager abilities, but other than that, they just worked; I remember my first phone, which didn t break in years. Obviously, if you re a phone manufacturer, you don t like that, because once you sell a phone that works, the customer won t come back to give more monies in ten years. Clever as you are, you devised two schemes to ensure your cash flow: make phones more brittle and crap, so that they break within a year, at most two; and drag ever younger people into the debt trap. For the truly stupid, sites and services offer ring tones and games and what not, and the lesser challenged you keep close by the continuous addition of new features that noone needs. So these days, almost every phone can play music files, which is mighty convenient to spice up your work commute with some tunes, but our youngsters are overburdened by that, it seems. I almost soiled myself laughing at a group of five Italians at Ezeiza Airport in Buenos Aires, who were sitting around waiting for a bus, every one of them ear plugged and grooving to the beats (you know how dorky it looks when people silently sing along rap songs?). That s not the funny part. The funny part is that every minute, one of them would say something, which would cause the others to unplug one ear, and form their lips to bleat what (making sure to add just a little bit extra of the tone of general disinterest, which is cool ). This elicited one of two responses: either the original speaker would say oh, nothing and everyone nodded, or he d repeat his wisdom, causing everyone to laugh and nod before in both cases they replugged and returned to luff themselves. I wonder how they made it to the airport themselves, and why they travel as a group. Worse than that, however, is that cellphone manufacturers remembered that their phones had speakers (for fancy ringtones) and consequently added the ability to blast tunes through them. As a result, groups of kiddies walk around or sit in trains, with one (or more) of those cellphones blaring into the environment. Apart from being generally inconsiderate, what I don t understand is how they put up with the sound quality. It s mostly hip-hop music you know that genre that makes some homies out there install 5000 watt subwoofers into their cars so make sure the windows rattle with the base but these phones have a frequency spectrum comparable in width to that of your grandfather s, way further up the scale (meaning they just don t do base). Playing hip-hop through those is like putting a flute concerto on a subwoofer, just worse, because high-pitch tones are harder to filter by those who don t want to hear them. And yet, I see it all over the place, kiddies listening to music through cellphone speakers. Is it because silence would kill them? NP: 65daysofstatic: The Fall of Math

Back from Argentina, back from DebConf. As always, the ~3 weeks I spent there were really great, in as many fronts as I can imagine or describe. But I won't go into that now - For the purposes of this posting, the single thing that I got out of DebConf was looking with envy at all the people that had something that used to be called a sub-notebook some time ago, and now morphed into the more modern(?) name netbook.
Several people were seen with their tiny Asus Eee machines, of various models. And I definitively decided I want one - I was quite close to buying one in Argentina, as they are readily for sale there (surprisingly, in Mexico Asus sells motherboards, but no netbooks)... But I've always prefered waiting or paying a little premium for having an on-country seller and warranty.

Back home, Pooka told me that several stores in Mexico do sell the Acer Aspire One. After a little research, I decided to go for it. Office Depot sells the AAO for MX$4500 (around US$450). The only model they carry comes with Windows XP installed (instead of Linpus Linux), which is a shame I thoroughly repeated to the vendor - But it does come with 1GB RAM and 120GB HDD, much better for my needs than the other model, with 512MB RAM and 8GB SSD. This is, after all, a full (although very small) machine. It has an Intel Atom 270 CPU - I haven't yet measured how it fares, but it feels quite responsive so far for typical desktop tasks.
But what made me really happy about it is the Debian support. The only tricky part was to get the installer going, as it does not have a CD drive to boot from (and I didn't want to completely overwrite my only available USB stick's data). Don't try installing Debian Etch, as its kernel will not support the built-in Realtek RTL8101E network card (maybe etch-and-a-half's kernel does?). My greatest ally in this was, of course, the wiki.debian.org article on the Acer One - I rebooted with Lenny's debian-installer, and everything was smooth from that point on. Propietary firmware is required for the wireless AR5007 card and webcam, but -exactly as documented in the wiki- they are covered respectively by madwifi and linux-uvc.
I did a very regular install, with basically the default desktop and notebook setup. I continue to be amazed... Everything just works! It is not even fun, there are no funny drivers to recompile, no bang-your-head-against-the-wall... Even suspend-to-RAM. It just works.
The only glitch I found so far is that, after suspend-to-RAM, the madwifi module must be removed and reloaded to have wireless network. This is a well-known glitch that can be easily worked around. But besides that, it is... as easy as it gets. And, at such a price, and under 1Kg weight... This computer will get used to go out with me quite often! Battery life is just 2 hours, but for most situations, it's more than enough.

gksu-polkit gets pipe support One of the features I really wanted to get into gksu-policykit early was working correctly with pipes. With the current gksu you cannot do something such as echo blah gksu tr a-z A-Z. It is actually very hard to work correctly with input/output with su and sudo bellow. I do think it also has something to do with me not being too clever in UNIX file descriptors at the time I originally planned how gksu works. I did get an email from someone at Sun offering to write support for that who never mailed me again, but anyway… gksu-policykit is currently able to get all the input and output forwarded to/from the process by using an interface similar to glib’s g_spawn_async_with_pipes. Here’s what we are able to do already:

$ echo test string   ./gksu/gksu-polkit /usr/bin/tr a-z A-Z
TEST STRING
$

It’s impressive to me that all the input and output goes over DBus quite nicely.

First of all, I don't want to blame individual persons. This is just a note of how disappointed I'm about some parts of Debian that are not complying to licenses when it comes to distributing software. debian-cd embedds copy of syslinux without source A couple of years ago, I took over the maintenance of the syslinux package since its previous maintainer was MIA. The takeover was motivated by to the fact, that having started to take care about live systems, I also started to use syslinux on a daily basis and that the syslinux package in Debian was horribly outdated. At that time, I found out that debian-cd, the toolkit to build the official Debian Installer images, doesn't take syslinux out of the archive at build-time of the image, but rather embedds a copy of the required binaries inside the package itself. So I asked Steve to update the binary what he did. Before the etch release, I needed to ask the debian-cd team to sync again their embedded syslinux copy to match the one I had uploaded to the archive, as it was again outdated. On the other hand, live-helper, the toolkit to build the official Debian Live images, was always using the package out of the archive and did never had that problem. After we have released the Debian Lenny Live Beta 1 images last week, we got reports from people trying them on Apple MacBooks and failed because syslinux, taken out of the archive (version 3.71), is broken on that hardware. Some people stated that Debian Installer images do work. That is because debian-cd has an embedded copy of syslinux (version 3.63) which doesn't have that regressions. Since syslinux version 3.71 is present in testing/lenny as well as unstable/sid, and stable/etch has version 3.31, that means... if debian-cd is embedding a syslinux binary with a different version, it must contain the sources for it (it also needs to contain the sources for it anyway, even if it would embedd binaries of the current version, however, it would be a tiny bit less arguable if its sources would be at least present in the Debian archive). So I checked debian-cd, and surprise, it doesn't contain syslinux sources. Syslinux is licensed under the GNU General Public License, version 2 or later. That means, that if you distribute the binaries and sources together, you can remove both at the same time if you decide to no longer distribute the binary (that is what Debian uses to do). This let me to bug #497270. The option to distribute the binary with a note on how to get the sources, valid for three years, could theoretically be done, but isn't used so far (since it has pretty bad practical implications of keeping sources arround even after having stopped to distribute the binaries). Debian sarge release has incomplete source images Checking fo the consequences for embedding bootloader binaries in debian-cd, I just saw that the Debian sarge release does ship syslinux version 2.04 in its images, but is shipping syslinux 2.11 in its source images. This is another violation of the GPL and I've filled this as bug #497471. ...and syslinux is just one bootloader, only used for i386 and amd64. Someone still needs to check for all the other bootloaders for the other architectures we support (and those also for the etch release). cdimage.debian.org distributes images without sources While browsing arround on cdimage.debian.org, I also found the kde4beta livecds made by the Debian KDE team back in November 2007. Although these images are nice, there is no source available for them at all. They use packages that are not available anymore in Debian since a long time. This time, this doesn't only violate the GPL as in the previous two cases, but almost any copyleft license under which we distribute software in main and that is included on these images. I've filled this as bug #497462. Again, this is not about blaming individual persons. But I'm pretty disappointed by these things. In Debian, we spend a big chunk of time checking licenses of packages before we start distributing them. We have our beloved NEW queue where, after the Debian Developer who has initial uploaded a package and has checked the sources, also ftp-masters are re-checking each and every package to ensure that our archive is kept legal. The NEW queue is a mesurement that consumes a big deal of our time, making uploading packages new packages slow, but this is the prize we pay for ensuring our freedom. And we do also make a big fuss about cluebating upstreams that don't respect licenses (be it intentionally or by accident). However, it appears that as good as our package checks are, we spend little to no time to check our resulting products made from these packages. Update: kde4beta livecds have been removed now from cdimage.debian.org, see #497462. Update 2: debimg does the same crap.

A few weeks ago we released version 2.2.0, and now version 2.2.1 of DOMjudge, our programming contest jury system. I'm actually very satisfied with the 2.2 branch because it implements some important wishes that users of the system had, especially moving nearly all state into the one central database instead of spread over db, files and hosts. It is getting more and more complete on the functionality side. Our next target, 3.0, will focus on a different part: installing the system and getting it running is not quite trivial. The system has grown organically, and the current setup procedure tries to install everything at once, from building the judging environment, setting up the web interface to generating the documentation. We aim to pull that apart so it gets easier and the administrator keeps better oversight. But that's all for the next contest season. Meanwhile, the 2.2.x branch will be maintained for bugfixes at least until ultimo 2008.

The current method of patching into place a series of ./configure variables as $(DEB_HOST_GNU_TYPE).cache files is becoming a pain - it blocks native builds of Emdebian packages for a start. So, I've been experimenting with a different method of support.
Centralised cache value support
Initially, I've collated all the current cache values needed (i.e. beyond the ones already provided for specific architectures) into /etc/dpkg-cross/cross-config.cache and have a script in emdebian-tools called emcache that will manage the central values by comparing them to the real values used in each build tree.
So, cache values, what are they?

1. Cross-builds fail if ./configure tries to compile a test program and then try to execute it because it will have been compiled with the cross-compiler - instead, the cross-build passes the value that the test was trying to calculate so that ./configure does not need to try to execute any cross-compiled code.


2. The values are derived from native builds, written to a $(DEB_HOST_GNU_TYPE).cache file that is passed to ./configure via debian/rules.


3. The values turn out to be mostly (completely?) architecture-independent, so are eminently suitable for collation into a central cache file.


4. Quite package-specific. There is some overlap but most are customised for a specific package. This led to a development of the central cache file: package-maintained cache files to support extensibility.

Package maintained cache files
I'm now experimenting with cache files written (and maintained) by packages during normal builds and dropped into /etc/dpkg-cross/cross-config.d/ - which would later migrate into dpkg support. Ideas welcome!
The basic idea will be that IF cross-building, the build process would check for /etc/dpkg[-cross]/cross-config.d/$source_package and, if found, add that to the cache value list for that build.
Cache files are shell scripts so this it be manageable to bring some intelligence to the process.
Where does MIPS come in?
Well, all the builds, so far, have been ARM or armel (where the cache values are likely to be identical) and i386 (which doesn't need a cross-compiler at all and therefore does not need cache files). MIPS is the first chance to check the cache values and ensure that the above criteria really are true.
Now that we have a volunteer looking at MIPS, the current MIPS builds are a suitable test bed.
What does this have to do with Debian?
Once Lenny is released, I'll be looking to implement this support via the long term mass bug filing for cross-build support into the packages themselves. It is possible that the process can be entirely automated - as long as the script knows which values are relevant. A normal cache file, post-build, can be very, very long whereas most cache files for Emdebian are just a few lines long - the longest is about 20 lines.
The current process is outlined on the Emdebian website, including a list of packages that currently need cache files to cross-build.
Oh, and just a note - when I start this phase of the long term mass bug filing, I'll first do delayed NMUs for the existing bug reports - hence the delay until Lenny is released.
In order to speed things along, I have also been doing some RC bugs - downgrading some, fixing others etc. (I've finished 6 since coming back from DebConf, so far, IIRC.) All efforts to get Lenny released will help Emdebian too, so if you want to help Emdebian, then help Lenny get out of the door and let's get to work on Squeeze.

(Squeeze is a great name for a release with lots of fixes for embedded stuff, don't you think?)

Three replies to things I saw today on Planet Debian on blogs of people that don’t have fully-working web comment systems:-

1. Professional Slide Installer (usual buggy blogger.com CAPTCHA) - yes, they exist. My village’s council sometimes hires them. I think they’re carpenters who have specialised. There are also professional slide inspectors (well, childrens’ play area safety inspectors, but professional slide inspector sounds cooler).
2. Internet Speed Hype (usual buggy wordpress kind-a captcha) - ThePhone.Coop (UK) doesn’t cap, but charges extra if you go over your subscription amount. We have a monitoring system that lets you check your usage fairly easily and set up email alerts when your prepaid amount is almost used up. (I work for agent AG_471 of ThePhone.Coop but I think I’d like them anyway.)
3. home of the madduck/ blog/ Recovering a lost default route (site under construction - see bottom of page) - I was told by a very wise man to always start a delayed reboot (shutdown -r +5) before messing with anything to do with the networking on a remote machine.

Among other things, my webmaster cooperative is an agent for the Phone Co-op. Particularly with Free Software, cost-efficient ways of downloading data is a good companion service to have and the Phone Co-op has given a good ADSL and calls service to my own home and office for a few years now. When there are problems, they’ve worked pretty well to fix them. Just last week, I had a phone call to tell me when routing problems in LINX were fixed… which was a great help. I don’t remember an ISP doing that for me for years. I think the last one was my university’s dial-up service, 10 or more years ago. Another unusual thing for a UK ISP is the excellent public position on the Phorm ad-snooper that I mentioned previously: We strongly oppose these practices, especially the loss of privacy [...] Phorm is not operating on our users’ lines and we have required and received assurances from our suppliers that this will remain the case. Our Chief Executive Vivian Woodell gave an interview to the FT (accept the first two cookies, then block the rest, else you only get two paragraphs) which has a pretty good explanation of how the business side of the cooperative works. We’re recruiting for Line Rental (PSTN and ISDN) until the end of the year, including special offers like residential Unlimited Anytime Calls for 7.95 a month (normally 9.99) at the moment, as well as the great climate-neutral and ethical policies - if your landline contract renewal comes up, give it a look. The Phone Co-op was ten years old in June, but there are still big challenges: I’d love to see a cooperative pay-as-you-go mobile phone service and the mobile contract offers still look a bit expensive to me (no bundled data on phones, 25 per month for a 3G data card). I’d also love to see support for some daring innovative solutions like customers owning their own tails (tails are the last link to their house, where most of the UK has a choice of one provider: BT), using that as a way to upgrade small towns and villages to fibre-optic, or offer resident-owned wifi. Update: As if by magic, Ofcom has started a social web consultation about mobile phone services. Go comment.

Yesterday a server at work needed some care - which was the reason why I had to leave the m68k porters meeting early. It was intented to migrate the filesystem to a RAID1 setup instead of using just a single disk.

Of course I tested everything in advance and it worked. Sadly Murphy did hit the scene as well and the previously tested upgrade path failed: somehow the RAID couldn't be started and the boot progress stopped.

Actually, the error was this one:

Failure: failed to load Module 1 no such module

Useless to say that the initrd was uptodate and included all necessary modules!

Luckily someone else happened to stumble upon the same problem last year and it was well documented on debian-user mailing list in a thread between Andrew Sackville-West and Martin F. Krafft , properly archieved by some mirrors.

So, the problem was in some mdadm script that was executed during boot process and which parsed the ARRAY definition in that way that the kernel modules couldn't get loaded.
If you follow the thread on that mailing list you'll come to the following hint:

Try the following patch agaist
/usr/share/initramfs-tools/hooks/mdadm. It ensures that RAID levels
include the word 'raid'. I think your mdadm.conf may say stuff like
level=5, when it should say level=raid5 or not specify level= at
all.

And yes, my ARRAY definition in mdadm.conf just stated level=1 as well. So after setting it to level=raid1 everything worked again.

Thanks, Andrew and Martin for solving that problem a year ago! :-)

Jacob is starting to learn about the world around him a little bit. He seems to have four categories of people: men, women, children, and babies. He can say "man" and "baby" pretty clearly. Earlier today, I heard Terah telling Jacob "Dad is a man. Mom is a woman."

Maybe an hour later, I walked into the kitchen. Jacob and Terah were there. Terah proudly asked Jacob, "What is dad?"

Without missing a beat, Jacob said "Fun!"

He must have seen me smile, because a second later, he added "Happy!"

Can't argue with that.

The 500000th bug day is coming. Some of you may remember the contest I launched last year for people to bet on the day bug #500000 would be reported. The bug rate in Debian is about 1000 bugs in 6 days from my survey. So, as we're now at about #497300, bug #500000 should happen in 14 days. It seems that Kartik Mistry is about to win the contest. Indeed, he will if the bug is reported between Sept. 11th and Sept. 17th which probability is very high. Folks, prepare to send cheers to India! Unless the bug rate increases a lot and Miguel "xerakko" Gea wins. Miguel, I watch you: no MBF for you! I definitely lost when Aug. 22nd came. I was betting on a small rate increase which indeed did not happen. You can start now computing the #600000 bug day. There *will* be a contest for it...unless I launch one for bug #1000000...:-)

Michael Janke is writing a series of posts about estimating availability of systems, here is a link to the introduction [1]. He covers lots of things that people often miss (such as cooling). If you aren’t about to implement a system for reliability then it’s an interesting read. If you are about to implement a system where reliability is required and you have control of the system (not paying someone else to run it and hope for the best) then it’s an essential read. It will probably also be good to give this URL to managers who make decisions about such things. Interesting summary of the connections between the Iraq war and the oil industry in the Reid Report [2]. The suggestion made by one of the sources she cites is that the intention of the war was to reduce the supply of Iraqi oil to increase prices. Sam Varghese has written an essay about this which summarises where the Iraqi oil goes [3]. It seems that half of Iraq’s oil goes to US military use, the other half is used domestically, and some oil is imported as well! So because of the US occupation the country with the second largest known oil reserves is importing petroleum products! If the US military was to cease operations world-wide then the oil price would drop significantly, this doesn’t just mean the occupation of Iraq and the various actions in South America, but also the bases in Germany and Japan. Interesting paper by Alexander Sotirov and Mark Dowd about Bypassing Browser Memory Protection in Windows [4]. This paper is good for people who are interested in computer security but don’t generally use Windows (such as me), if you want to learn about the latest things happening in Windows land then this is a good place to start. A well researched article by Rick Moen about the unintended effects of anti-gay-marriage laws [5]. Maybe some of the “conservatives” who advocate such laws should get themselves and their spouses tested. It would be amusing if someone like Rush Limbaugh turned out to be involved in a “gay marriage”. What Sysadmins should know about exposure to hazardous materials [6]. High-level overview of the issues, probably a good start for some google searches to get the details. Diamond John McCain is an interesting blog about the 73 year old (who was born in Panama) candidate in the US presidential election [7]. Update: Corrected my statement about Iraq’s oil reserves based on a comment by Sam.

• [1] http://lastinfirstout.blogspot.com/2008/07/estimating-availability-of-simple_04.html


• [2] http://blog.reidreport.com/2008/08/war-for-iraqi-oil.html


• [3] http://gnubies.com/comment/oil.html


• [4] http://taossa.com/archive/bh08sotirovdowd.pdf


• [5] http://linuxmafia.com/faq/Essays/marriage.html


• [6] http://blogs.techrepublic.com.com/networking/?p=637


• [7] http://diamondjohnmccain.blogspot.com/

Share This

One of my favorite things to watch are the “making of [movie, documentary etc] segments that are now routinely included in any DVD. It is nice to look behind the curtain and see exactly what choices are made, what is excluded, and why they are made. I wish that more books, especially academic ones, had a “making of” section, giving a window into these choices. We are not exactly encouraged to include this commentary in the book itself but one can find this type of insight in author interview. I recently read one such interview with the author of Two Bits: The Cultural Significance of Free Software. The interview is on his site and the original is here. There are a couple of things that I found particularly interesting, such as how to treat iconic figures such as RMS and ESR [not as researchers, for example ] and the importance of letting your research and thinking brew over a fairly long period of time, despite the pressure of publishing fast, quick and dirty, which is especially strong with anything “digital.” The book is hefty and long, but as is emphasized in the interview, it is also pragmatic and readable. If folks on Planet have not yet checked it out and are not ready to commit to a long book, I would checkout Chapter 6 on the creation of the copyleft. It is sure to please academics and geeks alike.

When volume becomes high enough you start to observe patterns in SPAM pretty easily. I think that this is primarily because people like to see patterns, whether they are present or not. The trick is determining whether they are real patterns or not, and then to a lesser extent whether they are useful patterns. For example I host mail for a business domain. That means that incoming messages come primarily from existing customers, and very rarely from potential new ones. In practise that means that email is expected to arrive from 9am til 6pm (+/-2hours) Email received at 2AM? Either it is somebody working remotely, a foreign contact, or much more likely it is SPAM. Now clearly you cannot dump all messages received at unusual times of the day, but it is a surprisingly robust SPAM indicator for that particular domain. All heuristics are fallable, but some are useful regardless.. I'd love to know what people can learn from their SPAM. This week I'm handling approximately 80,000 messages a day, per MX, which isn't huge (ie. 2-3 million a month). ObQuote: Highlander