This changed however, with the advent of WebGL, the straw that broke the camels back. WebGL required efficient processing of byte arrays which herald the creation of the ArrayBuffer. Although designed for WebGL, the ArrayBuffer can be used anywhere in your javascript. WebGL is currently available for Firefox 4 and Chrome. The ArrayBuffer allows you to allocate a opaque chunk of memory. To manipulate the buffer, we have to “cast” or map the array to a Typed Array. There are various typed arrays such as Int16Array, Float32Array, but the one that interests us is probably Uint8Array, allowing us to view our ArrayBuffer as a byte array.

var buf = new ArrayBuffer(1024);
var bytes = new Uint8Array(buf);
for (var i = 0; i < bytes.length; i++) {
  bytes[i] = 0xFF;
}

The Typed Array may seem like a foreign concept in a dynamic-typed language such as javascript, but it’s neccesarry to provide good performance for binary handling. If you try to assign a Uint8Array element a number greater than 255, it will be truncated, and if you put a string, it’ll become 0, proving that this is more than just your average JS array.

Already there is talk of using these in HTML File API and Web Sockets API. WebSockets currently only support plain text UTF-8 frames, which means you can’t talk binary over the wire. Given that a lot of exisiting protocols are binary, this was a severely limitation. A web based proxy websockify that proxies native protocols into websocket frames needs the base64 each frame. Array Buffer support would allow us to do away the base64 overhead.

After digging in source and finding various shenanigans with the WebFLV_on variable, the answer revealed itself in the preference pages of MythWeb (Settings > MythWeb > Video Playback). There is a tick box to “Enable Video playback”. However, it says it requires ffmpeg with mp3 support.

I’m using gentoo so installing ffmpeg was just a matter of emerge -av ffmpeg. After installing, I can finally tick the “Enable Video Playback”. However arriving at the preference pages and tried playing on the flash player, a new stumbling block appeared. It says that the pl/stream/bla/bla.flv is not found. Navigating to it manually revealed a 500 Internal Server Error.

Since I’m using Lighttpd, I discovered that it has a deficiency logging CGI errors. The error.log was useless and I ended up running Lighttpd in non-daemon mode (/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf) and looked at the errors spat out on to the console. Turns out that it requires Math::Round which I haven’t installed.

The story is actually a bit more cumbersome as before everything I needed to enable CGI on lighttpd for perl to work and to get around a streaming path issue, I modified $stream_url in /includes/defines.php to not double slash on my root, but I know everyone just wants to see what I wanted to see when I embarked on this journey – a screenshot of it in action:

It’s by no means perfect with video being low quality, lack of seeking and some high CPU usage – but it works!

You can pick an obscure character and apply a don’t match character range with it ie [^`]+. This is not true match any character though. Or you can try [.\r\n]+ which doesn’t seem to work at all. (?:\r|\n|.)+ works fine, but as you’ll find out soon, it is notoriously slow as each time you use it, you are creating a new 3 way branching point because of the brackets.

The perfect way I’ve found is actually a nicer variation of the first idea:
[^]+
Which means ‘don’t match no characters’, a double negative that can re-read as ‘match any character’. Hacky, but works perfectly.

The setrlimit call can limit set cetain limitations on processes. One such limitation is NPROC, the number of processes that can have the same UID. Using setrlimit NPROC can enhance security by preventing unexpected forking, like when an attacker is trying spawn a new process. However, the server I am running on uses LXC, and avahi is installed on the host. In LXC, the containers themselves have isolation between one another, but the host sees all processes. The PIDs of container processes are remapped but their UIDs stay the same. Thus, you will get UID collisions where user 102 of container can refer to say ntp, while 102 of host can refer to avahi. Because the host sees and accounts for all processes, setrlimit on avahi (102) of say 3 processes will also count existing processes in containers with UID 102 (such as ntp) and thus breach the limit and unable to spawn.

The only way to solve this is to edit avahi.conf and set rlimit-nproc or just disable rlimits altogether using the --no-rlimits switch.

I guess as LXC and control groups becomes more common, developers will need to adjust their assumptions about users and processes.

So here’s the list so far, which I’ll update as I find more:

• Intel DP67BG (Confirmed, see comment by Michael)
• ASRock P67 (All of them, last time I checked – i.e. Pro, Fatal1ty) (Seems to be bogus according to Brian)
• ASRock H67M (And all variants)
• Foxconn H67S and variants
• Foxconn P67A
• ASUS P8H67-V and P8P67? (See below)
• BIOSTAR TP67XE and variants
• BIOSTAR TH67XE and variants

There’s a good chance that if one of the H67/P67 boards from the same manufacturer (i.e. ASRock and Foxconn) have VT-d, all variants have it too. You can check by searching VT-d in the product manual.

Update 6/02/2011 – Latest Asus P8P67 manual (E6307) shows the VT-d option under “System Agent Configuration”. Is this a new addition or something I missed before I’m not sure. Quick check of other Asus boards ie P8P67 EVO or P8H67-M indicates they don’t have it. Exception is P8H67-V which seemed to have it from the beginning. It seems there’s hope for those with Asus boards.

Update 24/03/2011 – None of the boards except for the Intel one seems to support VT-d even if they claim to. There are continuing claims that P67/H67 doesn’t support VT-d.

It’s been a bit of a mystery whether VT-d is a CPU technology or a chipset/motherboard technology, but it’s clear that, like VT-x, you need both to know about this technology to work. Since the advent of i7s, various people have asking the support for this technology only to find that the main blocker is getting the right motherboard. Some lucky folks have gotten it as far back as dying days of the Core 2 era. Most i5s and i7s CPUs claim support for VT-d, however motherboards of P55 and H55 that support this was few and far between. The only sure way to find out if your motherboard supports it is if you find the option “Enable I/O Virtualisation” in the Advanced Features section of your BIOS. The situation markedly improved when P57 and H57 came about with MSI and Asus boards displaying the option. MSI’s H57M-ED65 is one such board. If you look at the downloadable manual, you’ll find the reference. Gigabyte is noticeably quiet on the matter. Armed with this knowledge I went out assuming that newer boards will follow the trend. How wrong was I.

There are special Sandy Bridge CPUs in the form of 250K and 260K. The K CPUs have a higher clock for the graphics, but sacrifices VT-d technology. Fortunately this is widely understood and reported, unlike last generation when confusion between VT, VT-x and VT-d reigned. What they failed to clarify was that, VT-d is unavailable in pretty much all P67/H67 chipsets. This means nobody can actually use VT-d anyway regardless of whether the CPU supports it or not. In fact, I don’t even know why Intel bother listing VT-d as a feature when support is so poor. Currently, the only sandy bridge (LGA1155) motherboard in existence, that supports VT-d is Intel’s DP67BG. I of course didn’t buy that board and as I’m building a server, I required integrated graphics and P67 doesn’t offer that. Only H67 does. As far as I can tell no H67 motherboard currently in existence has VT-d.

Anyway, this is my rant of the night.

The code is compatible with ASP.NET MVC 1, 2 and 3. To use it for ASP.NET MVC 1, just set the conditional compiler directive ASPNETMVC1 and it will enable the MVC 1 code, otherwise it will work with MVC version 2 and 3.

The code is now up at github: DefaultDictionaryBinder.cs.

There’s also an example MVC3 project showing the basic functionality of the Dictionary Binder: link

Armed with strace, and attaching to the rouge process, the following spat out of the console again and again.

gettimeofday({1287484365, 501293}, NULL) = 0
lseek(8, 0, SEEK_END)                   = -1 ESPIPE (Illegal seek)
write(8, "Oct 19 19:39:57 login[439"..., 105) = -1 EAGAIN (Resource temporarily unavailable)

The key lines were lseek and write, both trying to write to file descriptor 8. To find out what fd 8 was, all I had to do was ls -al /proc/7411/fd/8 – The culprit was /dev/tty12. Now having looked into syslog-ng.conf, I was reminded of the fact that By default messages are logged to tty12.... So it seems, tty12 is somehow denying access to syslog. Being in LXC, I decided to check out tty12 by doing lxc-console -n container -t 12. To my surprise, syslog-ng was instantly unclogged as log messages were released into console. It looked as if the tty12 buffer was clogged up.

Regardless of the reason, the easy fix is to stop syslog-ng logging to tty12 as I’m never going look at that far away console. Commenting the console_all lines, all was fixed. This would probably never have happened if I had used metalog :/

After fiddling around with the options, I finally found the culprit. The option inside the VNC viewer “Emulate 3-buttons (with 2-button click)” seems to be the cause. Turning it off seems to make my mouse clicks reliable. No idea why though.

function getVersion(callback) {
        var xmlhttp = new XMLHttpRequest();
        xmlhttp.open('GET', 'manifest.json');
        xmlhttp.onload = function (e) {
            var manifest = JSON.parse(xmlhttp.responseText);
            callback(manifest.version);
        }
        xmlhttp.send(null);
}

// to use
var version;
getVersion(function (ver) { version = ver; });
// version is populated after an indeterminate amount of time

As XMLHttpRequest is asynchronous, our method needs a callback to receive the version information. You can also get whatever other information you want in your mainfest.json. So there you go.