| Months | ||
|---|---|---|
| Jan | Feb | Mar |
| Apr | May | Jun |
| Jul | Aug | Sep |
| Oct | Nov | Dec |
Mon, 29 Sep 2003
It was refreshing to read through the developer guide for Judy. Occasionally there's an example of terrible engineering humour I'm sure people are already familiar with:
"Judy IV turned out to be enormous and time-consuming... Obtaining a ~2x improvement in speed and space required ~5x lines of code and ~10x complexity, but we only lost 3-4 engineers to malnutrition during the implementation phase."
"Real programs don't eat cache."
Apart from the lame jokes, Judy looks like a very interesting piece of software. It has a clean and simple API that seems to defy the complexity that lies under the hood. Inserting nodes into the tree causes Judy to create different species of sub-nodes whose format adapts to the type of data being inserted. The authors claim large memory and speed benefits over traditional data structures (arrays, sparse arrays, hash tables, B-trees, binary trees, linear lists, skiplists) for almost any type of data. Bonus marks given for mentioning Recursive Make Considered Harmful.
It's nice to see people within HP doing some real engineering rather than reselling Microsoft kit and announcing .NET related joint ventures. The developer's guide is called a "Shop Manual" which is pretty cute. posted at: 12:16 | path: /computers/programming | permanent link to this entry
Fri, 26 Sep 2003
Idea for a bandwidth efficient MTA
Postfix is great. We use some of the niftier UCE extensions on samba.org to reduce our spam and virus load. Originally we had a body_checks rule that rejected all messages containing a particular string in the message body that corresponded to the header of a .EXE file. A more advanced rule can be written with Postfix 2 using the mime_header_checks table to block all attachments of a particular type.
# Handle dodgy attachment types. For the latest virus DISCARD
# them but perhaps this should be changed to REJECT later on.
/^\s*Content-(Disposition|Type).*name\s*=\s*"?
(.+\.(lnk|asd|hlp|ocx|reg|bat|c[ho]m|cmd|exe|dll|vxd|pif|
scr|hta|jse?|sh[mbs]|vb[esx]|ws[fh]|xl))"?\s*$/ DISCARD
(Remove linebreaks to make the above appear on just one line)
Postfix 2 also allows the administrator to DISCARD a message matching a table check rather than REJECT which produces a bounce message. Generating a bounce, while the correct thing to do according to the RFC, is pointless and counterproductive when the From header is known to be incorrect. Using the above entry as a MIME header check allowed samba.org to weather the last couple of Microsoft viruses/worms/malware (Blaster, SoBig) and as a bonus, is relatively future-proof as other viruses relying on email to propagate are automatically blocked. For example the expression did not need to be updated for the Sven worm. Other people have come up with similar configurations for Exim and other mailers.
However the whole idea of server side filtering is based on the idea that bandwidth is essentially free. In Postfix expressions in the header_checks table can be done with only the overhead of a SMTP HELO and transfer of SMTP headers. The body_checks and mime_header_checks require the DATA portion of the SMTP protocol exchange to be completed, or at least started. In some countries bandwidth is anything but free and customers pay by the byte.
Why isn't teergrubing integrated into MTA software? The idea isn't particularly new. A host initiating a SMTP exchange is throttled down to an arbitrarily slow speed which has the effect of saving bandwidth for the receiver. No RFCs are harmed during this process, and resources are expended on the sender's system. Unfortunately the reverse is also true - the receiving system also has to consume system resources to keep track of the connection.
I propose an extension to an MTA that incorporates teergrubing on an IP based level. A baysean filter or a table of regular expressions could be used to match against message headers or bodies. Once a particular IP address sends a spam or virus mail they get (say) a ten second penalty. For further offences the speed and latency of the connection can be adjusted. The receipt of legitimate mail can act in a positive way so as not to penalise one-off offences. posted at: 13:48 | path: /internet/spam | permanent link to this entry
Wed, 24 Sep 2003
One of the more interesting Slashdot trolling pastimes is the impersonation of famous personalities. The idea is to masquerade as someone related to the parent story and go trolling.
Today's slashdot imposter is Seth Finklestein. Witness this example of the art. posted at: 11:51 | path: /internet/slashdot | permanent link to this entry
Fri, 19 Sep 2003
posted at: 13:49 | path: /computers/microsoft | permanent link to this entry
Thu, 18 Sep 2003
The Net Interprets Verisign As Damage...
and routes around it, to paraphrase John Gilmore.
- How to configure named to counter sitefinder
- ISC patches BIND (warning: contains obnoxious popups)
- slashdot
I don't think sitefinder is going to last very long. posted at: 09:04 | path: /internet | permanent link to this entry
Wed, 17 Sep 2003
This was an amazing little space opera type game from my childhood that is chockers full of jokes, great old-skool tracker mods and very engaging game play. My brothers and I used to play it for days at a time and start the traditional fights over whose turn it was to use the computer next.
The original authors released the source code for the 3DO version as open source and it has been taken up and ported to the PC (it was originally only available on PC as a DOS program). Go get it here. Joey Hess has packaged it for Debian so now it's a simple matter of going apt-get install uqm rather than having to download random bits of SDL from CVS to get it to work by hand. There is also a win32 installer for Linux-impaired systems.
"What is this game called frungy? How is it played? Who's ahead in the frungy championships?" posted at: 15:28 | path: /computers/games | permanent link to this entry
FP!
Hello to random other web logging poseurs on the internet.
posted at: 15:28 | path: | permanent link to this entry