Category Archives: Projects

Speculating about SteamOS

It’s been a tremendously long time since any new content appeared here (I’ve even been considering shutting this web log down) but today I find myself eager to share some thoughts!

What could stir me from my slumber? Somewhat surprisingly I find myself uncharacteristically excited about a gaming platform and, as I no longer share an office with fellow nerds, I have no recourse other than to gush at the internet.

Despite not being a huge gamer (I have likely bought fewer than half a dozen games in the last two years) Valve’s recent announcement of SteamOS has me rather excited. There are three main paths along which my mind wandered when pondering what SteamOS could be:

Firstly, as a self-confessed operating systems nerd (and someone who has spent most of his career on the fringes of that world) I’m excited to see how Valve have architected their Linux-based OS. Whilst it’s possible that they could just choose to ship a spin of an existing Linux distribution (such as Ubuntu or Fedora) I’m hoping they’ve been a little more adventurous.

Thinking about SteamOS for a few minutes whilst browsing their announcement page a system more akin to Android in many ways comes to mind – a highly customised OS platform tuned to the needs of an entertainment device, rather than a stripped down generic OS. I’m certainly not drawing the comparison with Android because I’m expecting Valve to have written huge swathes of OS components that make SteamOS a different beast to a more traditional Linux, quite the opposite – I fully expect them to make use of the excellent Linux userspace which is readily available and widely tested. It’s how they put their OS together and structure things in terms of distributing software, updates and security (more below) which I expect to be different. Particularly as there’s unlikely to be any need to consider ‘legacy’ applications.

It’s perhaps unsurprising that I half-hope, half-expect Valve to be using the tools of the Yocto Project to develop their custom Linux-based OS. Standing on the shoulders of giants in the Yocto community Valve could, with a relatively small team of engineers, create their OS with a focus on the unique requirements of their entertainment platform instead of getting bogged down in the sundry, largely solved, problems of distribution construction.

Secondly, as someone with an increasing interest in information security and secure and trusted Operating Systems I see a good requirement in the platform for interesting security work. I look forward to interesting security solutions which balance human factors (I expect the SteamOS to be primarily driven by a joypad) with the need for a hardened OS which protects a user and their sensitive data (most likely banking details) from attack whilst ensuring the platform remains as non-intrusive as possible.

Finally, as a Linux developer, I’m rather excited about the prospect of folks (particularly some of my friends and family) having Linux-based entertainment machines in their living rooms. I’ve been thinking about a largely vapourware project to build a digital platform to enable pen and paper role players to game with their group, regardless of geographical separation. The project has remained vapourware, at least in part, because each imagined iteration has fallen short of anything tangible – largely because there hasn’t been a compelling platform to target. I have considered (and in some cases prototyped) targeting the XBox, the web and tablets, as well as writing a cross-platform desktop solution, but have hit road blocks when attempting to architect for each of them. (Side-note: huge kudos to the Roll20 team for realising the vision). I hope to be able to target SteamOS using the tools I am familiar with and re-using components of a gaming platform, such as multiplayer chat facilities.

Oh yeah, fourthly – video games! \o/

Update (14/12/13) – the first version of SteamOS was released yesterday and it looks to be a fairly stock GNU/Linux created as a Debian derivative.

Cooking on Gas

It’s been a while since I wrote anything original and interesting here and even longer since I wrote about work. Let’s try and rectify that.

The following is a re-post from the Yocto Project Blog, though I originally wrote it for this blog.

For the last 18 months or so I’ve been working full-time on the Yocto Project, where I’ve touched various parts of the system. I’m really proud of what our team has achieved – we have an amazing tool that people want to use! Despite that, there are still some common tasks that users can’t achieve as easily as we’d like…

A gas hob

Untitled By sunshinecity on Flickr

Our system, Poky, has traditionally assumed a certain familiarity (to varying degrees) with Open Source software, Linux and building software. However the more competent our build system becomes the more we attract the interest of potential users who aren’t a typical UNIX greybeard.

The Yocto Project has been making various efforts to improve the usability of the project at all levels. We have an excellent technical writer on our team who works (laregely underappreciated) on improving the documentation for our project, we have a small but dedicated team of people making application development for Poky built images easier – much of this work focused around enabling as much of the development as possible to happen in the premier Open Source IDE; Eclipse and a project-wide focus on making things simpler and easier to understand.

In line with this effort I’ve spent most of my development time over the last cycle working on a GUI for the Poky build system called Hob (the name ties in with the baking theme – a hob is what we call the top cooking surface on an oven in England).

The aim of Hob is to enable a user to perform common tasks graphically, we focused primarily on enabling you to generate a custom image for the initial release but have several plans for enhancements over the coming months.

By way of introduction I spent some time producing a video to demonstrate use of the Hob (I’ll avoid ranting about the state of Linux video editing tools), it’s available to watch on YouTube and Vimeo.

The challenge of the Hob was turning the traditionally batch-run BitBake program into something more interactive, unfortunately I underestimated how much effort this would involve such that what I was able to deliver in the Yocto 1.1 time-frame isn’t quite as functional as originally designed.

For Hob the problem is that there is only so much information we can know about the how a package will be built by looking at the metadata. For example: we can’t know which of the build dependencies will actually get linked into a resulting binary, so we can’t do accurate image contents prediction by operating purely on the build system metadata. To that end this initial version of Hob comes with a caveat, the reported image contents are only an estimate.

As well established by Brooks, this version of Hob ended up being sort of a Pilot System (“write one to throw-away”) and we’ve learned a lot from developing this tool. Fortunately I followed best practices as already implemented in the BitBake code base to modularise as much of the Hob GUI as possible. Further, as Hob is actually a BitBake GUI, rather than some kind of wrapper program, many of the improvements I made are in the core BitBake libraries and much of the code will live on as we develop Hob in future releases.

For the next release we’ll certainly be improving Hob, and whilst nothing is set in stone at this stage, we are contemplating switching to a two-phase build – where the custom image generation is done once packages have been built. If we go this route we can be more accurate about dependencies and the size of the resulting image. Our initial feedback on Hob leads us to believe that as many people care about customising the image after the build as care about customising how it’s built. With a two-phase mechanism we’ll be able to build GUI’s that work well for both scenarios and can be used seamlessly together in tandem.

Approaching a Consensus on Robotics Software

I’ve been playing with Robotics on and off for the past few months, it’s an area which I’m really interested in and really enjoy tinkering.

It’s now gotten to the stage where I’ve done almost enough reading and tinkering that I actually want to start trying to put some serious robots together and to that end I’ve been looking at some of the many robotics software frameworks which are available (just look at my robotics tag on delicious for some of the ones that I’ve deemed interesting enough to warrant further attention).

I’ve been pleased to find that there’s a high calibre crop of robotics frameworks which focus on reusable and modular components built upon a Service Oriented Architecture (SOA).

Other than being good software practice to modularise ones code the crop of SOA robotics frameworks also make it much easier for hobbyists like myself to get into robotics with a reasonably priced robotics kit and offload processing to a more powerful machine.

The big three SOA based robotics frameworks which have attracted my attention through their solid reputations and many projects built on them are MRDS (Microsoft Robotics Developer Studio), ROS (Robot Operating System) and Fawkes.

Both ROS and MRDS support the Lego MindStorms NXT 2.0, which is my current vessel for Robotics exploration (an excellent Christmas present from my wife), but I’m ruling out the MRDS (despite it’s good reputation) because it requires me to run Windows.

I’m also ruling out Fawkes, though it has recently being picked by the Fedora Robotics SIG as the basis for their robotics spin, because whilst it seems like a very promising framework their new starter documentation is lacking and they don’t yet support the NXT. I will no doubt be revisiting Fawkes in the future.

Right now I’m looking at the documentation for ROS but unfortunately it seems it’s a pain to set up on anything other than Ubuntu. Hopefully it’s just that the documentation is out of date…

I’ve also started putting together a layer for Yocto to include some of the robotics packages I’ve come across and their dependencies – I’d love to build a Yocto powered robot in the near future!

Finally writing this blog post was prompted by the Robot Magazine covering MRDS and ROS recently: “THE NEXT BIG THING! Service Oriented Architectures – Two leading systems, MRDS and ROS, point to the future of robotics“.