Massive Server Farms Can Equal Massive Failure

A quick trip over to the Amazon Web Service Status Page reveals that massive server resources don't exactly equate to massive uptime numbers. The S3 storage cloud has been down pretty much all day due to "an issue with the communication between several Amazon SQS components." This has affected both the EU and the US, causing some big headaches.

I'm not all that disturbed. I'm just happy that someone makes even bigger impacting gaffes than I do.

Where Are the Java Physics APIs?

If I'm going to try and port Deskblocks to Java then I'll need to find a native Java physics API. If my only choices are native libraries then it makes more sense just to stick to Qt 4 - I'd rather keep this entirely in the "compile once run anywhere domain." Managing native libraries with wrappers functions is just a pain in the butt.

I was surprised to see slim pickins for physics API. For 2D physics I just found Phys2D and for 3D physics I found JBullet, a port of the Bullet physics API. Both seem to be great projects, and both seem to be currently active. Indeed, I'll probably give Phys2D a try and see if I can use it. I guess I just expected an ODE port by now.

KDE 4 Really Fast, Except When It's Really Slow

I've enjoyed openSUSE 11.0 not necessarily because it works flawlessly, but because it's the best working install of KDE 4. KDE 4 has a lot of great potential, but it's not fully realized until you hit KDE 4.1. Since 4.1 is the actual version of KDE 4 meant for widespread usage, I've been downloading the unstable builds from SuSE's build service.

Things have been working fine except for one extremely nagging thing - the initial draw of a konsole window takes 5-10 seconds. It's extremely obnoxious, especially when you need a terminal so often.

I found out this was due to NVIDIA's drivers on newer boards - as described in the KDE techbase and illustrated in the Ubuntu forums and How-To's. Luckily it was an easy fix - running nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1 as root set the appropriate settings in the NVIDIA driver to allow windows to resize at the speed they should. But I don't necessarily blame NVIDIA - the blame deserves to be cast further.

The Linux Hater's Blog brings up a great point about Xorg not being about to allocate offscreen buffers - something that I didn't realize. Xorg lacks a memory manager, so all the stuff you need for full OpenGL support just can't be done. It simply can't be done with Xorg. All the points made in the rant are absolutely right - the memory management infrastructure for pbuffer and framebuffer objects have to be there, otherwise you're hosed.

The core issue that comes from this deficiency is that X11 in and of itself is inherently unable to support OpenGL. Lack of offscreen buffers means that all the great stuff you should be able to do directly in hardware can only be accomplished with a software renderer. Of course, this defeats NVIDIA's entire business model of making the GPU the most important part of your workstation. So they had to massively replace parts of X11; the NVIDIA Linux drivers must, by sheer necessity, replace huge chunks of the XOrg implementation.

After reading the Linux Hater's post a lot of other stuff made sense - why NVIDIA's drivers are so invasive, why you magically don't need to install Xgl to run Compiz Fusion if you are using the proprietary nvidia driver (because it already replaced Xorg for you, thanks), and why KDE's desktop effects had window resizing slowdowns.

NVIDIA didn't break things - they fixed things. They're just trying to live in our broken world.

Java DeskBlocks

Right before I started my latest hacking-for-cash endeavor I was working on DeskBlocks, a physics sandbox rendered directly on the desktop. I was using Qt 4 for development, mostly so I could use ODE and refresh my C++ coding. One problem in development was that things would work perfectly fine in X11 - rounded edges, nice circles bouncing around, render speed was great - then things would work horribly in Windows. Or vice-versa. I could never get things to behave properly cross-platform.

With Java's big update, it's windowing toolkit now allows for translucent and shaped windows on platforms that support it. That means the rendering issues I had with Qt 4 may be solved with Java 6u10.

It makes me start thinking if I should move the project to Java instead. It appears there are Java bindings for ODE... so it just might work.

Real-Life High Dynamic Range Lighting

I've been a sucker for HDR in gaming for a while now. So when I saw mention on Hack a Day about turning your point-and-shoot camera into a full-featured model that allows you to do stop-motion and high dynamic range photography my curiosity was piqued.

The Stuck In Customs HDR Tutorial gives a good reason why HDR photography can be so appealing: our eye adjusts constantly as it is observing its environment, quickly dilating and contracting the pupil to modify the range of light and color hitting the retina. HDR photography does the same thing, re-sampling the image to take in a varying amount of exposure and light at different depths of field.

Hack a Day turned me on to using the CHDK firmware add-on with a Canon SD870 IS. The CHDK add-on software allowed me to do exposure bracketing in continuous shooting mode.

Luckily HDR photography is all the rage lately, so I even had a Grumpy Editor's guide to HDR with Linux. It was great - it introduced me to PFScalibration and Hugin's image alignment, which are both nicely wrapped together in the fantastically easy to use Qtpfsgui toolkit.

Of course I had to turn the flash off and lower the resolution (to allow the continuous mode to write to the SD card faster), but in the end I had a perfect stack of images at varying exposures to import into Qtpfsgui. A tree turns into something more provocative pretty quickly:



I was amazed at the quality of open-source options for photography - Qtpfsgui was great for HDR, and Rawstudio was even more fantastic in dealing with my RAW digital negatives. The SD870 IS doesn't have native RAW file support, but thanks to CHDK and DNG4PS-2 I was able to quickly pull DNG files off of my SD card and start editing them in Rawstudio.

Unfortunately I don't have much if any time to try out new things, but this was a pretty pleasant diversion for the evening.