Virus based batteries?

A breakthrough at MIT allowed a team of researchers to create virus based batteries, the main idea behind this is having tiny cells, which in turn would allow to have very small sized batteries that could be use to power really small electronic gadgets and maybe after a more study even electric cars. Even though there is not a finished prototype yet, things seem to be going just fine and two of the three most important components have been successfully put together, the full announcement is here.

Mozilla Ubiquity

This is really hot stuff, take a look at the video below:

Ubiquity for Firefox from Aza Raskin on Vimeo.

Computer virus made it to space!!!

Wow this is quite weird, it seems some of the personal astronaut laptops have been infected by a virus, according to NASA this is not the first time, I don't know what OS is in use by the ISS computers, both I'm sure is some UNIX derivative so we can be sure that the virus can't spread across its systems, but a virus may cause DoS if they don't actually pay ata good attention to what they're doing, anyway, to me is not a good idea to take a virus prone OS into space, you may read the full article at BBC News.

2006 SQ372

Well it seems that the first Oort cloud object has been found, this is great news!!!, you may read more about it in sciencenews.
For the ones who don't know what the Oort cloud is.... well there is this belief that outside the boundaries of our beloved solar system there is a spherical cloud filled with comets, it is believed that this could is the origin of all long-period comets, such as the Halley and many others, you can learn a lot more about this in wikipedia.

Having multiple X-VR2 installation instances

For concurrent development reason I need to come up with a way to have two different X-VR2 (with different versions an ABIs) installations, there is no problem in having different shared libraries but for the headers there is a problem, since all headers start from the xvr2/ directory how can I have multiple instances installed?
Well one way would be to invoke configure and install everything under different prefixes, which is nice, I could have both libraries and build different applications in the same machine which is way good, easy and painless.
The other way would be to do what the GTK+ guys did when they released Gtk+2 and that was to append the number 2 to headers prefix directory as well as in the library naming, that allowed them to have both versions installed for development while keeping all headers and libraries installed within FHS compatible directories.
Don't know which of those two I'll follow, but for sure I'll be using option #1 for now, time will tell if I should follow option #2.

On GUI tookits and thread safety (a few thoughs)

Current GUI toolkits (for most mainstream operating systems) are not natively thread safe, in fact, widget redrawing and event processing are most commonly performed from inside a global loop.
So what happens when you have a series of stuff to do in disparate threads and need such threads to update GUI elements? if the GUI does not provide a method then you normally start doing all kinds things, lets see a few of them:

Global Variable Madness: this is the worst of them all, it consists in having a set of globally shared variables (or objects) each one with a lock so from your thread you do something like:

object.lock();
object = somedata;
object.unlock();

Then in your GUI callback method....

object.lock();
someGUILabel.setText(object);
object.unlock();

Ok lets see... this method performs an object update instantly (as soon as it can acquire the object lock of course), however having global vars is not something you might want, but then, what happens when you update widget contents too frequently?

Invoke methods (ala Windows Forms): for each GUI object you have an invoke method, which basically tell the GUI engine to update the widget with the value sent during the invoke, notice that this method performs differed widget updates, so the contents are not instantly updated. This one is good for ultra frequent widget updates.

Separating GUI drawing from event processing: this is a good one, but only meaningful if you are the toolkit author, this is the best way to write a GUI toolkit this days, why? because of the multi-core thing!!! By having both things in different threads it is implied that you're taking in count multi-threaded processing so there is not case here, everything should be done already.

There are not too many choices ha? well its up to you choose the best of them and if you know a few more please share them.

The blog that never started in the right place

For some reasons I have some xvr2 post scattered in other blogs out there, I'll be adding them back here soon.