In fact, we started off with two or three different shells and the shell had life of its own.

With apologies to Ken Thompson, this is a list derived from the wafflings residents of a certain UK IRC channel. The conversation happened several years ago but I was reminded of it again today from a conversation on that same channel.

No names have been kept to project the guilty.


/bin/bush - a shell that steals and lies?
/bin/cash - displays adverts before each prompt
/bin/crash - Microsoft shell
/bin/mash - requires libsausage.so
/bin/hush - terse output
/bin/irish - only shell that finds jerkcity funny
/bin/rush - über-optimised for speed, but might not actually work correctly
/bin/flash - proprietary shell that displays adverts and cartoons and hangs periodically
/bin/welsh - whinges about people not using it, but then steals features from other shells in order to actually make sense
/bin/rehash - never actually runs any program, just uses markov chains to construct output from stuff it has seen before.
/bin/wash - will remove lint in your scripts if you let it
/bin/parish - prays for the successful exit of every command
/bin/punish - symlink to /bin/csh
/bin/sheepish - apologises when $? is not zero
/bin/diminsh - decrements all result codes by one
/bin/lavish - and you thought bashisms were bad...
/bin/brainwash - once you've tried it, you'll believe it's the only shell in existence
/bin/hoggish - written in Java
/bin/reversepolish - arguments order different in go must
/bin/ganesh - no subprocess dares exit zero for fear of being removed from the system
/bin/roguish - every day is April 1st as far as it is concerned
/bin/macintosh - it's shiny, has *loads* of things you think you can poke at, yet it only actually responds to a single key on the keyboard and has no useful features for fear of confusing the user
/bin/lush - garbles output from processes like a drunkard
/bin/snobbish - you're not good enough to use it
/bin/thrush - it itches
/bin/vanquish - kills processes mercilessly
/bin/tush - pert
/bin/fetish -> /bin/zsh
/bin/skirmish - multi-user shell
/bin/whiplash - gets invoked if you break too hard
/bin/newsflash - BREAKING NEWS pid 1234 terminated
/bin/mulish - DJB does Shell
/bin/hsilop - arguments order different in go must
/bin/whitewash - government approved
/bin/trish - for tri-state hardware
/bin/jdsh - it sucks...
/bin/flesh - optimised for viewing p0rn

What man's mind can create, man's character can control.

I have a project that required me to programmatically control power to several devices. I have done this before using a Velleman vm8090 board which is relatively easy to control. However they are relatively expensive.

I turned to ebay and found a similar module at a substantially reduced cost. Upon receipt however I discovered that instead of being a simple serial USB interface it presented USB HID and the Debian system I was running it on has loaded the hiddev driver for me but it did not implement any of the standard HID Usage Pages leaving me with no way to control the device.

I did the obligatory

sudo lsusb -d 12bf:ff03 -vvv

Bus 003 Device 019: ID 12bf:ff03  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x12bf 
  idProduct          0xff03 
  bcdDevice            1.00
  iManufacturer           1 Matrix Multimedia Ltd.
  iProduct                2 Flowcode USB HID
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               50mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      54
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               5
Device Status:     0x0980
  (Bus Powered)

This simply showed me what I already knew and surprised me that lsusb did not dump HID report descriptor items. Some searching revealed that teh device had to be unbound so lussb could access the descriptor.

Thus a simple

echo -n 3-1.1.4:1.0 | sudo dd of=/sys/bus/usb/drivers/usbhid/unbind

resulted in lussb dumping the descriptor items:

Item(Global): Usage Page, data= [ 0xa0 0xff ] 65440
                (null)
Item(Local ): Usage, data= [ 0x01 ] 1
                (null)
Item(Main  ): Collection, data= [ 0x01 ] 1
                Application
Item(Local ): Usage, data= [ 0x02 ] 2
                (null)
Item(Main  ): Collection, data= [ 0x00 ] 0
                Physical
Item(Global): Usage Page, data= [ 0xa1 0xff ] 65441
                (null)
Item(Local ): Usage, data= [ 0x03 ] 3
                (null)
Item(Local ): Usage, data= [ 0x04 ] 4
                (null)
Item(Global): Logical Minimum, data= [ 0x00 ] 0
Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0xff ] 255
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x08 ] 8
Item(Main  ): Input, data= [ 0x02 ] 2
                Data Variable Absolute No_Wrap Linear
                Preferred_State No_Null_Position Non_Volatile Bitfield
Item(Local ): Usage, data= [ 0x05 ] 5
                (null)
Item(Local ): Usage, data= [ 0x06 ] 6
                (null)
Item(Global): Logical Minimum, data= [ 0x00 ] 0
Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0xff ] 255
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x08 ] 8
Item(Main  ): Output, data= [ 0x02 ] 2
                Data Variable Absolute No_Wrap Linear
                Preferred_State No_Null_Position Non_Volatile Bitfield
Item(Main  ): End Collection, data=none
Item(Main  ): End Collection, data=none

By consulting the device class definitions document I determined the device was using the "Vendor defined" Usage page (0xff00 to 0xffff) so I would definitely have to write a program to control the device.

Linux provides a really easy interface to deal with HID devices called hiddev (gosh, such adventurous naming) which I already had to unbind to get my descriptors decoded so I am fairly sure it works ;-)

The kernel documentation and header for hiddev provide the absolute basic mechanics of the interface but no example code or guidance. The obligatory web search turned up very little and even that had to be retrieved from the internet archive. So It seems I would be forced to work it through myself.

It seems the hiddev interface is orientated around HID devices generating reports which the program is expected to read. Numerous ioctl() are provided so the program can obtain the descriptor information necessary to control and process the received reports.

However in this case we need to be able to send reports to the device, all the descriptor information revealed was that there were eight (Item Report Count = 8) values with eight bits each (Item Report Size = 8) with logical and physical values representing the whole range of the octets.

Fortunately the seller provided a website with some control programs and even source. After some time rummaging through the Visual Basic program I finally found (in FrmMain.vb:2989) that the eight bytes were largely unused and the first was simply a bitmask of the eight relays coil status, set for energised clear for off. With bit 0 controlling relay labelled 1 through to bit 7 for relay 8.

To send a report to a HID device the hiddev interface uses the HIDIOCSREPORT ioctl where the report data is first set using HIDIOCSUSAGE .

The HIDIOCSUSAGE ioctl is passed a hiddev_usage_ref structure which must be initialised with information about the report descriptor identifier (constructed from the Usage Page and Usage as set by the items in the descriptor), the index of the item (named usage) we wish to set in the report (in this case the first which is 0) and the value we actually want to set.

After a great deal of debugging the final program is very short indeed but does the job, my main problem now is that if I switch too many (more than one) relays at once the whole device resets. The scope says the supply rails are behaving very badly when this happens, looks like I need to add a load of capacitance to the power well to stabilise it during the switching events.

Oh and add in the fact Relay 1 LED doest work unless you push on it and I do wonder about the wisdom of the economy in this case. Though yet again Linux makes the software side easy.

Another NetSurf Developer Workshop

The weekend saw some of the NetSurf developers gather once again to do battle against the Red Queen...no, wait. I mean plan and write code.

The successful event was once again kindly hosted by Collabora at their Cambridge office, the facilities remain as good as at the previous event and provided a comfortable environment in which to work.

Four developers managed to attend from around the UK John-Mark Bell, Vincent Sanders,  Daniel Silverstone and Rob Kendrick. The turnout was a little lower than previous events, however Michael Drake managed to assist with some bug fixes remotely.

From Friday to Sunday afternoon we each managed to put in 24 hours of work consisting of almost 90 commits changing over 100 files and removing 10,000 lines of code.

The main theme of the event was consolidation ready for the 3.0 release. While not a glamorous target this is a major release for the project which we want to achieve soon, this requires the completion of numerous ongoing tasks (like finally removing the dependency of libxml) and fixing as many reported bugs as possible.

The Major things we achieved were:

• Merging of the new javascript implementation.
• Removal of libXML from "full save" and "libSVGtiny"
• Address issues accessing some https sites (TLS 1.2 disabled for now)
• Complete integration of UI message translations from single file (fat messages)
• Significantly improve the performance of DOM event dispatch.
• Several important bugs closed.

Once the final usage of libXML is removed (from the hotlist code) NetSurf will become substantially smaller on several platforms as we will not have two separate parser implementations linked.

One big feature of the 3.0 release which was not originally on the roadmap is that of JavaScript. We initially intend to provide two builds of with and without the JavaScript interpreter compiled into NetSurf. This allows those on very small systems to continue to run NetSurf and those users who want a richer web experience to enjoy it. 

Although JavaScript is a major new feature which is frequently requested the initial implementation will be incomplete. To complete the feature several thousand JavaScript to DOM interface binding functions must still be written. In addition it should be noted that we have yet to add dynamic layout or extensions such as Canvas or WebGL

We had a Raspberry Pi which was used to run RISC OS so we could examine the operation on this system. 

The 2.9 edition as shipped works OK but is lacking the substantial progress made in the last six months. 

The CI system build was run on the system and works well so we are reassured the 3.0 edition will provide an even better browsing experience.

The event was a great success overall and we are now very close to our 3.0 release which we hope to produce before Christmas.

I thought San Diego must be Heaven on earth...It seemed to me the best spot for building a city I ever saw.

I think perhaps Alonzo Horton overstated the case but San Diego was a perfectly pleasant place to spend a week. Recently I was fortunate and attended the Linux Plumbers conference (and bits of Kernel Summit) and as on previous occasions there were some interesting sessions and some less helpful diversions.

Melodie went along with me, our first trip away together without the kids in a long time. We did the tourist thing for a few days including the USS Midway aircraft carrier tour (recommended) and the harbour boat tour (also recommended).

The conference was co-located with several other events and there seemed to be a lot of people around not connected with KS or LPC. For me the hallway track was, as usual, much more rewarding and I got to catch up with several old friends and make some new acquaintances. A lot of my colleagues were about attending the Gstreamer and Linuxcon conferences so there was the obligatory work evening event (which was pizza and beer, just done brilliantly).

A track that did stand out for me was the Clang / LLVM presentations. They gave an excellent overview of their progress towards making the Kernel compile with their tools, such innovation appears to be making both projects stronger.

One thing that occurred to me was the blandness of KS and LPC this time, usually there are at least some loud disagreements but I failed to attend even one session where there was more than small differences which were quickly resolved.

Perhaps such conferences, like the majority of people attending them, are becoming middle aged and a little complacent. An observation like that does make me wonder where the next change will come from and what it will look like. Just as open source software (including Linux) has disrupted the proprietary software industry in the last decade what will come along and disrupt us? Or is open source the end of the line and we will just continue to evolve?

Education is when you read the fine print. Experience is what you get if you don't.

Given my title I guess I just got a load of "experience" from Gandi. Previously I have written about building the NetSurf Continuous Integration (CI) server and my misjudgement of the resources it would require to be useful.

I contacted Gandi and they confirmed my suspicion that my only options to extend the VPS were to spend a great deal more money. The total spend would have been in excess of £300 per year to get a minimally satisfactory configuration.

So I contacted Mythic Beasts and they offered the NetSurf project a selection of deals they could not refuse. Once we decided on the right deal for us the system was in place, ready to use, within a morning.

Thanks to the generous open source project discount the offering from Mythic is almost double what Gandi were offering for less than half the price. I was, as previously concluded, dumb to go with Gandi in the first place when Mythic were an option.

Once the system was transferred to the shiny new server I went back to Gandi and asked how much my mistake of buying a years service for a single month worth of VPS service was going to cost. The reply was somewhat disappointing I was simply referred to section 8.1.2 of the contract (tl;dr We have your money now, tough luck, your problem). It would appear my mistake was going to cost me the full £114 I had paid.

I was somewhat disheartened at this turn of events but then Daniel Silverstone offered to take on the VPS if I could transfer it to his Gandi handle so he could administer it. this seemed like a good solution, at least the resource would be used and not wasted. Gandi response to this was initially promising but this is the final reply:

I'm really sorry to inform you that my supervisor refused the share transfer request to the other  account. He told me that we do not transfer products either in those cases. I deeply apologize since I thought it was possible. I thank you for your confidence in  Gandi, and hope that this occurrence does not deter you from continuing with us.

Now I must stress that Gandi are completely within their contractual rights to do this and are not obligated to provide any assistance to help make my blunder less costly to me, but they have firmly shown they have no willingness to be flexible in any way which means I know where I will not be spending my money in future.

Oh and then Pete from Mythic mentioned that they have a full refund and flexible policy on their services and we can always switch to the monthly billing rate and get a refund on the outstanding balance or move it or...

Basically my recommendation for an open source project looking for hosting, VPS or any network services has to be to go talk to the nice people at Mythic and steer clear of Gandi. Maybe in future all providers will realise that they are in a competitive market and certainly a little customer service flexibility might have made this posting much more about my mistake and not the attitude of the suppliers involved.

Pimm's and Punting

The Sun came out in Cambridge the other week (yes I know, a rare occurrence) and because Robert is a generous soul he decided the office should go punting on the cam.

I had not previously been out on the river but Robert proved to be the consummate punter.

We even got fruit based drinks and some serenading, although perhaps that was not a benefit.


I took many photos of the event including the rather nice meal afterwards, some were even in focus and not blurry.

Fowlers Delight?

Fowler published his paper on Continuous Integration (CI) way back in 2000. Personally at the time I was a much more naive developer, I was not really an adherent to the whole XP community and had worked for a series of companies where the idea of a release build was of a month long process and the concept that the whole codebase could be built and tested on every commit was a comical notion at best.

By the time the time the 2006 edition of the paper came out however I was convinced. Ever since then I have tried to make the projects I worked on have as many CI features as possible. It is one reason I ran the ARM Kernel autobuilder for years as an attempt to provide at least build coverage.

I especially like the way these concepts mean that releases are much less "scary" events and release anxiety is reduced to a minimum. When every commit produces something that is of release quality a project really is doing it right.

The reason I mention any of this is I have recently set up the NetSurf projects CI server. The heavy lifting is being done by a Jenkins instance running on a VPS fulfilling the "Every Commit Should Build the Mainline on an Integration Machine" part of the Fowler guidelines.

Setting up Jenkins was much less trouble than many of the previous systems I have used. I have been a little underwhelmed by the support for plain old make based projects which you have to resort to shell scripts for, but leaving that aside the rest was straightforward. The documentation could do with a purge pass for the old hudson name and the error reporting (especially under memory pressure) is not great.

And there lies my one real issue with the tool, memory. The VPS has 512MByte RAM and runs nothing beyond a web server, jenkins and the C compiler to build the project components. One would hope that was plenty of memory, doing the builds by hand it did seem gcc is happy in that space, alas Jenkins is a Java application and guzzles RAM (over 60% of RSS right now) and causes itself out of memory exceptions with distressing frequency.

The project is left with the choices:

• The project is relatively poor (and I already blew the budget) so "living with it" and keeping an eye on it manually is a possibility.
• Extending the VPS with another 512MBytes of RAM (Due to my VPS provider choice I had not anticipated the need so this option would cost almost as much as the original set-up)
• Buying another more suitable VPS from somewhere reputable like Mythic Beasts (why I did not go there in the first place...dumb, sometimes I am just dumb)

It is such a pity too, aside from the RAM issues it is all going well and it has already encouraged us to get the toolchains for the less commonly built targets (ppc amiga and windows for a start) working.

A sad state of affairs

Surprisingly my previous post on my Debconf trip has gathered more queries over its title than anything else.

Mostly my blog titles are, if I can manage it, relevant quotes or book titles. For the last post I used the title of a collection of Mark Twain scripts surrounding his trip through Nicaragua in 1866.

I have not been able to read the publication myself beyond the quoted excerpts in more modern articles because, somehow, almost 150 years after the words were written the only access to these words is to buy a very expensive and rare 1940 publication.

This appears to stem from the fact the original Clements scripts were simply not published before 1940 and hence appear to gain copyright from that date (IANAL I might be wrong here is the source I used) and thanks to the US government effectively making copyrighted works published after 1922 be "protected" forever I may never read it at all.

Rather sad really, but if you do have a copy I could borrow...oh no that is probably illegal too? better just let the words fade to dust eh?

Travels with Mr. Brown

My return from Debconf12 has been tinged with a little wistfulness, I had a great time but wish I could have spent a little more time there to justify the seventeen hours travel each way. I took a lot of pictures which gave me a good record of my trip.

The talks, BOF and discussions were, as usual, very useful. The release team explaining what needed to be done for Wheezy was both informative and amusing.

The numerous BOF from Steve Mcintyre were a great source of discussion and ideas and appear to have generated progress on some quite contentious issues.

I especially enjoyed the Sylvestre Ledru talk on building the archive with clang and how this might be another useful tool in finding bugs.

Hideki Yamane gave a really useful talk "Let's shrink Debian package archive!" He gave a practical explanation on how Debian could benefit from using xz compression, where it is not appropriate and had a selection of real numbers to help the discussion. Given this was Hideki first talk at a Debconf I must congratulate him on doing an excellent job.

There were many other talks which I have not singled out here but that says nothing about their quality or usefulness, more about why I should blog immediately after an event and not leave it a week. Though the video team have managed to capture many of the talks so you can go and watch them too.

The event was well organised and the accommodation was pleasant, if a little crowded with three to a room. The hotel had a pool which was the centre for evening activities most days, though I did miss Neil McGovern (one of my room mates) unintentionally swimming in his kilt.

The lunch and dinner catering was outdoors which was novel. The food was generally good if a little limited for those of us with less straightforward dietary requirements.

Some of us did venture out to have dinner at the continental hotel on one evening for a change of scene.

There was of course the obligatory conference meal by the lakeside and an awesome day trip where I saw a mangrove swamp and (fortunately) no salt water crocodiles.

All in all I had a fabulous and productive time. I would like to thank Collabora for travel sponsorship to the event and to Neil who was a great travelling companion.

Each morning sees some task begun, each evening sees it close; Something attempted, something done, has earned a night's repose.

Thursday saw all the Collabora employees at Cambridge office go out and socialise at the beer festival. They seemed to have selected a wonderful day for it, the sun was shining and it was warm and blue sky day.

Alas, I had to attend some customer conference calls and work on some time sensitive research so I could not go to the ball as it were. At about eight my brain had run out of steam so I decided to call it a day and go and meetup with people at the festival for an hour or two.

The queue when I arrived dissuaded me from that notion. I asked one of the stewards and they indicated it would take at least an hour from where the queue finished.

So I decided to wend my way home along the bank of the Cam. I proceeded slowly along and to my utter surprise bumped into Ben Hutchings and his Solarflare work colleagues having their own soiree. I was immediately invited to sit and converse. Pretty quickly I was inveigled into accepting a glass of wine by John Aspden from his floating bar (AKA houseboat).

From here on my evening was a pleasant one of amusing new people, easy conversation and a definite pondering if the host would be discovering the delights of Cam swimming as he became progressively inebriated!

So although I missed the festival I did manage to have an enjoyable time. A big thanks to the solarflare guys and especially John who was the consummate host and provided me with far too much alcohol.

Interrupt Service Routines

Something a little low level for this post. I have been asked recently how to "test" for the maximum duration of an Interrupt Service Routine (ISR) in Linux

To do this I probably ought to explain what the heck an ISR is!

A CPU executes one instruction after another and runs your programs. However early in the history of the electronic computer it soon became apparent that sometimes there were events happening, generally caused by a hardware peripheral, that required some other code to be executed without having to wait for the running program to check for the event.

This could have been solved by having a second processor to look after those exceptional events but that would have been expensive, difficult to synchronize and the designers took the view that there was a perfectly good processor already sat there just running some users program. This Interruption in the code flow became known as, well, an Interrupt (and the other approach as polling).

The hardware for supporting interrupts started out very simply, the processor would complete execution of the current instruction and when the Program Counter (PC) was about to be incremented if an Interrupt ReQest (IRQ) was pending the PC would be stored somewhere (often a "special" IRQ stack or register) and then execution started at some fixed address.

The interrupting event would be dealt with by some code and execution returned to the original program without it ever knowing the CPU just wandered off to do something else. The code that deals with the interrupt is known as the Interrupt Service Routine (ISR).

Now I have glossed over a lot of issues here (sufficient to say there are a huge number of details in which to hide the devil) but the model is good enough for my purpose. A modern CPU has a extraordinarily complex system of IRQ controllers to deal with numerous peripherals requesting the CPU stop what its doing and look after something else.

This system of controllers will ultimately cause program execution to be delivered to an ISR for that device. If we were living in the old single thread of execution world we could measure how long execution remains within an ISR, perhaps by using a physical I/O line as a semaphore and an external oscilloscope to monitor the line.

You may well ask "Why measure this?" well historically while the ISR was running nothing else could interrupt it executing which meant even if there was an event that was more important it would not get the CPU until the first ISR was complete. This was known as IRQ latency which was undesirable if you were doing something that required an IRQ to be serviced in a timely manner (like playing audio)

This is no longer how things are done while the top half runs with IRQ disabled many are threaded interrupt handlers and are preemptable (I.e. can be interrupted themselves) which leads to the first issue with measuring ISR time in that the ISR may be executed in multiple chunks if something more important interrupts. Indeed it may appear an ISR has taken many times longer one time than another because the CPU has been off servicing multiple other IRQ.

Then we have the issue that Linux kernel drivers often do as little as possible within their ISR, often only as much as is required to clear the physical interrupt line. Processing is then continued in a "bottom half" handler  this leads to ISR which take practically no time to execute but processing is still being caused elsewhere in the system.

The next issue is the world is not uniprocessor any more, how many processors does a machine have these days? even a small ARM SoC can often have two or even four cores. This makes our timing harder because  it is now possible to be servicing multiple interrupts from a single peripheral on separate cores at the same time!

In summary measuring ISR execution time is not terribly enlightening and almost certainly not what you are interested in. The actual question is much more likely that you really want to be examining something that the ISR time was an historical proxy for like IRQ latency or system overheads in locking.

Linux kernel presentation

Recently I was asked to present a short introduction to the Linux kernel for our project managers. I put together a short slide deck for the presentation which I have decided to share.

I feel its important to note that I had a lot more to say about each section and the slides were more an aid for my memory to cover the important points. Of special note would be the diagram showing the "hierarchy" of contributors, this is of course nowhere near as well stratified as portrayed.

NetSurf at a show

The wakefield RISC OS show is an event the NetSurf project has attended for a long time. in fact since 2005 when the "stand" was a name on an A4 sheet through 2006, 2007, 2008, 2009, 2010 to 2011 we have always been present.

The event has changed in that time from a large affair with many exhibitors to a small specialist interest event with a handful of stands. I took some pictures this year which give a fair impression of the event.

We were seriously considering not attending this year as 2011 had seen us barely break even on donations versus expenses to attend. However we decided that the projects annual Grey Ox Inn post event dinner was probably worth making the effort.

So we all met up in a hotel just off the M1 near Wakefield and set up our table. And although NetSurf as a project now has much more usage on other platforms we still represent the principle browser for the RISC OS platform!

We had a pleasant time, talked to a lot of users and made our expenses back in donations. Overall an amusing Saturday. Based on the size of the event and number and age of the attendees, I fear the RISC OS may be destined for the history books.

Repaying a debt

Some debts are merely financial and some easily repaid but some require repayment in kind . Few debts are more important to me personally than a favour earned by a good friend.

Several years ago, before I started this blog, I replaced the kitchen in my house. Finances were tight at the time and I had to do the entire refit with only limited professional help. Because of this I imposed upon Mark Hymers and Steve Gran to come and assist me. They worked tirelessly for three days over a bank holiday for no immediate reward.

Mark and Steve with a drill

This weekend I had the opportunity to assist Mark with his own kitchen refit and reply my debt.

Although the challenges have been different on this build they were, nonetheless present, including walls which were most definitely not square and affixing cabinets 10mm too high so the doors could not close.

We also got to make a hole for a 125mm extractor which was physically demanding and not a little tiring (Steve actually wielding the drill had a fabulous aim)

I took some photos to document the process which has resulted in an image which is positively threatening, though the two of them are nice people really!

All in all a pleasant weekend with friends, the whole favour thing was really moot, I would have done it for a friend anyway.

Failing to avoid the spotlight

I am usually fortunate at conferences and aside from the obligatory "group photo" manage to completely avoid being in photos and videos of the event. However recently I attended the Linaro connect event in San Francisco and somehow got volunteered to be on a panel. 

Now usually such panels are fine and you get a bit of notice and can at least get some basic ideas and no-one bothers to film them. This time though I was not so fortunate and with no notice the overweight greying old fart has been captured on video.

 So here for your viewing pleasure is the panel discussion on "Is the GNU user space dying?". I should warn readers of a sensitive disposition that I appear fully dressed and awake(ish) in this video so viewer discretion is advised.

NetSurf Developer Workshop

Over the weekend we held the NetSurf developer workshop. The event was kindly hosted by Collabora at their Cambridge offices. The provided facilities were agreed to be excellent and contributed to the success of the event.

Five developers managed to attend from around the UK John-Mark Bell, Vincent Sanders, Michael Drake, Daniel Silverstone and Rob Kendrick. In addition James Shaw, one of the project founders, made a special appearance on Saturday.

Starting from Friday afternoon we each put in over 25 hours of actual useful work and made almost 170 commits changing over 350 files, added 10,000 new lines of code and altered another 18,000.

The main aim of the event was to make the transition from using libxml2 to our own libdom library for the browser DOM tree. This was done to improve the browsers performance and size when manipulating the DOM but also gives us the ability to extend the browsers features to include dynamic rendering and Javascript

We also took the opportunity to discuss and plan other issues including:

• User interface message handling and translation.
• User preference handling.
• Toolchain support.
• Disc caching.
• Javascript binding
• Electronic book content handler.

Rob tackled the first parts of the messages conversion from numerous separate files into a single easy to handle file which will in future allow for easier translation and reduce message proliferation.

We made decisions on the ongoing rework of user preference handling which will be implemented in future.

The decision on the toolchain was slightly changed to be that any core or library code (non frontend/toolkit specific parts) are required to conform to the C99 standard. Frontends are permitted to recommend and use whatever tools their maintainer selects but they cannot enforce those restrictions on core code. This issue is principly because the BeOS maintainer is compiling NetSurf with g++ 2.95 which is missing several important language features we wish to use.

The recurring issue of disc caching was raised again and we have come up with what we hope is a reasonably elegant solution to be implemented over the forthcoming months.

Now there is a suitable DOM to bind against, the existing Javascript engine support will be properly integrated and should result in basic script support before the 3.0 release. This support will remain a build time option so NetSurf can continue to be used on platforms where the interpreter is too resource intensive to be used.

A short discussion about the possibility of integrating a basic page based content handler for epub and mobi type documents was discussed and while the idea was well received no decisions on implementation were made.

Overall the event was a resounding success and we are left with only a small handful of regressions which appear straightforward to solve. We also have a clear set of decisions on what we need to do to improve the browser.

Time flies when you are having fun.

It has been months since I last put something here, so I think that requires a quick catchup.

The family Christmas was a brilliantly restful affair mostly spent doing nothing at home, just slightly tinged with anticipation of starting the new job.

I arranged to rent a room in Cambridge with just a moderate three mile walk to work. This has meant that after a decade of my daily commute being the steps downstairs to my desk I am now walking six miles a day!

Because of this unexpected physical exertion I seem to be slowly loosing weight instead of gaining it. Alas there is still a long way to go before I am my recommended weight (unless I gain three feet in height ;-)

Work has been fabulous, lots of great people doing interesting stuff. I was here only a month before I got sent to San Francisco for the Linaro connect event. Though getting on the outbound plane amidst the worst snowstorm in recent times was both tiring and not a little stressful.

The waking up at 03:00 to get the 04:00 coach from Cambridge to Heathrow would not have been too much of an issue If I had managed to travel down from Leeds and arrive before 02:00. The coach was so much fun that I arrived at 08:40 just as check in was closing for my 09:45 flight.

This was my first experience of San Francisco (although I have been to LA and Portland previously) and while most of the time was spent out in Redwood city at the conference venue Robert did take us for cocktails, comedy and cable cars which was a wonderful night out.

Since my return from the US I have also attended the Debian Bug Squashing Party in Cambridge and had a thoroughly amusing time with many of the usual suspects though I was encouraged to see a few new faces about too.

The commute up and down the country is getting tedious and seems to vary between taking two and four hours depending on traffic. This is encouraging me to consider moving the family as soon as I can. They are all doing great and seem to be thriving despite my absence during weekdays.

I hope to put finger to keyboard here a bit more regularly in the forthcoming weeks though a lot of my personal time is being swallowed with commuting and not being directed towards my open source pursuits.