Skip to main content

Posts

Showing posts from 2011

A simple illustration of the use of goroutines and channels in Google Go

For a long time I've been meaning to spend some quality time with Google Go and I finally have the chance. For the little home project I'm working on I needed a way to generate unique IDs. In Go there's a really nice and simple way of doing this: assign a single goroutine as an ID generator and use a channel as the way to grab a new ID. Here's the code: idMaker := make(chan string) go func() { var counter int64 = 0 for { idMaker <- fmt.Sprintf("%x", counter) counter++ } } () The first line makes a channel that will be used to communicate strings. In this case, I'd decided to have unique string IDs. Then there's a go function (in this case an anonymous function) that contains a 64 bit integer counter that is incremented every time an ID is generated. When an ID is generated it is formatted as a hex number and made available on the channel. It just loops around forever providing ID

A pre-Christmas Plan 28 update

Despite the lack of public announcements from Plan 28 on the project to build Charles Babbage's Analytical Engine there's plenty going on behind the scenes. The big news is the Plan 28's registration as a charity in the UK is now complete and has been published by the Charity Commission. Plan 28 is now registered charity number 1145043 . Every charity has to have 'objects' which are a statement of its aims. Plan 28's objects are as follows: 3. Objects 3.1 The Charity's objects ("The Objects") are for the public benefit 3.1.1 The advancement of education, in particular in the fields of science and the history of science, through the construction of Charles Babbage's Analytical Engine; and 3.1.2 The advancement of science, in particular through: a) Research in the fields of computer science, engineering and mathematics; and b) The raising of public awareness of Charles Babbage's Analytical Engine

A back channel confirms that I'm right... sort of

Through a little circuitous back channel I received an unofficial follow up to a blog post about the unused machine code in the GCHQ Code Challenge part 2. The follow up assured me that the unused code was left over after some clean up was done, and that the rest of the data in the file was random filler (as I'd already heard). But as I'd already determined that it was not actually random (at least at one level) I sent a carrier pigeon out with a question about my follow up blog post. Listening for secret messages transmitted during The Archers I received a reply indicating that I had indeed 'broken' the encryption on that stream of ASCII data (by guessing the algorithm and reverse engineering the key stream), but that the underlying data was actually random ASCII generated and encrypted using the following Python code: b = ''.join([chr(randint(0x20, 0x7f)) for i in range(0, 16 * 7)]) c = codec(b, 0x1f, s=5) The first part generates 112 bytes of rando

Down the GCHQ rabbit hole (or I think there really is a part 4)

Update : Confirmation that this is correct Early this morning I blogged that I thought there was a hidden part 4 to the GCHQ Code Challenge because of the amount of non-random data in part 2. Through someone who knows someone who knows someone at GCHQ I got the response the data was "a random filler and that they ran out of time to do anything interesting". Well, I don't believe that's the whole story. There's a distinct pattern worth investigating. Firstly, here are the three blocks of data that are untouched in part 2: 0150: 7d 1f 15 60 4d 4d 52 7d 0e 27 6d 10 6d 5a 06 56 }..`MMR}.'m.mZ.V 0160: 47 14 42 0e b6 b2 b2 e6 eb b4 83 8e d7 e5 d4 d9 G.B............. 0170: c3 f0 80 95 f1 82 82 9a bd 95 a4 8d 9a 2b 30 69 .............+0i 0180: 4a 69 65 55 1c 7b 69 1c 6e 04 74 35 21 26 2f 60 JieU.{i.n.t5!&/` 0190: 03 4e 37 1e 33 54 39 e6 ba b4 a2 ad a4 c5 95 c8 .N7.3T9......... 01a0: c1 e4 8a ec e7 92 8b e8 81 f0 ad 98 a4 d0 c0 8d ............

Is there another GCHQ Code Challenge?

Update: The answer is Yes, sort of . Last week GCHQ issued a 'code challenge' as a way of attracting candidates via a web site called Can You Crack It? . I did the challenge, which actually consists of three parts and has more to do with assembly language and reverse engineering skills than cryptography (in fact, the only time you come across a cryptographic function, you can completely ignore it). The cat is completely out of the bag now because some spoilsport published complete details on the web showing how to break it, but I think there may be one more mystery worth investigating. Part 2 of the challenge involves writing a virtual machine that executes some code to decrypt an in memory buffer containing an HTTP command. Here's a dump of the memory of the virtual machine after execution: 0000: 31 04 33 aa 40 02 80 03 52 00 72 01 73 01 b2 50 1 . 3 . @ . . . R . r . s . . P 0010: 30 14 c0 01 80 00 10 10 00 00 00 00 00 00 00 00 0 . . . . . . . ........ 002

Downton Abbey Series 1 Episode 1 Morse Code

The very beginning of Downton Abbey 's first ever episode begins with a close up of a Morse code key being used to send a telegram that will announce the critical news of two deaths. If you're like me you instantly wondered what was being keyed. Here's what I hear: dah T dah dah dah O di dah di dit L dah dah dah O di dah dit R dah di dah dit C dah dah dit G di dah dit? R So, it appears that the message begins: "TO LORC GR". I assume that is meant to be "TO LORD GRANTHAM" and that the C is actually D and has been incorrectly transcribed. Here's the audio as an MP3: Downton Abbey Series 1 Episode 1 Morse Code (first part) . Then over loud music it continues: dah dit N dah dah dit G dit E di dah dit R di dah di dit L di dit I di di dit S dah T di dah

A nice bottle of Lorem Ipsum 2009

Going out to lunch with friends, having a nice bottle of wine in a gastropub. Good way to spend the weekend. Then you decide the wine was really nice and you'd take a quick photograph of the label so you don't forget it. And then you notice the text on the bottle of Domaine Tissier Sancerre Rouge 2009. Yes, it's Lorem Ipsum filler text! Interestingly it's the version that's popular in English speaking countries and not in France. I called the vineyard in France who were only able to tell me that the bottle of wine was genuine, that there's very little of the 2009 red left, and that it's only available in the UK to the restaurant trade. So, if you want to get a bottle as a souvenir or Christmas present for the designer in your family you'll have to persuade a restaurant to part with the bottle.

The Lack of Affordance Problem

Yesterday, I complained about the lack of an eject button on an Apple USB DVD drive . That design philosophy problem goes much deeper than just a single drive. It pervades Apple products, and, although I love them, it drives me spare! If I could say one thing to Jonny Ive it would be: "In designing to make the every day use of Apple's products a wonderful experience you're missing the moment when your users need you most. It's when everything goes wrong that the user needs the maximum help. It's in those moments (of despair) that a well designed product will surprise and delight the user." The DVD drive is an example of the opposite. When it's working it's lovely to look at, but when it goes wrong it's as enigmatic as the 2001 monolith . The mystical incantations necessary to remove the DVD from the drive (such as the hold down the mouse button while rebooting your machine) have to be passed on from the Apple elders in secret whispers (o

How to forcibly eject a CD/DVD from a MacBook Air USB SuperDrive

So you've got a DVD stuck in the external USB SuperDrive that connects to the MacBook Air? And you've tried hitting the magic Eject button on the keyboard to no avail? And you've tried drutil tray eject at the command-line? And you've tried booting with Option held down and clicking eject? And you've tried plugging the drive into other machines (Macs, Windows PCs, Linux machines) to no avail? What do you do? Clearly you hit the physical eject button, right? Every DVD drive has one of those. On the SuperDrive you first look for it on the front: Hmm. Nothing there. Perhaps it's one of those pinhole things on the back. Or on one side: Or, heart in hand, the other side: I know, I know. Jonny Ive hid it on the bottom out of sight, right? It's so obvious now. Put a pinhole on the bottom where it will only be seen when needed. Form and functionality in one. Sleek lines when in use. An accessible emergency button when needed. Genius. Nope.

Back from the dead with a power supply repair: my BBC Micro Model B

A couple of weeks ago I plugged in my BBC Micro Model B and it went up in a plume of smoke . Unfortunately, the 30 year old machine had undergone one of the most common failures. A capacitor that had been sitting there all these years failed, burst open, emitted smoke and leaked all over the circuit board. Today, I repaired the damage. This blog post is for anyone who faces the same thing. To fix the damage I replaced three capacitors that are likely to die over time (including the one that had burst) using a kit costing £2.70 from this site and a copy of the BBC Microcomputer Service Manual . The kit has one electrolytic capacitor (which is polarized and has to be inserted the right way round) and two ordinary capacitors which can be inserted in any way. The three capacitors to be changed are marked C1, C2 and C9 on the circuit board. On my machine it was C2 that had failed. The first step is to remove the power supply from its case. This is carefully described in the

Turning GE Color Effects G-35 Christmas Lights into a 7x7 display with Arduino

Some time ago I saw some GE Color Effects G-35 Christmas lights and was fascinated by the combination of color patterns that they were capable of and the fact that they only had three wires. That meant that something digital was going on. Happily, a chap called Robert Quattlebaum did the hard work last year of hacking these lights to reveal that they are linked by a simple self-clocked serial protocol that can easily be driven by a microcontroller. That blog post gives the full details of the protocol. Each lamp can be set to a specific brightness and an RGB color (4 bits per color). And the protocol is clocked at 30┬Ás per bit so it's possible to refresh the entire 50 LED string at a rate of 24Hz. Perfect for hacking fun. So I got a set and plugged them in just once (still in their packaging) to check that they worked. Here's a video of the lights getting their one real work out before the soldering iron got to them. The first thing I did was remove the lovely

My BBC Micro Model B and a plume of acrid smoke

So, after yesterday's post about The Demon Machine I decided it would be fun to play around with the BBC Micro Model B and so I plugged it in and powered up. The familiar two-tone boot sound played and the machine was on. About 15 minutes after power up there was a fizzing, popping sound from the computer and I ran to cut the power. Too late! A plume of blue/grey acrid smoke poured out of the left hand side of the machine right by the power supply. I cut the power and moved the machine away from anything that might burn quickly and waited for the smoke to stop. It quickly dispersed and so I did the only thing a self respecting software engineer would do... I decided to turn it back on again. But not without opening the power supply so I could take a look inside while it was running. Here's the PSU open after the fire: Warning. I don't recommend that you do this sort of thing yourself. There are high voltages there, plus a bunch of electrolytic capacitors tha