My Dad's computer has broken down today. He could not start it up! The WinXP always reboots during the start up process. Sometimes it reboots before the log on screen. At other times it reboots right after he enters the password. Seems like it's been infected by a virus!

I told him I will install the latest Ubuntu 11 for him tomorrow. I plan to install it over the old Red Hat partition. This way, he may still retrieve the documents on WinXP drives.

My toy project is getting close to the phase 1 completion! Lately I'm been trying hard to simplify the rules. My goal for this project is evolving. Now I'm morphing this complicated and realistic simulation into a fun game. Rules implementation, sound effects and animation are all done. It seems working well. The next step is to create an AI opponent. It should not be difficult. I know what to do, I just need the time to do it.

Then I will need to refine the maps and scenarios. First objective is the Taiwan Strait. Afterwords, the bloody battles between Hitler and Stalin in World War II.

I love virtual box! In a matter of just a few days, I've had Fedora, Ubuntu, Open Suse, Mandriva, Free BSD and Mac OS X installed on every one of my machines! Yes, even Mac OS. And I'm running out of space fast on these virtual disks.

Here's how I increase the size of the virtual disk for my Fedora on virtual box, from 8G to 40G.

0, Make a copy of your old VDI, just in case.
1, Create a new VDI with a bigger size, 40G.
2, Download Fedora live CD image. Alternatively, you may get a GParted Live CD image, if your virtual disk is not in LVM (Logical Volume Manager) format.
3, Create a new virtual machine on virtual box. I called mine "resize-vm". Attach the Fedora live CD, your old and new VDIs to it.
4, Boot your new virtual machine "resize-vm".
5, Open a terminal, become root by "su", then copy the old disk to new disk by "dd if=/dev/sda of=/dev/sdb".
6, Shut down "resize-vm".
7, Edit the original "Fedora" virtual machine, remove the old VDI, attach the new VDI. Boot "Fedora".
8, Go to Fedora menu "Applications/System Tools/Disk Utility", create a physical volume from the unallocated space, I named it "extra". Note down the device name, which is "/dev/sda3" in my case.
9, Open a terminal, become root by "su", then run "pvcreate /dev/sda3". This way, we created a new physical volume.
10, Run "vgdisplay", find out the name of the volume group, "VolGroup".
11, Run "vgextend VolGroup /dev/sda3" to add the newly create physical volume.
12, Run "vgdisplay" again, you will see "Free PE / Size" has been increased, in my case, it's now "8191 / 32.00 GB".
13, Run "df -kh", locate your old logical volume name, which is "/dev/mapper/VolGroup-lv_root".
14, Run "lvextend -L32G /dev/mapper/VolGroup-lv_root".
15, Shut down "Fedora". Boot "resize-vm", become root by "su".
16, Run "e2fsck -f /dev/mapper/VolGroup-lv_root".
17, Run "resize2fs /dev/mapper/VolGroup-lv_root".
18, Shut down "resize-vm". Boot "Fedora" with the new enlarged VDI.
19, Done!! Delete the old backup VDI if you want to save some disk space on your host machine.

I've successfully compiled a simple SWT program using GCJ on MingW. I'm glad it works, but I still feel a bit unsure about GCJ. First, there's not much activities in the past few years. Some of the documentation on the GCJ and GNU Classpath web sites seem to be out-of-date. The mailing lists are quiet. I guess there are not many people interested in compiling Java into machine code. Who can blame them, It's not easy to use GCJ. I myself have to refresh my skills on GCC tool chain first.

Also maybe the demand is just not there. From what I know, the modern Just in Time virtual machines have quite good performance already. The dynamic compiling they do at run time can provide extra optimization than the traditional static compiling. But the performance on JIT virtual machines are not consistent. They are usually very slow at the beginning, then gradually improves when more and more byte code are compiled into native code. So for a real-time program, native compiled code is still more suitable. The problem is, how many people use Java in a real time programming project? Most of the time, Java is used in back end enterprise applications. In these kinds of enterprise environments, performance issues are solved by architecture (adding more hardware). Remember, some of the J2EE vendors are also selling hardware.

I've been researching ways to improve the performance of my Java programs. One technology is called ahead-of-time compiling, which is to compile Java source code directly to native machine code. The GCJ, the GNU Compiler for the Java is such a tool.

All my Java programs are GUI code using SWING. Unfortunately, GCJ doesn't support SWING/AWT yet. But SWT works with GCJ. And there is a library called SWINGWT, which is SWING implemented on SWT. So here's a potential easy way to convert my Java programs to small and fast native code. There are quite a few other benefits as well, such as, hard to reverse-engineering, easy to deploy, no need for end users to pre-install Java run time.