Blog
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:
[
](/images/expedite-benchmark.pdf “Expedite Benchmark (PDF)”)
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 unavailable and presents an interesting free software view of OpenMoko unavailable.
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 unavailable, GPE Phone Edition unavailable, 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 unavailable, 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 unavailable, the Zaurus guys have zaurusd unavailable, 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 unavailable 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.
Back from OEDEM’07
::: {.img-shadow} OEDEM07 photo unavailable. :::
The second annual OpenEmbedded DEvelopers Meeting took place in Berlin from the 6th to the 10th of October 2007. Due to the slight overlap with my vacation in Portugal, I couldn’t attend the coding sprints on 6th and 7th, however I could make it to the technical discussion days on 8th and 9th. On 9th, the generous folks from Tarent sponsored our dinner for which I’d like to say a big “Thanks, folks!!!”
This time we not only had the core developer team on board, but also key people from the various communities and interest groups, i.e. Stelios from Digital Opsis, Robert from Tarent, Graeme and me from OpenMoko, Florian from Kernel Concepts, Uli from ROAD, Philip for the Gumstix unavailable community, and more.
I’m not going to repeat all of the discussions we made (that’s what we have the meeting minutes unavailable for), however this is the executive summary from my point of view:
::: {align=“left”} OpenEmbedded has four major issues that prevent even more wide spread acceptance. In a nutshell, it boils down to :::
::: {align=“left”}
- Too much progress:
org.openembedded.devkeeps constantly changing and (temporarily) breaking. - Too much flexibility: If you want to use it as the base for your product, you’re overwhelmed by the amount of options.
- Not enough documentation: The reference documentation is nice, but it lacks actual workflow based tutorials and a general overview.
- Bad reputation about being too complex: If all you want is building applications, the learning curve is a killer. :::
::: {align=“left”} We sat together to come up with a plan of action to fix most of these issues. Briefly: :::
::: {align=“left”}
- Last year we agreed to releasing metadata snapshots. Most of the infrastructure (autobuilder, regression tests, etc.) is in place now, so we can actually start doing these releases early next year. The snapshots will be known-good for a certain — documented — combination of image targets and target architectures / machines. Once the snapshot gets tagged, we will branch and only apply very critical bugfixes to this branch. People can then base product work on such a snapshot. We believe it’s going to be two or three releases per year.
- We will add more product-based templates as examples, e.g. images like wlan-router-image.bb, nas-image.bb, set-top-box-image.bb, …
- Once the OE foundation work has been installed, we will use these resources to hire someone for improving the documentation.
- At the end of the day, there are lots of people using OpenEmbedded who really shouldn’t. OpenEmbedded gets (ab)used as a development environment, which it is not — although there is the incredibly useful command
bitbake -c devshell. This can be fixed by handing out prebuilt OpenEmbedded toolchains to the people. People then can use these for application work without having to deal with OpenEmbedded at all. Alternatively — once they feel more brave — they can again use OpenEmbedded, but speed it up since they won’t have to go through the complete toolchain generation. :::
Once again, the issue of creating a registered non-commercial non-profit foundation was discussed. And this time, we finally agreed on the legal form and the statutes. We will create a german e.V. (eingetragener Verein) and the statutes will be based on the statutes of the KDE e.V.. The actual founding work will take place at FOSDEM’08 in February.