Dizwell Informatics

News from Nowhere

The Dizwell Blog

R.I.P. Rachel

First glimpsed at the crack of dawn from inside my study, on my birthday, January 7th 2006, this was my first-ever close-up Swamp Wallaby:

We called her Rachel, after the name of the young daughter of a web-friend of mine on the Oracle groups… and I soon upgraded to a monitor that was about 10,000 times thinner!

Rachel then did what all good wallabies do and started “begatting”. I’m afraid we didn’t keep great records, but I’m pretty certain she begat Jefferson, Milhous, Franklin and a good few others.

She never came in the house, and never even quite managed to get used to us coming out of the house to put food out (though she’d never hop off too far and would soon be back), but she turned up practically every day and became something of a fixture around these parts:

(That’s her with Milhous)

Sad, then, to report that we haven’t seen Rachel since late September. They are always prone to going ‘missing’ for a couple of days, sometimes more. But for her not to turn up for, now, getting on for 8 weeks… well, I fear we must conclude that Rachel has departed for good.

The maximum lifespan of a swamp wallaby is, allegedly, about 15 years. I’d guess she was 2 years old from that original photograph, which means she only managed around 6 or 7 years… not very long, then, and I suspect the local foxes as a result. But we’ll never know.

Happily, we still get a mob of around 4 to 6 wallabies every night, including the ever-intrepid Chandler:

Long may they continue to come… but Vale, Rachel.

Gill Sans and Linux (part 956)

Any reader (assuming I still have any) with a long memory will know that I have a thing about Gill Sans, the font.

Actually, I have a thing about Eric Gill, the guy who designed it in the late 1920s. He was a very strange fellow indeed! By all accounts a devout Catholic, he nevertheless found time to have an affair with his sister, sex with his dog and do a bit of child abuse on the side. Regardless, he was a great sculptor, type face designer and all-round artist. When I was in London last month, I was able to take a quick trip to Broadcasting House in Portland Place, which is graced by a great sculpture and a couple of bas-reliefs of his:

That’s Ariel between Wisdom and Gaiety, the latter of which I suspect Eric to have been overly familiar with!

Anyway, I digress.

The point is, if you’re running Linux and you want the Gill Sans font, how do you get it, because it’s certainly not baked-in to any distros I know of?!

Well, the method I’ve always used in the past is to visit the Microsoft website and download the Euro fonts update for Publisher 98 (my, how long ago that seems!) in an XP (virtual) machine and copy the relevant TTF files across to the Linux box, because that font is included for free in that update. (Similarly, you get Frutiger Linotype -another nice font, this time designed by Adrian Frutiger in the early 1970s- for nothing if you install ye ancient Microsoft Reader).

This approach is, of course, completely in breach of the license for those fonts and thus A Very Bad Thing To Do (though it works). So don’t do it (even though you can). And I haven’t done it for ages as a result of having seen the licensing light, honest!

So that option is really (morally) out of the question these days.

So what else can you do? Well, why not instead visit this website and download the blighters with, apparently, no licensing restrictions at all?! Good question… As far as I know, it is actually impossible to produce a Gill Sans font that is legal and legitimate, because the font is copyrighted up to its ears, never mind licensing restrictions. So, I don’t know where those downloads come from originally, and I’m pretty sure that they are not entirely kosher -though I could be wrong and I would hate to cast aspersions. So, download them and use them as your conscience dictates.

I suppose you could always buy the thing, too, if you really felt like it (and had the better part of $1000 to spare!)

Either way (and here comes the technical stuff for the benefit of my forgetful brain): To install fonts in bulk (at least on Debian 6, ‘Squeeze’): copy them to the .fonts folder in your home directory (e.g., /home/hjr/.fonts), and then issue the commands:

su - root
fc-cache -f -v

If there isn’t a .fonts folder already in your home directory, just create one.

Or, you can install them individually by double-clicking the downloaded/copied/purchased ttf file and hitting the Install Font button. The downloaded files can be deleted afterwards, because this process copies the font files to your /home/<name>/.fonts file.

Squeeze and VMware Workstation

If you’re running Debian Squeeze (x64) and trying to install VMware Workstation (7.1), you may run into difficulty post-installation where it perpetually warns you about not being able to find kernel headers and the like. Here’s the fix for that.

First, if you haven’t already, become root and issue this command:

aptitude install gcc make binutils

Next, make sure you’re fully updated (aptitude update will take care of that) and that you have rebooted after the update. That way, you know for certain that you’re using the latest kernel. Finally, issue this command:

aptitude install linux-headers-`uname -r`

Those are ‘back ticks’ around the “uname -r” bit (usually found, on US keyboards at least, above the tab key, and left of the ’1′ key in the main part of the keyboard). They cause the command uname -r to be executed and the value it generates to be passed back to the rest of the aptitude install command. This way, you ensure you’re installing the version of the kernel headers which precisely matches the version of the kernel you’re actually using.

After that, just run Workstation as normal and it should detect everything normally and offer to compile some kernel modules -and once that’s been done, the thing should run fine.

Another year…

Once again, it’s time to celebrate the birthday of Benjamin Britten (he would have been 97 today).

Unfortunately, I must do my celebrating confined to bed, since I have the muscle aches and gripes one usually associates with influenza (but which is probably just a 24-hour niggle-thing).

Anyway, at least I get to listen to plenty of the master’s music this year! So, happy birthday, Ben!

Change number of Virtual Desktops

Debian 6 (“Squeeze”) only uses two virtual desktops by default -which means, if you enable the Desktop Cube, you actually end up enabling the Desktop Plane!

In the old days, you’d solve this problem by right-clicking the virtual desktops applet in the bottom panel, click Preferences, and change the number of virtual desktops there (to four, if you want a proper cube back!):

As you can see here, however, you now only get an option to adjust the number of rows the virtual desktops are displayed in, which isn’t the same thing at all, and which has no effect on the number of virtual desktops which exist in the first place. So that option’s not on these days. Where else can you do the deed, then?

Well, if you want desktop cubes, you are presumably running Compiz desktop effects. And, if you have any sense, that means you’ll have installed the CompizConfig Settings Manager (System → Preferences → CompizConfig Settings Manager menu options if so). At the very top of that application is an item for General Options -and that, in turn, has a tab for Desktop Size. Click that, and bump the Horizontal Virtual Size up to 4:

Job done:


Not, I think, that anyone’s really paying attention, but I’m back from London, having had a great time there. Must have walked about 60 miles in the 10 days; fell back in love with The Tube; was present to see a High Court judge sworn in; enjoyed a Latin mass at the Brompton Oratory and a lovely Evensong at Westminster Abbey (I try to be ecumenical in all things!); had a wonderful time with my extended family after all this time; and much, much more.

I mention it now only because I’ve just deleted my Twitter and Facebook accounts (two of the biggest, most pointless wastes of time on the planet, I think!), and I wouldn’t want anyone thinking I was dead or something!

Have a few tourist memories on me, anyway:

(Battersea Power Station. Still un-re-developed after all these years!)

(St. Paul’s Cathedral main entrance. Interestingly processed by my ‘panorama stitching’ software!)

(King’s Cross Station, with St. Pancras Hotel in background)

(Mornington Crescent tube station. I am a keen player of the Mornington Crescent game!)


For the first time in 16 years (nearly 17, in fact), I am travelling back to London for a 10-day stay. I shall be doing lots of tourist stuff in London, with side-trips to Dublin and my old home town of Gillingham (plus Chatham/Rochester).

I’m looking forward to it very much -hope the cats and wallabies won’t mind putting up with the house-guest animal-sitters we’ve arranged for the interim, though!

The flight leaves in about 10 hours (doesn’t time drag when you really don’t want it to!), and I’ll be touching down in London at around 7AM (GMT) on October 1st. I won’t see these sunny shores again for a further three weeks after that.

Data Pump via the Network

I will confess that I’ve tended to stick with ye olde exp and imp (export and import) utilities because I know them reasonably well and they do the job. However, the writing has been on the wall for both of them for quite a few years and you’re supposed to have been progressively switching over to using the all-new, all-dancing expdp and impdp replacements. For the stuff I use these utilities for, however, I’ve managed not to need the new versions… until today. We recently upgraded all our databases to 11.2 from -except one, which got converted to 11.1 months ago- and when you try to do a traditional export against the 11.1 database, it terminates with an error:

. exporting materialized views
. exporting snapshot logs
EXP-00008: ORACLE error 1455 encountered
ORA-01455: converting column overflows integer datatype
EXP-00000: Export terminated unsuccessfully

Hunting around the subject, it seems there’s a bug in late versions of exp that make this to be expected, which is a bit of a show-stopper. However, those same bug reports all unanimously declare that the new data pump version of export does not suffer from the same problem. So, finally, it’s time to switch to using the new “dp” utilities after all!

The trouble is, however, that we’ve used the traditional utilities to pull production data over to development environments. Whilst logged onto the dev server, for example, I’d do something like:

exp "sys/[email protected] as sysdba" file=prod_exp.dmp full=y direct=y

…and the export file, called “prod_exp.dmp” would be produced in whatever directory I happened to be sitting in when I typed the command, on the dev server. Production data was thus dumped out to a dev server directory, thanks to the use of a tns alias in the connection string bit of the command. Put another way: the export utility runs locally on my development server, but knows to connect to my production database to fetch its data.

Unfortunately, this is not how the Data Pump utilities work. They always run on the server and never on the client. Which means that, other things being equal, the output file is always on the server, too -even if the utility is invoked remotely!

So, for example, you could issue this command whilst logged into the development server:

expdp "sys/[email protected] as sysdba" directory=dumpdir file=prod_exp.dmp full=y

…and the thing would work just fine. But when you then navigate the file system of your development server, you will not be able to find a file called “prod_exp.dmp” anywhere! And that’s because the file has been written on the production server, in whatever location the “dumpdir” directory object is pointing to on that server.

You can invoke data pump export remotely, in other words, but all the action and all the output will only ever happen on the remote database. If you want the dumpfile to be sitting on your development server’s hard disk at the end of the exercise, this sort of syntax won’t achieve that, I’m afraid!

But this, happily, will:

expdp "sys/password as sysdba" network_link=prodserver directory=dumpdir file=prod_exp.dmp full=y

With this syntax, typed on the dev box, you’re now connecting locally -that is, to the development database. That therefore means you’re going to be outputting to whatever part of the development server’s file system is referenced by the dev box’s “dumpdir” directory object. But, the new parameter network_link means that the development database doing all the work will know to connect to whatever database is at the end of the “prodserver” database link in order to get its data (so, obviously, for this syntax to work, I must first have issued a command such as create database link prodserver connect to system identified by password using ‘dbprod’). This syntax -a local connection string, but an extra network_link parameter- therefore achieves what the old export command did: production data “pulled” across to my development server and ending up as a dump file on my dev server’s hard disk.

In a word, the trick is not to invoke the data pump utility with an old-fashioned “@somewhere” to achieve a ‘remote connection’, but to use one of the new parameters the new utility makes available to you to have the data ‘pumped’ from a remote location. Easy -though not perhaps entirely obvious!

Change Windows 7 Login Screen

When I have to use Windows 7, the first thing that really puts me off is the dolls-house-y login screen. It’s so clutzy as to be annoying, and I didn’t realise until today that it can be gotten rid of. Which makes this an essential thing to do on any Windows 7 system you are unfortunate enough to have to use. You can do it by poking around in the registry, or by running this svelte utility.

Firefox Problem with KVM

It’s a trivial one, really, but if you disable Fedora’s Network Manager in order to be able to create KVM’s bridged network connections as mentioned in the last post, you will probably find that every time you now launch Firefox, it will start in ‘Work Offline’ mode. This is a pain if you want it to automatically re-open tabs you had open when you last shut down!

The fix is quite simple, however. Type about:config in Firefox’s URL bar and agree to be careful! Filter for the word toolkit. Find the item called toolkit.networkmanager.disable and double-click it so that it becomes set to ‘true’. Shutdown Firefox and then re-start it: this time, it will correctly identify that you are not working in offline mode.