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…
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.