Categories
Programming

A Brief Rhapsody on Art and Engineering

From microship.com: “It is essential, when designing a complex system, to spend some relaxed time fantasizing about what it will be like when it’s finished. After all, this is what drives the process of engineering: at some level between rigorous and fanciful, an image of the finished product must be held in the mind, savored, and examined from all sides. Only after this playful interlude (which, to a manager, may be disturbingly indistinguishable from unproductive wall-staring) can decomposition of the design into subsystems, tasks, and packaging make any sense.”

Categories
Programming

Powerswitching with IP

Power supplies which can be controlled via IP seem like a pretty sound idea for sysadmins who don’t want to get called out at 2am to reboot a server.

They’re pretty expensive though, which made me realise that they’re an ideal application for the uCsimm “linux on a tiny low power board”. The boards come pre-installed with Linux, and has builtin ethernet and 18 i/o lines. Add a few relays, install a secure webserver and, hey-presto, homebrew remote power control.

Categories
Programming

Harmonia

The Harmonia Project releases some code and the world blinks a bit.

I also stumbled over videos from the 2001 Dynamic Languages Wizards Series, including a panel on language design with Guy Steele and Paul Graham.

Categories
Blogging

Degree Confluence

The Degree Confluence Project collects photos and stories from each longitude/latitude intersection in the world. It is pointless but beautiful, like many of the best things in the world. This is the closest confluence to me. It’s in the middle of the water!

Edinburgh is warm and sunny. Fortunately, there are lots of parks nearby to laze around in. If the weather was like this all year round, I don’t think I’d do anything else. I was talking recently to a group of children who asked what I did for a job. I didn’t think they’d be interested in my usual “3d graphics for brain scanners” spiel, so I went for “I work in an office”. That was enough information to keep them happy, but I later realised how crushingly accurate it is. Why such madness! I remember, when I was young, wondering exactly what people did in offices all day. I think I decided it involved moving lots of bits of paper around. I could never figure out what “commuting” was either, except that it took a long time.

I have been learning the dvorak keyboard layout. I’m learning it for ergonomic reasons rather than speed. Several people I know have suffered from RSI and I don’t want to join them. I’m now trundling along at 15wpm, which is humbling compared to the 80wpm I can manage with qwerty. I can practically feel my synapses rewiring themselves. It’s every bit as painful as when I switched from “inverted mouse” to “normal” in Quake3.

A paper on High Dynamic Range images and other cool stuff got me interested in optics again. I must’ve slept through optics courses at Uni, because I never really got a handle on it at the time. I should’ve heeded my optician’s warning from years before – “don’t do optics!”. Anyhow, now that I have a digital camera I was sufficiently motivated to draw lots of diagrams and figure out stuff like “why does the apeture affect depth of field”. I feel enlightened now. Optics became easy once I started anthropomorphising photons. And, for some presumably unconnected reasons, the bees in my garden are acting very stoned and are staying still long enough for me to take decent photos of them.

I’ve also been flirting with designing a simple CPU. I understand low-level stuff like gates, flip-flops and timing diagrams. I also understand high-level stuff like ALUs, pipelining and machine code. I was curious to see if I could join those two worlds together to design my own simple CPU. I’m happy just to simulate it (this is what happens when I actually try to build stuff) and TkGate is the most useful tool which I’ve came across for that. Soon, I will have my own 4-bit CPU doing pointless arithmetic operations. Ahh, maybe I should just build a time machine and go back to 1980 again.

Categories
General

When I’m 64

I’ve been taking lots of digital photographs recently, and I recently worried whether I’d still be able to view them in thirty or so years. I have several old documents in Pagemaker 4 format which I know I’ll never be able to read again. So, will this happen with my photos? Are my jpegs future-proofed?

I’m not worried about the physical media becoming obselete. Our abililty to store data has constantly increased. Every bit of data I have is kept on my harddrive. When I change machine then I copy it wholesale onto the new machine. I never “archive off” old material onto tape/CD/DVD to free up space, because my hard drive is always larger than my storage needs. I’m fairly confident that in 30 years time, I will still be able to access the raw sequence of bits which make up each photograph.

Will I be able to view these bits as photographs though? In the year 2033, I could probably emulate today’s hardware/software and still run exactly the same utility to view my photos. It’s a bit of a heavyweight solution though. I don’t really want to snapshot the current version of the linux kernel, XFree86, Gnome and GThumb just so I can view photos sometime in the future.

It seems more sensible to stash away a description of the jpeg file format – that way, even if noone else wants to view jpegs, I can still code up a viewer because I know what the sequence of bits means.

But how should I do that? Storing the source code of a C++ or Java JPEG viewer isn’t going to be much use, because In The Future it’ll be pretty hard to figure what the semantics of C++ or Java were in the year 2003. I’d have to stash away a copy of the Java Language Spec too, otherwise I’d just be left with a pile of meaningless squiggly brackets. We learned that when people had to tackle a myriad of COBOL dialects for Y2K problems.

Is there any “timeless” programming language which I could use? Something which I’ll still know the semantics for in 30 years? Hmm, I guess you could express a JPEG decoder using the lambda calculus, but that’s a bit extreme. The semantics of the lambda calculus will still be understood in 30 years, but you’d have a hard time figuring out what a large “lambda calculus JPEG decoder” actually did.

I think, if I’m going to stash away a description of the JPEG algorithm, it’s probably going to be a good old fashioned english-language description. That’s probably good enough for 30 years. I don’t think the semantics of the English language and mathematical notation are going to change much in that time. It’s not perfect – just look at the ambiguities which most “english language” specifications contain. But, the language .. the medium in which the description is expressed .. is probably stable for a good few decades. Maybe this Haskell paper is a good alternative to the published standards document.

I wish the story ended at this point. But it doesn’t! How should I store the description of the algorithm? I don’t expect I’ll be able to read PDF documents in the year 2033. Their semantics are way complex, more so than the JPEG format. You’d have to record the semantics of Truetype fonts, or whatever, in order to display them in the future. Postscript is no better. The Postscript reference manual which gives an english-language description of the format/language is over an inch thick.

ASCII or UTF-8 is going to be a good bet. I think we’ll still be able to read that in the future. I probably want to include some mathematical formulae, so maybe I need some mathematical markup too. It begins to sound like XML.

So that’s the next 30 years sorted out. What I wanted my data to last for 3000 years? Can you store information which transcends changes in language, notation and cultures?