Recent blog entries for reenoo

301

I've moved my blog over to my new site at nelianur.org.

So, thanks for all the fish advogato, but it was time to move on.

LISP

I've been looking into LISP recently (initially for university stuff). Historically, I think it played an outstanding role in the development of computing. Bringing functional programming to a world of assembler and low-level C hacking is clearly an achievement in its own right. I am particularly impressed learning that LISP was used to control some NASA spacecraft - today most people don't even use anything higher level than C or perhaps C++ on robotic systems, and that's on much more powerful and significantly more accessible hardware (try attaching a JTAG interface to a probe on another planet to debug a problem with your code).

From a language design point of view I'm not overly impressed by (Common) LISP though. Some of the criticism I have for it is arguably purely a question of taste: I find the lack of mixfix operators rather annoying, but of course it makes parsing by orders of magnitude easier. More of a problem is the apparent lack of strong typing - e.g. LISP will happily allow you to have elements of differents types in a list, among other more serious issues. It also appears to be possible to change semantics based on input types of a function. The fact that functions (like +) can take a variable number of arguments is a bit of a nail in the coffin from my point of view. I'll keep using Haskell for real world functional programming.

GHC on Debian/armel (ARM EABI)

A while back Riku Voipio called for help with missing bits for Debian/armel one of which was GHC. Not knowing Martin Guy was already (privately) working on bootstrapping GHC (an ARM port existed already) I decided to have a go at it. The GHC porting documentation is clearly excellent and resulted in quick success (relatively quick given the slow build hardware). At that time Martin was already far ahead of me. Meanwhile he has made packages available. I have yet to get around to reporting some minor problems GHC upstream and I may also investigate why ghci doesn't work at some point, but basically this means Haskell is available to the EABI crowd :)

Final Random Bit: Linux Kernel in a Nutshell

When someone pointed me to Greg K-H's book Linux Kernel in a Nutshell my initial reaction was: Building a kernel isn't exactly rocket science. Why would I want to read a book about it?

Well, it seems I was wrong. I skimmed through the PDF version today and noticed a very useful feature of make menuconfig: Hit / and it allows you to search the CONFIG_ strings.

Android

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 licensing questions 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.

There Is Still Hope

Bonfire Night

Tempus Fugit

A Brief Moment of Magic

Looking back

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!

And so it has begun

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.

New toys for the RoboCup community

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.