Log in

No account? Create an account
Malc's Journal [entries|archive|friends|userinfo]

[ website | meta-homepage ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Blogging elsewhere [Apr. 15th, 2011|23:16]
You might have noticed that I don't write much here any more; that situation will probably persist semi-indefinitely. However I have recently started writing some technical articles on Syslog, the Systems Research Group's new blog. You can find my articles here.

IPv6 doom: the rogue RA bug [Jan. 23rd, 2011|03:07]
In this article I describe a problem which I and others have seen in the wild many times, whereby a single broken host will severely cripple the ability of other hosts on the local network to reach IPv6-capable (dual-stack) servers, regardless of whether the local network has deployed IPv6. This is primarily aimed at network administrators, although the problem affects many people.

Why I will never* buy an Android phone [Jan. 21st, 2010|05:36]
[mood |uncomfortableuncomfortable]

Because this seemingly-inocuous patch (which postdates Android 1.5, and thus fixes a bug affecting several of the earlier Android phones) reveals an alarming mess.

Before that patch, making an emergency call on some networks (e.g. Rogers in Canada, and T-Mobile in the USA) would cause a system service to throw a NullPointerException, and the phone to reboot.

I am really quite surprised and shocked. How on earth could such a bug — in the single most important feature a phone has, a malfunction in which could be life-threatening — make it into multiple models of phone without detection until after release? It's hard to say precisely who is at fault here, so I'll go with "everybody". The network, the manufacturer and the OS developer should all be clear to themselves and to each other who is going to make sure that this stuff is actually fit for purpose. Android 1.5 clearly wasn't suitable for use in a phone, and given the lack of evidence of any significant change in behaviour of Google/HTC/... since then I have no confidence in any version of Android. Maybe as a netbook OS it would be great, but I just don't want to potentially trust my life to it.

(In the UK, DECT phones very sensibly carry a warning that they are not to be relied upon for emergency calls and that alternate provision should be made. Maybe Android phones should carry a similar warning, suggesting that one also carries a non-Android phone for emergency use!)

Incidentally, I don't think that this has resulted as a consequence of Android's open source nature: having prodded git a bit, I believe the bug was present in a bulk Google upload on 3rd March 2009. Someone more familiar with the Android source control maze might be able to confirm that.

A product which should exist [Jan. 3rd, 2010|16:59]
Last night I had an idea for a product. I think it ought to exist already; does anyone know where I might buy one? It's a USB virtual DVD-RW drive, in the same form factor as a pen drive. I want to be able use it exactly as if it were a USB DVD-RW drive permanently containing a DVD-RW disc; I should be able to write an CD/DVD image onto it (of, say, a Windows installation disc) using the usual CD/DVD-recording tools, then use it exactly as if it were a DVD drive containing the disc I had just written (for example, booting the Windows instaler from it). Actual USB DVD drives are large, cumbersome and frequently need external power supplies — not to mention DVD media — and I'd much prefer something that I can attach to my keyring. I see no reason for this to be difficult or expensive to produce; it could presumably just be a >=4.7GB USB flash drive with slightly-modified firmware.

The 3G dongles I've used recently have had roughly this capability, as it happens: they contain their drivers and an installation program on a flash chip, and this emulates a CD drive so that the installation program will autorun in Windows. I suspect I wouldn't be able to write my own full-sized CD image there however.

Useless adapter? [Nov. 3rd, 2009|15:03]
Is there any possible application for a male Micro SATA to female SATA + male Molex adapter? It could be used to plug a normal hard drive into a Micro SATA bay, I suppose, but only if you ignore the Molex. If you plug in both Micro SATA and Molex you'll be joining two power sources together.

Anyway, if you can think of a purpose, I appear to have bought three by accident. I meant to buy these instead which are rather more useful (but out of stock everywhere).

Paris [Sep. 20th, 2009|23:14]
[mood |touristy]
[music |Oh La La - Paris Ne t'Aime Pas]

I've been in Paris for the past nine days, nominally to present a paper on MOOSE at ITC 21's DC CAVES workshop. At least one of you has requested a writeup, so here goes, although this is as much for my own future reference.

Beware: behind the cut, this post is quite long and includes several photos. If you're reading this via RSS and don't see the cut, I apologise.

What I Did On My HolidaysCollapse )

Converting Subversion to Bazaar [Jun. 8th, 2009|05:19]

I have spent much of this evening (and, well, this morning) trying to convert a private Subversion repository into a public Bazaar repository hosted on Launchpad. This should be easy, and in a way it is, but there are a few pitfalls and alternatives which I thought I'd write up to save someone else the bother of figuring this out for themselves.


This is a Bazaar plugin which provides (semi-)native access to Subversion repositories from the usual bzr tool. I don't really need its myriad features for treating a Subversion repository as a Bazaar repository or vice versa, etc., but it also provides a command "bzr svn-import" which would appear to do exactly what I want. However...

  • bzr-svn directly copies Subversion's author field to Bazaar's committer field. There is nothing wrong with this per se, except that it's not neat: Subversion authors are usually just UNIX usernames, whereas Bazaar's committers usually consist of a full name and email address. Launchpad, for example, will fail to associate commits which were converted in this way with a Launchpad account. I eventually fudged my way around this by dumping the Subversion repository (svnadmin dump), editing the dump file by hand to have Bazaar-style authors (fiddly — it's not designed to be human-editable!), and importing into Bazaar from that — but since the issue below was later deemed a show-stopper this effort was wasted. :-(
  • bzr-svn writes an unusual sort of repository — specifically, one with rich-root data. Again, not really a problem per se; this behaves as a normal repository to a sufficiently-recent bzr (in fact it's also faster, apparently) and is at some point going to become the default. However the particular format bzr svn-import chooses to write (in my setup at least — bzr-svn 0.5.3 on Bazaar 1.13.1) cannot be read by versions of Bazaar prior to 1.9. For comparison, the version of Bazaar in Ubuntu 8.04.2 ("Hardy Heron") is 1.3.1. I consider this unacceptable; I'd like my repository to work for people who have a version of Bazaar older than a few months. It turns out also that whilst Bazaar can convert between some versions, it can't convert this particular repository format to one readable by version 1.3.1.

So, I went looking for alternatives.


At first glance, this shortish Python script seems like a poor imitation of bzr-svn with little to recommend it over the more official-looking plugin. However, svn2bzr has a trick up its sleeve: it can remap authors in a simple but effective manner.

It did turn out rather buggy, though; I hit two coding errors which prevented my use of the script until I figured out what the author was trying to achieve and made a few small changes. If you want my fixed version, it's available in a Bazaar repository (of course ;-) ) which will hopefully be merged upstream at some point. No guarantees that I've fixed the bugs correctly, as I wasn't at all familiar with the code, but it seems to have worked fine for me.


SRCF compromise [Apr. 25th, 2009|02:25]
I've spent the past couple of days dealing with a major security incident on the SRCF's main server, pip (almost exactly 18 months since our last such incident). Now that things have calmed down a bit, I thought I'd write something about it for those who expressed an interest in the details.

Read more...Collapse )

SRCF major new service announcement [Apr. 1st, 2009|01:02]

As users of the SRCF are no doubt aware, the SRCF strives to be at the forefront of technological developments on the Internet. It is therefore with great pleasure that we announce today support for a new, cutting-edge distributed hierarchical document search and retrieval protocol: Gopher.


Enjoy browsing Gopherspace!


Stupid utility of the day [Feb. 12th, 2009|14:14]

I present Gigabyte EnergySaver as bundled with my new motherboard.





[ viewing | most recent entries ]
[ go | earlier ]