Robert Schusters Blog

Fedora giving FOSS graphics driver “nouveau” a try

The free and open-source graphics driver for Nvidia graphics cards “nouveau” is going to be tested in the Fedora distribution. I have to say that, as a user, I have some troubles with Fedora right now but this move makes me happy. Even of I do not have this kind of graphics boards in use any more.

Yeah, you heard right: I don’t use Nvidia hardware and I find it great that Fedora is trying ‘nouveau’. I even read the development’ teams status updates and was anticipating the day some distribution would make their support official (I know it is in Debian as well).

Let me use this nice news to point to a big adversity that is coming to the embedded Linux world (or is already there). The PowerVR SGX is a graphics chip for embedded use. It is very powerfull but requires not much power to run. It is also contained in many of the new embedded CPUs like OMAP3/4, i.MX51 etc. Soon many consumer devices running a Linux-based OS will be delivered to users (e.g. the new Nokia internet tablet and the Touch Book). If you own an Intel Atom-based system with a ‘Poulsbo’ graphics chipset you already have an SGX implementation. The new Qt version already has a GL widget which can be driven by the SGX.

And this is where the shit hits the fan: At this time the OpenGL ES drivers for the SGX are proprietary and can only be distributed through your particular vendor. It is also like when asking about Jazelle things. Everyone is extremely close-lipped. I doubt that this has something to do with a possible move towards free software (*curses NDAs*).

I can’t do anything about this but I can utter my discontent. If you are affected by the above situation you may do so, too.

My BeagleBoard also contains an SGX.

Comments on latest post on OpenJDK

Hi,

there have been interesting questions in the comments sections of my last post. I take the time to answer them here:

Mark Wielaard asked: Finally, do you have any speed comparisons of the hotspot/zero and cacao on arm ?

Unfortunately not. Subjective it feels as if the SwingSet2 demo runs better with Cacao. The Freerunner and its software are also not in a good shape to make performance tests. Even native C applications show unacceptable slow behavior.

Xerxes Rånby said: Your combined effort have provided the key to unlock the possibility to run OpenJDK on all embedded Linux NAS storage devices, home routers and more

Indeed and I very much welcome people to try compiling the recipes for their MIPS devices as well. I also wonder if OpenJDK can be compiled against uClibc and uClibc++. If that is the case then we can also have OpenJDK+Hotspot/Zero on AVR32 (though a few more patches to the build system will be needed for this).

Andrew John Hughes wrote: What version of IcedTea did you use? I think some issues have changed/been fixed. Certainly –with-openjdk-src-dir isn’t broken any more

I used the latest from the stable release: 1.3.1. Good to hear that some issues are already fixed. I am looking forward to integrate some patches after Xmas.

Eric Herman wrote: My sense is that Java is not truly Free if I can not bootstrap it from C, and I was of the impression that I still needed a working Java in order to build Java. I look forward to learning more about the excellent work you’ve been doing.

Actually with OpenEmbedded this is the case: OpenJDK is bootstrapped without the need for a pre-installed Java runtime. What I left out in my explanation is that all of this builds on top of my previous work on a completely self-hosting Java^H^H^H^HJava-like toolchain based on GNU Classpath, JamVM/Cacao, ECJ and eventually Jikes. I have written down the gory details of this in the OE wiki to make it possible that anyone can pick up my work enhance it or re-use it in another build environment.

Finally Wladimir Mutul asked: Why not use Scratchbox(.org) for your cross-compilation ?

Before starting with OpenEmbedded Jalimo was only targeting the Nokia Internet tablets and as such we build our stuff with Scratchbox. First of all: I really like the Debian-way of packaging things (all of the Java related recipes in OE resemble Debian conventions for instance). However three points were most important when deciding to leave the Scratchbox path:

• At the time we worked with SB it was not possible to either get JamVM or Cacao working reliably inside SB. So we had to use Jikes as a Java compiler. GNU Classpath adopting Java 1.5 syntax would have made it neccessary to use ECJ instead which needs a Java runtime.
• OpenMoko appeared on the scene and we wanted to provide binaries for this platform. Additionally we had an Irex Iliad (an Ebook reader) and wanted to support it, too. OpenEmbedded built for those out of the box and it turned out that with little work OE could be modified to support Maemo as well.
• Last but not least with SB a lot of manual work was involved when integrating a new patch or updating to a new version. With OE it is a matter of renaming a recipe and checking which patches are still needed. Gentoo packagers do it in the same way.

It should go without saying that I miss things that would be available by basing everything on Debian. E.g. source packages, direct support for Ant builds, many many tried and tested packages and of course GCJ. Furthermore it isn’t all bright and shiny with OE either. For instance the project is an extremelyfast moving target. People add new stuff to it everyday. Some things have effects on your recipes and may cause build problems. However this is why projects like Poky exists which make stable release on top of OE snapshots.

I hope my explanations cleared things up a bit.

Happy holidays!

Serving cross-compiled OpenJDK with IcedTea

As Ken and Sebastian have already announced it OpenJDK integration into Jalimo was finished. However there was a bit of work to do to not only compile OpenJDK but to also package it nicely. This work is now also completed.

Additionally – and this was not told anywhere else yet – we can now also offer Cacao+OpenJDK. So anyone who is in need of a decent JIT for its target platform can now build this combination, too.

Those who do not know OpenEmbedded may wonder what is so special about the work I have done in the last weeks. Well, the special thing is that we are cross-compiling the OpenJDK. That means the machine on which the JDK is built is of a different kind than the one on which we want to run it later on. The difficulty stems from the fact that the OpenJDK build system is not designed for this (in contrast to the one used by PhoneME btw).

Before I will tell you about the guts of cross-compiling OpenJDK lets enjoy some screenshots:

People may have seen these apps on their desktops and as such they are not very exciting. However for me they have a special meaning: As a contributor to GNU Classpath it was always my wish to be able to run any Java (=J2SE) program on any device running a Free operating system. I was contributing to the Free Swing implementation and together with the enormous work done by Roman, Thomas, Lillian and many others we were able to run a few Swing and AWT programs. Still performance, completeness and correctness of our implementation where limited in many places and would require more years of dedicated effort. Thanks to Sun releasing Java as free software and the important work done by the IcedTea team we can now have the real thing on our devices and suddenly get 100% compatibility.

Now on to the cross-compilation guts:

First of all compared to the work that would have been required with plain OpenJDK IcedTea made the effort of cross-compiling the thing a breeze. The best thing that IcedTea provides is the ability to use a GNU Classpath-based toolchain to build OpenJDK. On the major distros GCJ is used as a runtime and ECJ as the bootstrap Java compiler. In OpenEmbedded we have JamVM, Cacao and plain GNU Classpath as runtime options which work equally well. JamVM does not understand some of the “-X”options so I had to patch their use away.

Although IcedTea is a nice environment I had to patch a few things to get things started. E.g. IcedTea requires you to point to a GCJ home directory. It will then create symlinks to libraries and headers files contained within them. The problems with IcedTea are: When cross-compiling the libraries provided by your system’s GCJ do not make sense for your target (e.g. your system GCJ has AMD64 binaries while your target requires those for ARM). Secondly in a cross-compilation environment like OpenEmbedded you do not want to rely on stuff outside the environment. As such I had to modify this behavior to link to header files (jni.h and likes) which are provided by the OE-built GNU Classpath.

There where other problems like IcedTea not respecting the –with-openjdk-src-dir option. It will still try to download the OpenJDK sources itself (which is not allowed in OE, because this is done through the environment).

All in all I collected my changes in patches which I called ‘build hacks’. I consider these hacks fixable and will work together with the IcedTeam team to resolve those for future releases in order to make cross-compiling OpenJDK even easier in the future.

Besides IcedTea I had to patch OpenJDK itself to get things compiled properly. The first thing that causes trouble is that you cannot chose the compiler being used. OpenJDK contains some complicated makefiles that check your system environment and then decide which compiler to use. I used good old sed to replace the respective part of the makefile. I believe this behavior can be added to IcedTea without causing any harm to the other IcedTea users.

The next problem is the sanitizing step. This one will compile a few binaries (for the target platform!), run them (impossible) and decide on their output whether the build can continue. These checks are done for CUPS and Alsa. The fix is to patch them away. I think an optional –disable-sanity-checks would be OK for IcedTea.

The final big problem with OpenJDK’s build system is that it uses the result of ‘uname -m’ for its decision. This is troublesome because ‘uname -m’ will only tell you the architecture of your build machine not the target one. I solved this by replacing all these calls with a variable and allowed IcedTea’s makefile to provide a value for this.

The remaining issues where minor: Some unsuitable paths here, a sizer.32 binary that I had to take from a previous non-cross build there.

Apropos non-cross build. This was the really ambitious undertaking. But before I explain this here are some cross-compilation basics that I learned in the years contributing to OpenEmbedded:

Non-cross compilation aware projects are troublesome when they create binaries whose output is going to be used directly in the build. The general approach to this problem is that you first compile this particular binary for your build system and use it in the cross-build. In OpenEmbedded this will often result in a separate build recipe. If your project is cross-compilation aware it will allow you to specify the location of such binaries. E.g. Cacao 0.99.x has the –with-cacaoh option to point to the location of the non-cross-compiled header generator. In non-cross-compilation aware projects you need to patch the makefiles accordingly.

The IcedTea build normally consists of two builds of the JDK. The first one creates a bootstrap JDK. This one is heavily patched, stripped down and can be build using GNU Classpath-based software. In the second step the bootstrap JDK’s java, javac and a few other binaries are run to build the final JDK. For our cross-compilation effort this means we need to get this bootstrap JDK built for the build machine and as said above this is where things get troublesome.

The reason for this is that OpenJDK depends on a few libraries like CUPS, Alsa, libjpeg and giflib which I either had to provide in their native (= for the build system) form or patch their use away. Remember that I cannot just take e.g. Debian’s libcupsys-dev because that would be outside the OpenEmbedded build environment (and would make people unhappy who use OE on a different distro).

I decided to go the way of patching the bootstrap JDK build since printing and sound would not be needed for bootstrap purposes anyway. Originally I also disabled most of the AWT (and as such the libxt, xproto dependencies). However it turned out that at one point the OpenJDK build converts a bunch of GIF pictures into Java byte array source code using javax.imageio which requires the headless variant of the AWT.

A few lines above I told you that the bootstrap JDK is compiled separately for the build machine. In a simple project we could now skip this part from the cross-compilation build. However the bootstrap JDK build also creates libraries (for the target machine) to which the final JDK links against. That is why we cannot skip this part.

So cross-compiling OpenJDK consists of the major steps:

• build a GNU Classpath-based toolchain (gjar, gjavah), ECJ and Ant
• build the bootstrap JDK for the build machine (‘make icedtea-against-ecj’)
• build the bootstrap JDK for the target machine
• replace the binaries in bootstrap/icedtea/bin with those of your native boostrap JDK
• build the final JDK

and as I have written in the first part of this posting: You need to patch everything heavily to get some problems out of the way which stem from the fact that OpenJDK is not cross-compilation aware.

Finally a screenshot showing Cacao+OpenJDK:

The next step will be integrating Hotspot-Shark into OpenEmbedded and of course getting as many of my patches upstream as possible.

Compared to GNU Classpath + Cacao/JamVM the OpenJDK packages are ~6 times larger. I am curious to see how the modularization efforts of Java7 works out. With the work done now it will be much easier to follow those developments.

Edit: Fixed images links.

Even more PhoneME Advanced stuff

The support for PhoneME Advanced in Jalimo (and thus in OpenEmbedded) is getting better every day. Apart from upgrading to build 87 I took Ken Gillmers recipe for PMEA with the personal profile (think AWT support) and adjusted it a bit. A test build for the BeagleBoard went so smooth that I decided to put it into OE’s repository immediately.

Mandatory screenshot:

That image shows two instances of PMEA running the “personal” and “basis” demo (top left and top right). For added fun I also started the ‘basis’ demo with Cacao 0.99.2 (with some fixes for hardfloat) and GNU Classpath 0.97.2.

Suffice to say this recipe is now not only available for the BeagleBoard but also for OpenMoko, Maemo/IT OS, Gumstix, BugLabs BUGs and the plethora of other devices supported by OpenEmbedded.

Have fun!

PhoneME for Jalimo – continued

We all love it: Screenshot time!

This is PhoneME running on an N800 with the Chinook/Maemo 4.0/OS 2008 distribution. Since the differences between Maemo’s Chinook and Diablo distribution releases are minimal you should be able to use the same packages on both. More on that later.

And here we have the same app (= jalimo-swt-example) running on OpenMoko’s Freerunner.

Needless to say that startup and runtime performance of PhoneME simply rock: The small SWT-based UI appears within 4 to 5 seconds on both devices.

If you have any of the two devices (or an N810) you can now install the JVM through Jalimo’s repositories. Get them while they are hot.

PhoneME Advanced Foundation (with JIT) at Jalimo

This was a big pile of work but now it is a nice achievement for Jalimo: The most complicated issues have been sorted out and we can now build Sun’s PhoneME Advanced (Foundation profile) with the JIT compiler enabled for all our little ARM devices (And not only we can do this but everyone because the recipes are in the repository).

The first device for which I could build the runtime was the BeagleBoard. You can see the full log of the first bits of CVM-goodness on that device here. What is important to note is that the JIT compiler is enabled:

CVM_JIT=true

When compiling the source with the JIT the build gets a bit more complicated: Some Java programs will be compiled and run on certain sources. What  is nice that these helper programs actually run on a GNU Classpath-powered VM. See, this code is still does usefull things for us.

Buglabs recently did a comparison of Cacao, JamVM and PhoneME Advanced (interpreted only) on ARM systems. Surprisingly (or not ) JamVM does a very good job!

While we are at it: JamVM seems to be the only (free!) Java virtual machine that can run on the AVR32 architecture. The port is not yet included in the upstream repository but is nevertheless quite interesting: The guys doing the port are making use of the Java hardware acceleration (whose specification can be obtained freely).

Finally the other day I wrote down everything about the Java support in OpenEmbedded to the shiny new OE wiki. I hope that with this information people will quickly be able to customize their OE-based distribution. Furthermore the pages describe the quite complex bootstrap process and each of the packages that belongs to it.

Next stop: OpenJDK

Campaign for Software Freedom on Nokia IT Devices 2008

Yeah, I am in a writing spree today. I just sent this to the Maemo mailing list. Basically I continue where I left of last year.

Since comments are still not open for anyone at this site (Sorry, I cannot do something about this). Contact me via email (thebohemian _ at _ gmx.net) for suggestions. If you think I am silly, continue to do so but don’t start your mail program.

Hi!(If some bits sound to serious for your taste, take them with a grain ofsalt.)

I finally subscribed to this list because I think the time is right. Iattended LinuxTag 2008 in Berlin/Germany a few days ago. Quim Gil andother people from Nokia and the Maemo community were there. In the firstMaemo talk Quim invited the community to speak out to Nokia (Btw: reallyNokia or just the OSSO team?) and I want to participate therein.

If you attended the first talk I was the guy asking to raise your handif you want to see the Nokia IT devices being freed of all proprietarysoftware in one way (install a different OS) or another (make IT OS 100%free itself).

This brings us right to the topic: Free Software - free as in freedom,you know.  

I was *not* asking the question to show the Nokia staff that there aremore than just '5 free software' visionaries in Maemo but mainly becauseI reported this[0] bug last year and was missing noticeable support fromother free software friends. I know that some really good people havealready given up on this topic and rest assured that this will also bemy last attempt to subvert this community.  

So the question at the talk was for me to find out whether I am reallyalone with my views. Apparantly it also made all of you show that youare not alone, too.  

Ok, Quim introduced the '10 action days'. My impression is that theywould like to hear stuff like 'add feature X to the website', 'portapplication foo to maemo' or something else from that category. I haveno suggestion like that because I strongly believe that a healthy freesoftware community can fix any technical deficiency on their own.

You are not a zealot like me and need an argument now? Ok. The freesoftware scene came nearly out of nothing. Although free programsexisted long before Linux was written, there was no organisation ofthose. One of the early communities that rallied together to make achange was Debian. It evolved from nothing to something that commercialfree software vendors *want* to base their products on. Debian is thedistribution Maemo was derived from.

Ok, let me state some stuff before it gets hairy:

- I do not consider someone/an organisation/company evil here. There arejust different fears, opinions, convictions, way of doings etc.resulting in different behavior.

- I consider the OSSO team at Nokia to be more open to FOSS than anyother part in that company and that those guys are restricted by companypolicies. If there is something to fix than it will have most likely todo with that other parts.

- I am very thankful for every contribution from Nokia staff to the freesoftware community. However I treat every non-free part of the IT OS ifit does not exist when it comes to being thankful.

- If not said otherwise I speak in the name of those Maemo users whoknow that FOSS is the way to go. Everyone is free to completely disagreewith my views & opinions.

Over time I learned about a few reasons why companies keep theirLinux-based operating systems closed or deny NDA-free access tospecification. Here are some:

a) treaties/contracts made with chipset vendors (e.g. ARM, TI) enforce acertain non-disclosure of specificationsb) fear of being imitated/plagiated by ... well manufacturers that are*specialized* in doing soc) company-wide policies that enforce a certain working style or commonstandards in different company sections (set up to make it easier tocope with national laws/regulations from *inside* the company[1])d) fear of appearing less unique to the customer (something marketingpeople preach)e) fear of 'eating away' market share from other inhouse devices(especially from those where the margin is higher   )

Without knowing anything from inside OSSO/Nokia in this regard I stillhope that those reasons apply more or less to them because I want tobase this year's "Campaign for Software Freedom on Nokia IT devices(tm)"[2] on them.  

What the campaign is hoping to achieve is the following:

1) Users should be able to install any compatible OSes on their Nokia ITdevices they wish like one can do on their desktop computers.

2) It should be possible to port and put Maemo on other non-Nokiadevices like it is possible to e.g. port Fedora to any machine.

-

The means to achieve this goal are the following:

1) All software in Maemo should be licensed under free software licenses(I do not care about Skype, Flash, etc).

2) Either specifications or free software drivers should be provided forthe components in the Nokia IT devices.

To achieve those goals the following things should be adhered to:

 * Tackle one bit after another.

Please prioritize important things (e.g. virtual keyboard/handwritingrecognition & battery management). If things start moving thecommunities' reward is patience. Feel free to make a big fuss when eachcomponent is freed. The free software community will party together withyou.

 * Future software/hardware releases should not add non-free components

Remember that there is always more than one way. E.g. the free softwarecommunity can certainly accept a proprietary GSM modem which responds toAT commands or a GPS module providing NMEA[3].

-

On the one hand it would be totally cool to get the existing devicesfreed and many people would welcome that BUT if all fails and non-OSSONokia staff cannot be convinced that this would be a remarkable andtrust encouraging move THEN the fallback plan is to bring future devicesinto a better FOSS shape. That way we will have fully free (as infreedom) devices in say 2 or 3 generations.

The free software heart aches when saying that but I accept that at thispoint in time Nokia's HW lab will already have designed the next devicesand there is no possibility to make substantial changes without causinghigh re-engineering costs.

-

Benefits: I am not a lawyer, marketing expert, economist or else. Askthem if you want advice. However a commodization of portable deviceslike the ITs is likely.

Firms and communities could also more easily order a bunch of Nokiadevices and make use of them for special tasks (without having to signspecial contracts, of course).

-

This is really a long mail. I stop here and present the short plan: Iwill distill the above stuff into an 'official' statement, put it onlinesomewhere (Maemo Wiki?) and let supporting users subscribe to it. Thefinal document is then given to Nokia/OSSO as part of the 'action days'and if the interest from them is not zero ... well, then you will readmore mails from me. I also hope^H^H^H^H expect more people to chime in then.

	After all this our common goal, isn't it?

Well done if you made it this far. If you are thinking about replyingplease use your time productively. I am not inviting to a discussion -instead I presented a plan. You either contribute to it or let us goahead without your support.

RegardsRobert

[0] - https://bugs.maemo.org/show_bug.cgi?id=1584

[1] E.g. in order to sell Nokia devices in some random country a numberof employees must be trained to deal with support and warrantyquestions. Stuff like this is what customers expect from amulti-national company.

[2] The acronym would be rather CSFONID but CFSONID can be pronouncedziff-sonid and I like that more. Call it whatever you like.  

[3] Rest assured that one day GPS and GSM hardware will be produced asopen hardware.

The part where I say that this will be my last attempt may have a negative connotation but that is not my intention. I am just doing an economical decision like any investor would do. I have a limited resource at stake which is my freetime (or lifetime) and a number of possibilities to make investments in. If I do not see any prospect I will do something else because proprietary software is simply not my way to go.

I like scripts

As the title says I like scripts and many other people like them, too. In package management systems there are four of them which are especially important, namely prerm, postrm, preinst and postinst.

The maven-pkg-plugin which we are developing for Jalimo to ease the effort to create proper (binary) packages for various GNU/Linux distributions (as well as IzPack installer for all kinds of OSes) just learned to support them. This is important especially for supporting the Maemo platform because according to their guide you have to restart a certain system service after installation.

Here is the output of such a script which is now part of our example application jalimo-swt-example2:

Nokia-N800-44-4:~# dpkg -i  debs/jalimo-swt-example2_0.1.0-0maemo_chinook-r2_all.deb Selecting previously deselected package jalimo-swt-example2.(Reading database ... 15719 files and directories currently installed.)Unpacking jalimo-swt-example2 (from .../jalimo-swt-example2_0.1.0-0maemo_chinook-r2_all.deb) ...Hello user! This is the pre-install script talking.We are dealing with maemo_chinook distribution. Possibly betterknown as Maemo 4.0 (Chinook). It uses the deb packagemanagement system.

You can use the following variables:prefix=/bindir=/usr/bindatadir=/usr/share/jalimo-swt-example2datarootdir=/usr/sharesysconfdir=/etcjnidir=/usr/lib/jnibundledjardir=/usr/share/java/jalimo-swt-example2version=0.1.0-0maemo_chinook-r2name=jalimo-swt-example2mainClass=org.jalimo.examples.swt.SwtExample2

Isn't this great?

Same script different distribution:

root@fic-gta01:~$ ipkg install jalimo-swt-example2_0.1.0-0openmoko-2007.11-r2_all.ipk Upgrading jalimo-swt-example2 on root from 0.1.0-0openmoko-2007.11 to 0.1.0-0openmoko-2007.11-r2...Hello user! This is the pre-install script talking.We are dealing with openmoko-2007.11 distribution. Possibly betterknown as OpenMoko 2007.11. It uses the ipk packagemanagement system.

You can use the following variables:prefix=/bindir=/usr/bindatadir=/usr/share/jalimo-swt-example2datarootdir=/usr/sharesysconfdir=/etcjnidir=/usr/lib/jnibundledjardir=/usr/share/java/jalimo-swt-example2version=0.1.0-0openmoko-2007.11-r2name=jalimo-swt-example2mainClass=org.jalimo.examples.swt.SwtExample2

Isn't this great?

The packaging plugin got vastly improved in the last weeks. IMHO the most important bit is, that it can distinguish between distributions: For the plugin at makes a lot of difference if you want your package to run on Debian Etch or Debian Lenny. The latter contains a lot more Java packages and therefore it tries to make use of them (if there is no package for a specific Maven artifact it will automatically bundle this) which means putting the package name into the dependency list and adding it to the application’s classpath.

For this to work the plugin contains a built-in Maven2 artifact (= single jar file) to target distribution package mapping. In the earlier version of the plugin there was only one definition of such mapping, now it supports any number. Also system properties, additional files (including the above mentioned scripts), the main class and many more can be set on a per distribution basis.

The plugin also knows the distribution’s packaging system, of course. Finally you can add/modify your own distribution mapping without the need to recompile the plugin. Still some basic information about Maemo Chinook, Debian Etch and Lenny as well as OpenMoko 2007.11 is already provided.

What is additionally nice is that Maven2 itself got packaged for Lenny.

SWT on Maemo updates

Just before FOSDEM I have a nice batch of screenshots to show. What I am going to present today is a new Jalimo demo application which is available in binary form from the Maemo Jalimo repository (sourcecode is in SVN).

It makes use of SWT 3.4′s ability to switch to fullscreen mode (and back). Since a convention for Maemo apps says that toggling fullscreen should be possible by pressing a certain hardware button, I added the neccessary listener as well. It works nicely.

Last but not least while reading through through the Hildon documentation I learned that the environment provides its own file chooser dialog. Since I was fixing a bug in our SWT anyways I added support for this dialog as well.

The results can be seen here:

In related news:

Jalimo is actively contributing and committing stuff to OpenEmbedded now. One of the nice results is that other people start adding the packages into their distributions. Eg. OpenMoko now has GNU Classpath, Cacao, JamVM and SWT in their repositories. The same is going to happen for GPE and AFAIK Angstrom. Nice one!

For the Maemo packages which we provide on our own we lately switched from the manually and Scratchbox-built packages to the ones made by our OpenEmbedded-base autobuilder. For those who used the old repository for their N800/N810 device already I wrote a small migration guide.

And on a completely different topic:

Richard is in Berlin today and does a talk about the philosophy and history of free software. With a little luck a friend and I can organise an interview with him. I spent half the night on getting some interesting background information.

Jalimo progress – piecing together the gems

Jalimo is coming along very nicely. Some weeks ago we got SWT to build fine inside OpenEmbedded and Scratchbox. First it worked at all:

Then we added support for those special hildon menus on the Maemo platform:

With the new N810 devices the keyboard shortcuts should actually be usable.

Invisible and not possible to show on screenshots is the good amount of work that went into the infrastructure: Finally this week I managed to write some OpenEmbedded package recipes which make the Java Toolchain selfhosting. It still needs an initial Java 1.4 capable runtime and compiler but only to compile ECJ, then Classpath (already using the just built ECJ) and finally the Cacao runtime. After that this triplet is used for every other Java package. It is not only those 3 projects which I have to thank, but also the Debian Java maintainers because I heavily reused the ideas of their source packages to write the build recipes.

With this in place the goal of pushing many of our recipes upstream to OpenEmbedded comes much closer. Still there are many things to do to make Java development really shine in OE like Ant integration or – my very special wish – GCJ Ahead Of Time compilation. I hope that with  the groundwork done more people will enter the scene and bring more features and possibilities: IcedTea and PhoneME come to my mind …
While I was fleshing out the build system bits, Sebastian worked on the new Jalimo Wiki, tested my recipes and wrote and documented some Jalimo example applications which should help new Jalimo users and developers to get into the game.

Here is the SWT example from Jalimo in action on both platforms:

The app is built using Maven2 which is very common in the Java scene. So with Jalimo on the device it will become pretty easy to run custom Java applications on them. Even proper packaging is possible through a Maven plugin I wrote some time ago and which is now published (under the GPL) and is extended by other people.

I made many more screenshots but did not want to put them all into the article.

If you wonder where the base of all this stuff is or in other words “Show me the code!”. Well, have a look at our SVN repository then, check it out and contribute.

Certainly there a still rough edges in Jalimo and there is a lot to do but if I compare that to the time when we started this at tarent out of nothing (from an integration point of view, of course) and only with the goal in mind, we have achieved quite alot. Today we can built the basic infrastructure for many of OpenEmbedded supported devices and the Maemo 4.0 or “Chinook” platform and provide a ground for custom applications or the base to port existing ones.

All I can say is that I really enjoy this deep diving in the free software universe and that I am very happy about all those gems that we can pick up and integrate and am grateful to those who made them.

With some luck Sebastian or I will present Jalimo at FOSDEM’08 Free Java Devjam. I am looking forward to see you all there!