I'm a bit late with my obligatory Android post. Partly
that's because I wrote this in a lab at university a while
back and forgot to post it.

The announcement of Android and the release of the "early
look" SDK have created quite a bit of hype. There have been
numerous similar announcements by other initiatives to get
Linux on mobile devices, so what's with the excitement about
Android?

Of course, it's backed by Google. Whether you like it or
not there isn't going to be a way around it. But that's not
all there is to it. The engineers behind Android have simply
done an excellent job judging from the SDK. And there's a
lesson or two to be learned by the open source world:

The Linux kernel is good at what it does.
Userspace is generally not worth bothering with.

I found this very striking. If you have a look at what's
running in the emulator (which is based on Qemu), you'll
notice that there are just a few processes and the only
standard component among them is dbus.

Android uses a custom (launchd/upstart-like) init
replacement. Traditional, SysV style, init systems waste a
lot of time just forking shell processes. And doing stuff
in shell also opens the door for monstrous shell scripts
that spend ages performing simple tasks such as creating
a few files and directories (that script takes 5-10
seconds to run). It still takes a while for
Android to boot though, which I hope is just because my
laptop is slow.

Android also doesn't bother with providing a complete
Unix commandline environment, since, hey, the user isn't
going to see that anyway. It's funny how it's never occured
to me to stop shipping the lower layers (non-essential bits
of busybox, login). But then again, I'd probably have been
yelled at for that by some users...

I have yet to check whether udev or a udev replacement is
involved as that tends to be a bit of a bottle neck on
resource constrained devices. It would certainly be nice to
either get things to work without udev or with a more
efficient replacement. The other thing I have yet to figure
out is whether any type of X is involved in windowing. At a
glance, it doesn't look like it though.

You can build efficient security models that are
still simple enough for people to actually use them.

Most PDA/phone stacks make the assumption that only one
user uses the system. Personally, I prefer multi-user
environments so I can lend devices to friends/family, but
for the average user that assumption is reasonable.

In a multi-user environment you need technologies like
SELinux to separate individual applications run on behalf of
a single user. Mobile stacks have to my knowledge (apart
from an extremely locked down set of Motorola phones) up to
now never bothered with that. Applications either all run as
(yuck!) root (Qt/Embedded, Qtopia) or as a single user (GPE,
Maemo, Poky, OpenMoko) without any significant restrictions
as to what individual applications are allowed to do.

Enter Android... Why not re-use the space freed by the
single-user assumption and run each application as a
separate user? Sufficient for most use cases and still very
simple to understand. Security models only matter if they
are simple because they won't be used otherwise. It remains
to be seen how well the Android security model works out in
practice but I like the concept.

It's not a platform unless it comes with a
comprehensive API and an easy to use, well-integrated
SDK.

I found it rather amusing how people referred to OpenMoko
as the first open platform in reaction to the Android SDK
release. At present OpenMoko is a prototype device plus a
number of mockups and a few prototype applications. There's
a long way to go to turn that into a platform.

First of all, developers will want a comprehensive API.
From experience talking fellow developers through
GLib/GObject/Gtk+/etc. development basics, it's fairly
obvious to me that just throwing a bunch of libraries at
people doesn't do the trick. People get lost too easily
around the borders between the territory covered by the
different libraries involved. Arguably, this is mainly a
documentation problem, but there's more to it. Following the
development of the Gnome desktop throughout the years shows
that people spend a lot of time discussing at which level to
implement functionality, shuffling bits around, etc.

Android takes a different approach. Using the Java
programming language allows integration with Eclipse (or
similar commercial IDEs) which provides developers with API
documentation right in the editor. Combine that with
refactoring/reenginering features of modern Java IDEs and
you'll never look back to anything else.

And the level of integration goes beyond that. You don't
even have to leave Eclipse to upload your application to the
devices. It's all just a matter of clicking a few buttons.
For an "early look" SDK that's rather polished and provides
a new level of efficiency compared to what I'm used to on
other Linux based systems.

The primary goal must be to attract developers.
The larger the set of potential developers the better.

If you want people to use your stuff you'll have to make
it easy for them to hop on the train. As simple as that may
sound, most of the time it just doesn't work like that.

I believe the choice of Java as the programming language
was the right one. Personal taste aside, there is hardly any
way around Java. It's the de-facto standard first language
in teaching around the world.

It remains to be seen whether there will be other
language bindings in the future. It doesn't seem very likely
to me though, since Google probably wants to avoid a mix of
languages which easily leads to a giant mess.

Avoid cross compilation and complex build
systems.

People tend to spend a lot of time setting up a cross
toolchain, fighting applications that won't cross compile
cleanly, etc. That's a major waste of time.

Of course there are various meta-level build systems,
which try to hide that sort of thing from you. But that
comes at the price of another level of indirection and
complexity. There are very few people who actually
understand how, say, OpenEmbedded works under the hood in
every detail - the problem being that in certain cases you
need that level of understanding to get your work done.

Android's take on this is to avoid cross compilation and
build systems altogether (for application development
anyway). I like the approach. It's very refreshing to find a
development environment that you can instantly work with
after downloading. My first simple application ran in the
emulator within minutes.

People have raised the question whether Android renders
various other projects obsolete. And, realistically, I think
it will once fully open source under a permissive license.
The impact will be dramatic. As outlined above, traditional
handheld distribution paradigms along the lines of a "base
system" are shown to be irrelevant and there's been a clear
focus on creating a fun developer and user experience.

Do I sound overly optimistic for the success of Android?
Perhaps. I haven't held a device running Android in my hands
yet after all and there are licensingquestions
to be sorted out, too. Given the list of consortium members
behind
the Open Handset Alliance, however, I'm confident there's
some exciting, well engineered stuff ahead.

Now that I'm settling in here in Cardiff, it's time to look back at the very busy past year or so.

Back in August 2006 Familiar 0.8.4 was released. I had been working effectively full time towards that release for a couple of months (apart from RoboCup induced interruptions). It was a fairly successful maintenance release which added support for several new hardware platforms. I'm well aware of a number of issues with 0.8.4 but it's basically as good as an OE-using niche-distro gets. Sure, you can upgrade stuff here and there, fix the one or the other bug, but at the same time equally many pending upgrades and bugs pop up at the other end of the tree.

Note that I was one of the most enthusiastic proponents of OE in a discussion earlier in 2006 but handling most of the builds for the 0.8.4 release changed my perspective quite a bit and made it perfectly clear to me that for significant improvements Famliar would need something different.

The post-0.8.4 period also marked the end of the first year of my two year project at university. There, it was similarly clear that a change in direction was needed (never underestimate a robotics problem...) and that it would require significant efforts to turn the (then vague) plan into reality. I basically put all non-university activities on hold as a result.

I was involved in some of the planning for Familiar 0.9 though and I do indeed have a fairly precise idea of how I would like to see it implemented (from scratch by the way). Those plans, however, rely on infrastructure bits which as of today haven't fallen into place yet. The distro-engineering parts as such could be done fairly quickly - I do have a working (significantly improved) new base system which took 3 evening sessions to put together. From there it's probably just a matter of a week all the way up to X (including window manager, etc.). Oh, and we'd get virtually any piece of non-handheld-specific software packaged for free.

Why haven't those plans taken off yet? Honestly, I don't know. It's probably a combination of a lack of time and an after-you-after-you problem among the involved developers. Certain other events of this past year have destroyed a bunch of trust relationships and made communication difficult.

At the same time in a different universe... We made excellent progress with the two year project at university. The project schedule was ambitious, but apart from a few minor issues we successfully reached our goal and presented our results in mid-July. The project report is now also finished and the only thing left for me to do for my degree (Diplom) is writing my thesis. I've even talked to a potential supervisor already and we've agreed on a (rough) topic. I just love it when a plan comes together.

At the same time in yet another universe... I decided to spend two semesters at a university in a foreign country through the Erasmus programme. That also worked out just fine in the end and I'm now studying Computer Science with Distributed and Mobile Systems at Cardiff University. So far, lectures have been interesting and nicely complement stuff I've already done at my home university in Bremen.

So, what about Familiar? I've had a few days off during Freshers' week (I'm taking 3rd year modules) and used a tiny fraction of that time to catch up on what's happened in the Linux-on-handhelds realm during the past 6 months. And, yeah, I still believe there's a need for a distro like Familiar - with a strong focus on end users, secure, reliable software and working upgrade paths. This is especially true since projects that set out to replace Familiar simply don't appear to deliver. Quite frankly, I hate to see so many users left out in the cold. Realistically, however, my schedule here isn't much less busy than back in Germany. And I also have to prepare stuff for my thesis.

Long story short, I'm going to continue concentrating on my studies and no longer consider Familiar a project I'm actively involved with. I wish the remaining Familiar developers and competing projects all the best. Put out some great products for me to find when I check back after graduation!

I've kept this very low
profile for a long time as it wasn't clear whether things
would work out as planned until the very last minute. But
now it's official as I'm here now: I will be studying at Cardiff University for the
next two semesters as part of the Erasmus
Programme.

I noticed today that the Four-Legged-League has been
renamed to Standard
Platform League and will be using a new humanoid robot
at future competitions. There isn't a whole lot information
available about the Aldebaran
Nao but it definitely makes me wish I was starting with
my 2 year project now (rather than being almost finished) so
I could join the local
team.

Why is a standard humanoid platform so
exciting? If you've ever worked with robotics hardware and
prototypes in particular, you'll know only too well that you
rarely get to do the stuff you want to. There's always one
hardware component or another that fails on you, not to
speak of the usual pain of (systematically) incorrect sensor
readings. A standard platform makes sure that everyone has
the same starting point and (ideally) allows people to
concentrate on algorithmic work rather than developing and
fixing hardware.

I've recently been doing algorithm prototyping in GNU Octave. Although not fully compatible with Matlab, it usually interprets code written for Matlab correctly. Some functionality (specialized functions) is missing but usually slightly different but equally capable replacements are available.

I must say I'm impressed with how quickly you can develop mathematical algorithms in Matlab/Octave. Basically, you're all done at about the same time you'd start debugging your matrix library in any other language. It's definitely an approach people in computer science in general and robotics in particular should use more often.

Octave uses gnuplot for plotting but hides the gory gnuplot details from you which is really pleasant. On the other hand, if you're used to computer algebra systems such as Maple or GNU Maxima it feels a bit odd to plot a set of points rather than a (symbolic description) of a function. Considering the internal representation of a function in Matlab/Octave it does however make sense the way it's implemented.

I don't know how
many people read this or how many care, but I'm in fact very
much alive. I'm in the process of finishing off the second
last assigment for this semester (apart from a to-be-written
report for my 2 year project and the usual exams). The weird
thing is it's actually the last regular semester for me,
afterwards I'll just have to write my thesis.

What else have I been up to? I've accepted a job at the
robotics lab for the next couple of months, where I'll be
doing some interesting probabilistic robotics and vision
stuff, apart from (real) embedded development. Real as in
not just another PC crammed into a cubic inch which is a
more adequate description for most consumer devices that
people like to label embedded.

Speaking of
which... I stopped reading mail on my personal account (the
one that receives mail from mailing lists and anything open
source related) months ago. I haven't decided whether to get
back into the loop yet. Given the fact that my schedule for
the next months won't leave much spare time it's at least
not going to happen very soon.

Of course there's
also a good side to this break, in fall it will hopefully be
clear whether a bunch of other projects will be able to
deliver what they promise or not. Once that's out of the way
it will be a lot easier to evaluate the purposefulness of my
involvement in Familiar and related projects.

PS:
All courses and the final presentation of our 2 year project
went well. So, yeah, life is good :)