Name: Rene Wagner
Member since: 2005-09-29 00:17:53
Last Login: 2008-03-09 17:47:36


I'm a twenty-something computer science student who spends part of his spare time on Free/Open Source Projects with a focus on handheld devices. Other hobbies include kiting and playing the (classical) guitar.

Past Projects: Familiar, GPE, OpenEmbedded, LCDproc

Recent blog entries by reenoo


I've moved my blog over to my new site at

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

27 Nov 2007 (updated 27 Nov 2007 at 11:34 UTC) »


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.


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

Cardiff Bay
Cardiff Bay on a cloudy day
Bonfire Night

25 older entries...


reenoo certified others as follows:

  • reenoo certified robilad as Master
  • reenoo certified mjw as Master
  • reenoo certified twisti as Master
  • reenoo certified gary as Master

Others have certified reenoo as follows:

  • rufius certified reenoo as Apprentice
  • fzort certified reenoo as Apprentice

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page