Report from XMMS2Con

The XMMS2 Team Hard at Work

Photo by Sébastien Cevey

Last weekend I arranged and participated in the first XMMS2Con. For those not familiar with XMMS2, it's a cross-platform Free software media player software suite that allows you to play audio files, manage your music libraries and more. Usually we do our yearly meetup at FOSDEM, but this year it wasn't possible for a couple of us to join, so I entertained the idea of a special meetup. We got a lot of things done and a lot of code merged.

First of all, we released the latest version of XMMS2, 0.7 DrNo, even before the Con started. This release was way overdue; in fact, it was nearly a year since our last release, 0.6 DrMattDestruction. We had a few reasons for the delay of the release — I think most of the people in the team are starting to feel the effects of their "real life." Some have become parents, others have been busy with work, school and other activities that have to take precedence over our love for hacking. But as always, when we get together and get to it, we get a lot of work done. I think I am not the only one to feel a bit energized and to come away with a lot of ideas that would be cool to see realized.

The most discussed topic on Saturday was GenIPC. What is GenIPC you might ask yourself? Well if you have been around and tried to write any XMMS2 bindings at any point you know that it involves a lot of manual labour for wrapping all the functions the server implements. GenIPC makes that effort less difficult. Our plan is to have the IPC definition in a XML file, which can then be used to generate the code for each binding. One of the benefits of this approach is that it will be easier to add new functions to all bindings. The other great benefit is that it will be easier to implement native bindings for all languages, since you only need to write the serialization and the code generator and the rest will be taken care of for you. Tilman Sauerbeck has done some great work with GenIPC and the server side of it was merged directly after the DrNo request. On Saturday Tilman, Anders Waldenborg and Henrik Gustafsson discussed a lot of improvements for GenIPC in order to allow for function overloading and default arguments. This work is now well under way and I hope to see it in the master branch pretty soon, since I want to convert native Qt4 bindings to GenIPC and also finish my Objective-C bindings.

The next big project that Sebastien Cevey and Daniel Svensson looked at was S4. S4 is our homegrown database backend that is supposed to replace the SQLite backend we have now. S4 was developed by Sivert Berg as a Google Summer of Code™ 2009 project. The rationale behind S4 is that we horribly misuse the SQL part of SQLite and force our datamodel into it. This mismatch leads to bad performance, lot of code overhead and so on. S4 solves this by introducing a datamodel that fits our use case a lot better. Preliminary tests show that S4 is a lot faster when you have a lot of entries in the database, in fact the only time it's slower is when you do advanced queries that use regex matching and that's slow almost everywhere. We will probably do some reworking so that we don't use regex, but rather globbing as we had with SQLite. I hope to see S4 merged soon.

We also discussed our participation in Google Summer of Code for 2010 and everyone was really looking forward to it. We discussed a lot of ideas that we could have propose as student projects and I think we have some really cool and interesting ideas coming up for 2010.

Thanks to everyone that came out. I had a great time organizing it and I am more than willing to do it again. I also want to make sure to thank Purple Scout AB for hosting us and Google for the fantastic Google Summer of Code program, that not only gives us cool code and good students but also money to spend on things like XMMS2Con.

By Tobias Rundström, Long Time Hacker on XMMS2 and Google Summer of Code Mentor

RTEMS and Google Summer of Code 2009

The RTEMS Project had 6 students accepted for Google Summer of Code™ 2009, with one additional student that was funded through the donation that Google gives to mentoring organizations in conjunction with a donation from OAR Corporation. We were extremely pleased with our students' results and their interaction with other projects, each other, and the community.

Xi Yang's project was to provide more RTEMS Board Support Packages (BSPs) that run on the free Skyeye simulator and to improve testing capabilities when using Skyeye. RTEMS uses Skyeye to test as well as GCC on ARM targets. Xi also implemented an LCD framebuffer driver for use with RTEMS.

Another student, Santosh Vattam worked on improving the Object Coverage of our test suites for a core part of RTEMS. Our initial coverage reports were generated for the SPARC/ERC32 using the closed source simulator TSIM. Santosh and I, his mentor, addressed cases which appeared to be test suite deficiencies while apparent simulator anomalies were passed on to Xi. During this, an obscure bug in RTEMS was uncovered and Xi and I worked together via chat to solve it. At the end of the summer, 3 SPARC and 2 ARM configurations were either at 100% or very close.

Santosh's project was a tie-in to the work of Roxana Leontie. Roxana operated under the same rules as Google Summer of Code but worked outside of the program. Her project was updating the Nano-X RTEMS port and providing a new RTEMS framebuffer device interface, and her first succesful demonstration was running the Nano-X Minesweeper program on RTEMS. As Roxanna progressed, Xi updated his LCD framebuffer driver to match her new interface.

Aanjhan Ranganathan's project was to provide a generic interface for RTEMS applications to use the Memory Management Hardware Unit available in most recent embedded processors for memory protection. His major tasks included studying the PowerPC MMU hardware architecture implementation and behavior, to propose a multi-level API design within the scope of RTEMS infrastructure. Most of the above tasks have been accomplished successfully and tested, but a lot of scope for further work exists.

Josh Switnick had a project which suffered from those unexpected "challenges" that make software development interesting. His project was to port RTEMS to the 8-bit AVR, as RTEMS had previously only been ported to 16- and 32-bit architectures. Mentors worked with Josh to produce a cross-toolset built with AVR specific libc support ported from AVR-LIBC to newlib, and to build the free AVR simulator simulavrxx. Josh produced a working port and is continuing to work to tidy up the loose ends.

Lucian Cocan's project was to continue the 2008 Google Summer of Code project of Real-Time trace. Lucian's initial work was to package the work into something that is suitable for a user. The tool was modelled on the command line tool, libtool, as it provided a simple yet consistent interface for the user. Lucian successfully produced traces for a number of the sample programs plus the example priority inheritance capture engine example.

JiSheng Zhang's project was to implement run-time dynamically loading relocatable object files or libraries into RTEMS, which is based on the IEEE Std 1003.1-2004 API (dlfcn.h) interface. Jisheng completed the basic functions of elf loader after the midterm, then he worked on figuring out how to get the dependencies included in the RTEMS kernel. Currently two tools are supported, i386 and sparc, and Jisheng is continuing to work on add other architecture support such as m68k, power pc, mips, and arm etc.

You can read my full report about our 2009 Google Summer of Code experience on the RTEMS wiki.

By Joel Sherrill, RTEMS Maintainer and Google Summer of Code mentor

Open-sourcing Living Stories

For the past two months, small teams of reporters and editors from the New York Times and Washington Post have been experimenting with Living Stories, a new format for covering news on the web. Using this technology platform, we can capture hundreds of developments as events unfold on a single dynamic page so that readers have many ways to easily digest the information. Living Stories has helped the Times enlighten readers on such subjects as global warming, the Afghanistan war, the N.F.L. playoffs and executive compensation. The Post has used it to report on health care reform, the Redskins' season and the overhaul of the D.C. school system.

Since we launched this proof-of-concept test on Google Labs in December, 75% of people who sent us feedback said they preferred the Living Stories format to the traditional online news article. Users also spent a significant amount of time exploring stories. This tells us there's a strong appetite for great journalism displayed in a compelling way.

In addition to the positive input from visitors, we've also heard from publishers interested in telling their own stories through the format. So we think it's time for the next stage of this experiment: releasing Living Stories more broadly to see what you can do with it. Today we're open-sourcing the code so all developers can build their own Living Story pages. (Here's the open-source documentation for technical details; read our Google News Help Forum to ask and answer general support questions.) Now that we're shifting into this public phase of the experiment, the Times and the Post are going to wind down their work on the version hosted on Google Labs. We'd like to thank them for embarking on this stage of the project with us. We're looking forward to continuing to work with them, and many other publishers, on Living Stories as well as other projects that help to advance how news is presented online.

In coming months we're going to look into creating software tools that make Living Stories even easier to use for news organizations. Until then, we can't wait to see what fascinating works of journalism developers, reporters and editors, working together, create using the open-sourced Living Stories code.

By Neha Singh, software engineer, and Josh Cohen, senior business product manager