The latter is slightly neater and more compact than the former, but I will always retain fond memories of Vera.

As a sort of quick test for Linode performance, I decided to run ab against the new server from my desktop here at home. I fire it up for the first run: 100 requests, 10 connections. It performs well. Next I jump to the next order of magnitude: 1000 requests, 100 connections. It times out.

In doing so it also kills off the SSH sessions I have logged into the Linode server.

After some experimentation, it becomes clear that the magic number of connections is 32. If I have 32 or more connections through ab, the connection locks up.

I opened a ticket with Linode and began trying to nut it out. I checked the iptables settings, the nginx settings, various kernel TCP/IP settings. All to no avail.

Today I tried out the 1000/100 test from another server I control and voila, it works fine. So it turns out that the limit on connections wasn’t at Linode’s end, it was at my ISP (iinet). They must have introduced this recently as I recall performing similar “sanity test” benchmarks on remote servers before.

Anyhow. The moral of the story is: I shouldn’t have thought unkind thoughts about Linode. It wasn’t their fault. However I offer as a suggestion that in future cases like these, they run ab from their side to eliminate ISP middlemen problems.

For instance, it uses the formidable OGRE for rendering.

There are two things (so far!) that bug me about NeoAxis.

The first thing is the documentation. It is pathetically incomplete. It is extremely annoying to be looking stuff up in the help file (only supplied in the useless CHM format), only to find a blank page. And even when you do find something more substantial, it’s apparently translated from Russian (really, I’m not kidding) and has a lovely Engrish feel to it. Naturally this is unhelpful.

The second, much smaller gripe, is the coding style. Ostensibly NeoAxis games are meant to be written in C#. However the sourcecode that we are basing our project on is riddled with C/C++ idioms. The most obvious of these is the if(!someFunction()) error_handler(); idiom, which is scattered liberally throughout the code. I guess try/catch was a bridge too far for most of the code.

So. Forget my last entry.

LuaSQL is a perfect example. This little library provides a very think DBI-style layer to talk to various databases. But it’s not available as a LuaRock.

Instead it is necessary to install it by hand. It’s packaged as a tarball, which isn’t so bad. But there’s no configure script, so some changes must be made by hand before it will compile.

For ubuntu, the locations of the libraries are different from whatever platform the original LuaSQL code is written on. Also, you will get two gcc errors when you go to ‘make’; the first is a PIC error, which is easily fixed by adding -fPIC to the command line switches. The second is a little more subtle.

Lua is written in ANSI C, according to all the literature. This seems to actually mean C99. LuaSQL uses the gcc switch -ansi, which actually defaults to C90, not C99. You need to replace the -ansi switch with -std=c99 for LuaSQL to compile properly.

--===============2045766128707237696==
Content-type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"


Obviously problematic, as many email programs would then render HTML mails as plain text. Hilarity ensues.

Well first off, there’s a tiny bug in the cat2email code. It should put out ‘Content-Type’, not ‘Content-type’. Fix this and you get a different set of incorrect headers:

Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


Hmm, still useless.

The culprit, it turns out, is Wordpress. In 2.1 and 2.2, the wp_mail function was modified to use the PHPMailer class. If you crack open wp-includes/pluggable.php, you’ll see that the wp_mail function always forces conversion to plaintext. Pretty dodgy.

What it ought to do is check for custom headers and work with them. I’ve submitted a patch to the Wordpress mob, and if you really need it, see below.


--- /Users/jacques/Downloads/wordpress/wp-includes/pluggable.php
+++ pluggable.php
@@ -187,7 +187,15 @@
$phpmailer->AddAddress("$to", "");
$phpmailer->Subject = $subject;
$phpmailer->Body = $message;
- $phpmailer->IsHTML(false);
+ if ( strstr( $headers, 'Content-Type: text/html' ) )
+ {
+ $phpmailer->IsHTML(true);
+ }
+ else
+ {
+ $phpmailer->IsHTML(false);
+ }
$phpmailer->IsMail(); // set mailer to use php mail()

do_action_ref_array(‘phpmailer_init’, array(&$phpmailer));

Update: Looks like a more robust fix is scheduled for Wordpress 2.3.

Putting aside my complete failure to properly RTFA on the Mailman-Postfix hookup, I found an interesting problem with the default install of Mailman: if you modify permissions to allow Apache to reach the relevant cgi-bin directories, parts of Mailman stop working. Modify it back using the included check_perms script and Apache stops working.

The solution is to add the Apache user (www-data) to the Mailman group (list). Then everything works.

bash: ./configure: /bin/sh: bad interpreter: Permission denied

Which has nothing whatever to do with the root cause. The actual problem is that pecl downloads files to /tmp and does its work there. If /tmp is mounted as noexec, pecl will fail with errors like the one above.

Solution #1: Change the fstab for /tmp, removing the noexec option.
Solution #2: Working in another directory – such as /usr/src – manually perform the steps pecl automates. An example for xdebug is found here.

Wondering why it’s acting funny? Cursor moving too fast or too slow? Cast an unfriendly glare at your cat, who even now may be snoozing nearby in a state of offensive cuteness. A single strand of her fur has stuck to the mouse eye and the stupid laser beam is confused.

You need to enter cean:install(compiler). in the BEAM shell before you can load and execute .erl files.