Branimir's Blog Archive

Did PowerPoint kill Columbia?

In his classic book Visual Explanations Edward R. Tufte shows how bad presentation of information had catastrophic consequence in making decision to launch the Space Shuttle Challenger on January 28, 1986.

In his recent essay The Cognitive Style of PowerPoint (excellent read by the way, it is well worth the $7, buy a copy to everyone in your school or company who is PowerPoint-addict) Tufte analyzes the key slide in the Boeing report on Space Shuttle Columbia. The reports provided the rationale for NASA officials to curtail further research (such as photographing the Columbia with spy cameras) on the tiles during the flight.

Did PowerPoint kill Columbia? Find out for yourself on Tufte's web site: ET on Columbia Evidence—Analysis of Key Slide, also: Report of Columbia Accident Investigation Board: The Boeing PowerPoint Slide.

Posted by Branimir Dolicki at 12:38

# - G - Add comment

SPAM Filters That Fight Back!

I've been using SpamAssassin for some time now and I'm really pleased - the amount of spam I have to deal with manually has reduced to maybe 5% of the original. Especially interesting is filtering with Bayesian Classifier. Bayesian Classifier (explained at Paul Graham's Web site) learns from the past messages that you marked as spam or nonspam.

Now, I find the last idea from Paul Graham Filters That Fight Back really cool. I mean, no matter how well my filters work they can't really do anything to prevent spam. Spam exists because there is (and I guess will always be) a tiny little fraction of people that actually read and respond to spam. No kidding. Such people really exist. They don't filter spam. So what can the vast majoriy of people who don't read spam and don't want spam actively do against spam? Paul Graham's idea is: have a program that will automatically follow every URL in the spam. If many did that, spammers' costs would grow linearly with amount of spam they send.

Long time ago I heard someone say that we should always call the 800 numbers advertised in the spam: call the number and go to lunch break. That way we would cost spammers money. The problem with that is that this process is hard (even impossible in some cases) to automate. The crawling idea can easily be automated.

Posted by Branimir Dolicki at 11:51

# - G - Add comment

Fax spammer

This morning I've got a fax spam. Apparently fax spamming is explicitly forbidden in Germany so I really want to kick those guys' asses. Fortunatelly there is this cool site: www.spammer-hammer.de which exists for exactly that purpose.

SpammerHammer offers, among other things, a long template warning letter for fax-callback operators written in beautiful German legal language.

This particular spammer is already known to SpammerHammer and there are already people taking steps against him. I'm going to join them (I'm so excited! ;-).

The funniest part of this story is the telephone message that you hear when you call the listed number (which is there for the purpose of "unsubscribing"). It mentons the full address of the spammer! The mp3 of the message is here. The only problem is that the address is in Hungary and the address is in Hungarian. That is not a problem for SpammerHammer folks:

"Közleményszolgáltato es Kereskedelmi Korláltolt Feleössegü Társaság" ist der schier unausprechliche Name des großen Unbekannten, kurz Köz-Szol-Ker Kft., der angeblich in Karinthy F, út 4-6, 1111Budapest, Ungarn, residieren soll.

Posted by Branimir Dolicki at 11:28

# - G - Add comment

Installed OpenACS for branimir.com

Branimir.com now runs OpenACS! I've installed version 4.6.3. It wasn't as smooth as I hoped but hey - it's working. It uses Apache as reverse proxy for virtual hosting and SSL and Postgres.

BTW, I'm really impressed how db_source_sql_file works only thanks to the fact that db_get_pgbin is broken :-)

Here's what db_source_sql_file tries to do:

set fp [open "|[file join [db_get_pgbin] psql] $pghost $pgport $pguser -f $file_name [db_get_database] $pgpass" "r"]

Now, this works correctly only because db_get_pgbin always returns empty string so that psql from the PATH gets executed. Here's what db_get_pgbin does:

    set pool [lindex [nsv_get db_available_pools .] 0]
    set driver [ns_config ns/db/pool/$pool Driver]    
    return [ns_config ns/db/driver/$driver pgbin]

What this seems to be trying to do is find psql binary in a place like /usr/local/aolserver/bin. Fortunately the section name is misspelled in the last line (driver instead of drivers) so the proc returns empty string.

Posted by Branimir Dolicki at 04:51

# - G - Add comment