With the record attempt due today for Firefox 3 downloads, I thought that it would be a good time for me to update my advice for getting BBC’s iPlayer going in Firefox running on Ubuntu. First, you need RealPlayer 11 for Linux. Once downloaded, the file RealPlayer11GOLD.bin needs to be made executable before running it with administrative privileges. The following command do this:
chmod +x RealPlayer11GOLD.bin
There is a catch though and it is that while the RealPlayer 11 installation is seamless for Firefox 2, the same cannot be said for Firefox 3 because directory locations have been changed such plugins are now found in /usr/lib/firefox-addons/plugins. The result that copies of or symbolic links to nphelix.xpt and nphelix.so are needed in that location. The following commands do the trick:
sudo ln -s /opt/real/RealPlayer/mozilla/nphelix.xpt /usr/lib/firefox-addons/plugins/nphelix.xpt
sudo ln -s /opt/real/RealPlayer/mozilla/nphelix.so /usr/lib/firefox-addons/plugins/nphelix.so
To cap all of this, I have seen advice that libtotem-complex-plugin.so needs to be removed from the Firefox plugins directory as well. I am not sure about this but I did that and all is working well for me. Let’s hope that continues to be the case.
The fancy artwork that comes with Ubuntu Studio does look appealing so I got lured into converting my vanilla Ubuntu 7.10 into something a bit more avant garde. The theme’s all very dark (you can have a peek here; file size is 1.1 MB) but it looks very smart, even if the merging of application title bar and top desktop panel due to their having the same colour and texture is a little disconcerting. My momentary lapse of discipline also got me adding a whole array of audio, graphics and movie applications that I may never use; it’s good to have them if I ever fancy a fiddle but removal is not off the agenda either. The other thing that came with the package was an alternate kernel that looks as if it might be of the real time variety, at least if the "rt" in its package name is to be believed. The main reason for mentioning that is that VMware has ceased working so I need to snag the correct kernel source code to get things going again. Let’s hope that it’s a successful venture…
Update: After a spot of poking, Synaptic offered up the required kernel header files and VMware was reinstated with only a modicum of effort. All’s well that ends well.
It should have been as straightforward as following the instructions on the openSUSE website but a bug in VMware Tools derailed things on me. The usual procedure would have you starting by selecting Install VMware Tools from the VM menu before popping into the virtual machine to do the rest. Once binutils, gcc, gcc-c++, kernel-source and make are in place, next steps should involve using YaST to install the RPM for you to run the vmware-config-tools.pl script from the terminal.
However, a bug in compat_slab.h puts a stop to any hopes of installing the vmhgfs component. That’s needed if you want to enable the shared folders feature; looking in /mnt/hgfs then would get you to any shared folders Everything else will be there but why miss out on one piece of functionality when it come in useful?
Having found a useful thread on the subject, here’s my way forward: it is as the expected procedure up to the point of installing the RPM. With VMware Tool installation on a Linux guest, you have two options: use RPM as described or use the compressed tarball. The latter seems the better course. Extract the contents into a folder and navigate to that folder. When there go into vmware-tools-distrib/lib/modules/source and extract the file vmhgfs.tar. Proceed into the resulting vmhgfs-only contained wherever you put it and perform the following edit of compat_slab.h:
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 22) || defined(VMW_KMEMCR_HAS_DTOR)
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 22) || defined(VMW_KMEMCR_HAS_DTOR)
After that, recreate and replace vmhgfs.tar before issuing the following command in the terminal window while in the vmware-tools-distrib directory: ./vmware-config-tools.pl (anything prefixed with "./" picks up the file from the current working directory rather than where system binaries are stored). A kernel compilation will be involved but all of the defaults should be sensible. Hopefully, all will work well after this.
Update: I am left with a number of outstanding issues that I need to resolve. Lack of internet access from the VM is one of them and a constant forgetfulness regarding the nationality of my keyboard (it’s British) might be another. In the interim, I have removed VMware tools until I can spend some time setting these to rights. Internet access has returned and British keyboard layout is being interpreted correctly in the meantime…
In a previous sustained spell of Linux meddling, the following installation routine was one that I encountered rather too often when RPM’s didn’t do what I required of them (having a SUSE distro in a world dominated by a Red Hat standard didn’t make things any easier…):
tar xzvf progname.tar.gz
The first line extracts from a gziped tarball and the second one changes into the new directory created by the extraction. For bzipped files use:
tar xjvf progname.tar.bz2
The next three lines below configure, compile and install the package, running the command in its own shell.
su -c make install
Yes, the procedure is a bit convoluted but it would have been fine if it always worked. My experience was that the process was a far from foolproof one. For instance, an unsatisfied dependency is all that is needed to stop you in your tracks. Attempting to install a GNOME application on a KDE-based system is as good a way to encounter this result as any. Other horrid errors also played havoc with hopeful plans from time to time.
It shouldn’t surprise you to find that I will be staying away from the compilation/installation business with my main Ubuntu system. Synaptic Package Manager and its satisfactory dependency resolution fulfill my needs well and there is the Update Manager too; I’ll be leaving it to Canonical to do the testing and make the decisions regarding what is ready for my PC as they maintain their software repositories. My past tinkering often created a mess and I’ll be leaving that sort of experimentation for the safe confines of a virtual machine from now on…
When Windows XP was my base operating system, I used VMware Workstation to peer into the worlds of Windows 2000, Solaris and various flavours of Linux, including Ubuntu. Now that I am using Ubuntu instead of what became a very flaky XP instance, VMware is still with me and I am using it to keep a foot in the Windows universe. In fact, I have Windows 2000 and Windows XP virtual machines available to me and they should supply my Windows needs.
A evaluation version of Workstation 6 is what I am using to power them and I must admit that I am likely to purchase a license before the evaluation period expires. Installation turned out to be a relatively simple affair, starting with my downloading a compressed tarball from the VMware website. The next steps were to decompress the tarball (Ubuntu has an excellent tool, replete with a GUI, for this) and run vmware-install.pl. I didn’t change any of the defaults and everything was set up without a bother.
In use, a few things have come to light. The first is that virtual machines must be stored on drives formatted with EXt3 or some other native Linux file system rather than on NTFS. Do the latter and you get memory errors when you try starting a virtual machine; I know that I did and that every attempt resulted in failure. After a spot of backing up files, I converted one of my SATA drives from NTFS to Ext3. For sake of safety, I also mounted it as my home directory; the instructions on Ubuntu Unleashed turned out to be invaluable for this. I moved my Windows 2000 VM over and it worked perfectly.
Next on the list was a serious of peculiar errors that cam to light when I was attempting to install Windows XP in a VM created for it. VMware was complaining about a CPU not being to run fast enough; 2 MHz was being stated for an Athlon 64 3000+ chip running at 1,58 GHz! Clearly, something was getting confused. Also, my XP installation came to a halt with a BSOD stating that a driver had gone into a loop with Framebuf fingered as the suspect. I was seeing two symptoms of the same problem and its remedy was unclear. A message on a web forum put the idea of rebooting Ubuntu into my head and that resolved the problem. I’ll be keeping an eye on it, though.
Otherwise, everything seems to be going well with this approach and that’s an encouraging sign. It looks as my current Linux-based set up is one with which I am going to stay. This week has been an interesting one already and I have no doubt that I’ll continue to learn more as time goes on.