GTK, ASU, FSO? TMTLA!
With the new Openmoko Framework initiative (as posted in previous installments of this column) facing its first milestone release (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 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 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. 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 http://trac.freesmartphone.org for our 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 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 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 ;)
From Switzerland to Brazil
::: {.img-shadow}
{width="200"}
:::
As I have mentioned previously, I'm really trying to cut down the number of conferences I go to this year. However, both the OpenExpo in Bern (from which I returned last friday) and the Bossa Conference in Brazil (which I'm there since saturday) are too important to skip.
OpenExpo went very well, I had some good talks with people regarding further platform development. I had a talk where I outlined three major factors of OpenMoko (Freedom, Experiments, Innovation) and the forthcoming middleware initiative. If you manage to understand german, have a look at the video.
::: {.img-shadow}
{width="200"}
:::
The second of three days Bossa have passed now and I'm really enjoying Brazil. My talk about OpenEmbedded was on the first day and since then I'm more relaxed. I have never been a fan of the climate in Germany, so what I'm being exposed to here (an average of 29 degrees) is just about right :) Apart from the most amazing venue I've ever been to, it's the people and the topics which are completely right on spot. After the conference I will work for a few days with the INdt guys on merging our OpenEmbedded trees and collaborate on Python and the Enlightenment Foundation Libraries.
On a more personal note, OpenExpo and Bossa were partly responsible for bringing fresh new motivation into me and my middleware work for OpenMoko. All the developers I have met agree with me that -- for the time being -- there's hardly anything more necessary than a solid framework for people to get started with their own approaches on how to improve how we interact with mobile devices. Services like telephony, PIM storage database, network, location, and context, need to be there -- no matter which UI toolkit or applications we are going to focus on.
::: {.img-shadow}
{width="200"}
:::
I'll be heading back to Germany on saturday, looking forward to a spring full of refreshening infrastructure development (and some shiny bread-and-butter applications, of course -- middleware development needs to be application driven).
Let me finish with some more great news...
- The price range for the Neo FreeRunner has been published, it's going to be less than 400 USD -- which is quite a substantial improvement over the estimated 650 that was published last year. Given the features (Wifi, GPS, GSM, BT, Accellerometers, VGA) and the openness (priceless!) I think it's pretty decent price.
- OpenMoko Inc. has been accepted as a mentoring organization for Google Summer of Code 2008. I'm looking forward to mentor some exciting projects. Please start submitting student applications now!
Cheers!
Back from Fosdem 2008
::: {.img-shadow}
{width="200"}
:::
Just returned from Brussels where FOSDEM 2008 took place. For the second time, the OpenEmbedded team had a booth where we presented embedded devices and talked about build systems and software for mobile and embedded devices. On show were some Zaurus models, an iRex Iliad, two Chumbies, and a Neuros OSD.
We also demoed some FIC Neo1973 models with OpenMoko which received lots of attention -- the most frequently asked question was (of course) when the new hardware would be ready. I can't really comment on that, however John and Will from OpenMoko Inc. just brought me a brand new FreeRunner prototype and apart from some minor issues, it is really looking very well. By the way, I will demo this prototype next month on the OpenExpo 2008 in Bern, so if you have a chance, just drop by and take a look.
::: {.img-shadow}
{width="200"}
:::
Between talking to people, I managed to unbrick three devices. Unfortunately I forgot to reseat the TORX screws on one device, so if you want your screws back, come over next year. Luckily, the Neo1973 case fits very well even without the screws, so you will probably not miss them ;)
During a very remarkable meeting with a resident of the #neo1973-germany channel we improved the freesmartphone.org telephony API and also recorded a video of the moko underground software pyneo. Note: If you don't have sound on the videos, you need to install h264/mp4a codecs. A recent gstreamer-faad with libfaad2 should be sufficient.
On Saturday evening, team OpenEmbedded had the constitutional session for the forthcoming OpenEmbedded e.V. There's still some bureaucracy pending which I hope will be done around late April / early May. I'll keep you posted.
By the way, this was the warmest FOSDEM ever! I'm very amazed that I managed to survive it without a cold -- which is quite an achievement considering our booth was right opposite the main entrance resulting in a constant unpleasent flow of air. As for the general FOSDEM appearance I have to agree with Harald Welte's assessment though, especially his comments about the beer event venue and the public transportation.
I want to thank all of the people who helped organizing our appearance -- you really did a great job, guys!