Towards the end of 2010

Howdy, dear reader!

It’s been a while on this blog, mainly due to the fact that many short status updates are better twittered than blogged. Then again, as promised / threatened in last year’s installment of this column, I had to spend most of the time this year with iOS development, rather than with FOSS — and it doesn’t look like this will change much (you know, food and things…). Still I do care a lot about projects like OpenEmbedded, Vala,, and the like, so here’s what has been going on this year:

OpenEmbedded (

OE moved along quite well this year. I did not have much time for it — other than taking care about a couple of Vala and FSO recipes — but I’m especially pleased that the community finally embraced major clean up. Thanks to Frans, Richard, and all others involved, OE is improving heavily — although it wasn’t easy: Over the last couple of years, the OE core contributors developed a resistance against any changes affecting more than a handfull of recipes, however in order to make OE handle even more contributors and various use cases, we had to do some substantial cleanups. This will reduce maintenance and improve the overall quality of recipes in OE, which is the #1 complaint I hear.

Vala (

During the first half of the year, Vala went through some extremely tiring phases of non-activity, which improved vastly when its main developers opened up a bit, i.e. giving more developers access to the tree, adding branches, etc. There have been many changes in the Dova profile, but also the GLib profile has seen an incredible amount of work, bugfixes, some new features, and more.

The pace of changes that affect basic things had also impact on my vala-book plans; apart from a severe lack of time on my side, I think it’s better to wait until Vala is closer to 1.0. Otherwise I risk describing a moving target, which — considering the time I have to work on that project — would effectively kill it. That said, it’s great to see that Vala is getting better every day and gains more and more popularity from all kinds of developers.


The progress on is two-fold; on one hand, we have seen quite a nice amount of work to support more devices. On the other hand though, in contrast to all the work I did in 2009, there has been a severe lack of development of the core in 2010. This I plan to change as soon as possible. For 2011, I see myself continuing to develop FSO in the following three dimensions; internal, external, and integration.

  1. Internal | FSO is a heavy DBus consumer. I think by now we are one of the largest projects using DBus, at least considering the amount of API and running processes that communicate with each other via DBus. We always had our share of problems with DBus, especially some concurrency problems and race conditions are still haunting us. Both libdbus and dbus-glib exhibit their own share of problems, obviously this is not much of an issue on the desktop, but it turns out to be a major PITA on embedded systems, such as a phone. That’s why I have been excited since I heard that the glib team planned to write their own DBus backend and put it right into the glib. This work has now been released as of glib 2.26. Over the next weeks, I will port FSO to using gdbus in a branch.
  2. External | DBus-signals have some problems. That’s why some big projects (BlueZ and ConnMan, to name two of them) adopted an agent-style of API, where the clients have to implement a server API which is being called by the actual servers. While this means some more work for client developers, it has major benefits. I’m going to change some of our APIs to adopt this style.
  3. Integration | To deliver an integrated solution for today’s mobile phones, FSO needs to add more glue to work with existing services, such as BlueZ (bluetooth connectivity), Connman (ethernet and wifi connectivity), and some VoIP services. While these services work fine on their own, FSO lacks an API that uses these individual services in combination to achieve higher level tasks.

All this means that I will not be working much on the actual ports, but rather use my — very limited, did I say that yet? — time to drive the core forwards. I still believe that we will have full FOSS phones — other than the Openmoko devices — soon. Please help to make this dream a reality. (And no, please don’t talk to me about Android…)



Comments (4) left to “Towards the end of 2010”

  1. DnP wrote:

    Any news about sidplayer for iPad? :)

  2. mickey wrote:

    The sad truth is that while we have refined the concept to the point where we exactly know what we want, we did not manage to write a single line of code yet. Other clients kept us really busy this year. We still want to see all our players with a native and dedicated UI on the iPad, I’m afraid though it will take some more time.

    To tell a bit more about the problem… it’s a major undertaking since a) we want to get rid of the different apps and put all the playroutines (Sid, Mod, Pokey) into one app and b) we absolutely have to rewrite it from scratch.

    The codebase of the players is from late 2008 and it was our very first Objective-C and i(Phone)OS project thus… it smells badly :) We have learned a tremendous amount of things about the language and the frameworks in the last two years and therefore just can’t look too much at this dusty code.

    So… rest assured the new version will come, but it will take a bit longer than expected. As soon as we have a beta version early next year, you’ll get something to test.



  3. DnP wrote:

    Never mind :) Until then I’ll use Modizer…

  4. DnP wrote:

    It’s the end of year and nothing with sidplayer :) Is there any problem?

Post a Comment

*Required (Never published)