biotext.org.uk

One of the few annoying things about my oldish MacBook Pro is its keyboard, for example a few unresponsive keys, but particularly the lack of a # key. It’s a UK keyboard, and has £ for shift-3, and # is hidden in alt-3 (not labelled).

This is fine in native desktop apps, but less fine in some text-mode programs (e.g. vim), when for some reason this often produces a superscript ³ instead.

So I’ve set up a custom keyboard mapping in iTerm to map F3 to #, which works nicely. However!

If I’m SSHed in to a remote Linux machine (or even my local Ubuntu VirtualBox) neither of these keys work in X apps. But, xmodmap (via the config file ~/.Xmodmap) can help. For some reason, Macs all have a dedicated key for these characters — § and ± — which no-one ever uses. But with this line in ~/.Xmodmap we can remap it to produce #:

keycode 18=numbersign

UPDATE: I’ve found a better way which works pretty much globally…

Using Ukelele you can copy the British keyboard layout and then remap keys to your heart’s content. I’ve moved the § character to the alt-§ key combination, in case I ever need it, and moved the # character to the raw § key. This seems to be respected almost everywhere so I don’t need to mess around with alt-3 or F3 any more. Joy. It also works over JollysFastVNC to a remote RealVNC server, which none of the other methods did.

Unfortunately, things still aren’t perfect. If I actually open a VirtualBox console session into GNOME on the local Ubuntu VM, the pointless § and ± key actually produces < and > so neither of these tricks work. In fact, I can’t get anything to generate a # even though I have the MacBook Pro Intl keyboard layout selected in GNOME. Any ideas?

UPDATE 2: YES!! I’ve finally cracked it for VirtualBox. With the help of the xkeycaps command, I discovered that X the keycodes coming into Ubuntu weren’t what I thought they were — somewhere the Mac-ness of the keyboard layout was getting lost. It turned out that the § key was generating keycode 94 instead. So I set up this in .Xmodmap on the Ubuntu VM:

keycode 94=numbersign

Now it works in VirtualBox too. Leave gifts of thanks below

Recently, one of our web servers fell victim to an apparent DoS attack, being hammered with hundreds of simultaneous dynamic page requests, far more than it’s specced to handle. To its credit, it stayed up, although it took about five minutes to log in via ssh, and when we spotted what was happening, the load average was over 100 which I think is the most loaded I’ve ever seen. The offending IP address was at UCSD who do a lot of bioinformatics, so there is a chance it was a misguided attempt to scrape a lot of data from us, rather than an actual hostile act, but in any case the upshot is the same.

It worried me that there was no easy way to remotely check the machine’s health, so I hacked together a quick PHP page to report various vital statistics on demand — load average, memory usage, disk usage etc. — and a Perl monitor that can raise the alarm if anything exceeds safe bounds.

(continue reading…)

This took a fair bit of searching, and the answer’s non-obvious…

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.

(continue reading…)

I just ran into a problem when trying to upgrade to the latest rpm-packaged version of Subversion on Centos 5 x86_64 — simple solution, but not obvious, so hopefully this will help someone.

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?

(continue reading…)