As mentioned in my last blog post the GuruPlug Server Plus needs some major refactoring before it can be used. Not doing so will make you end up with a fried brick. There are various stories in the forums about cooling it properly, so you might want to have a look first instead of following mine blindly. And of course - whatever you do - it is your fault when you end up with a brick, not mine!.

Replacing the power supply As I would never ever trust the PSU (see my last blog post for the gory details) and some additional free space in the case is necessary, it is time to rip it out. As replacement I've ordered an external 5V/20W PSU. To connect it to the plug I've drilled a hole into the case and added a proper connector after soldering the original cable from the old PSU to it. Make sure to add some retainer to stop the cable from touching the CPU/memory heat sinks later.

Proper heatsinks One of the biggest problems in the original GuruPlug design is the heat spreading and collecting piece of alloy, which probably makes things even worse than better. After some discussion in #debian-devel the idea came up, that the board should be able to run fine without a heatsink - at least when idling. That is the case, indeed. So let's get rid of that piece of alloy, together with the holders and springs. Unfortunately heat things are necessary to handle some work load. To mount them make sure you get some good thermal glue as you don't want to insulate the chips from their heat sinks. I've used Arctic Silver II thermal glue - not cheap, but working well. Make sure to clean the heat sinks and chips properly with alcohol (2-Propanol is my favourite for that), so there is no fat and dust left. When you use the glue be careful to read the documentation properly and make sure you apply only as much as necessary - a thin coating is enough. After applying the glue and mounting the heat sink you need a clamp to put some pressure on it while the glue dries.

Heat sinks for the memory As there is a lot of space around the memory chips, I've got some 14x14x6mm heat sinks. Luckily there are only small parts on the other side of the board, so it was not hard to attach clamps to ensure the glue is able to dry properly. In case largish amounts of glue are squeezing out between heat sink and chip you probably want to start from scratch and clean everything (quickly!) with alcohol again.

Gigabit Ethernet PHY and CPU heatsinks PHY and CPU need proper heatsinks as they're becoming pretty hot under load. Due to space limitations I had to stick with a 17x17x20mm heat sink for the PHY. I've tried to get a largish heat sink with BGA mount for the CPU, but I was not able to find one in short time and without ordering 1000 of them. So I've got another one of the 17x17x20mm model for the CPU. Later I found two other heat sinks which might fit on the GuruPlug's CPU: Malico 19x19x25mm or a Advanced Thermal Solutions Maxigrip. But for now the smaller one will have to do the job, also I'm scared to removed it without destroying the CPU. To mount the heat sink on the PHY a bit of preparation is necessary to ensure that the glue doesn't result in short cuts on the IC's pins. The arctic silver documentation recommends to use silicone on the pins to stop the glue. As I neither had the proper silicone nor did I want to make such a mess, I've decided to get a sticky insulating tape and some tooth picks to mount it properly on the IC pins. Make sure to do a proper job here! With good clamps you can work on the PHY while the memory heat sink glue is still drying. The other problem on this side of the board is that some higher parts are mounted on the lower side of the board, so make sure to get some foam to protect them from your clamps. Except of the size of the heat sinks there is no real difference to the small ones: add glue, mount the heat sink and fix it with a clamp. Before the glue dries completely make sure you remove the duct tape strips again. Be careful not to wipe any excess glue onto the IC pins. If you manage to do so you might want to remove and clean everything properly. So just be careful and everything should be fine. Mounting the heat sink on the CPU is easier as the CPU is a nice BGA package. No need to protect pins an there are none.

Finished As you're able to see on the photo I did not the very perfect job, but fine enough to work properly.

First tests with the new heatsinks Some tests with stress and some heavy network traffic showed quickly that the heat sinks are working well! But not well enough to be able to mount them into the original closed case (how the hell was this supposed to work before!?). Without any air to breath the temperature on the CPU heat sink went up to 85 deg C quickly. So on the CPU's die are > 100 deg C, which is at least close to the max allowed temperature.

Adding air holes Obviously some additional air holes are necessary. After meeting my drill and cutter, the original case looks a bit like a piece of cheese now. Some more tests show that the temperature sticks around 76 deg C under heavy load now. That is still pretty hot, especially when the temperature in the room becomes hotter in summer. As I'm not going to run a lot of traffic trough it (my cable connection is limited to 20 MBit/s anyway), I guess it will work. Below is a graph I've recorded with my multimeter and qtdmm. It shows that the temperature rises to ~76 deg C and stays there. Not sure if I could introuce some more load, the CPU had a load of 6 running stress. Network traffic was around 2x100MBit/s again. I could imagine with 2xGBit the CPU and PHY would become much hotter (no idea if it would be able to handle it at all, though). The PHY was usually a bit cooler than the CPU, so I didn't spend time to measure the temperature properly.

Conclusion My opinion is still the the original design of the plug is an insane QA and design failure. There is no way that it could ever work as shipped originally. If I'd have to design a new case for it, it should have a single insulated compartment for a PSU to ensure that no contact with high voltage is possible. The case around all other parts should be made of alloy with a lot of air holes. So the case could be used as heat sink (properly done, not with these insulating duct tape strips) and at the same time allow air circulation and a nice view on the LEDs on the board. Of course the case would be much more expensive than, but I'm sure it would work properly and would be worth the money. And if done peoperly, it would look much better than this blinking plastic thing. I could imagine it would sell well! So at the end I'm wondering what GlobalScale Technologies will do. I doubt it will be possible to create the 'professional upgrade kit' as they had announced before. Replacing all units is the only proper way. We'll see what happens. At least my GuruPlug is working well now and it will be used as replacement for my OpenWRT router soon. WiFi is not working, but that will be handled by my media center anyway.

omlet (or here) is a vim extension for writing OCaml code. In my opinion, it has a better indentation than the standard OCaml vim support. Unfortunately, it has a cost: the indentation vim code is more complex. And it has a few bugs :-( The main bug is that it doesn't like unbalanced comment opening "(*" and closing "*)" tags. From time to time, it enters an infinite (or very long) loop when there such a tag left in your file. It can be very far away from the point you are editing. It isn't too problematic, because unbalanced tags are a syntax error. But the problem is that it matches these tags inside strings also. So whenever you start using regular expression like "(.*)" the whole indentation fails. But there is a very ugly solution to this problem! Problematic code:

 let parse_rgxp =
   Pcre.regexp ~flags:[ CASELESS] 
     "^(?<license>[A-Z0-9\\-]*[A-Z0-9]+)\
      (?<version>-[0-9\\.]+)?(?<later>\\+)?\
      ( *with *(?<exception>.*) *exception)?$"

Solution, add ignore"(*":

 let parse_rgxp =
   ignore "(*";
   Pcre.regexp ~flags:[ CASELESS] 
     "^(?<license>[A-Z0-9\\-]*[A-Z0-9]+)\
      (?<version>-[0-9\\.]+)?(?<later>\\+)?\
      ( *with *(?<exception>.*) *exception)?$"

Very very ugly coder: you balance comment tags in dead code -- very very bad ;-) ps: another solution when the plugin enters the infinite loop, hit Ctrl-C. This will stop it and let you define your own indentation.

AltOS The Altus Metrum Operating System Altos is the core of the software for all of the Altus Metrum products. It runs on the 8051-based micro-controllers within both the flight computer and the ground station devices. AltOS a small cooperatively multi-tasking operating system. AltOS Version 0.7.1 Released Bdale and I have just released AltOS version 0.7.1. Version 0.7.1 is the first release to include the new Java-based ground station software which runs on Linux, Mac OS X and various Windows flavors. AltOS Changes in 0.7.1

1. Deal with Windows and Mac OSX USB stacks. These two operating systems do interesting things with USB and found some boundary conditions within the AltOS USB stack which couldn t be tested on Linux. With test cases discovered, the panic calls were turned into code that dealt with these cases correctly.
2. Increase packet mode payload size and add callsigns. The callsigns are set by the master end of the packet link (normally the TeleDongle) so that the entire radio conversation conforms to regulatory requirements. Increasing the payload size makes data transfers go faster.
3. Place configuration data in fixed flash addresses. This change makes it possible to read the serial number and radio calibration data back out of the flash data when reprogramming a device.

TeleMetrum Changes in 0.7.1

1. Ensure GPS date information is written to on-board data logger. The GPS date information is used when constructing eeprom log file names; without this, the eeprom downloading tool would generate a filename based on the current date.
2. Allow TeleMetrum to be used as a programming dongle. This means the user can reprogram a TeleDongle or another TeleMetrum using the TeleMetrum as a programming dongle. Before this, only the TeleDongle could be used to program other devices.

AltosUI - Ground Station Software for Altus Metrum devices Version 0.7.1 is the first release containing our new cross-platform Java-based user interface. AltosUI can:

• Receive and log telemetry from a connected TeleDongle device. All data received is saved to log files named with the current date and the connected rocket serial and flight numbers. There is no mode in which telemetry data will not be saved.
• Download logged data from TeleMetrum devices, either through a direct USB connection or over the air through a TeleDongle device.
• Configure a TeleMetrum device, setting the radio channel, callsign, apogee delay and main deploy height. This can be done through either a USB connection or over a radio link via a TeleDongle device.
• Replay a flight in real-time. This takes a saved telemetry log or eeprom download and replays it through the user interface so you can relive your favorite rocket flights.
• Reprogram Altus Metrum devices. Using an Altus Metrum device connected via USB, another Altus Metrum device can be reprogrammed using the supplied programming cable between the two devices.
• Export Flight data to a comma-separated-values file. This takes either telemetry or on-board flight data and generates data suitable for use in external applications. All data is exported using standard units so that no device-specific knowledge is needed to handle the data.
• Speak to you during the flight. Instead of spending the flight hunched over your laptop looking at the screen, enjoy the view while the computer tells you what s going on up there. During ascent, you hear the current flight state and altitude information. During descent, you get azimuth, elevation and range information to try and help you find your rocket in the air. Once on the ground, the direction and distance are reported.

Three Operating Systems, One AltosUI AltosUI provides all of these features on the three target operating systems, Linux, Mac OS X (version 10.5 or newer) and Windows (XP, Vista or 7). The bulk of the software is written in Java and is built once and tested and delivered on all three target platforms. A tiny shim library is built on each system to provide access to the Altus Metrum devices connected over the USB link. Thanks to our contributors! We ve gotten lots of help getting this software built and tested:

• Tim Van Milligan at Apogee Components helped shake out portability and installation issues on Mac OS X and Windows Vista
• Adrian Adamson from Featherweight Altimeters helped with Windows install adventures as well as fixing data export from telemetry files after unfortunately losing eeprom data in a field in Kansas.
• Bob Finch has written a bunch of our documentation, provided packaging files for Arch Linux along with helping debug general Linux compatibility issues.

Future Plans With the basic AltOS and AltosUI functionality running, we ve got lots of ideas about where to take the system in the future. And, we d love to hear ideas from you as well. Some of the ideas we ve like to get done include:

1. Google Earth file export. We had a Linux-based C program to export a KML (Keyhole Markup Language) file that Google Earth can read and present to the user overlayed on satellite photo data.
2. Data Plotting. Being able to plot flight data right in the UI would be nice, and there are several Java plotting packages available to try out.
3. State-dependent display. When the rocket is on the pad, you only want to know if it s ready to fly. When the rocket is descending on a chute, you want to know where it is in the sky and how fast its falling. Presenting a limited amount of information that is most likely interesting to the user should make the display more useful.
4. Ejection charge testing. The TeleMetrum firmware has the ability to fire ejection charges over the USB or radio links. Safely hooking this up to the user interface will allow for wireless ejection system testing. The key here is safely , of course, which means figuring out a fool proof user interface.

I m sure there are any number of additions that could be made to this list; feel free to send along ideas that you ve got. Of course, all of this software is licensed under the GNU General Public License, so you can get the source and hack on it in the comfort of your own home.

(Disclaimer: Possibly one of my longest post ever, you may want to scroll to the bottom and only look at the pictures.) So, what s new in SD since last week? Fetching everything From http://bugs.freedesktop.org/, it was possible to download all the bugs I reported there (that means 2 ), but trying to download those reported by Julien led to a crash without any trace. Dichotomy FTW, I came up with a bunch of bugs which would lead to the same result, which confirmed that the amount of bugs processed at once wasn t the issue. Playing around with strace, it appeared that exchanges with the remote server were apparently fine, so an issue on the client-side SOAP machinery got suspected. So let s enable tracing:

use SOAP::Lite +trace => 'all';

Tada! The issue was indeed local: malformed XML got received, leading to a die call issued from the XML-RPC layer. Thankfully, one can set up a fault handler, which I used to display the range of bug IDs which triggered that bug, so that people can look into it and determine what to add to the blacklist until the underlying issue s been investigated (presumably, bugzilla s at fault). Speeding things up With that blacklisting of buggy bugs, one can then try to move to other queries, dealing with more bugs. Some examples follow:

reporter=kibi@d.o
product=xorg&component=Driver/VMWare
product=xorg&component=Driver/nouveau
product=xorg&component=Server/general
product=xorg&component=Driver/intel

Moving from 2 bugs to 10-100 bugs (Julien s or VMWare s) was OK. But then moving to several hundreds of bugs (Driver/nouveau = 500+ bugs) led to noticeable performance issues. Not to mention what happened when one reaches several thousands of bugs (Driver/intel = 2500+ bugs). Indeed, even with network exchanges cached into a local file, processing data was taking up to several dozens of minutes. I knew about Perl s -d:DProf, which helps figuring out where time is spent, but was pointed to -d:NYTProf (and its accompanying tool, nytprofhtml). Some hotspots got noticed:

• There s a huge pile of stuff relying on UUIDs heavily, and a cache is going to be introduced to avoid later calls once a value s been computed once. That s going to benefit all replica types, not just bugzilla.
• I didn t care much about date/time at the beginning, but that turned out to be a very bad idea: since the format returned by bugzilla wasn t matching a well-known format, time was spent in the DateTime::Format::Natural fallback, leading to a big performance penalty. Fixed with a trivial regular expression.

Things got better, but not good enough. There are several Prophet (the engine under the hood) backends, so one can play with:

PROPHET_REPLICA_TYPE=sqlite   # the default for SD
PROPHET_REPLICA_TYPE=prophet

Switching to prophet was a big win, but still not good enough. Indeed, many tiny files are written, and most of the time is spent in I/O. Although I m nothing like a performance guru, I guessed that running on an average laptop, with ext3 and its default commit interval of 5 seconds might not be helping, so I gave a quick try to -o remount,commit=60, and that seemed to help. Even though there are probably other tricks to find in that area (which hopefully won t require root privileges ), there s already a patch which landed in prophet s master branch, replacing File::Spec->catfile with an optimized version: that function alone was eating 10% of runtime In the sqlite case, disabling the auto-commit feature helped reducing the I/O load, but a proper patch is still lacking for now (running into locked database issues, or into missing tables after having created them isn t fun, so I postponed debugging that). Since performance issues looked like they could be solved eventually, I switched back to implementing missing features. Handling more than comments Currently 3 types of stuff are currently fetched from the bugzilla server:

• Bug status: plenty of properties.
• Bug comments: comments that are linked to bugs.
• Bug history: changes that impacted bugs.

(Yes, that means that attachments are totally ignored for now.) Until now, only bug comments were considered. The first comment was used to determine a pseudo-title (using its first line), the reporter, and the creation date. This approach was chosen to try and get a basic sync working quickly, so as to get:

• A list of bugs matching the query.
• All comments for each of these bugs.

Now, the algorithm is the following: from the bug status, determine a set of properties of interest; then walk the history backwards, and update the properties incrementally until the (presumed) initial state is reached. Then create the ticket using this initial state . Adding the incremental property changes to that initial ticket makes it possible to represent the bug s life as a list of Prophet::ChangeSet objects. That s where the fun begins, since properties in the bug status may not match properties in the bug history, so one needs to establish property correspondence. Also, some properties can be multivalued for added fun. I believe that s where most of the time is going to be spent while developing a new replica type in SD: once one knows how to get a hand on needed info on the remote server, the main question is what to do with it. For now, I decided to ignore many fields to make it possible to do a big sync like Server/general, property support will be improved later on. Screenshots Instead of pasting lengthy terminal excerpt, let s use some screenshots instead (sorry, I m not sure how to present such things in an accessible way, suggestions welcome). Cloning Julien s bugs, listing all open tickets, listing all tickets, searching using a regular expression: Displaying bug 42 (that s the local ID): Now, let s start the embedded web server through sd server --port 1234 and point the browser there. List of RESOLVED bugs: Status and comments for bug 42: History for bug 42: Compared to the original bugzilla page: Next time Some items which need work:

• Tweak properties to address the issues raised above.
• Start fetching attachments as well.
• Support further syncs. Currently, a big sync is done once, and there s no way to tell sd to sync new changes since last time, if any. This will probably lead to rewriting how fetching is currently done, which is: discover all bugs, then fetch all comments and all history items, for all of them. Properties like last_change_time will probably be of some help here.
• Have a look at what happens with other bugzilla instances, like Gnome s.

Backlight control is one of those things that you'd think would be simple, but ha ha this is computing so of course it's an utter disaster and everything is a huge mess. There's three main classes of backlight control in the x86 world, all of which have drawbacks:

• ACPI specifies a mechanism for backlight control, and the majority of modern machines implement it. It has the advantage that the brightness query interface is generally aware of anything else in the system which may have changed the brightness, so it's unlikely to get out of sync with reality if the platform tries to do something odd like change the backlight itself in response to an ambient light sensor or some other event. The main drawback is that there's typically a fairly small number of available backlight values, usually somewhere between 8 and 20.
• A platform-specific mechanism. This used to be more popular before the ACPI backlight interface took off, but some machines still require it. The idea here is that there's some sort of platform-specific way of requesting a backlight change, ranging from a vendor-specific ACPI method through to triggering system management calls by magic register writes. These methods usually (but not always) keep in sync with other firmware changes, but rarely provide any more brightness steps than the standard ACPI interface.
• Many mobile GPUs have backlight control registers built in. These usually give you a range of several thousand possible values, but using them will almost certainly leave you out of sync with reality if the firmware touches them at all. To make things worse, the firmware control of the backlight may occur after the gpu - so you could end up with two different controls that both need to be full in order to get maximum brightness. The worst case scenario is that the firmware gets confused by the values not being what it programmed and you end up with a hung machine.

Right now, if there's an ACPI backlight interface then that's usually the only thing we'll show you. We can do that because we can identify if there's an ACPI backlight interface when we parse the ACPI tables at the start of booting, and that information can be registered before we start setting up any other backlights. The problem comes when we have no ACPI backlight interface. We don't have any idea whether there's a platform mechanism until a platform driver loads, which could be at any time. As a result, we've been reluctant to expose GPU-level backlight control because doing so would often give you two separate backlight controls and no indication as to which should be used. Userspace doesn't really have a way to make that decision either, so everyone ends up unhappy.

This is especially problematic with some machines which provide no ACPI or known platform control (or, in the case of some Samsungs, only provide platform control if you have a special Linux BIOS that Samsung won't give you) but can control the backlight via the gpu. Right now you get nothing, because giving you something would potentially break other systems and the needs of the many etc. Sorry! But this is obviously problematic in the long term, especially because multi-GPU machines tend to have multiple ACPI backlight interfaces, so I've been working on a better approach.

When a backlight device is registered, it appears under /sys/class/backlight. If it's an ACPI device it has a symlink pointing to some random ACPI device. If it's a platform device it's pointing at something like "dell-laptop" which is approximately unhelpful when it comes to figuring out what it controls. If it's a GPU-level device then it probably points at the PCI device, which is helpful except in the case where you have multiple backlight controls on a single GPU. So, by and large, you have no good way to identify which backlight control is preferable unless you keep a huge list of all possible backlights along with some scoring.

The first thing I've added to improve this is a "type" attribute. This tells you whether a given backlight is firmware-level (like ACPI), platform-level (like the various laptop drivers) or performs raw register writes (like a GPU driver). That lets userspace decide which interface is preferable. It'll typically be the ACPI interface, because that's the most likely to keep synchronisation and so avoid bizarre brightness bugs. The next thing has been to start fixing up the parent links. There's nothing we can do for the platform level devices, but the ACPI drivers could at least point at PCI devices rather than into ACPI space. That means that multi-GPU systems can now identify which interface to use based on the currently active GPU. Finally, I've started pointing the GPU-level backlight controls at the specific output rather than merely at the PCI device. This probably makes little difference for laptops as such, but once we start exposing backlight control for monitors that support ddcci it'll make things much easier as we'll know which backlight control corresponds to which monitor.

I've then written a small library that accepts information about the output and picks the "best" backlight for the device. It's obviously based on a pile of heuristics and there's a couple of bits of API that I suspect need to be nailed down yet, but it means that this code only needs to be written once. It's then simple to glue this into X drivers, which means that they can expose a "Backlight" xrandr property on each relevant display. That means that backlight control is then handled at the session level with the X server acting as the privileged agent, which simplifies a bunch of things and means we can finally let hal die entirely. Long-term this means we'll have unified backlight control for all of your displays, which is a wonderful thing.

Summary: We kind of suck right now, but there's a reasonably clear path to getting better.

Christoph, belier really looks like a hack. It s easy to use ProxyCommand to connect to hosts using several hops. Let s say that you want to connect to host c, which can only be reached from host b, which can only be reached from host a. It s as simple as doing:

Host a
    User logina
Host b
    ProxyCommand ssh a nc -q 1 b 22
    User loginb
Host c
    ProxyCommand ssh b nc -q 1 b 22
    User loginc

And of course, it just works with scp, rsync, and everything ssh-based. It cannot auto-login using passwords, but I m not sure that having passwords in clear text is a good idea either;)

Sometimes remote accounts are only reachable with a series of ssh/su/sudo commands. Using ProxyCommands in .ssh/config works for simple cases, but not with several hops, or if passwords have to be entered. The belier tool takes as input a series of user@hostname strings and will produce an expect script that does the actual login work.

$ cat input
user@host1 root pw1
user2@host2 pw2
$ bel -e input
$ cat host2.sh
#!/usr/bin/expect -f
set timeout 10
spawn ssh -o NoHostAuthenticationForLocalhost=yes -o StrictHostKeyChecking=no  user@host1
expect -re  "(% # \\$) $"
send -- "su - root\r"
expect ":"
send -- "pw1\r"
expect -re  "(% # \\$) $"
send -- "ssh -o NoHostAuthenticationForLocalhost=yes -o StrictHostKeyChecking=no  user2@host2\r"
expect -re  @[^\n]*: 
send -- "pw2\r"
expect -re  "(% # \\$) $"
interact +++ return

The generated host2.sh script uses ugly ssh options, but is easily edited. Now I need the same thing for scp... Update: Carl Chenet, belier's author, kindly pointed me to the documentation which has examples how belier can set up ssh tunnels to copy files.

The last few months have been busier than I expected, resulting in various failures to get stuff done. The good news is that things are a little more relaxed now and I'm gradually catching up, but if you've emailed me and I haven't replied then you should probably do so again.

A couple of updates - the source code for the Augen Android tablets I wrote about still hasn't been released, but the vendor does seem to be doing their best. Their supplier seems to be refusing to hand over the source code (they were given a tarball that was supposed to be it, but in fact just turned out to be the various GPLed bits of Android) and they're obviously stuck between a rock and a hard place. The obvious observation is that they should have done due diligence before starting to ship these things, but given that they're out in the wild and they're trying to improve things it seems reasonable to carry on working to try to obtain the source rather than insisting that kmart stop selling them.

Fusion Garage, on the other hand, are still failing to provide source and seem entirely unconcerned about it - they've failed to respond to any of my emails since the first. Augen aren't providing source because they can't, while Fusion Garage aren't providing source because they won't. Irked by this, I've decided to try Don Marti's suggestion and file a case with US Customs. I'll admit that I have absolutely no idea how seriously these cases get taken, and so I've no great expectation of any sort of interesting outcome. But even so, if you're in the US and try to buy a Joojoo then there's a chance that it'll be seized by US customs on the way in.

Another week, another Emacs extension! I had (once again) a wonderful idea: what if I could have the weather forecasts in my Org agenda? Wouldn't that be wonderful? My quest started by looking for a service offering a good weather forecast API. I found nothing simple as the hidden Google Weather API, which is nice, but not documented. Not at all. Not a single line. Nah. Then, I wrote a google-weather extension, implementing a basic Emacs Lisp API to retrieve data from the Google service:

ELISP> (google-weather-data->forecast (google-weather-get-data "Paris"))
(((9 8 2010)
  (low "53")
  (high "63")
  (icon "http://www.google.com/ig/images/weather/rain.gif")
  (condition "Rain"))
 ((9 9 2010)
  (low "53")
  (high "69")
  (icon "http://www.google.com/ig/images/weather/chance_of_rain.gif")
  (condition "Scattered Showers"))
 ((9 10 2010)
  (low "54")
  (high "72")
  (icon "http://www.google.com/ig/images/weather/partly_cloudy.gif")
  (condition "Partly Cloudy"))
 ((9 11 2010)
  (low "55")
  (high "75")
  (icon "http://www.google.com/ig/images/weather/partly_cloudy.gif")
  (condition "Partly Cloudy")))

My API even implements data caching, which is nice to speed up the agenda display. By the way, I think my next job will be to hack on the url-cache feature of Emacs, which is utterly buggy and has probably never be used. But that's another topic. Finally, I just had to write another module on top of that to export the forecasts to Org. A screen shot is probably better than a long and boring explanation, so here's the result. My only regret is that the icons provided by Google are ugly squares, so I did not want to use them. On the other hand, I did not found any icon set that would have all the icons Google provides (around 20). So I felt back on the icon naming specification to map the Google images to standard images. Any better idea would be welcome, of course. All the information can be found on the Google Weather for Emacs extension homepage.

... or, 'yellow pages.be'. Or something. I like it that there is an on-line version of the Belgian yellow pages. Who wants to look up a phone number in a huge book, anyway? And that's ignoring the fact that it isn't any good for the environment. I also like it that the yellow pages are now no longer distributed by default on paper. You can still get them, if you so wish, but you have to explicitly request them. Of course, searching an on-line database is also faster than flipping through pages until you find what you're looking for. What's more, you can limit your search to your location rather than whatever shops just happen to be in the version of the book that is distributed to your house. That makes it much more efficient, since rather than all thousands of computer shops in the whole province, you'll find the computer shops in your municipality. Or the ones that are in a radius around your address, if you choose that option. Rather, that would be the case. But for some unfathomable¹ reason, truvo, the company behind the yellow pages, decided to make the option that gets you the names and numbers of companies that serve your region, rather than companies that actually are in your region, as the default. And since there's really n o limit to what companies can enter as the 'region' they serve, you suddenly get a name for a shop hundreds of kilometers away when all you wanted was to find the closest grocery store. D'oh. 1 Yes, yes, I can guess that money has something to do with it. But whatever, that don't matter.

It was back in July that I got my amateur radio license, and I haven t written much about it since. It s about time I do. I ve been really enjoying it. I am now wishing I hadn t put off getting into it for so many years. It s a lot of fun and promises to be a lot of fun for a long time. Why? I am frequently asked, What can you do with amateur radio? Yes, you can talk to people all around the world, but of course you can do that with the Internet. Talking to people all around the world can be done with no infrastructure in between, so that s a pretty neat feature, but not compelling to everyone. I have realized that the question is poorly-framed. I had asked that question myself for a long time and only recently realized that I was asking the wrong question. I think the better question would be, What makes amateur radio fun and a good way to spend your time? One thing I ve discovered is that the amateur radio community has an amazing sense of community. Hams, almost universally, seem to love helping out each other, whatever the task may be: setting up antennas, learning how to operate a radio, even fixing a flat tire. I ve seen this directly, and heard about it from others, time and time again. There s an excellent article out there by Nate Bargmann called Why I consider Amateur Radio an asset in my life that makes for good reading. There is a lot of fun in amateur radio. It was quite exciting the first time I talked to someone out of state, realizing that the piece of wire in my trees, and 100W of transmitter power, were all it took to get a message 700 miles away. And even more exciting when I talked to a person in Kazakhstan the same way. No satellites, no phone lines, no undersea cables just my antenna, his, and radio waves. Then there s the fun in talking to somewhat random people. It s not completely random, as I m only talking to people that have passed a test there are about a million of us in the USA. (And for the long-distance HF communication, a more rigorous exam is required, so the number is probably less than that.) But when I call CQ an invitation for anyone listening to reply I never know who will reply. I ve talked to a retired Canadian museum curator, a Mississippi farmer, a resident of Long Island, Russians participating in a contest, two Hawaiians participating in a different contest, and the list goes on. Some of these have been brief contacts lasting only seconds, while others have been conversations that stretch on towards an hour. I liken amateur radio to buying my first iPod. I had never owned a portable MP3 player. I had always figured, why bother? How often am I away from a computer or a CD player? But once I got one, I realized how nice it was. It was convenient to just store my entire library on there and not have to try to sync it across multiple devices. It was convenient to not have to carry CDs with me in the car, and to listen to music at places I hadn t tried to before. The same sort of thing applied to getting a Kindle, and to amateur radio. I didn t realize how much fun it would be until I tried. Some Memorable Moments Towards the end of showing you some things that have been exciting, here are a few memorable moments from my ham radio experience so far. Saturday night was one. I was tuning around listening to anybody to talk to. I heard some people calling CQ in heavy accents. I eventually realized that the All-Asia contest was going on, and figured out how to participate. I made my first voice-mode contact with people on a different continent and it was with Kazakhstan! Within a few minutes, I also talked with three stations in Russia. I had not expected that. I ve made contact with several stations in the Indianapolis area, where I used to live. It was particularly fun to talk to W9IMS, located at the Indianapolis Motor Speedway, which operates around race times only. Again I discovered that station simply by tuning around on the band. I took a 5W handheld radio with me to New York City during my trip there for Debconf. It was a lot of fun to talk to random New Yorkers while visiting, and they were all very interested in my impression of the city, what I ve done so far, and what they thought I ought to do. Some offered specific tips (such as which train from Manhattan to Brooklyn offers a good view while elevated). A local ham, W0BH, gave me some basic training on how to operate during amateur radio contests. During these contests, hams try to make contact with as many other hams in as many places as they can. I didn t think this sounded like a lot of fun. Until I tried it. It was indeed a lot of fun, and interesting being occasionally that rare Kansas station that a bunch of people are trying to talk to at once. One evening, we lost power. I tried calling the electric company, but there was no answer over there for some reason. We re out in the country, and there are no neighbors visible that can inform us whether it s a big problem that the power company probably knows about, or whether it s localized to us. So after wondering what to do for a minute, I thought I d get on the radio and ask. (We own a backup generator for these situations.) Almost right away I heard from a person driving in his pickup. He told me he saw a widespread outage, and heard on his police scanner about other towns that were down for the same reason. I wouldn t have known otherwise.

A few days ago I talked about how noisy my new Dell Studio 15 was but I can now report back with the beginnings of a solution to that problem, and it doesn't appear to be ACPI related. The first clue I needed was that if I switch to the proprietary fglrx drivers for the Radeon the fan quite quickly drops off to a much more reasonable level. It seems the fglrx drivers have issues, however, in particular I get big black patches on my screen. This video corruption happens especially in Firefox, but sometimes in other applications as well. They also appear to screw up my suspend/resume, which is probably even more annoying to me. The second clue that I needed was that Radeon power management support has only just made it into recent kernels. Thanks to Michael Kirkland for providing me with both of those clues :-) Looking under /sys/class/drm/ I find a whole bunch of stuff, but in particular there are /sys/class/drm/card0/device/power_method and /sys/class/drm/card0/device/power_profile. Looking through the kernel source code I can see that power_profile can be set to low, mid, high, auto and default, while power_method can be set to either dynpm or profile. Trying out all of these values, it seems I get the quietest result with the profile method and either the low or mid profile. The dynpm method is nearly as good, and I would think it should really be the default for a 'Mobility' chipset. From the detailed benchmarking that Phoronix did I wonder if it shouldn't be the default for everyone. For myself, I see some small 'tearing' artifacts occasionally when running with the low profile. These disappear when I run with the mid profile, and since that seems to have pretty much the same temperature (and noise) results I'll go with that one. Though the laptop often does still make more noise than I would prefer it to, it is no longer annoying everyone in the room. Not unexpectedly this seems to have a huge impact on power use, too. It appears that the laptop should now give me around 4.5 hours when I do everything I can think of to lower the power use, whereas before it was more like 2.5 hours. Now I guess I can get back to hacking on DAViCal...

So, we have some netgear prosafe switches and some IP Power 9258 devices where I'm currently working, unfortunately, these don't always get the IP configuration that you'd expect (or, they get a DHCP lease from a DHCP server that I can't query the leases from...), however both come with little windows utilities that "magically" find the devices and give back (quite a lot, really) information on the IP configuration of the device. Being somewhat of a "oh god, I don't want to use windows, please don't make me" type person, and knowing the the IPPower 9258 boxes were going to a remote site where I'll only have linux machines on the same network as them, I figured that it would be a good idea to sit with wireshark and find out how the heck these tools worked. Turns out that both just send out a UDP broadcast packet (or two) and then sit and wait for responses - this meant that to get the information that I wanted out of them I could get away with writing very little python, taking the UDP packet that I got back, taking the payload and dismantling it piece by piece so that I could display that information. The scripts aren't at all polished, but if anyone happens to need something (that should work multi-platform, too) to discover either of these, let me know and I can throw you what I've got.

Forgive me readers, for I have sinned... or at least, not blogged for a looooong time. I've been reasonably busy, stopped working for Runtime Collective and started contracting for a small company in Portsmouth, it's been somewhat hectic, and the commute isn't brilliant, but it has given me a lot of time for reading... Really, mostly a lot of my time during the week is commuting, working, reading and sleeping, haven't had much time for anything else, and have mostly been knackered... I'm getting in to the habit now, though, so am getting a bit more time for getting on with other things. I have, however, gained a lot more fiction books in the last few months, and am averaging 2 or 3 books a week at the moment. Most enjoyed the first 2 books of the Demon Trilogy by Peter V Brett - have to wait till 2012 to get the last book, though - which is a loooong time! Actually, I seem to have made a habit of ending up starting trilogys recently where not all of the books are published, in the case of Feed by Mira Grant I managed to really screw up - not even the second book is due out until next year - but the first is really quite good. I've also got the first book of Mark C Newton's Legend of the Red Sun books, really enjoyed that, but am waiting for the second in paperback, as they're much easier to carry around and use on the tube. Have read the Millennium trilogy, and thoroughly enjoyed it. The first film, although a reasonable adaptation of the book, misses some good parts of the book, and doesn't leave you feeling as if you know the characters as much. Am also planning on working through all the Laundry books by Charles Stross, I picked up The Fuller Memorandum on a whim (OK, it was on a 2 for 1 in Waterstones...) and really enjoyed it, so am going to get the rest (when I start getting low on books again - I've currently got another 5 queued up, so it might not be for a couple of weeks). So, other than that, what have I been up to? Well, played the last bits of DLC for Assassins Creed 2 on the PS3, and thoroughly looking forward to the release of AC3, played most of the way through Lego Harry Potter, wandered about and saw people... you know, the usual things! Oh, and of course, August bank holiday weekend (28-30) were spent with good peoples at the ever fantastic Debian UK BBQ where much Nero was imbibed, many people spoken to, and some gpg signing done - as always many thanks to Steve McIntyre for a fantastic weekend, to Collabora and Mythic Beasts for the beer, and to antibodyMX and Coding Craft Ltd for the food (Oi, Pashley , stop being crap and sort out your company website...).

After a bit of work, I got the sheeva plug working the way I wanted it to. First of all, I grabbed a spare 1G USB flash disk I had laying around and installed Debian squeeze to it by following tbm s instructions here: http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html After debian was installed to the USB disk, I removed it from the plug and used dd on my laptop to create an image of the filesystem. I mounted the filesystem as a loopback device and created a jffs2 partition image from it after doing a bit of minor tweaking. I placed the USB disk back in the plug and booted to it. Using this intermediate filesystem and the mtd-tools package, I wrote the new jffs2 image to the NAND mtd device. I then modified the uboot environment to suit, saved, and now have a working setup. Detailed instructions are below. pre-requisites Connect the plug to your network with the rj-45/cat5 cable. Connect a USB flash drive to the plug. I used a 1G drive, but 512M should be sufficient. Install the tftpd package on a machine on your network. You ll also need screen on the machine that you use to connect to the plug s serial terminal. I ll assume these are the same host. You need the IP address of the tftp server. In this example, we will assume that the IP is 192.168.1.2 and that you will assign 192.168.1.200 to the plug. $ sudo apt-get install tftpd screen Place uImage, uInitrd, and uBoot in the /srv/tftp directory: $ sudo wget -O /srv/tftp/uImage http://www.cyrius.com/tmp/beta1/marvell/sheevaplug/uImage
$ sudo wget -O /srv/tftp/uInitrd http://www.cyrius.com/tmp/beta1/marvell/sheevaplug/uInitrd
$ sudo wget -O /srv/tftp/uBoot http://wp.colliertech.org/cj/wp-content/uploads/2010/09/07/uboot.bin Connecting to the serial console We are now ready to boot the plug. Note that you have to be quick with the screen command. I recommend you type it out and get ready to press the enter key. You have to interrupt the bootloader in order to enter the u-boot console. Attach the power and immediately enter the following command: $ screen -S sheeva /dev/ttyUSB0 cs8,ixoff,115200 If you did this right, you should see a prompt like this: Marvell>> update uboot As per tbm s instructions, you can now update the uboot if needed. Instructions for that are here: http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html I ll put them inline here for completeness.

Marvell>> setenv serverip 192.168.1.2 # IP of your TFTP server
Marvell>> setenv ipaddr 192.168.1.200 # IP of the plug
Marvell>> bubt uboot.bin

be sure to answer n to the question about env parameters. Now reset the device. Don t forget to interrupt the bootloader so we can get back to the prompt:

Marvell>> reset

Let the device know that you will be running a mainline kernel and set the arcNumber:

Marvell>> setenv mainlineLinux yes
Marvell>> setenv arcNumber 2097
Marvell>> saveenv
Marvell>> reset

Install Debian to the USB disk Interrupt the boot process once more. We are now ready to run the debian installer. I ll leave the details as an exercise for the reader. The following should put you into the installer, which you are probably quite familiar with by now. NB: I will assume that you will use a single ext3 partition for the entire system. This will make it easier to build a jffs2 image out of the resultant partition on the USB disk.

Marvell>> setenv serverip 192.168.1.2
Marvell>> setenv ipaddr 192.168.1.147
Marvell>> tftpboot 0x01100000 uInitrd
Marvell>> tftpboot 0x00800000 uImage
Marvell>> setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most
Marvell>> bootm 0x00800000 0x01100000

build a jffs2 image Once the installation has completed, power down the plug and remove the USB disk. Put the USB disk in the machine you used to get the console on the plug and note what device the kernel assigns to it. In my case, it was given sdc, so debian is installed to /dev/sdc1. I will use these values for this example. If the filesystem was automatically mounted, unmount it. Create a disk image of the partition and mount it as a loopback device.

$ sudo umount /dev/sdc1
$ dd if=/dev/sdc1 of=/tmp/debian.img
$ mkdir /tmp/mnt
$ sudo mount -o loop /tmp/debian.img /tmp/mnt

You can now remove the USB disk and return it to the plug. Modify the /etc/fstab file. The root filesystem will be /dev/mtdblock2 and of fs type jffs2. My fstab file looks like the following:

proc            /proc           proc    defaults        0       0
/dev/mtdblock2 /               jffs2    errors=remount-ro 0       1

We can now create a jffs2 image from the mounted and altered fresh install:

$ sudo mkfs.jffs2 -l \
  -e 0x20000 \
  -X zlib \
  --eraseblock=128KiB \
  --pad \
  --output=/tmp/rootfs.jffs2 \
  --compression-mode=priority \
  -n \
  --squash \
  -r /tmp/mnt

write jffs2 to nand Now that we have an image to flash to the NAND, let s boot off of the USB disk. It should now be attached to the plug. Power on the plug and use screen to get a console. Interrupt the bootloader and enter the following commands:

Marvell>> setenv bootargs_console console=ttyS0,115200
Marvell>> setenv bootcmd_usb 'usb start; ext2load usb 0:1 0x01100000 /boot/uInitrd; ext2load usb 0:1 0x00800000 /boot/uImage'
Marvell>> setenv bootcmd 'setenv bootargs $(bootargs_console); run bootcmd_usb; bootm 0x00800000 0x01100000'
Marvell>> run bootcmd

Log in as root with the credentials you configured during the install. You will need to install a few packages in order to complete the nand flash. You can then ssh to the host on which you created the jffs2 image and cat it to stdout, piping this to nandwrite:

$ sudo apt-get install mtd-utils
$ ssh user@192.168.1.2 cat /tmp/rootfs.jffs2   sudo nandwrite /dev/mtd2 -p -

You now have a jffs2 image on the nand. Configure u-boot One more reboot to set u-boot s environment, and you will be done. Power down and remove the USB disk. Power on and get the serial console using screen. Break into the bootloader and enter the following commands:

Marvell>> setenv bootargs_console console=ttyS0,115200
Marvell>> setenv mtdpartitions mtdparts=orion_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)
Marvell>> setenv bootargs_root root=/dev/mtdblock2 rw rootfstype=jffs2
Marvell>> setenv bootcmd 'setenv bootargs $(bootargs_console) $(mtdpartitions) $(bootargs_root); nand read.e 0x00800000 0x00100000 0x00400000; bootm 0x00800000'
Marvell>> saveenv
Marvell>> reset

You should now be good to go.

Since the introduction of the 3.0 (quilt) source format, it is now possible to integrate multiple upstream tarballs in Debian source packages. This article will show you how to do the same with your own package shall you need it. It s quite useful to easily integrate supplementary plugins, translations, or documentation that the upstream developers are providing in separate tarballs. Step by step explanation We ll take the spamassassin source package as an example. The upstream version is 3.3.1. The main upstream tarball is named as usual (spamassassin_3.3.1.orig.tar.gz) and contains the top directory of our source package. We already have a debian directory because the package is not new. Upstream provides spamassassin rules in a separate tarball named Mail-SpamAssassin-rules-3.3.1.r901671.tgz. We grab it, rename it to spamassassin_3.3.1.orig-pkgrules.tar.gz and put it next to the main tarball. The pkgrules part is the component name that we choose to identify the tarball, it s also the name of the directory in which it will be extracted inside the source package. For now that directory doesn t exist yet so we must create it.

$ mv Mail-SpamAssassin-rules-3.3.1.r901671.tgz spamassassin_3.3.1.orig-pkgrules.tar.gz
$ cd spamassassin-3.3.1
$ mkdir pkgrules
$ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz

This is already enough, the next time that you will build the source package, the supplementary tarball will be automatically integrated in the generated source package.

$ dpkg-buildpackage -S
[...]
 dpkg-source -b spamassassin-3.3.1
dpkg-source: info: using source format  3.0 (quilt)'
dpkg-source: info: building spamassassin using existing ./spamassassin_3.3.1.orig-pkgrules.tar.gz ./spamassassin_3.3.1.orig.tar.gz
dpkg-source: info: building spamassassin in spamassassin_3.3.1-1.debian.tar.gz
dpkg-source: info: building spamassassin in spamassassin_3.3.1-1.dsc

The supplementary tarball is now part of the source package but we re not making anything useful out of it. We have to modify debian/rules (or debian/spamassin.install) to install the new files in the binary package. A special case: bundling related software In very rare cases, you might want to create a bundle of several software (small perl modules for example) and you don t have any main tarball, you only have several small tarballs. Rename all the tarballs following the same logic as above and when building the source package you can ask dpkg-source to create an empty (and fake) main archive for you with the option --create-empty-orig:

$ dpkg-buildpackage -S --source-option=--create-empty-orig

Use with care as the version number you give to the bundle is what users will see and it s likely unrelated to the version number of each individual software. Common mistakes Forgetting to extract the supplementary tarball If you forget to extract the content of the supplementary tarball in the pkgrules directory, dpkg-source will emit lots of warnings about those files being deleted. In fact, you did not delete them but you only forgot to create them in the first place.

dpkg-source: warning: ignoring deletion of directory pkgrules
dpkg-source: warning: ignoring deletion of file pkgrules/20_fake_helo_tests.cf
dpkg-source: warning: ignoring deletion of file pkgrules/60_shortcircuit.cf
[...]

Using a bad version number for the supplementary tarball Sometimes the supplementary tarball has a version of its own that does not match the upstream version. You must still name the file in a way that matches the upstream version of the main tarball otherwise it will not be picked up by dpkg-source and it will generate a new patch in debian/patches/ containing the whole new directory. It s possible to encode the version number of the supplementary tarball in the component name (in our example above we could have picked pkgrules-r901671 as component name) but this means that the name of the associated directory will regularly change and you must adapt your packaging rules to cope with this. However this last trick has the benefit of being able to update the additional tarball without bumping the upstream version. A sourceful upload of a new revision of the package will be accepted by the archive: the main tarball is ignored since it s unchanged but the supplementary tarball is taken since it s a new file for the archive (it has a different filename). Be sure to move away old versions of the additional tarball when you do that if you don t want to upload several versions of the same tarball by mistake! Misextracting the supplementary tarball dpkg-source is very smart when it extracts the supplementary tarball and you should be as well when you manually extract it. If the tarball contains only a single top-level directory, that directory is extracted, renamed to match the component name and moved in the source package directory.
If the tarball contains several top-level files or directories, then the target directory is first created and the content of the archive is directly extracted into that directory. Here are commands to install the files in both cases (we re already in the source package directory):

$ mkdir pkgrules
# Archive contains a single top-level directory
$ tar -C pkgrules --strip-components=1 -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz
# Archive contains many top-level entries
$ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz

2 comments Support my work

This summer of 2010 has been memorable. It started with a difficult period following the hospitalization and death of my mother, a series of very intense and equally memorable conferences catapulting me out of my funk and ending with a trip to Ireland, perhaps one of my most pleasant trips ever. I have always wanted to go there, as I have some good Irish friends and I was also quite attracted to the place due to its history, so when the opportunity came for me to go, I did not hesitate to book my ticket. I was not left disappointed in any way, shape or form, although since I barely experienced the gray, misty, and rainy weather Irish is famous for, my experience may admittedly be a bit skewed. These are some of things I did and some of my fragmented thoughts about Ireland and some photos, proof that the weather was UnIrish Ireland and The Irish: Well I can t as no one can speak of The Irish as if they were some unitary group but I did learn a lot about Irish history and managed hang out with a number Irish folks (even a family) and one thing that seems to mark Ireland as distinct, what makes it stand out from the rest of its Western European brothers and sisters, is the pervasive sense of history bleeding into the ambiance, perhaps because it is so tragic. The short version of the history, if you don t know it, is that the Irish, especially the Catholics, got repeatedly screwed by the British monarchs/rulers/planters/government/ for nearly a thousand years, the last five hundred of those being particularly harsh and ugly, a cycle of slight gains crushed by various forms of tyranny and violence at least until part of the country achieved independence (Northern Ireland is a bit of a different story). I may have gone a bit out of my way to learn about Irish history, more than I have done for any other place, but this historical consciousness seemed to be inescapable, precipitating into all sorts of conversations and places. To take one example, I went to see Gaelic Football, one of the two beloved national sports (the other being hurling), and the minute you learn anything about this sport, you learn that it is intimately bound with the Irish fight for independence and nationalism. The Irish are also very warm, kind, and outgoing. They also seem to curse an awful lot as well, so much so cursing is a bit of a national pastime, which yes, I (f*cking) loved as I tend to have a bit of a foul mouth myself, curbed I will admit, in recent years and in the classroom. It crept up in a lot of places but was most pronounced during the All Ireland Semi-Final Gaelic football game when the ladies (not lads, mind you) behind me were constantly yelling at the referee, hurling the c-word (rhymes with trunk) whenever they made a call they disagreed with. EASA/Maynooth.: I went to Ireland to attend the largest Anthropological meetings in Europe, and in specific an all day panel on digital anthropology, which seemed like a great opportunity given we are a a bit of a minority. The conference was impressively large with roughly 1200 attendees (can you believe there are that many anthropologists?), smoothly run, and the all-day panel on digital media was quite lively and I got to meet some really interesting folks. I was a tad sad to find out Maynooth is the only university in Ireland with an Anthropology department (for crying shame lads!!!) but at least it is located in a darn stunning university: the old quarters of the campus are strikingly beautiful. Anonymous: I have done some work on Anonymous and well when I found out there was going to be a raid/protest at the Church of Scientology (a pretty dismal, and run down church), I got in contact with Irish anon to let them know I was coming. Although someone first decapitated me (at least in character with their norms, right?), when I showed up in person, they were not only civil but really quite hospitable (greeting me with one of my favorite songs). Overall it was a great day. I was reminded of important differences among Anons (Irish Anon s take their anonymity pretty seriously, the New York Anons do not) and also good to experience the social life and metabolism of a protest, especially one attended by folks who have lost family to the church. Dublin: Since I stayed with my friend and his family in Dublin, this is where I spent most of my time. I was able to hook up with various friends, including one from graduate school who just got back from years of fieldwork in Rwanda and hearing about his experiences and stunning but stunningly sad project made me feel like mine in comparison was Child s Play (in fact, it really was). I got to see the Debian crew (many who work at Google) and I finally paid a visit to the office, which was exactly how I imagined it to be (good and abundant food, good lighting, lots of toys and bikes, lots of Star Wars posters.. Yep, it could have been in Silicon Valley). But I was surprised at the young age of the marketing and sales folks who were hanging in their lounge when I ran into them. In fact when I saw them I thought like I was looking at my freshman class or something! It was great to see the Debian folks (though no one I met was actually Irish), as well, one of my favorite things to do whenever I visit a foreign city. I walked my heart out in the city getting a blister in a shoe that I thought was blister proof and while not as picturesque as some other European cities, it has a ton of character and no shortage of Guinness and pubs (no surprise there). My favorite places/things were: The National Library (great exhibit on Yeats, but make sure to use the multi-media as that is where all the information is stuffed), St. Stephen s Park (overflowing with chubby ducks and lovely flowers), the prison Kilmainham Gaol (would not advise a visit if you are feeling in any way down, there is some heavy shit you learn during the tour), the simple stained glass that seemed pretty common, and finally the Long Room in Trinity Church, which you enter after the Book of Kells (I realized just how much I adore books when I visited this old library stuffed from floor to ceiling with old old old books). The West Coast: I did not think I was going to head out west but after hurricane Earl started its burst along the eastern Seaboard and I was able to change my ticket for free so I stayed a few more days. I went to the Burren and the Cliffs of Moher both totally stunning, really majestic. As is often the case with these type of these natural wonders, I am often left elated and awed but such strikingly wondrous places also seem to subsequently spur a more melancholic state of mind and heart. Friends, Family, and Dogs: While in Dublin I stayed with my friend A. and his extremely hospitable family, which included, a brother, a father, and three Irish mutts, one of which, Buster (pitt bull/lab mix), pretty much stole my heart. Buster s true love, is food, so much so he almost poised himself to death a little while back snorting down something he shouldn t have costing the family a pretty penny to save him. My friend no longer lives there but came from Berlin and it was a real treat to not only spend days layered upon each other with a friend (it has been an awful long since I have done that outside of conferences) but also meet his family. You learn a lot about your friends that way and in this case, there is some serious and I mean serious intellectual jousting that happens, sometimes bordering on warfare but generally it plays out in more contained, civil and fascinating fashion. Now I understand why my friend is armed with seemingly endless knowledge: it was needed for purposes of defense at home. So in essence, a great, great trip and a fantastic way to end a memorable summer and transition into what I hope will be a bit of a monkish (I call it monk mode) period for this academic year. I am (so so so) fortunate enough to have a fellowship at the Institute for Advanced Study and am going to try my darnest to take advantage of the fact I am not teaching (Hell Yes!) and hide away and accomplish all that I have set out to do.

I've been using IPv6 on my rootserver for some time now. Last week I migrated to a new rootserver and copied my domU/VM instances over to the new hardware. Everything is working fine so far - except IPv6. The network setup is the same as on the old server: the external interface is eth0. The domU/VMs are hooked up to a bridge, called xenbr0. There's another bridge for internal communication: xenbr1. The dom0/Xen host itself seems reachable via IPv6. The /48 subnet is provided by Sixxs and is using a static 6-to-4 tunnel. But the VMs are not reliable reachable, although it is setup in the same way as it was on the old server and where it was working like a charme. The configs of the hosts are these:

Xen dom0

config	old server	new server
System	Debian Etch 2.6.18-6-xen-amd64 linux-image-2.6.18-6-xen-amd64 linux-modules-2.6.18-6-xen-amd64 xen-hypervisor-3.0.3-1-amd64 xen-ioemu-3.0.3-1 xen-linux-system-2.6.18-6-xen-amd64 xen-tools xen-utils-3.0.3-1 xen-utils-common	Debian Squeeze 2.6.32-5-xen-amd64 libxenstore3.0 linux-image-2.6.32-5-xen-amd64 xen-hypervisor-4.0-amd64 xen-linux-system-2.6.32-5-xen-amd64 xen-tools xen-utils-4.0 xen-utils-common xenstore-utils xenwatch
/etc/sysctl.conf	net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 net.ipv4.conf.default.proxy_arp=1	net.ipv4.ip_forward=1 net.ipv4.ip_syncookies=1 net.ipv4.conf.all.rp_filter=1 net.ipv4.icmp_echo_ignore_broadcasts=1
/etc/xen/xend-config.sxp	(network-script network-route) (vif-script vif-bridge) (dom0-min-mem 196) (dom0-cpus 0)	(vif-script vif-bridge) (network-script network-route) (dom0-min-mem 196) (enable-dom0-ballooning yes) (total_available_memory 0) (dom0-cpus 2) (vncpasswd '')
/etc/network/interfaces	# device: eth0 auto eth0 iface eth0 inet static address 85.10.209.30 broadcast 85.10.209.31 netmask 255.255.255.224 up route add -net 85.10.209.0 netmask 255.255.255.224 gw 85.10.209.1 eth0 true up ip route add 85.10.209.0/28 via 85.10.209.1 src 85.10.209.30 true up route add default gw 85.10.209.1 true auto xenbr0 iface xenbr0 inet static address 85.10.209.30 netmask 255.255.255.224 pre-up brctl addbr xenbr0 up route add -net 78.47.85.144/29 dev xenbr0 true up ip -6 r a 2001:6f8:90e:145::1/64 via 2001:6f8:90e:1:216:3eff:fe55:197c dev xenbr0 true up ip -6 r a 2001:6f8:90e:146::1/64 via 2001:6f8:90e:1:216:3eff:fe2f:481d dev xenbr0 true up ip -6 r a 2001:6f8:90e:147::1/64 via 2001:6f8:90e:1:216:3eff:fe60:68be dev xenbr0 true up ip -6 r a 2001:6f8:90e:a100::1/64 via 2001:6f8:90e:1:216:3eff:fe70:be dev xenbr0 true auto xenbr1 iface xenbr1 inet static address 192.168.x.254 netmask 255.255.255.0 pre-up brctl addbr xenbr1 # some internal IPv4 routing auto sixxs iface sixxs inet6 v4tunnel address 2001:6f8:900:c6e::2 netmask 64 endpoint 212.224.0.188 local 85.10.209.30 ttl 64 up ip link set mtu 1280 dev sixxs true up ip route add default via 2001:6f8:900:c6e::1 dev sixxs true up ip -6 route flush dev eth0 true up ip -6 r a 2001:6f8:90e::/48 dev xenbr0 true down ip -6 route flush dev sixxs true	# device: eth0 auto eth0 iface eth0 inet static address 178.63.83.84 broadcast 178.63.83.127 netmask 255.255.255.192 gateway 178.63.83.65 # default route to access subnet up route add -net 178.63.83.64 netmask 255.255.255.192 gw 178.63.83.65 eth0 auto xenbr0 iface xenbr0 inet static address 178.63.83.84 netmask 255.255.255.192 pre-up brctl addbr xenbr0 up route add -host 178.63.83.104 dev xenbr0 true up route add -host 178.63.83.105 dev xenbr0 true up route add -host 178.63.83.106 dev xenbr0 true up ip route add 178.63.123.128/26 dev xenbr0 true up ip -6 r a 2001:6f8:90e:145::1/64 via 2001:6f8:90e:1:216:3eff:fe89:6c31 dev xenbr0 true up ip -6 r a 2001:6f8:90e:146::1/64 via 2001:6f8:90e:1:216:3eff:fedc:af5f dev xenbr0 true up ip -6 r a 2001:6f8:90e:147::1/64 via 2001:6f8:90e:1:216:3eff:fe08:8f40 dev xenbr0 true up ip -6 r a 2001:6f8:90e:a100::1/64 via 2001:6f8:90e:1:216:3eff:fe70:be dev xenbr0 true auto xenbr1 iface xenbr1 inet static address 192.168.x.254 netmask 255.255.255.0 pre-up brctl addbr xenbr1 # some internal IPv4 routing auto sixxs iface sixxs inet6 v4tunnel address 2001:6f8:900:c6e::2 netmask 64 endpoint 212.224.0.188 local 178.63.83.84 ttl 64 up ip link set mtu 1280 dev sixxs true up ip route add default via 2001:6f8:900:c6e::1 dev sixxs true up ip -6 route flush dev eth0 true up ip -6 r a 2001:6f8:90e::/48 dev xenbr0 true down ip -6 route flush dev sixxs true

The config of one of the Xen domUs is this:

sample domU config

config	old server	new server
system	Debian Lenny 2.6.18-6-xen-amd64	Debian Lenny 2.6.32-5-xen-amd64
/etc/sysctl.conf	net.ipv4.conf.default.rp_filter=1 net.ipv4.tcp_syncookies=1 net.ipv4.conf.default.forwarding=1 net.ipv6.conf.default.forwarding=1 net.ipv4.conf.eth0.proxy_arp=1 net.ipv4.conf.default.proxy_arp=1 kernel.shmmax=268435456	net.ipv4.conf.default.rp_filter=1 net.ipv4.tcp_syncookies=1 net.ipv4.conf.default.forwarding=1 net.ipv4.conf.all.forwarding=1 net.ipv6.conf.default.forwarding=1 net.ipv4.conf.eth0.proxy_arp=1 net.ipv4.conf.default.proxy_arp=1 kernel.shmmax=268435456
/etc/network/interfaces	# The primary network interface auto eth0 iface eth0 inet static address 78.47.85.145 netmask 255.255.255.248 up ip route add 85.10.209.0/27 dev eth0 up route add default gw 85.10.209.30 dev eth0 up ip -6 address add 2001:6f8:90e:145::1/64 dev eth0 true up ip -6 route add default via 2001:6f8:90e:1::1 true up iptables -t nat -A POSTROUTING -s 192.168.x.96/27 -o eth0 -j MASQUERADE true iface eth0 inet6 static address 2001:6f8:90e:145::1 netmask 64 gateway 2001:6f8:90e:1::1 auto eth1 iface eth1 inet static address 192.168.x.1 netmask 255.255.255.0	# The primary network interface auto eth0 iface eth0 inet static address 178.63.83.104 gateway 178.63.83.84 netmask 255.255.255.192 broadcast 178.63.83.127 up ip -6 address add 2001:6f8:90e:145::1/64 dev eth0 true up ip -6 route add default via 2001:6f8:90e:1::1 src 2001:6f8:90e:1:216:3eff:fe89:6c31 true up iptables -t nat -A POSTROUTING -s 192.168.x.96/27 -o eth0 -j MASQUERADE true iface eth0 inet6 static address 2001:6f8:90e:145::1 netmask 64 gateway 2001:6f8:90e:1::1 auto eth1 iface eth1 inet static address 192.168.x.1 netmask 255.255.255.0

The dom0 seems to be reachable via IPv6 just perfectly fine. When trying to reach the domU I see packets going through the xenbr0 bridge and reaching the domU eth0 interface. The ICMP6 echo request packets (proto 58) are unanswered there, no echo replies. Strange enough it seems to work from time to time, but mostly not. I've also tried to set a generic default route like ip -6 route add default dev eth0, but still no improvement. Did I miss something when migrating to the new server? Is there any mistake in the configs? Any suggestions are appreciated! :-) UPDATE:
This is a tcpdump from the domU, doing a ping from dom0:

07:35:29.308261 IP6 fe80::e46d:25ff:fe1f:317b > ip6-allnodes: ICMP6, router advertisement, length 56
07:35:29.329411 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 45, length 64
07:35:30.329439 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 46, length 64
07:35:30.451991 IP6 2001:418:4001:3::c657:b0c5 > vserv.windfluechter.net: ICMP6, echo request, seq 52836, length 64
07:35:30.481124 IP6 fe80::e46d:25ff:fe1f:317b > ff02::1:ff70:be: ICMP6, neighbor solicitation, who has 2001:6f8:90e:1:216:3eff:fe70:be, length 32
07:35:31.329906 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 47, length 64
07:35:31.481645 IP6 fe80::e46d:25ff:fe1f:317b > ff02::1:ff70:be: ICMP6, neighbor solicitation, who has 2001:6f8:90e:1:216:3eff:fe70:be, length 32
07:35:32.329284 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 48, length 64
07:35:32.481114 IP6 fe80::e46d:25ff:fe1f:317b > ff02::1:ff70:be: ICMP6, neighbor solicitation, who has 2001:6f8:90e:1:216:3eff:fe70:be, length 32
07:35:33.329951 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 49, length 64
07:35:34.329705 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 50, length 64

UPDATE #2:
The issue is finally solved. The solution can be found here.

Long ago I've set up a small but occasionally useful service on merkel: Debian Official Kernel Configuration files. It extracts and stores the configuration files from all kernel packages ever uploaded to the archive (does not seem to work particularly well with stuff uploaded to experimental though). Now that merkel is going away, this service is likely going to die. If you care about things like that, and would like to see it continue beyond merkel's demise, feel free to grab the script code and historical config files, and set it up elsewhere (it's not likely that I'm going to bother).

Really, I should have known better than to buy myself a rather 'bleeding-edge' laptop. I suppose I've been lucky with my last couple of laptops and was thinking that pretty much everything works on Linux. Or maybe I'm being picky, because in fact pretty much everything does work on my new Dell Studio. I bought this laptop mainly because it has a 1920x1080 screen, without being a 17" monster. I had such a monster about four laptops ago (an enormous Sony Vaio weighing in at around 5kg and with a 1hr battery life) and it was an disaster: lots of weird proprietary stuff that never worked, like the external speakers in the docking station. But I loved that screen right up until the day Fraser threw a pair of scissors into it. With the advent of mass-market 1920x1080 screens I've been waiting for them to arrive in laptops at a reasonable price, and the availability of this screen in a few possible laptops seemed to me to be that point. It's a Dell Studio 15, and as well as the nice screen, it comes with a new Intel i7 Quad Core CPU, 6G RAM, 640G hard drive and a Blu-ray drive. While there are a few similar models around this one seemed to have the best mix of features-for-weight-and-price, so I bought my first Dell. I built a USB key with the latest Debian Installer from Squeeze and installed that and everything came up pretty well. I had to use the broadcom-sta driver for the wireless, since the BCM 43224 is not (yet) supported by the free b43 driver (though from looking the mailing list people seem to be working on it, and it looks like it might not be too far away). Everything seemed good. X came up on the (georgeous) screen. I don't care too much about 3D performance, but it was nice to note that the ATI 5000 series is expected to have full support as soon as it's integrated into the right places - it seems the code is written, and public, it just isn't incorporated into the 'radeon' driver quite yet. The fact that ATI is nowadays a free-software friendly company was one of the reasons for choosing this, in preference to an NVidia-based laptop. But it seems that it isn't all roses. The fan in the laptop seems permanently on, and not on, in a quiet-just-barely-audible way, but ON, in an 'IN UR LAPTOPZ KOOLIN UR P0RCESSAZ' kind of a way. Too damn noisy for me to concentrate in a quiet room. I've investigated what's going on, and it seems likely there are some ACPI misunderstandings happening. Some googling and some pecking around in /sys makes me wonder if the laptop expects some kind of configuration choice between favouring Active cooling and Passive cooling, and it's defaulted to the first one. Perhaps you get better benchmarks that way. Linux ACPI also seems to only half understand it, it has two thermal zones, and one of them always appears with 0 temperature. I can see set points for the fans, but have no control over them. In particular this got me out reading the ACPI 4.0 specification, and it explicitly mentions this choice of favouring 'Active' vs 'Passive' as being done by configuring the passive trip point setting to a higher value than the low & high active trip points. In the ACPI 4 spec (page 409) it says:

To implement a preference towards performance or energy conservation,
OSPM can request that the platform change the priority of active cooling
(performance) versus passive cooling (energy conservation/silence) by evaluating
the _SCP (Set Cooling Policy) object for the thermal zone or a corresponding
OS-specific interface to individual devices within a thermal zone.

This laptop is showing 'passive' at 95000 millidegrees celsius, and 'active' at 55000 / 75000 so right in line with the suggestion. However I don't see any way in Linux to change these trip point values, and in any case I'm not convinced the laptop is actually obeying them at all. It should be that if I do nothing on the laptop for a while the temperature would surely drop below 55 degrees celsius. Surely a modern laptop will sit at under 40 degrees when it's quiescent, and the temperature sensor that does show me something sits at around 30 degrees in this too, 26.8, to be overprecise. That one doesn't budge either. Looking in /sys/ I can't for the life of me find a way to set that cooling policy, and when I disassemble the DSDT it looks like a noop... Thinking that perhaps there was a newer BIOS, I looked at the Dell site and found there was one. Great! Investigating even further, it seems Dell hardware has some interesting capability via libsmbios and some utilities which will let me install my BIOS from a Linux system... even better! Linux is a second-class citizen though, and when I look for the Dell BIOS Hdr file I need there is no version of the file for this laptop - let alone the current BIOS version. And when I download the BIOS from Dell's website and unzip the first layer of packaging I find that both of the files inside will only run on Windows. I added a FreeDOS boot stanza to Grub 2 in order to discover this, also discovering in the process that this is not well explained, and I could not find how to do it on the FreeDOS or Grub2 websites, so in passing, here is what I added into /etc/grub/40_custom :

menuentry 'BIOS Flash 1558 A09' --class os  
        set root='(hd0,msdos1)'
        linux16 /boot/memdisk
        initrd16  /boot/1558_A09.img
 

Which certainly does boot FreeDOS from Grub2, into the image built from the 8M FreeDOS base image, and which I called '1558_A09.img' because that seems to be one of Dell's reference numbers for this model / BIOS version. So still no BIOS update for Andrew, it seems, and the laptop is probably going to continue to be noisy for some time. Possibly forever. Suspend/Resume works though. Kernel mode-setting for the ATI Radeon Mobility HD 5450 (or whatever it is) seems to work. Building kernels seems to work. The Blu-ray drive seems to work, at least as far as reading CDs - just because I got a laptop with a "Full HD" screen doesn't mean I watch movies on it: those pixels are for programming on! In any case, after reading the literature of pain about playing Blu-ray disks on Linux I'm convinced that we won't be shelling out to buy one any any time soon. After a bit more frustration I did manage to get the BIOS installed, using the hack I found here of running the Windows BIOS update under Wine and copying the BIOS file out of the temp directory while the error message is displayed. I could then download a random DOS-installable Phoenix BIOS to get copy of phlash16.exe and put those two files on the FreeDOS image I created earlier. Finally I was able to put that learning about how to boot FreeDOS from Grub2 to good use! Unfortunately, having jumped through all of those hoops (including the frustration of trying to build and use Dell's firmware-extract tools on a Debian system), the fan continues to grind away at annoying volume, with no way that I have been able to find to control it, and the temperature sensors also seem wrong, since one doesn't budge from 0 and the other doesn't budge from 26800. During boot I get a bunch of error messages, like:

[    1.049936] \_SB_.PCI0:_OSC invalid UUID
[    1.052202] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    1.052210] pci 0000:00:1c.0: PME# disabled
[    1.065228] pci 0000:07:00.2: PME# supported from D0 D1 D2 D3hot D3cold
[    1.065237] pci 0000:07:00.2: PME# disabled
[    1.079086] Unable to assume PCIe control: Disabling ASPM
[    1.086412] HEST: Table is not found!
[    1.249906] ACPI: Fan [FAN0] (off)
[    1.249959] ACPI: Fan [FAN1] (off)
[    1.250093] [Firmware Bug]: ACPI: ACPI brightness control misses _BQC function
[    1.259118] acpi device:02: registered as cooling_device2
[    1.262132] thermal LNXTHERM:01: registered as thermal_zone0
[    1.262139] ACPI: Thermal Zone [TZ00] (27 C)
[    1.262561] thermal LNXTHERM:02: registered as thermal_zone1
[    1.262571] ACPI: Thermal Zone [TZ01] (0 C)
[    1.262598] ERST: Table is not found!
[    2.769664] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    2.769670] ACPI: resource 0000:00:1f.3 [io  0x1840-0x185f] conflicts with ACPI
                         region SMBI [bus 1840-184f pref window disabled]
[    2.769672] ACPI: If an ACPI driver is available for this device, you should use it
                         instead of the native driver

I don't yet know what this all means, so I guess I'll be signing up for the linux-acpi mailing list to see if there's anything I can do to get things working better. Any pointers will be gratefully received :-) Right about now I wonder if maybe I should have gone for the HP or the Asus, even if they were a little heavier and a bit more expensive and next time I get a new laptop I must remember not to spend more than $900 (USD$600) on it. [Updated: 2010-09-08... Noise Problems Solved