I did achieve a measure of success with my plumbing efforts and just when I thought it was over, my Nokia e51 fell into the water tank. It was soaking in the tank for a couple of minutes before I managed to fish it out.

Soaking the phone in a water tank is not the same as getting caught in the rain or dropping it into a puddle. In a puddle the water will not penetrate deep inside the phone for a few minutes. The trapped air inside will see to that. In a water tank there is pressure. If the captive air does not escape, it will be compressed (remember PV = nRT ) and the water will penetrate easily.

After fishing it out, I didn't expect to be able to make any calls using that phone. The white LED was burning fiercely but the LCD was off. It didn't respond to the power button so I switched itoff by pulling out the battery. Didn't put the battery back in without using an electric blower on it for a few minutes to attempt to try it out.

Only the back cover cannot be opened. The front face plate on the E series phones cannot be removed without a special tool, which I don't have. Putting the battery back in resulted in the white LED lighting up even before the power button was pressed. The LED turned white but didn't get any further.

I put the phone in my camera dry cabinet and finished up the plumbing matter, and then took the phone to the nearest Nokia dealer. They don't have the tool for it either. YOu need to drive into their repair shop at Bambalapitia and the timing was such that the place would be closed by the time I got there. The next day is a sunday.

So what I did was to keep the phone in the camera cabinet through saturday night and the whole of Sunday. On monday morning when I tried to switch it back on the phone actually did boot up. But you can still clearly see water behind the LCD.

So I used the blower on it and put it back in the dry cabinet. By evening the phone was back to normal. My investment in the camera cabinet has been recovered.

Previous versions have also been plagued by the gcj and /etc/alternatives mess. The standard way to configure /etc/alternatives to use the Sun JVM is to say

But that croaks out with:

Sure you can now install java with synaptic. But why should I? I have countless versions of the Sun JVM and JDK lying around on my hard drives. So what I did was to copy over the old /usr/java folder from Fedora Core 6. This folder contains serveral different versions of java and looks something like this:

lrwxrwxrwx 1 root root   12 2008-07-18 11:24 1.3 -> jdk1.3.1_18/
lrwxrwxrwx 1 root root   11 2008-07-18 11:24 1.4 -> j2sdk1.4.2/
lrwxrwxrwx 1 root root   12 2008-07-18 11:24 1.5 -> jdk1.5.0_06/
lrwxrwxrwx 1 root root   12 2008-07-18 11:24 1.6 -> jdk1.6.0_02/
lrwxrwxrwx 1 root root   12 2008-07-18 11:24 default -> jdk1.5.0_06/
drwxr-xr-x 8 root root 4096 2006-05-04 16:51 j2sdk1.4.2
drwxrwxr-x 9 root root 4096 2006-03-10 07:00 jdk1.3.1_18
drwxr-xr-x 9 root root 4096 2006-05-04 16:51 jdk1.5.0_06
drwxr-xr-x 9 root root 4096 2007-06-15 06:33 jdk1.6.0_02

As you can see, each of the major version numbers are represented by symlinks that point to the current (well in some cases not so current) release for that branch.

Next the symbolic links in /etc/alternatives/ were deleted and fresh links were created to the /usr/java/1.6 folder above. If I update my 1.6 branch, all I have to do is to change the symlink from jdk1.6.0_02 to whatever the current version is.

If I want to use java 7, I just download it and expand it into the /usr/java folder. Then a symlink name 1.7 is created to point to the exact release and then the link in /etc/alternatives is updated. In fact I am going to do all that right now (with java 7)

When I booted up The volume control icon at the top was a red x and when clicked on it told me that I had no GStreamer plugins installed or they were mis configured. After little bit of googling I found that adding myself to the audio group is the fix

That was too easy but debian had a suprise up it's sleeve. On mythtv there is no sound at all. It's dead silent and the mythfrontend output shows:

2008-07-02 12:38:11.269 Opening ALSA audio device 'default'.
ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave

To fix this I ran alsa conf. Now I can hear what the idiots on the idiot box are saying but it's jerky. That's a separate mythtv issue that I don't have the energy to look into right now.

First up I was looking to install the latest versions of Thunderbird and Firefox and was rather dismayed to find that debian archives only had really really ancient versions on them. I was looking around in third party repositories when I realised that Iceweasel look pretty much like firefox. It turned out to be a case of a rose by another name. (Romeo and Juliet is the only bit of Shakespeare that I can claim to be even vaguely familiar with)

Iceweasel is Firefox and Icedove is thunderbird. The Debian flavors had been given different names apparently because of a copyright dispute with the mozzilla foundation.

Like the web browser, the web server also caused a bit of trouble. Apache 2 wouldn't start.

This error was because the installer had put together apache2 running in MPM mode along with PHP 4. They are not compatible so why wasn't PHP 5 installed? (apache 2 is compatible with PHP, but apache 2 in MPM mode isn't)

After uninstalling PHP4 and installing PHP 5 this particular problem went away. But the webserver still refused to start because it didn't recognize my url rewriting instructions or mod security directives. Never figured out how to enable mod security but mod rewrite can be enabled as:

That doesn't take me out of the woods just yet. None of the sites are functioning, they are all returning 403 forbidden errors. Initially I thought this is because the owner is UID 500 (yours truley on the old fedora core). On this debian box my uid is 1002 (why not 1000? That's another long story)

Anyway, i changed ownership and then changed the group to www-data (they seem to keep changing the group and username. I remeber the days when it used to be nobody:nobody)

Thankfully both my browser and web server seem to be working ok now.

I am not complaining about the quality of the products. They are very good. I am complaining about their creating so much of garbage by packing each item individually. I used stuff from both IK Com and APM they are both the same. Why can't they ship then in packs of 6 or 10? why use so my polythene?

Patch cables are also packaged individually. So I didn't by all the patch cables that I needed. Some of them I made on my own. Unfortunately it didn't do much good. I wasted about a dozen RJ 45 jacks because of lack of practice in wiring it. All I had to show for it was a sore thumb from trying to push the cable into the jack.

Having decided on Suse, I tried to download and install it by using the 'network installation method'. It allows you to start the installation by downloading just the core components. Packages are downloaded only if you really need them. Thus the initial download is only 71MB, but it seemed like it would take forever to complete with the mirror I was directed to being very slow.

Then I discovered that Debian had the same installation method (which is called the Tiny CD). That downloaded really quickly and I was armed with a boot CD in minutes.

The installation turned out to be painless. No messing about with X server configurations. In the old days most newbies were turned off linux all together because it was well nigh impossible to configure X. Things have changed.

By the time that Red Hat Linux 7 was out, I was a full time Red Hat user. By the time Fedora 10 is out, I will not be using their distros any longer. Though upgrading from Fedora 8 to Fedora 9 on my media server wasn't too bad, upgrading my Fedora Core 6 to Fedora 9 was a nightmare. It's not the first time that I have had trouble with fedora upgrades either.

I had already tried to do a live update using yum. It starts of an infinite loop of never ending dependencies and makes no attempt whatsoever to do the actual installation. So tried the DVD upgrade. The trouble is that the fedora installer does not recognize my IDE hard drives at all.

There were various suggestsion in many blogs, in the end I came up with a suggestion that libata.dma=1 should be passed as a boot time parameter. That did cause the hard drive to be reconized (by this time, I had rebooted at least 20 times).

The installer went forward a few steps and complained about some partitions not being labeled. I had labeled what I thought were important ones but not the others. I didn't know that swap had to be labeled (what's the logic behind that?)

When the fedora installer fails, there is no recovery mechanism you have to reboot. I rebooted into rescue mode and did the labeling. The installer progressed a bit further now and complained about one of the files on the DVD having an incorrect checksum.

That was the last straw. The DVD was downloaded using Jigdo. The mirror that I was redirected to was appalingly slow and it took more than 2days to download the files needed. Less than 50% of the files in fact had to be downloaded, because I had used the 64bit DVD as the base (the 64 and 32 bit versions have more than 1000 files in common)

I know that using Jigdo means tI don't have to download the whole DVD again, i can just download the offending file but damned if I will bother.

The desktop is an old Pentium 4 2Ghz that still runs Fedora Core 6 which redface had long since marked as obsolete. I decided to update that to Fedora 9 as was but was loath to download the DVD iso again (the ISO i had downloaded is the 64 bit version, this machine obviously needs the 32 bit version)

The next best thing seems to be to try to do a live update with yum; In order to do that, you have to change all the repositories in yum.repos.d to version reflect the desired version number (9) and then run yum update. I tried to make life easier for the installer by creating a local repository out of the 64 bit DVD (it contains more than a 1000 files which are either ,noarch or .i386)

Having the local repository didn't do much good. The update process seemed to take forever just to sort out the package dependencies. I initially tried yum update and soon gave up on it. Then I tried yum update yum. That seemed like it would take just as long.

Even with an update that should have very few dependencies it gets stuck. That's because many apps are linked against either expat (xml libraries), python, ssl or glibc. Updating one of them would mean countless RPMs have to be updated and if one rpm has expat as a dependency, another one of it's dependencies is sure to have glibc so it starts an avalanche. ll this without downloading a single RPM.

After this experience I am not surprised that redface themselves advice against live updates. There must surely be a better way. Yes there is ; jigdo.

[fedora]
name=Fedora 8 - x86_64
failovermethod=priority
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/x86_64/os/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=x86_64
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY

[fedora-debuginfo]
name=Fedora 8 - x86_64 - Debug
failovermethod=priority
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/x86_64/debug/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-debug-8&arch=x86_64
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY

[fedora-source]
name=Fedora 8 - Source
failovermethod=priority
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/source/SRPMS/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-source-8&arch=x86_64
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY

That's the content of my /etc/yum.repos.d/fedora.repo note that it refers to release 8 when it should refer to 9. The files in /etc/yum.repos.d are created by the 'fedora-release-9-2.noarch.rpm'. That has apparently been installed. That has apparently been installed according to the rpm command.

Interestingly any 'yum update' command results in:

followed by:

Setting up Update Process
Could not find update match for mythtv
No Packages marked for Update

Yet the product websites and browsing through the repositories clearly show that there are newer versions available. At this point I tried editing the files in the yum.repos.d folder by hand to change '8' to '9'. The message about repmod did go away, and now updates seems to be happening.

Later I realised that I should copy the repo file from /media/Fedora\ 9\ x86_64\ DVD/media.repo to /etc/yum.repos.d/Fedora-install-media.repo so that anything on the DVD can be installed wtihout having to download again.

At the new house I have a Wimax connection with a 2mbps downlink and 512 up. In the three weeks I have been living here i have never seen anything download at 200k ro anything go up at 50 k so i wasn't suprised when downloading the torrent took more than a day. It took two more for the share ratio to go past 1.0

I did an upgrade rather than a fresh installation and was suprised to find that the updater ran almost as slowly as the download - well not exactly but it did take close to an hour to update all the packages.

The release notes change has a list of changes as long as your arm but I still haven't noticed anything significant.

All projects seem to be effected by it.

Our upgrade policy is to provide updates only for one year and it's nearly two years since version 3.0 was released, still if you have version 3.0 you can download the new version free of charge.

Are there any new features? not this time. What about bug fixes? yes there are two. One deals with FTP uploads. There were a couple of incompatibilities reported with certain servers. That has been sorted out. Then there was a bug in queue and upload mode and file sorting.

When you use Rad Upload in queue and upload mode (which is needed if you are to embed it into an HTML form), the queue is displayed in a table. The columns in this table can be reordered by dragging them about. Unfortunately that breaks sorting. The applet would sort by the wrong column when you clicked on the table header.

There isn't a large difference between the old and the new version - it's only a minor bug fix. What's more important is that the applet has now been signed with a new certificate. The old cert, is due to expire in a couple of weeks time, so the new version has been made available in advance so that users can move to the new version before the d-day

SLT ADSL is a pretty lousy service anyway. SLT is a dinosaur pretending to be a geek. Dialog Telekom is an Aligator Gar but they have long since stopped pretending to be anything.

Actually I was quite suprised by the result. The network is pretty quick. But how come the upload speed is close to 1mbps while the downlink is only 50? I suspect the download speed would probably be faster if I had used a USB cable instead of bluetooth. Bluetooth as we know it is limited to 1mbps but a faster version is not far off.