So is BT Templeton, the person who has been hacking away at Guile-Emacs GSoC after GSoC. :-)
(They seem very skilled, don't be fooled by the fact that it's GSoC; no idea what the skill level of people who take part in that usually tends to be.)
The use of the vulnerability to repair the vulnerability is very cool. I've done some related work, which may be of interest when one wants to patch a bad binary on the router (instead of simply removing a bad binary as done in this article).
http://eschulte.github.io/netgear-repair/pub/netgear-repair....
I walk through a similar process here [1], using binwalk to extract the source-code from a firmware image, then running the insecure router software in a QEMU VM. Although the purpose in the linked instructions is to repair a different Netgear exploit from October 2013 by modifying the insecure binary executable (see [2] for information on the technique).
A major limiting factor is that OCaml has no support for parallelism, and due to it's use of a global interpreter lock for GC it can't run multiple threads.
That said it's great to program in (like Haskell with convenient IO and semicolons) and it compiles to blazing fast executables.
This is by choice, because single thread performance matters more, and you can use fork or MPI to scale across NUMA nodes and clusters much more scalably and safely.
Having used fork/join to parallelize an OCaml genetic algorithm, I can say from experience it is neither safe nor practical.
Edit: Intentionally only supporting single-threaded processes is a perfectly fine design decision, however I haven't seen this argument made for OCaml, rather I've seen "multi-threading our GC would be hard" as the justification for the single-thread limitation. Admittedly it was 3-4 years ago when I last had to deal with this.
There are now several experimental multithreaded OCaml runtimes floating around, which also have the key property of not slowing down the single-threaded case. I don't expect multicore to remain a limitation for OCaml in 2014.
