Chris Staite from the University of Birmingham has built a statically-linked version of Chromium, the open source version of Google’s Chrome browser, for Centos.

You can get it from here.

I was getting so sick of Firefox’s slowness and bloat, and Chromium is so much snappier, and more memory-efficient too.

Although to be fair, I don’t have nearly so many extensions installed yet…

It should just work out of the box with no extra dependencies to install. I’m using 64-bit Centos 5.4, and although it’s a 32-bit app, it seems entirely happy so far.

Everybody (?) knows that in theory, if you have 64-bit Firefox on 64-bit Linux (x86_64), you can use nspluginwrapper to install 32-bit plugins, like the Flash Player. There’s some instructions here for example.

However, those instructions are flawed in two regards.

Firstly, Flash Player 10 doesn’t come with a .xpt file any more, but that’s not apparently a problem.

Secondly, and more mistifyingly, nspluginwrapper seems to require you to give the absolute path to the plugin’s .so file, for some reason. So if you get an error like this:

$ nspluginwrapper -v -i libflashplayer.so
*** NSPlugin Viewer  *** ERROR: libflashplayer.so: cannot open
shared object file: No such file or directory
nspluginwrapper: no appropriate viewer found for libflashplayer.so

Then try again with the full path to the plugin:

$ nspluginwrapper -v -i /home/bsm/clegg/.mozilla/plugins/libflashplayer.so
Install plugin /home/bsm/clegg/.mozilla/plugins/libflashplayer.so
  into /home/bsm/clegg/.mozilla/plugins/npwrapper.libflashplayer.so

Restart Firefox, and away you go, joy! No feeling for stability yet, but I’ll post again if there are any problems.

Incidentally, I first tried installing nspluginwrapper via yum, and got a whole bunch of unsatisfied dependencies:

Error: Package devhelp needs libgtkembedmoz.so, this is not available.
Error: Package devhelp needs libxpcom.so, this is not available.
Error: Package devhelp needs gecko-libs = 1.8.0.12, this is not available.

Then I just tried installing the RPMs from the nspluginwrapper home page (first the one marked Viewer, then the one marked Plugin) and it worked like a charm.

Hat tip to this thread on the Ubuntu Forums for finally revealing the key bit of information about absolute vs. relative paths.

UPDATE: Aaargh, sound doesn’t work. But that seems to be the fault of my ALSA drivers rather than Flash or nspluginwrapper. Apparently Flash can only use ALSA for sound, and not any of the other various Linux sound architectures, and only OSS works on this PC…

Andrew.

It goes like this, as root:

$ yum update subversion

[normal messages snipped]

Transaction Check Error:
  file /usr/share/emacs/site-lisp/psvn.el
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/man/man1/svn.1.gz
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/man/man1/svnadmin.1.gz
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/man/man1/svnlook.1.gz
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/man/man5/svnserve.conf.5.gz
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/man/man8/svnserve.8.gz
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5
  file /usr/share/xemacs/site-packages/lisp/psvn.el
from install of subversion-1.5.5-0.1.el5.rf
conflicts with file from package subversion-1.4.2-2.el5

WTF? Surely doing an update is supposed to replace files from an earlier release with a later one?

The reason, as my colleague Ian discovered, is that 64-bit Centos has both 32 and 64-bit versions of Subversion, which causes it to get its knickers in a twist when doing an update. So we just did the following:

$ yum erase subversion.i386
$ yum update subversion

to remove the 32-bit version and then just update the 64-bit one. Works fine. (Touch wood…)

Probably works with Redhat Enterprise (RHEL) too and possibly other distros.

EDIT: If you only have the Centos base RPM repository, you won’t find svn 1.5.5 (or any recent versions). You need to set your system up to use RPMForge as well, as documented here. Thanks to GR in the comments for pointing this out.

Andrew.