» openSUSE Conference 2011, first program commitee meeting

I'm part of this year's openSUSE Conference program committee, in order to bring in some of my experience with organizing the awesome FOSDEM conference ;)

So we had our first program committee meeting today, and the summary is available on the wiki, on the forums and the opensuse-project mailing-list.

» Workaround for Eclipse Helios JVM crashes

You might run into this too: when using Eclipse Helios (3.6.2 here), it sometimes crashes on an alleged double free in the JVM, detected by glibc.
That's actually a feature of glibc that serves to detect bugs and security issues, which kills a process that tries to free a previously allocated memory area that has already been freed.

In this case, however, it is most probably a false positive, but glibc still decides to kill the process.

The workaround is to run Eclipse with the environment variable MALLOC_CHECK_ set to 0. There are several ways to achieve this:

1. when you run eclipse from a shell, run it like this:
   
   MALLOC_CHECK_=0 eclipse
2. if you prefer to just run eclipse or by clicking on an icon, create the following file in your $HOME/bin, e.g. like this (just copy/paste into a shell):
   
   cat<<EOF >"$HOME/bin/eclipse"
   #!/bin/bash
   export MALLOC_CHECK_=0
   exec /usr/bin/eclipse "$@"
   EOF
   chmod 0755 "$HOME/bin/eclipse"

Note that with the latter option, you obviously need to adapt the fully qualified path to the eclipse script depending on how and where you installed it. If it comes from RPM packages, than /usr/bin/eclipse is fine. If, like me, you downloaded the tarball from eclipse.org and unpacked it somewhere under your home, you must change it accordingly -- e.g. to $HOME/apps/eclipse/eclipse

In any case, you should NOT add export MALLOC_CHECK_=0 to your ~/.profile or ~/.bashrc as that would turn off that glibc check for ALL the applications and processes you would run. And that's a bad idea.

» Canterbury Rolling Application Platform

Following the announcement of the Canterbury distribution, there has been a lot of work about this in the background too. In order to provide developers with the easiest framework to package with, we are pleased to announce the availability of the Canterbury Rolling Application Platform.

No more tedious packaging, upstream won't have to deal with the idiosyncrasies of distributions any more. Just write your source code, use our framework, and it will automagically be turned into a craplet, which is the new name for artifacts in our distributed platform. It will just fly!

Unlike all efforts of packaging and distribution, our approach is truly revolutionary and provides instant and effortless scalability for the cloud through virtualization of provisioning for horizontal and vertical growth of your business.

At the center of this revolutionary platform lies our secret sauce, Publish Organic in the Open, which will enable you to quickly push out your stuff into the wide world of users of the new Canterbury Rolling Application Platform.

aprfoo@feci.es$ make_poo --dist=loo LibreOpenOffice
Preparing upstream organic ... [DONE]
Building craplet loo.crap ... [DONE]
Flushing buffers ... [DONE]
Pushing to canterbury.org ... [DONE]
Finishing up. Congratulations, your CRAP is flying at the loo !

We are expecting big vendor support behind this effort, with HP, Oracle, IBM and probably also Microsoft, as it would only be a natural fit for their .NET platform.

It is obviously written in Python (significant whitespace fits in naturally with our philosophy) and will be available in git repositories soon.