St.Augstin, Braunschweig, Berlin, Taipei
Although trying (really!) to cut down travelling, it’s still a lot. Here’s a sweeping swipe of what happened during the past couple of months and what’s going to happen soon.
Froscon
FrOSCon took place at its usual place on the last weekend in August and it was a very well organized conference – even better and more streamlined than the previous year was. I had the pleasure to listen to the Minix3 talk from Prof. Tanenbaum, which was very entertaining. Unfortunately my Openmoko talk was right after his one, so I had to take people kind of down to earth ;)
Since I was feeling pretty weak at this weekend I could only attend the first day. Looking forward to next year’s session.
Braunschweig
Been travelling from Frankfurt to Braunschweig (to work with the Openmoko students on the framework) for a couple of times and I have started to actually use my Openmoko FreeRunner as a GPRS-forwarding device for my laptop. Using the freesmartphone.org framework it’s a breeze to do that. I just have to issue the dbus command ActivateContext("internet.eplus.de", "", "") and wait until the context goes online. Then I use iptables to enable NAT and forwarding for the laptop on the FreeRunner and it’s done.
GPRS is very solid on the FreeRunner – it works for hours without any disconnections or other interruptions. If the data connection is not 100% loaded you even get incoming call signalling and can take phone calls in between
Framework
Talking about the Openmoko / freesmartphone.org framework… we had a successful milestone3 release of it, debuting PDU-mode for SMS and phonebook data as well as lots of bugfixes over the place. We also have some nice reference docs now – i’m still working on introductionary type docs.
Unfortunately despite me trying to educate, lots of people still don’t get the point of the framework releases – I get frequent comments on the testing UI zhone, but rarely anyone is actually contributing to the dbus API specification and implementation discussion :( I seriously ponder whether to release console images in the future to make this 100% clear. I say it again: FSO is not about user interfaces, it’s about a strong independent dbus service level framework to facilitate 3rd party development.
That said, there are four important contributions in the freesmartphone.org world: pkg-fso, fso-gpsd, frameworkd-glib, downloads.freesmartphone.org:
- pkg-fso is a team coordinating the packaging of any software from the FSO initiative (and, widely, any software related to Openmoko).
- fso-gspd is a program offering a compatibility layer for the org.freedesktop.gypsy implementation of ogpsd. There are a lot of programs using the gpsd interface and with this compatibility layer, those programs will still work, but benefit from the improved accuracy of the UBX-based ogpsd.
- frameworkd-glib is a C library offering bindings to the freesmartphone.org framework APIs. Handling modern dbus APIs can be cumbersome in C (think a{sv} and friends), so this library offers you convenience functions for that.
- We now have official feeds unavailable hosted by a machine living in the same rack that serves kernel.org. Thanks to our friends at NSLU2-Linux.org unavailable and OSUOSL.org.
All software goodies live in our git repository.
Mobile Developer Days ’08
Last week I had the honor to give an invited talk about OpenEmbedded and Qt-integration into OE for the Mobile Developer Days 08 conference in Berlin. This conference is pretty unique in that it adopts a platform-agnostic approach, i.e. you will find people working on Symbian, Qt, PalmOS, Windows Mobile there. I even spotted iPhone folks. In my opinion, such a holistic approach is important for the future of development on mobile devices. Congrats, folks.
Speaking about the iPhone… true readers of this column may remember that I have been a MacOS user since early this year. To add up on this, lately I acquired an iPhone to gain some experience with this exciting new development platform. I have just been looking into what this system provides. I can already say that there’s a whole lot of stuff where FOSS can learn and I’m glad to be a part of both worlds, so I can try to be a catalysator.
Taipei ’08
On Sunday I’m going to fly over to Taipei. It’s been a while (12 months to be exact) since I met the folks in person there and there’s lots of stuff to catch up on. Now that the framework approaches its 0.9 release at the end of the year, we need to discuss the plan for the next 6 months. Can’t wait to meet all the engineers again! It’s going to be three interesting weeks. Stay tuned :)
{width=“200”} 
{width=“200”} 
{width=“200”}GTK, ASU, FSO? TMTLA!
With the new Openmoko Framework initiative (as posted in previous installments of this column) facing its first milestone release unavailable (nothing but solid phone calls, so don’t be disappointed. If you have no Openmoko device, check out the video in the same directory), we are now facing three different major software stacks for the Neo family (there are special-purpose variants, but I won’t go into details here). As there is quite a chance that developers might be confused about that, I want to use this chance to sketch the big picture and answer some of the questions around the future of these stacks.
Products
Openmoko is selling hardware products. Openmoko funds work on software stacks, so that the actual hardware can be more than just a developer board, but rather approaching a useful mobile compagnion. As with all kinds of products, Openmoko products have a – more or less specific – target audience. However, as we learned during all these months since we sketched the first product in the nice summer of 2006, even this specific target audience is not completely homogenous. The existance of the three software stacks is both due to the fact that we all are still learning how to write software for mobile devices, but also because there are quite substantial differences in what people expect from and want to do with their Openmoko devices.
Stacks
So – what are these three stacks, where are the actual differences and who should run which stack? In a nutshell, it boils down to the following:
- The Openmoko 2007.2 Stack, utilizing GTK+ and assorted applications. 2007.2, since it was the 2nd iteration of the GTK+ user interface that we released in 2007.
- The ASU Stack, the combination of a classical smartphone stack based on Trolltech’s Qtopia ported to X11 and enhanced with an EFL-based launcher and new applications. You may have seen the term Illume which is the launcher of ASU.
- The FSO Stack, also known as the Openmoko Framework initiative. This one is called FSO, because it’s an implementation of the freesmartphone.org APIs. You may also have seen the term Zhone which describes the framework testing user interface and is a minor part of this stack.
Openmoko 2007.2 is for people who are familiar with the GNOME Mobile unavailable initiative and who want to write applications that run on multiple devices running (parts of) GNOME Mobile. This includes Maemo, which runs on the Nokia Internet Tablets. The strength of the GTK+ stack is a UI and programming environment similar to what you run on your Linux desktop, if you’re into GNOME. The GTK+ has PIM applications based on the Evolution Data Server and runs the gsmd phone server. Although you can use them, the applications are still pretty rough und unfinished. Some people have problems with the stability of the phone server.
ASU has been started to integrate the Qtopia unavailable stack – ported to X11 – with a new set of graphically pleasing applications based on the Enlightenment Foundation Libraries. Qtopia is a more mature product than the GNOME Mobile stack and you can expect all the standard feature phone applications to work in a solid way. It uses the Qtopia phone server. Since – contrary to standard Qtopia – it does not directly use the framebuffer, non-Qt applications can safely share the screen with Qt applications, that is until you are writing applications that do not communicate with the framework. If you want to integrate, then you’re back to C++ and Qt.
FSO has been started to overcome the deficiencies both of the 2007.2 and the ASU stack, namely to come up with an extensible framework that gives developers the infrastructure they need to create solid and exciting software products based on the Openmoko platform. An infrastructure that supports competing UIs while we can collaborate on developing services, making the framework strong . Here, the focus is on stable highlevel services that you can access from whatever language or UI that supports dbus unavailable. People report that despite its infancy, e.g. the phone server part in FSO is already more solid than anywhere else.
Future
Right now, Openmoko’s priority is getting the ASU to a point where it is stable and satisfies the every-day use with the FreeRunner product. In parallel, Openmoko recognizes the framework initiative as critical for further iterations of their software stacks. The goal is to be able to take one application from one stack and replace it with an application from another stack. Once all applications are framework-aware, this goal can be reached – which also implies userdata compatibility between software stacks, of course!
In practice, this means once the framework has reached a certain extent (see our issue tracker — for tasks, issues, and milestones), we can expect it to be seen in all kinds of products, likely including further releases of the ASU. Until then, the FSO image is already your best bet if you want to write something that is tailored for your special usecase. If you want, you could also help us shaping our framework-testing-toy Zhone into something that fulfills the daily needs :)
Of course, Openmoko would also love to see Openmoko 2007.2 getting more love, but they don’t have the resources to do it. If you are interested in working on it, here’s a strategy I’d recommend:
- Remove neod, gsmd, and phonekit.
- Integrate the framework phone subsystem and make the dialer talk fso.org OTAPI (substituting gsmd and phonekit).
- Integrate the framework device subsystem and make the launcher use it (substituting neod).
- Debug and polish the PIM applications.
- (optional and only when it’s ready) Integrate the framework PIM subsystem and make the PIM applications talk framework.
I hope that answered most of your questions. If not, feel free to add more via commenting this article.
Momentum
Momentum is something really strange! It’s hardly predictable and you have to run to catch it before it goes away – but when it’s there, things are progressing like there’s no tomorrow :-)
There’s a whole lot of momentum present in some of the projects I care about:
OpenEmbedded
- OpenEmbedded will abandon monotone and move to git as its primary SCM. This will increase the wide-spread adoption of OE and attract new people. We will have more (shortlived) branches and merges will be easier. We will also revamp the commit policies a bit to introduce more stability to both the stable and the unstable branches.
- Setting up the non-profit organization (german registered association e.V.) is progressing and we will soon have our legal entity.
- Some couraged people are revamping our website into something that’s more accurate, structured, (and pretty). Good for both OE-novices and experts.
OpenEZX
- OpenEZX developers started to push for mainline inclusion. This will greatly increase the visibility of our project.
- OpenEZX developers are working on a 2nd stage bootloader that overwrites the MOTO kernel, but leaves the rest of the flash file system untouched – by this we can boot both an OpenEZX kernel from SD as well as the original system (with its kernel on SD), which makes testing a relief.
- We found security holes in the MOTOMAGX kernel, which may enable us to put our own code on these systems.
- Motorola has released new devices, apparantly running EZX. More devices for the platform!
- Openmoko’s Framework and Zhone phone UI is going to provide a slick looking – working – featurephone userland for OpenEZX – the first releases are just a couple of days away. It’s now important we get kernel work finished, so we can release something that is a real alternative to the closed source MOTO system on EZX devices.
Openmoko
- Openmoko successfully went into mass production of the Neo FreeRunner (GTA02) device. Finally, people will have the 2nd generation of the first truly open source hardware platform in their hands.
- The Qtopia/Enlightenment based next generation software update is progressing nicely. I expect a release in the next couple of weeks.
- The new dbus-centric Openmoko framework initiative as well as the Zhone bread-and-butter application will see a release within the next 48 hours.
Exciting times for Linux on mobile platforms, n’est-ce pas?
State Machines -- Resistance is Futile
::: {.img-shadow}
{width=“200”}
:::
So I’m rewriting the call handling in the Open Phone Daemon for the second time now. Cowardly, twice I tried to get away without implementing a full state machine, but it always came back to me.
Telecommunication stuff is all about state machines, and honestly… they are your friend, not your enemy.
Yet another reason to see that my third semester in university with all the finite state machines was not superflous :D
Chemistry
I seem incapable of working together with some people. I tried hard, but it just doesn’t work. Everytime we discuss anything my blood pressure is raising and we run into arguments. I’m sick of that. Perhaps it’s just me – I’m afraid the older I get, the less patient I get. Then again, it could be just a matter of chemistry – some pairs function, some not. Might be nature.
Froscon Submission Deadline in 10 days
I just realized it’s only 10 days until the Froscon call for papers unavailable has its deadline. You should better get started submitting a paper – I will do the same. Looking forward to seeing you at one of germany’s nicest OSS conferences!
Openmoko Framework Initiative
I have not been posting about my work for Openmoko for quite a while. There are multiple reasons for that, ask me privately if you want to know… Today though, I want to post about a high-priority project inside Openmoko, Inc. – the new framework and middleware initiative which me and some guys will be working on.
I have been talking privatly about this to people on conferences, but now it’s going to be an official project. It’s something we attempted to do when we started back in 2006, but for some reason, we did it the wrong way. We tried taking existing components to make them fulfill our usecases and to fit our needs, which in some cases turned out to be impossible. This time we’re moving the other way round. We will take our usecases as the goal and create the necessary infrastructure to make it happen. If – while we’re on the way – can integrate existing efforts, even better. If not, we will eventually see how to merge with existing efforts. The goal is to get things done – now!.
Basically all this is about two components, which are independent, but closely related.
- The framework.
- A bread-and-butter application.
The Framework
::: {.img-shadow}
{width=“200”}
:::
The purpose here is:
- Give people the infrastructure to create solid and exciting software products based on the Openmoko platform,
- Support competing UIs while collaborating on developing services, and
- Encourage framework users (e.g. application developers) to also contribute to the framework.
With this in mind, we define the following requirements:
- Make it simple,
- Concentrate on core services,
- Be programming language agnostic,
- Be UI toolkit agnostic, and
- Try to reuse existing technologies as much as possible, but not at the cost of a bad API.
Our way to achieve this on a technical level is through dbus:
- Chose dbus as the collaboration line. Below dbus, we can work together. Above dbus, we can differentiate.
- Expose features through dbus APIs implemented by UI-agnostic and language-agnostic services (daemons).
- Optimize for Openmoko devices, but support multiple architectures (OpenEZX, Xanadu, …) and purposes through plugin interfaces and suitable hardware abstraction mechanisms.
- Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars. ;-)
The framework is not going to cover everything but the kitchen sink though, especially it’s not about:
- Bootloader, Kernel, or System Init.
- X-Window-System, Window Manager, UI Toolkits,
- Application Launchers, Applications, or Fancy UIs.
The Bread-and-Butter application
::: {.img-shadow}
{width=“200”}
:::
The framework initiative is related to developing an application that uses the framework to turn a Linux-phone into a usable feature phone. The main goals for this application are:
- Make it simple,
- Concentrate on core features,
- Have a beautiful, efficient and consistent UI,
- Be easily extensible through scripting, and
- Show the power of the framework.
This application is developed in tandem with the framework, because when you write framework APIs, it’s important to have existing API consumers. Without API consumers, APIs are just specs, could be awkyard, or plainly unusable – that’s why this bread-and-butter application is of central importance to the framework project.
I’m looking forward to spend a lot of time on this project and I invite all of you to participate. Most of the discussions will happen on the Openmoko developers mailing list and the FreeSmartPhone standards list We already have achieved some important basics thanks to great contributions by the moko underground people that are grouped around the neo1973-germany.de site and the IRC channel #neo1973-germany. I’m also looking forward to great results from this years’ Openmoko Google Summer of Code. As for the current status, we will update the wiki page OpenmokoFramework frequently and sent status updates once and then to the mailing lists.
Good speed!
Bossa Conference Video
The guys from INdT posted the Bossa Conference promotional video for next year’s installment:
Yours truly can be found a couple of times… so – how many appearances do I have in this video? :D
Last day in Brazil
Sitting in the business center of the Beach Class Suites hotel trying to fix some strange bugs in ecore-native. In a couple of hours I’m leaving to the airport, travelling back to Frankfurt, Germany. This week in Brazil has been an amazing experience, especially the friendly guys at the INdT. There’s a spirit of freedom and creativity hanging over the whole installation and it’s not surprising at all that the results unavailable just rock. One of the key elements of successful software products is the communication between designers and developers – and they got this one completely right.
The Mamona team worked on an own branch of OpenEmbedded for quite a while now and we had a lot of diffs to go through. We started with merging EFL and Python since these are also important for Openmoko. We now have granted Vivi commit access and Aloisio will be on board soon as well maintaining some of the recipes upstream at org.openembedded.dev. By that we reduce further divergence and improve collaboration.
Although we did work most of the time, we also had the chance to hang around a bit together in the after hours, watching soccer, playing table-tennis, table-soccer, pool, etc. We even spent a couple of hours playing guitar and singing along – that was real fun. Thanks a lot guys, I really felt welcome! And yes, I’m trying to come back later this year, preferably when it gets cold and windy in Germany ;)