Originally sung by Chiba Saeko (and as always, composed by Kajiura), this performance by Yuriko Kaida et al. is an excellent cover of the original.

One of my New Year's resolutions is to post on here a bit more frequently. I guess we'll see how that one turns out.

Here's a sample featuring two of my favourite vocalists, Kubota Keiko and Oda Kaori:

(Original & translated lyrics)

I was a bit hesitant to embed a Flash video on this website; my dislike of Flash and plugins in general nearly stopped me, but the sheer awesomeness of the content forced me to do it. Waiting (im)patiently for HTML5 video to take off…

…Did I know, she asked, that Brisbane was originally founded as a penal colony for convicts who committed new offences after they had arrived in Australia?

I spent a good half hour enjoying this single piece of information. It was wonderful. There we British sat, poor grey sodden creatures, huddling under our grey northern sky that seeped like a rancid dish cloth, busy sending those we wished to punish most severely to sit in bright sunlight on the coast of the Tasman Sea at the southern tip of the Great Barrier Reef and maybe do some surfing too. No wonder the Australians have a particular kind of smile that they reserve exclusively for use on the British.

(Posting on this blog for the first time in 11 months, alert the media!)

Voidwars is a free-to-play space combat strategy game that can be played with only your web browser. A game of Voidwars takes place in real time and generally lasts a month or so. You just need to log in a few times per day, check on your empire issue your orders etc.

It's a far cry from the basic featured game that it once was. It's been slowly evolving to a really rather cool game. Changes to the way research works mean you no longer have to wake up at some silly hour to set the next research going; the tech tree UI lets you define precisely what your scientists should do to advance your technology.

Another nice new feature is the ability to speed up construction of buildings and ships by spending money. This can help you to develop newly acquired planets into useful outposts much faster.

Endless tweaking, balancing and revamps of the combat system have made for some very strategic space battles. A collection of different weapon and armour types, along with different classes of ship hulls means that there is no one winning strategy for building your fleet. But of course focussing on building just one type of ship will leave you vulnerable to someone who notices this. A balanced fleet is often best.

I'm no expert though, as I've yet to actually win a game…

If you've played Voidwars before, now might be the time to give it another go. And if you haven't, well… what are you waiting for?

There's a trial game available (it resets once every week) to get a feel for what the game is like before you commit to a full game.

As stated in the linked post, it is not an Opera desktop build, but Wingogi/Lingogi, the Windows and Linux versions of the reference builds that we use internally for testing Opera's platform-independent core. It will be at least some time before you see a normal Opera desktop build that achieves this pass level.

Note also that this is still not a complete pass, as "the animation must be smooth". Top men are working on this. Top men.

Along with Safari's recent similar announcement, this impressive progress by both parties is great news for web browser interoperability.

Congratulations to the core developers, QA, and everyone else who's been working hard on this.

No publicly available build passes yet (so for now you'll just have to take our word for it), and there are still some layout issues to correct*, but Opera plans to a release technical preview version of a working build on labs.opera.com within the next week or so.

Webkit is close behind on 99/100 currently; they may well succeed in releasing a passing public build very shortly too.

* Remember that 100/100 does not mean that the browser passes the test fully, the other two requirements are that the animation has to be smooth and the final page has to look exactly, pixel for pixel, like the reference rendering.

Last night I received an automated e-mail from my web server's control panel warning me that memory usage had been at 80% for the past 30 minutes. Somewhat worrying, so I looked at where the memory was going. The vast majority seemed to be going to Apache threads, and there seemed to be many more threads there than usual. Not really having time to look into it in-depth, and knowing that the server had been running for a long time, I restarted Apache and left it till tomorrow.

Next day, things are still working fine, and I go in to work. Checking IRC when I get in, I find not one but two messages quoting me the following message from #whatwg on Freenode:

[22:02] <Philip`> The error message on http://www.xiven.com/weblog/search/results?q=%00 seems quite peculiar

The error message in question was an out-of-memory error from PHP in my XML parsing script. The connection with the odd memory events of last night was made...

At first I thought it was just a case of a problem with null characters (%00 is the URL-encoded hex code for null, and nulls can often be problematic). But %00 (or U+0000) was not the only thing that would cause this crash: other characters included %ef%bf%bf (U+FFFF) and %ef%bf%be (U+FFFE), and invalid UTF-8 byte sequences were also causing problems. Additionally, ASCII control characters such as %01 (U+0001) to %08 (U+0008) etc, although not causing the out-of-memory error, would make the XML generated by the website be not well-formed, giving the infamous "Yellow Screen of Death" on Gecko browsers.

The following PHP code was somewhat hastily added to the main script for the website:

Hopefully that covers everything (checked various docs online as to what characters in XML should be excluded). I haven't had the chance yet to look more in-depth as to why PHP was consuming all memory and apparently crashing Apache threads on certain characters; whether the exact cause is in my code or in PHP's XML parser itself, I'm not sure yet. But for now at least, sanitizing the UTF-8 characters of all input variables should keep things relatively safe. I have little doubt though that there must be a better way…