Truecrypt + ext2/3 + Linux AND OS X

Ok, so the combination of Truecrypt and ext2/3 is not optimal for sharing data between Linux and OS X. Truecrypt and fuse-ext2 on OS X cannot mount an ext2/3 partition read-write. So I will now go back to the lowest common denominator for all OSes: NTFS…
Update: Yes, it seems NTFS is a good alternative. With both OSes using NTFS-3G, I can use the Truecrypt file on both Linux and OS X — and even Windows, if I had one… Creation of a 200GB Truecrypt file takes time, though. And copying all the data to it, even more.

Description of Apple’s Keynote file format

What a nice surprise. Apple has actually documented the Keynote file format. Sadly, as far as I can see, there is no import/export capability in either PowerPoint nor OpenOffice.org Impress. That would be a nice feature. But it’s good that Apple does document the format. Since it is XML, it is easy to parse. However the hard part is always the semantics, not the syntax…

Akonadi Hell

Which sick, twisted mind designed Akonadi? Everytime I run Kontact for the first time, it will fire up a dialog, presenting me with strange errors that happen upon running Akonadi. The second time around, it works fine. This is, by the way, on a fresh KUbuntu 10.04 installation. Sometimes, a little bit more Q/A on complex FOSS projects would be really, really nice.
Update: Plus the display of Google contacts using Akonadi (in the KDE address book) is totally borked. Well, good thing I only change my contacts through MobileMe or the iPhone, and push those changes on to Google…

Spherical Harmonics Explorer

I have written a neat little Spherical Harmonics explorer. Right now, the projection function has some weird bug still, but the basis functions, and arbitrary combinations of them can be viewed nicely. The tool is written in Python, using PyQt4 and PyOpenGL. Python is excellent for prototyping such a tool. It might not be as fast as C++, but the rendering speed using PyOpenGL is more than enough and very smooth. I might put the small 3D viewer widget online later, because it might be useful for many people. Here’s some eyecandy:

Update: Now the projection also works fine. See the example screenshot of an order 5 approximation. This still needs some more work, still using a very basic Monte Carlo sampling approach, which converges terribly slow. But I can already produce some results.

Selecting between overloaded signals in PyQt

The signal mechanism in Qt allows for overloading. E.g. the QSpinBox comes with two signals called valueChanged(int) and valueChanged(QString). However, since Python is dynamically typed, such overloading gives rise to problems. Here is how you can select which signal you want to connect to your slot:

from PyQt4 import QtCore, QtGui, uic

class MyMainWindow(QtGui.QMainWindow):

def __init__(self):
QtGui.QMainWindow.__init__(self)
self.ui = uic.loadUi("MyMainWindow.ui", self)

# Slot connections
self.ui.spinBox.valueChanged.connect(self.spinBoxChanged)
self.ui.spinBox.setValue(4)

@QtCore.pyqtSlot(int)
def spinBoxChanged(self, i):
# do something...
pass

Notice the (int) in the decorator of the slot. This has to match the signature of the signal. I haven’t dug into more complex signals, passing around arbitrary objects, but I think that is not a problem: Qt datatypes have a Python wrapper, and functions in Python cannot be overloaded anyway, so there won’t be clashes with pure Python signals and slots.

Redefining quit-char in Emacs 23

The quit command C-g is pretty much standard in Emacs. It runs the interactive function keyboard-quit and also serves as the default quit-char. It aborts basically every running function, also it allows you to cancel operations in the minibuffer. The Emacs documentation describes current-input-mode, set-input-mode and set-quit-char for getting and setting the quit-char value. Also, global-set-key allows you to rebind keyboard-quit to another character. However, this does not work very well. The quit-char is not settable for non-tty Emacs versions, e.g. on OS X using Cocoa Emacs you get this:

So, basically nothing changes. On a tty it looks more promising:

After rebinding the keyboard quit as well, using (global-set-key (kbd “C-q”) ‘keyboard-quit), not much happens either. It seems the minibuffer assumes C-g to be the choice of the day. Running find-file with C-x C-f or interactively via M-x find-file, and then hitting C-q does nothing except printing “Quit”. Hitting C-g however quits the minibuffer. This seems to be documented in Bug #1218 of Emacs.

gitx with push / pull support

I love gitx, the git GUI for OS X. However, it used to have no push / pull support. Which is pretty important for git. But git and github are beautiful pieces of software. So there is another fork on github, containing push / pull support and more. This little context menu made me happy:

Readymade binaries can usually be found on Brotherbard’s blog.
Update: There is a better, newer branch even yet. See my other blog post.

Backup of running VirtualBox machines

If you are using VirtualBox for running servers, you might have stumbled across the question: How do I backup a running virtual machine? The problem is, that the machine state, consisting of the hardware state and especially the virtual harddisk, might change during the backup. This means that you will most probably end up with an inconsistent machine state, from which you might not be able to recover, after restoring the machine from your backup.
So I thought up a little script that creates a static machine state that can be backed up, while the vbox continues to run on a current, changing machine state.
Requirements: two states named current and previous (you have to add them manually first), where “current” is the current vbox snapshot, which the machine is running on. The script will move the current state to the name “previous”, and delete the old “previous” state. It will then take a new “current” snapshot.
The previous snapshot (.vmdk and .sav) together with the main .vmdk or .vdi can then be used for backup purposes.
So it’s a good idea to run this script before your daily backup run. The snapshots take only some seconds. Deleting the old snapshot might take a bit longer, because the deleted machine state is committed back to the main machine state.
Note that your backup software will fail to backup the current snapshot correctly. However, since vbox generates random IDs for the states, it is not easy to exclude the file from the backup set. So just ignore error messages from your backup software concerning that particular state file. This way you will have a machine state that lags only some minutes compared to your backup system.

#!/bin/bash

VBOXMANAGE="/usr/bin/VBoxManage -q"

if [ $# != 1 ]
then
echo "Usage: $0 VBoxName"
exit
fi

echo "Renaming old snapshot..."
$VBOXMANAGE snapshot "$1" edit previous --name deleteme
echo "Renaming current snapshot..."
$VBOXMANAGE snapshot "$1" edit current --name previous
echo "Taking new snapshot..."
$VBOXMANAGE snapshot "$1" take current
echo "Deleting old snapshot..."
$VBOXMANAGE snapshot "$1" delete deleteme

Evoke 2010 wrapup

On Friday and Saturday I went to the Evoke 2010 in Cologne together with 0xtob. Exactly 25 hours before the 4k Intro compo deadline we started coding… Well, I haven’t coded an intro ever before, 0xtob has some more experience. Plus the two other, very brilliant entries in the competition had much more time to prepare. But nevertheless we managed to submit an entry for Linux, which took about 3.2KiB.

0xtob even managed to code a minimalistic sound engine in less than an hour, so that we had at least some noise playing in the background. The whole intro is just one scene without any fading in or out so far. It’s basically a raytraced implicit, morphing function (interpolating between two animated implicit functions). So we actually do not render any explicit geometry. The raytracer is written in GLSL, and the textures are a port of Ken Perlin’s original improved Perlin noise to GLSL, which I somehow managed to do. The intro runs on both Linux and OS X, but on OS X it is currently about 7KiB, so not quite 4k. A Windows port will follow at some time, I guess. We are planning to clean up and beautify the intro somewhat and put it on pouet in the coming weeks.
All in all it was a lot of fun, and we got a lot of help: jix borrowed us his MBP running Linux, because the orga did not want to accept OS X as the host OS, and 0xtob’s Quadro NVS was not up to the task rendering the whole thing in 720p. 🙂 Some unknown guy borrowed us the MDP to DVI adapter. Robert helped to crunch the binary to minimal size, and also made the shader more colourful than ever. Roman gave helpful hints and was another pair of eyes watching over the code.

MobileMe bugs: Image upload with Linux based browsers impossible

Well, the MobileMe gallery upload seems to only like Mac browsers. I have only my SuSE box here, so I tried to upload using Chrom 5.0 and Firefox 3.5. No luck. Both browsers throw errors. Just like this:

So far, I cannot find any documentation on this behaviour. I would have assumed that either FFox or Chrome would work. MobileMe on OS X says it supports FFox and Safari. But since Safari is not available on Linux, I thought I might try FFox and Chrome. Now waiting for a MobileMe chat support guy. I doubt they are educated enough to actually help me…


Update: The chat guy was friendly, and had one hint: update to FFox 3.6. I was still on 3.5. And sure enough: now the upload works. Only one file at a time, though. But I found out even more on my own. It seems all the images are accessible from your iDisk as well. They are stored in Web/Sites/_gallery/id. Where id is the number of your gallery. However, you cannot just upload pictures there. Every image needs to be put in a separate directory. Every directory must then have the following files:


exif.json
large.jpg
medium.jpg
square.jpg
web.jpg


The exif.json is obviously a JSON style EXIF data block, e.g. like this:
{“data”:{“infoSensing”:”One-chip color area sensor”,”infoExposure”:”Normal program”,”infoExposureIndex”:”–“,”infoFNumber”:”2.8″,”infoDistance”:”–“,”infoGPSLongitude”:”8° 15&#39 35.40″ E”,”infoWidth”:”2,048 pixels”,”infoName”:”IMG_0133.jpg”,”infoDigitizedDate”:”Thu, 19 Aug 2010 12:18:20 PDT”,”infoFocalLength”:”3.85 mm”,”infoHeight”:”1,536 pixels”,”infoExposureTime”:”0.003846154″,”infoGPSLatitude”:”50° 0&#39 5.40″ N”,”infoAperture”:”f/3.0″,”infoMetering”:”Average”,”infoShutter”:”1/260″,”infoSize”:”1022.27 KB”,”infoBrightness”:”–“,”infoCameraModel”:”iPhone 3GS”,”infoMaxAperture”:”–“,”infoCameraMake”:”Apple”,”infoExposureBias”:”–“,”infoFlash”:”32″,”infoOriginalDate”:”Thu, 19 Aug 2010 12:18:20 PDT”,”infoGPSAltitude”:”115.00 m”,”infoISOSpeed”:”64″,”infoLightSource”:”–“,”infoSoftware”:”4.0.2″},”status”:1}
This should be easily created by a short shell script, using “exiftool -s image.jpg” and some awk magic. The image files in the folder are:

large.jpg: 2048×1536 (original resolution? at least for iPhone 3GS)
medium.jpg: 427×320 (approx. iPhone screen resolution)
square.jpg: 160×160 (thumbnail)
web.jpg: 1024×768

For portrait, I assume that the width and height are swapped. Have not checked this yet. Later, I will try to whip up a bash or Python script which produces these files automatically from a list of input images. Let’s see if this works.

Oh yes, one more thing: In Linux you can easily mount the iDisk with “wdfs  http://idisk.me.com/your-id iDisk/
“.

Update 2: A quick check revealed that the iDisk interface is quasi read-only. Writing new albums or pictures there will not show up in the gallery itself. That would have been too nice. So I guess this is only possible via the (unpublished?) HTTP API of MobileMe itself. Just like the Picasa API for uploading and manipulating photos. But it seems the API is quite hard to decipher, which is sad, given that Google practically documents all their APIs and encourages mashups and websites using their services.