::: {.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 unavailable.
::: {.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 unavailable 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…
Cheers!
::: {.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 unavailable 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!
So I have promised to travel much less this year, however some trips are inevitable. For the first two quarters in this year I’m looking forward to participate at least at the following conferences:
If you have a chance, then drop by and lets have a chat. Don’t be shy – people say, I’m a nice guy :)
As reported in previous installments of this column, the Maemo unavailable team picked me for a developer discount on the new Nokia N810 internet tablet (thanks again, folks!). I also own a 770 but skipped the N800, so this has been a huge jump for me.
The N810 hardware is pretty good. It features a fast processor, a nice display (not as highres as the one in the Neo1973 though), and a superb audio subsystem. The overall look and feel of the device is very convenient – well done, industrial designers at Nokia. Maemo grew a lot during the past years, I’m looking forward to write a couple of applications (in Vala, of course) and do my share to make Maemo and OpenMoko share parts of the platform.
I’m not feeling good on the keyboard. Don’t get me wrong, for me it’s pretty important to have one, but I miss the feel. The Zaurus C3x00/C1000 keyboard was better, let alone the Psion 5mx/Revo series. So there’s room for improvement. Also, I’m still not satisfied with battery life during real-life usage. This device is so great that I want to use it… a couple of hours a day. If you really do that you need to recharge daily.
This device is so fast that – together with nice software – it could be an incredible user experience. Alas, Maemo still thinks Gtk+ is the way to go and this is a seriously limiting factor. Thankfully some bright guys from Nokia Research, namely the INdT, already started going a much more promising route. Canola2 on the Nokia N810 shows two things:
An annoying factor is also that there’s still a whole lot of closed source contained in the operating system distribution. Also, scratchbox is cumbersome – I prefer OpenEmbedded which makes it more easy and standard to compile additional packages.
All in all, it’s a good experience and a very nice device. We can learn a lot from this nice project. And I hope that eventually we can do better… but watchout: Nokia doesn’t sleep ;)
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 unavailable, Ångström unavailable, 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:
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!
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.
Let me point you to two publications I found interesting:
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?
FSFE fellow Robert Schuster informed me about his progress bringing Java to OpenMoko unavailable and presents an interesting free software view of OpenMoko unavailable.
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.