OK, after I did the manual updating as was explained in the last post, I was unable to run my applet. The Java Console throws java.lang.ExceptionInInitializerError error. I did not know what went wrong.
After googling, I arrived at the following information.
#
Run sudo update-java-alternatives -l to see the current configuration and possibilities.
#
Run sudo update-java-alternatives -s XXXX to set the XXX java version as default. For Sun Java 6 this would be sudo update-java-alternatives -s java-6-sun
#
Run java -version to ensure that the correct version is being called.
I ran the command, and the following was the result on my console:
java-6.19-sun 60 /usr/lib/jvm/java-6.19-sun
java-6-sun 63 /usr/lib/jvm/java-6-sun
java-gcj 1042 /usr/lib/jvm/java-gcj
java -version shows:
Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
Java HotSpot(TM) Server VM (build 16.2-b04, mixed mode)

So, my manual installation works. But why does running applets throw the above error? So I decided to revert to java-6-sun. And the exception does not show again. What went wrong?

I recently had to update my JRE to the latest 6 update 19 to replicate a security warning dialog. I found the tutorial here. I will copy it here just in case something happens to that blog and this info that I surely will need again later disappears (Og, God forbids!)

Start by downloading the JDK for your architecture from SUN. Take the .bin file, extract it by running it as a shell script:

sh jdk-6u19-linux-i586.bin

This will create a new folder called /jdk1.6.0_19. Rename this to java-6-sun-1.6.0.19 (just to remain consistent with how Debian/Ubuntu refers to JDK's) and move this folder to /usr/lib/jvm:

sudo mv jdk1.6.0_19 java-6-sun-1.6.0.19
sudo mv jdk1.6.0_19/ /usr/lib/jvm

Officially you are suppose to use the update-java-alternatives command when using a Debian distro, but frankly I find it easier to do this manually. We need to update the /usr/lib/jvm/.java-6-sun.jinfo, so type:

sudo gedit .java-6-sun.jinfo

This will open up a hidden configuration file. The first line likely shows:

name=java-6-sun-1.6.0.06
...

Simply change this to point to the new version:

name=java-6-sun-1.6.0.10
...

Also, update the java 6 symlink to point to the one we just installed:

sudo rm /usr/lib/jvm/java-6-sun
sudo ln -s /usr/lib/jvm/java-6-sun-1.6.0.10/ /usr/lib/jvm/java-6-sun

If anything goes wrong after the above steps are taken, proceed to the following. But only if anything screws up. (Taken from here).

• Open a Terminal window
• Run sudo update-java-alternatives -l to see the current configuration and possibilities.
• Run sudo update-java-alternatives -s XXXX to set the XXX java version as default. For Sun Java 6 this would be sudo update-java-alternatives -s java-6-sun
• Run java -version to ensure that the correct version is being called.

• Open a Terminal window
• Run sudo update-alternatives --config java
• Follow the onscreen prompt

Session functions, including session_start() should come first in an PHP page. It can not be preceded by any other thing, not HTML tags, not even a new line!

Recently I moved my wordpress blog to a new domain. Many links broke. Styles were not applied. After googling, I stumbled upon this wisdom.

To update WordPress options with the new blog location, use the following SQL command:
UPDATE wp_options SET option_value = replace(option_value, 'http://www.old-domain.com', 'http://www.new-domain.com') WHERE option_name = 'home' OR option_name = 'siteurl';
After that you will need to fix URLs of the WordPress posts and pages, which translated from post slug, and stored in database wp_posts table as guid field. The URL values in this field are stored as absolute URLs instead of relative URLs, so it needs to be changed with the following SQL query:
UPDATE wp_posts SET guid = replace(guid, 'http://www.old-domain.com','http://www.new-domain.com');
If you have linked internally within blog posts or pages with absolute URLs, these links will point to wrong locations after you move the blog location. Use the following SQL commands to fix all internal links to own blog in all WordPress posts and pages:
UPDATE wp_posts SET post_content = replace(post_content, 'http://www.old-domain.com', 'http://www.new-domain.com');
Browse through WordPress blog to check if everything is okay. You also need to re-login to WP Administration as authentication cookie has now became invalid due to different domain.