If this is some sort of database muckup, I hope they don’t revert it to yesterday or something, I just finished enrolling for 2010S1!

In particular I was looking for the gcc extension or flag to reduce the number of bytes used by an enum with only a small number of values __attribute__((packed)) did the trick!

I have started a project, along with a few other computer science students here at UNSW, to use social networking and bayesian filtering techniques to try and win the competition, and donate the prize money to charity. We have a website, windarpa.com, where people will be able to submit the locations of balloons they find, along with a vote for which of our short-list of charities they would prefer to see the money go to. Check it out, and tell your friends!

How can I not keep coming back for another year if it means in 365 days they’ll be giving me another one for free!

Yesterday Hung, Jayen & I started work on UNSW’s code base for the 2010 Robocup competition, and ended up with something quite neat that we didn’t have before. The Nao runs a piece of software from Aldebaran called ‘NaoQi’, which provides an abstraction layer over the Robot’s hardware, and also some sort of inter-process communication for each of the ‘brokers’ you are running. rUNSWift has previously had just one broker, which internally manages the communication between each of its modules. This has the benefit that it is very fast, when compared to using ALMemory, however it means that whenever we want to upload new code to the robot, we have to completely restart NaoQi to reload the librunswift.so shared-object library.

The new approach involves having two ‘brokers’: ‘loader’ and ’soccer’. The loader is loaded by the the NaoQi automatic loader on startup, using the same method that librunswift.so used to be loaded. The loader has methods called startSoccer() and stopSoccer(), which will load and unload libsoccer.so on demand. The loader can be communicated with over the network, and we hope to integrate this with our off-robot debugging utilities. With any luck this should greatly cut down on wait time between builds of the various rUNSWift modules.

We still have the performance advantage of having all the core components (vision, behaviour, localisation, locomotion, etc.) inside the ’soccer’ broker, avoiding ALMemory for everything except when we reload code through the loader.


#include <iostream>
#include <functional>
#include <vector>
using namespace std;
int main() {
vector<int> v;
vector<int>::iterator it;
v.push_back(3);
v.push_back(4);
for (it = v.begin(); it != v.end(); ++it) {
cout << *it << endl;
}
transform(v.begin(), v.end(), v.begin(), bind1st(plus<int>(), 3));
for (it = v.begin(); it != v.end(); ++it) {
cout << *it << endl;
}
return 0;
}

Also WordPress doesn’t like newlines or tabs in <code> </code> blocks? Lame!

Jeff Arnold, creator of Ksplice, presented a talk this year at linux.conf.au, the annual Australasian Linux conference, about his product, the first practical technology for updating the Linux kernel without rebooting.

Jeff Arnold wrote most of Ksplice as part of his Master’s thesis, and upon its completion, started Ksplice, Inc. with a few classmates.

The Wikipedia article on uptime makes the statement about system administration: “Long uptime can indicate negligence, because critical updates can sometimes require reboots.” Ksplice endeavours to change this perception by making it possible for server administrators to apply important security patches immediately and without causing any downtime.

At the time of writing, we could not find a comparable technology.  We found some references to Solaris having hotpatch support, and we assume IBM’s System z has this functionality due to the nature of their zero-downtime availability.

One can use Ksplice at any time, without interfering with any running services, connections, or applications.  The catch is that Ksplice is really intended only for small security patches to the kernel, and not for even minor upgrades.

Ksplice applies patches to a running Kernel by loading new versions of entire functions into memory, and replacing the existing function code with a jump to the new one. This way, from a caller’s point of view, nothing has changed.

Most Linux Kernel security patches can be applied by Ksplice without doing any extra work. In the case where the semantics of a persistent data structure has changed, a programmer will need to write a few additional lines of code to tell Ksplice how the previous data structure can be transformed into the new one at runtime.

The performance impact of applying a Ksplice update is minimal. A small amount of memory will be expended to store the replacement code, and calls to the replaced functions will take a few cycles longer because of the inserted jump instructions.

Of course, with great power comes great responsibility.  Ksplice makes it easier to change a running kernel, but that opens up all kinds of avenues to hackers, allowing them to easily mess with the core part of your system (only if they gain root access, of course).

Ksplice is currently available for download from their website, or as a package in debian, and Ksplice, Inc. sell support for business.  There is currently work in progress for an up2date-type utility, which will make rebootless kernel updates as easy as distribution updates.

David Claridge & Jayen Ashar

So it’s the last sleep before LCA, and there are now 7 of us UNSW CSE students coming along (that I know of). Boarding passes all printed and ready to go. It should be fun, watch this space for updates! See you in Hobart.

so true!