Tempus Fugit
2007 was a very busy year for me. There has been great progress in the projects I care about, e.g. OpenEmbedded, OpenMoko, OpenEZX, Enlightenment, Maemo, Ångström, and some more. In 2007 I travelled more than in all the previous years in sum -- lets see whether I recall where I have been:
- Berlin (CCC, to meet colleagues),
- Bermingham (once for GUADEC),
- Bonn (for FROSCON),
- Brunswick (twice, to meet colleagues),
- Brussels (for FOSDEM),
- Denmark (for Mobile Developer Days),
- Siegen (to meet colleagues),
- Taipei (to work at OpenMoko Inc.),
- Zürich (for OpenExpo),
- and some more which I forgot about :D
A couple of weeks have been spent by my wife and me moving into a new apartment, my office room drowned and dried, I received dozens of parcels, and I saw (too) many new PCBs.
I saw a 3-man project growing into a company (with some unfortunate collateral losses on the way) and did a tiny little share to bring the Asimo robot forward. I met many interesting people on various conferences and in Taipei, and made some good new friends. Oh, and last but not least I (finally) got my doctoral degree.
It was a good year, albeit a bit too hectic for my taste. For next year, I'm trying to focus on less things, but more intense. Bringing forward my dreams of ubiquitous computing, high level application frameworks, and fluid user interfaces...
I wish all of you who read this a blessed 2008 -- may health and success be with you. See you next year!
First encounter with Vala
I just rewrote the openmoko-terminal2 application (a lightweight terminal for the OpenMoko environment using Vte) in Vala. Please compare with the source of the C-based incarnation here.
In my opinion, Vala is nothing more and nothing less than the future of application coding for the GNOME platform. Vala combines a nice high level syntax (modelled after C# and Java) using GObject as the object model and compiles straight away to plain 'ole C. Yes, that means no runtime libraries, no bloat, no performance drawbacks.
Vala removes the need of typing run time typecasts and endless function names and adds compile-time type checking. This will boost your coding-efficiency a lot. Vala has an enormous potential for the C-dominated GNOME platform and I hope people will realize that and be giving Vala a chance.
Yes, I still prefer Python (and C++) -- but now I have a sane escape route for some projects where I had to do stuff in C. Which I consider being a very good thing :D
P.S. Of course OpenEmbedded supports programs written in Vala as well -- I added the compiler a couple of weeks ago. Sane autotools-based projects don't need to do anything but add vala-native to the DEPENDS line.
Usability through Bling
Let me point you to two publications I found interesting:
- Interaction Designer Peter Sikking shows the necessity of a holistic approach in order to create stellar UIs.
- Gustavo Sverzut Barbieri compares UI toolkits for “fancy embeded interfaces”.
Framebuffer vs. X11
Putting some new fuel to the neverending fire -- whether the (undebatable) performance drawback of using a full-blown window system like X11 outweighs the benefits in flexibility; Just recently I built the Expedite benchmark utility (from the Enlightenment project) for my Neo1973 (266MHz armv4, VGA display, unaccellerated framebuffer).
Thanks to the Evas canvas abstraction, Expedite has tons of rendering backends, including ones for the framebuffer and X11. And here are the results of the jury:
”)
I this is is quite shocking (I expected the framebuffer to win, but not by that far). With an average frame-per-seconds of 17 for the framebuffer backend and 11 for the X11 backend, this looks like X11 introduces an overhead of about 50% on my platform.I wonder how the directfb and SDL backends would score -- I'm going to do these eventually. I'm also curious in the results of Gtk+/X11 vs. Gtk+/fb as well as Qt/X11 vs. Qt/Embedded. I'll do that once I have nice benchmark utilities for the respective toolkits.
Surely this result only applies to unaccellerated framebuffers, hardware-accellerated xrender may win by far, but this is what we don't have right now. The question is, did we bet on the wrong horse here? Do we really need all the goodies X11 give us? Do we really need a windowing system abstraction on a phone? Do we really need to run multiple toolkits in parallel? What do you think?
Java for OpenMoko moves forward
FSFE fellow Robert Schuster informed me about his progress bringing Java to OpenMoko and presents an interesting free software view of OpenMoko.
Collaboration Launch on PhoneServer and DeviceDaemon
With a subtle delay of something like 11 months, I managed to visit the friendly guys from Kernel Concepts in Siegen last week. The most important subjects were how to move forward with regards to a phone server and device daemon collaboration. Here is a short summary what these two things are, why we need them, and what we are going to do.
PhoneServer
A phone server encapsulates the access to the telephony subsystem. It is necessary to allow multiple clients query the state of the subsystem and to perform operations taking non-functional requirements like concurrent access, security, information caching, and quality of service, etc. into account. Similar components can be found in lots of closed source smartphone platforms. The free software community is still missing such a component. Yes, there are first approaches in OpenMoko (libgsmd), Qtopia, GPE Phone Edition, and probably more, but neither one supports all our requirements on such a component.
I have been reluctant to think about a phone server until being more certain about its place in the platform and the way it should talk to both the upper layers and the lower layers. As reported in previous installments of this column, by now I am sufficiently convinced that dbus is the proper abstraction (and collaboration) line, hence the phone server needs to talk dbus.
We will now start to work on a minimal dbus interface specification of the phone server. Since the folks that brought us the GPE Phone Edition have good contacts to the Linux Phone Standards forum, we are expecting input from people who have tons of experience with telephony APIs. However, this will not just be a completely free and open specification process, but also backed up by code -- in the good tradition of FOSS projects. So, I'm inviting everyone and their brother to collaborate on this telephony API. Especially application programmers, please tell us which syntax and semantics you prefer. I have just opened the freesmartphone.org wiki and will fill it with some of our initial thoughts soon.
The first milestone will be a phone server that talks to libgsmd, although I'd love to see a backend for the Qtopia gsm code as well. I'm very happy to see Ixonos' work on gsmd2, I'm sure this also will be some valuable input for us -- perhaps even an alternative backend or more!
DeviceDaemon
The other thing everyone wants but seems reluctant to work on is a peripheral device daemon. Throughout my involvement in the embedded Linux community I have seen dozens of those daemons in different flavours, all more or less device specific, hardcoded, not extensible, etc. I myself have implemented more than one hardware abstraction layer from scratch. The desktop world has HAL, OpenMoko has neod, GPE Phone has machined, the Zaurus guys have zaurusd, Opie had odevice, and more! All that duplicated work should really end now and be consolidated into one extensible lightweight machine and peripheral daemon.
As with the phone server, over the next couple of days I will add some initial thoughts into the freesmartphone.org wiki. Please see Florian's blog post here and this wiki page for some more details. Right now it's not even clear whether we need something completely new -- we also consider stripping down HAL or reimplementing it using the same dbus interface to be able to reuse OHM.
Again, I'd be delighted if we can could quickly start adding some real world requirements and dive into coding. Please feel invited to contribute.
Maemo & OpenMoko
I've been accepted to the N810 Internet Tablet developer device program -- thanks Nokia! I'm going to use this opportunity to work on sharing more technology between the Maemo and the OpenMoko platforms.
OpenMoko Media Player and Web Browser
On the last day I was in the OpenMoko Office, MokoNinja visited me and we recorded videos where I present the state of the OpenMoko Media Player and the Web Browser.
Almost back in Germany
::: {.img-shadow}
{width="200"}
:::
你好! My stay in Taipei is almost over and I want to update you all on some news around my work here in the OpenMoko, Inc. office. During the past couple of months, I have dedicated lots of my resources to improving the current incarnation of the software stack for our existing users, the GTA01 early adopters. We have now come to a point where the OpenMoko SmartPhone Stack is almost there. Especially Telephony, PIM and the mediaplayer have gotten much better throughout the last months. We even have a nice new webkit-based browser with a slick and simple interface. All in all it's getting better every day and I'm very confident, we'll iron the last problems out within the next couple of weeks... and this is where the actual fun begins -- once you guys can implement all your crazy ideas on top of this platform.
::: {.img-shadow}
{width="200"}
:::
To support this, the management and me agreed that for the remainder of this year, I suspend my position as overall platform architect to become the head of the new tools group. As such, I'm going to concentrate on improving and streamlining the developer's experience (read: SDK). Once the most important problems in this field have been solved, I will get back to my original role. As for the future of GTA01, we have yet to ship a GSM firmware update and a working GPS driver. This is pending some legal issues at our end which I would have hoped were resolved by now, but once the ball is in the court of the lawyers, it's rolling very slooooooooooow.
Structure-wise there has been a lot of friction -- disagreement, fear, uncertainty, doubt, you name it -- while OpenMoko migrated from being that crazy open source project inside FIC to being an independent 50-something-people-company whose upmost priority is to stay in business. We grew so fast that we couldn't scale, hence the only way that got us back to operational mode was to impose a renewed and improved structure on it. I guess this is an almost inherent effect of rapid growth.
::: {.img-shadow}
{width="200"}
:::
The actual outcome of it is that we engineers can now safely step down from being part-time network administrators, product managers, marketing experts etc., since we now co-work with dedicated people that perform these tasks. Which is good. Even better is that I really enjoy working with the local engineers. It took us a while to get started communicating well, but now it's great. We have so many bright guys in this company that I'm proud of being a part of it. With the improved structure and a respectful passing of ideas, specs, and code forth and back, our engineering teams will perform much better implementing exciting new software products for OpenMoko.
All in all I have enjoyed this stay in Taiwan very much, a lot of my pleasure courtesy to the great weather, my health, and all the nice buddies in the OpenMoko Apartment and the Office. Thanks guys, you know who you are -- 谢谢! :D
On to Taipei
Tomorrow, I'm heading over to Taipei for a while. I have mixed emotions here, on one hand I'm really looking forward to meeting all the guys again and seeing the shiny new OpenMoko office -- on the other hand, there is quite a bit of internal disagreement which may only be resolved by some serious discussions. Being the optimist though, it is my hope and utter belief that I will return from this journey with a renewed vision and plan for the next 12 OpenMoko months.