QEMU with OpenGL ES acceleration

In the graphics side, the major differences between ARM and X86 systems is that on ARM 3D acceleration is done with OpenGL ES. It is mostly a subset of modern OpenGL used on X86 desktop machines. From QEMU point of view this could mostly be ignored, as OpenGL was mostly used on games and specialist applications. This has now been changing, as desktops and user interfaces have started OpenGL to render graphics. Without acceleration, these user interfaces become slower than slugs crossing a tarpit.

For this reason, MeeGo introduced OpenGL ES acceleration support to QEMU. With the lack of easily available MeeGo QEMU images and test setup, I've created a test setup for Linaro 11.05 image.

Running torus opengl es1 demo from mesa-demos inside QEMU.

Getting replaced by scripts - and it feels good!

As mentioned on Phils blog, Debian buildd's have now capability of autosigning builds. Today when arriving home I was greeted by an empty feeling - There was no builds to sign. The long standing routine had come to an end.

Good system administrators constantly look how to replace themselves with scripts and automation. Bad ones build job security by owning manual processes than nobody else can master.

With signing now done by some code instead of us, I (and other buildd admins) have more time and energy to work on irregular tasks - upgrading chroots, helping developers with porting problems etc. Not to mention blogging and updating ones own packages to sid..

Meanwhile, there are still some issues needing solving - $HOME isn't available on all buildds, -volatile and binNMU's need still manual signing. Certainly not the smoothest update, but it is already making life easier.

(unnofficial) Bits from ARM porters

Quite a few things have happened recently in the Debian/ARM land

ARM and Canonical have generously provided us with bunch of fast armel machines. Four of these are now as buildd's, bringing the total of armel buildd's to 7. In other words, armel should no longer lag behind other architectures when building unstable packages.

One of machines, abel.debian.org has been setup as a porter box. It is faster (around 3x) than the older porterbox (agricola). All Debian Developers have access to the porterboxes.

The new buildds have allowed us to enable more suites. Thanks to Philipp Kerns work, armel builds now experimental, lenny-volatile, lenny-backports as well as unstable/non-free. Especially if you are using stable Debian, access to backports and volatile should make life happier :)

Finally, the next big thing is Hardfloat ARM port, effort being lead by Konstantinos Margaritis. This doesn't mean that the armel port is going away. Majority of ARM cpus sold are still without FPU, so the softloaf port (armel) will still have a long life ahead. Meanwhile, the armhf port will provide a more optimal platform for people with bleeding edge ARM cores (ARMv7 + vfp). Some people have been unhappy with the new proposed new port, and various alternatives have been proposed. However, armhf is currently the only solution being actively worked on.

Update: thank canonical too

WebGL on N900

With the recent "PR1.2" firmware upgrade of Nokia N900, a new feature was enabled in the browser - WebGL. WebGL is cool and scary. The cool part is that it is a chance to bring lots of games to to Linux users. The screenshot is from Match3D, a 3D tic-tac-toe game.

The best way to get started is with the Learning webgl tutorial. Passing through the lessons, some are clearly featuring buggy graphics. I don't know if the website, N900 browser or the OpenGL ES driver is being buggy. Which brings the scary part of WebGL - not only does one need to deal with buggy browsers, one has to deal with buggy 3D hardware/drivers! WebGL is still very much work in progress, and on N900 the webGL is rather an "easter egg" than a proper feature. For example the 3D graphics from the GPU does an extra roundtrip via CPU before appearing on the screen.

Other WebGL resources are for following blogs about WebGL, the Khronos Demo repository and more demos can be found at CubicVR site. The last CubicVR demos feature another scary new browser feature (not yet supported on N900) - audio processing in JavaScript.

I'm going to debconf10

Jep, I'm coming. I bought flight tickets from Icelandair just weeks before Eyjafjallajökull changed from a little known volcano to something everyone knows (but probably can't spell if asked...). The volcano seems to have settled, but at some point I was really happy the ticket was paid with credit card, and at least I'd get my money back. After debconf we plan to travel around NY and nearby, but the accomodation appears to annoyingly expensive, I guess due august being the high season for travel...

In other news it is also possible that I'll visit aKademy 2010 in Tampere, Finland this year.

The Dark side of "Ad-supported" web

Techcrunch wrote recently an enlightening article about Scam ads in social games.

Irony is the techcrunch article itself showing scam banners as well:

Cult of workarounds

Wouters otherwise great document on daily buildd maintainance touches a pet issue of mine. There is a great example of a very, very common behaviour pattern in free software community. And I'm certainly as guilty of as Wouter from this behaviour.

Doing it wrong:

Note the 'tr'; this is to avoid 8bit characters from appearing in the mail, which might otherwise be converted to their quoted-printable version in transit to the buildd; and since buildd-mail (the part that receives that mail) does not understand MIME, this would corrupt the GPG signature. This way, we do lose a few characters from the changelog, but that doesn't really matter -- the source still contains the unmodified changelog entry.

Doing it right.

Why, when we have access to all the sources, we still prefer hacks and workarounds over fixes? We are wasting our biggest advantage over propiertary systems!

Why #2 - do we still have to fight 7bit issues in email? Any mailer deployed in the last decade support passing 8bit mail fine. But, not all mailers (most usually, exim or qmail) support _converting_ 8bit mails to 7bit, and thus don't _advertize_ 8BITMIME capability. And when a properly 8BITMIME supporting mailer needs to pass a mail to a smtp daemon that doesn't advertize 8bit capability, the sending mail daemon will happily convert the mail to quoted printable mime. Graah.