Today, I took part in a tour to the Intelligent Sensor-Acuator-Systems (ISAS) department here at the University of Karlsruhe. They work on a project for extended-range telepresence. At first it is like a regular Virtual Realtiy device: Head-mounted display for the 3D view of the world and an acoustic tracking system to record the user’s curret position and orientation. While this is a nice toy by itself, the guys from ISAS have developed a system where you can walk through inifinitely large virtual places, including a virtual museum, a pacman game and our cafeteria, rendered by quake, and still stay in the 5x5m room at the university.This works by bending the space, at least the space you percieve: The computer calculates a path that resembles the path you want to go with regard to length and turns, but bends it a barely noticeable bit, thus guiding you in circles around in that room. This guiding is done by shifting the view on the display, making you counter-act that shift and thus turning. A bit like dizziness, when you think you tip over and you move the other way.This works pretty well, at least for movement at regular speed and not too many unpredictable turns - the less predictable the path you take in the virtual world, the less optimal is the path you will take in the real room, thus having stronger and more noticable bends.To me, this seems to be the first step to a world like the one Tad Williams describes in his “Otherland”-Series. Together with what promising but also threatening advances are made on the neurological front, e.g. retina prothesises, “real” virtual reality for mass comsumption is not so far away. And even more improvements in the human-device-interface field have been made: Remote control of human movement by stimulation of the equilibrium sense was sucessfully tried in Japan (German link).I have more pictures of today’s presentation and check out the video on the Karlsruhe telepresence installation.

Repeat with me: I HATE HARDWARE! My laptop's hard disk drive (iBook G4, purchased last year before going to Debconf4) has 369K+ load cycles completed, which means it has a very good chance of starting to fail some time soon. Great. Specially not because of loosing data or anything, but because changing a disk on one of this bastards is like finding a needle on a hayloft. Harry Potter's books are getting insane as a movie source. The Goblet of Fire is quite lengthy, but when turned into a movie it becomes a complete piece of craziness. During the whole movie you feel like someone is talking behind your ear: "run, run, cut this, run, not time for elves, no time for tournaments, forget about this, does not fit (mao, anyone?), run,... Arf arf arf, YES! We made it 2.5h !!!" It leaves me wondering how on earth they are going to turn the 5th "most boring HP book in the saga" book into a movie, and how they will manage to turn the 6th one into a 2.5h movie again, without dropping half of the superinteresting things happening there. Oh, well, I guess I have to read the books again.

As Benjamin Drieu noted, ccache is a wonderful tool. He complains about the configuration needed, which in the Debian package is really, really small. Just do PATH=/usr/lib/ccache:$PATH in your .bashrc or .zshrc and it will be used for all compilations. Very useful and less cumbersome than creating the links in ~.

The holiday season is here. Seems to me like we just finished up last year. Man the years are starting to fly by fast. Got a decent deal on a Sirius receiver at Best Buy this weekend. So far I like it and it integrates in the car and at home pretty well. Now all I need to do is figure out how I want to integrate the ipod into the car system. Can you say Wired Car? Soon we will be able to find affordable solutions to having internet in the car. It is only a matter of time. Spent most of my time the last few weeks working on the car. Between tires, coolant leaks, and bad alternators the thing has had soon good work done on it. She is running good now tho and I feel like she will make the winter ok. All I have left that is not a need now situation, but a I want to do it just to get it done, is replace the front brakes and rotors and bleed the lines. Suppose to be decent temp. wise Monday so maybe then. Been working on the desktop backing up data so that I could set the two sata 160gb hard drives into a Raid0 array. I cant install Ubuntu using d-i because of dmraid. I have to use the live cd to go in and install dmraid to access the drives in the raid then bootstrap it. There has been some talk recently about putting dmraid into the d-i so that it works out of the box. Maybe that is something I would like to get into. Currently I have grub installed and placed dmraid scripts in the initramfs. Now I just have to solve why it can not find init. Looks like it is not able to mount / and /dev off the cuff. More time pending, I will play around with it and make notes if need be then turn that around into the d-i stuff in debian.

Do you want to hear the most incredible "it's not a bug - it's a feature" story ever?

After shooting hundreds of megs of RAWs with my Canon 350D last couple of weeks, I noticed a very strange thing - importing this large amount of files from my camera into F-Spot took ages. F-Spot ate memory in tens and hundreds of megabytes and never returned it back to the system. Well I blamed it on Mono and went searching for a better way. Then I found out that command-line C program gphoto also take the same horrific amount of memory to import my photos. I saw that to download 900 Mb of photos (~250 photos) photo memory use went up to ~910 Mb (2 Mb were shared). Luckily Linux managed to swap out part of gphoto, so I could finish the download with my 512 Mb of real RAM and a 1 Gb swap file. I googled and founds tens of bug reports on this - first of them as early as December 2004. Ouch.

Well - let's see what the problem is, shall we? Some bugreports reference a bug in gphoto's SourceForge bug tracker where a users reports that downloading a 250 Mb video file takes 250 Mb of RAM and developers reply that unfortunately that is the limitation of current infrastructure and it is very hard to fix. Bumer.

But wait! He says that downloading ONE file takes a lot of RAM. This limit should not exist when downloading multiple files - we should be able to drop information about previous file as soon as we start downloading the next one, right?

Ok, lest see, what really is going on there. Downloading source of gphoto. Looking at it. Seeing a lot of mess. After around 10 minutes I start to understand that there is a table of option names and functions and the real job is doe by command line parser who calls a function as soon as he encounters a proper parameter on the command line. :P After 3 more minutes jumping around the code I finally get to a function that gets called to download a single file. Looks pretty easy:

• take a CameraFile pointer


• pass it to gp_file_new() for inicialization


• pass it to gp_get_file() to get the actual data of file (download happens here)


• pass it to gp_write_file_to_file() to dump the data to a file on disk


• pass it to gp_file_unref() to free the data

Looks all fine and dandy so far. However I see the memory use that suggest that this last operation does not happen as it should, so I search for the gp_file_unref() function. I do not find it in gphoto source, but as I soon figure out - it is in libgphoto2. The function is pretty straight forward - the reference count of the structure is reduced by 1 and if it has reached 0, the structure is freed from memory via gp_file_free() function.

Hmm, I wonder what will happen if I replace gp_file_unref() with gp_file_free() in gphoto? After a quick compile and installation (I thank the Gods and all DD's for the wonders of "debuild -us -uc && sudo dpkg -i ../gphoto*.deb") I ran gphoto again. Wow, it now only consumes 8-16 Mb of RAM and not 900. The files downloaded fine, but in the end glibc made a lot of fuss about "double free". What does that mean? It means that someone managed to get a reference to our MemoryFile and didn't give it back. Naughty boy!

We only call three functions using that pointer, so it should not be hard to trace them trough the source to see what they do. The gp_file_new() function looks good, it sets reference count to 1 always. gp_get_file is more complex - I get to crawl through a lot of strange redirects to all levels of gphoto architecture. At one point I get a bit alarmed as I see a local variable called ref_count, but then I see that the code just stores reference count there for safekeeping while data is copied from another object and right after that copy reference count is put back safely. After all that I get to the end of the gp_get_file function, just a couple thing left - cache the result, clean up and return the file. Wait a minute ....

CACHE?!?!?!!

$(&@($^@#$(^@&^$(#&$@#(&$(@#$&!^&$^@*!(&$#(@& !!!!!

It appears that someone thought that it is a good idea to use a gig or so of my RAM for cache, just in case if I would like to download the same photos the second time around in the same program call. IT IS NOT!

Results: one line patch, one NMU building for upload, one *very* long bug in upstream bug tracker, one developer quite upset and not too convinced about the correctness of free software ways any more :P

This vast amount of C++ ABI transitions is so bloody annoying. It makes developers maintaining C++ packages so unproductive as they are blocked for weeks waiting to upload new versions of their package.

Why isn’t the package updated in Debian yet?

Well, we have just another C++ ABI transition, this means the libsigc++ is incompatible to the version before and all packages have to be recompiled.

Debian is just too slow, even Ubuntu and Gentoo are faster...

Gentoo is source-based and I had, back when I used it, the impressions that some developers do not really try to compile it before they commit the new version, but I think this has changed now. Ubuntu, well yeah, even they are much quicker in transitions, out of various reasons I’m too tired to rehash here. Not only am I blocked by libsigc++-2.0 which I theoretically could NMU away, but by the whole bunch of gtkmm stuff which also needs to be recompiled with all of its dependencies. It will take weeks until the new revision of Gobby could enter at least Debian unstable. I bet that Ubuntu MOTU will update my package by their own before I am able to upload a new one to Debian to get it synced from there.

This article cracked me up; specifically, two lines of it. “‘The agreement signed today will defend Somalia’s territorial waters, defeat the pirates and put an end to the illegal fishing and poaching of our precious natural marine resources,’ Prime Minister Mohamed Ali Gedi said.” “Defeat the pirates” sounds like something out of a video game or cartoon. That could’ve just as easily been about killing Shredder, defeating the Foot Clan, and saving April O’Neil. “‘We will end the piracy very quickly, there is no question about that,’ said Mr Casini.” This company is clearly the answer that the RIAA and MPAA have been looking for!

Several years ago (it seems like more than three) I was a student at Brown University. In addition to studying computer science and mathematics, I also took a bunch of courses in the music program, including three years of piano lessons. When I graduated, I gave a recital for friends and family, plus any members of the public who happened to wander in (not many did). And, this being the 21st century, we recorded it and I got a CD of the recording. I edited it, split it into tracks, and handed some copies out to my friends and professors as a going-away present.

Now I'm no longer a student of any sort, and Brown seems a lifetime away, but the music is still sitting on my hard drive. I've always meant to make it available for download, but I couldn't figure out how to get past technical issues of space or bandwidth. A few days ago, though, I had a rather belated bright idea: maybe the Creative Commons project would have links to places where you can host your music for free. Lo and behold, it turns out that the Internet Archive lets anyone upload audio to their server! Better yet, they're even willing to store lossless encodings -- more than willing, actually; FLAC is the preferred encoding of uploads.

So, to make a long story short, click here to hear my bad piano playing. :-)

I've already fielded enquiries from two people who have found my blog via Google, and given the 10,500 visas a year being issued, there's only going to be more, so in the interests of not spending too much time answering questions individually, I'm going to write a detailed account of things. Disclaimer: This article is not a replacement for doing your own homework. I expressly disclaim any responsibility for you getting your visa application denied, being cavity searched when you attempt to enter the US, or being sent to Guantanamo Bay. In particular, this information is subject to change, and as I'm not applying for a new visa every day, I'm not going to know about the changes. If you find something here that is blatantly wrong, or out of date, please let me know, but at the moment, I'm writing about my experiences. I'm undecided about maintaining a website devoted to capturing the state of the art in E-3 visa applications. If in doubt, spend the money (and I do mean spend, it's not a cheap phone call) and call the information line - 1902 941 641 - to speak to a human being, and ask all the questions. Resources

• The Australian Government's Department of Foreign Affairs and Trade's page on E-3 visas
• The US Consulate's E-3 visa page
• The US Consulate's page on applying for a non-immigrant visa

What's the process? Your potential employer (sponsor) needs to file a Labor Condition Application (see the form here). At present, this form hasn't been brought up to date with respect to E-3 visas, it's the same form used for H1-B visas. Your employer needs to have written at the top of each page "E-3 - Australia - to be processed". This bit of handwriting is apparently key. You need to have the signed LCA in your hot little hand before you roll up at the US Consulate to apply for your visa. As for how long these take to be processed by the Department of Labor, the FAQ says a week for postal applications. From my experience, and the experience of a couple of other people I've spoken to, it takes anything up to about four weeks. Generally speaking, you do not have to concern yourself with the LCA process, unless for some reason, you're sweating on the LCA so you can apply for your visa. My personal opinion is that the whole process is so long, bureaucratic and unpredictable, that you really don't want to be making any firm plans based on any assumptions on when you think anything is going to happen. Start your planning from when you have been issued your visa, not when you expect you will be issued your visa. Once the LCA has been issued, your sponsor will send it to you along with a wad of paperwork, most of which you just take with you to the consulate. You can make an appointment online. Paperwork-wise, you need to take a completed DS-156 and a DS-157 if you are male between 16 and 45. These forms are available here. You can make an appointment online, the links to make an appointment at each of the US Consulates are also here. I found that the lead time to an appointment was around a month, so if you know the LCA application has been made, you can probably make the booking at the Consulate, so as to try and parallelise things a little bit. What do you need to take to the interview? You need to take your completed DS-156 and DS-157 forms. You need one for each person. So if you are the principal (i.e. the person being hired), you need a DS-156 for yourself, and your spouse, and whichever of you is male needs a DS-157. Bring the sponsor's offer letter too. You need a receipt for a non-refundable visa application fee. You need one receipt per person applying for a visa. You get these receipts by paying $130 per person at any Australia Post outlet. As the visa is non-immigrant, you need to be able show some sort of ongoing connection with Australia. If you own property here, and are planning to continue owning it while in the US, bring a rates notice. I don't know what else is useful to demonstrate an ongoing connection. Also bring a bank statement, as you need to demonstrate an ability to support yourself while in the US. Bring birth certificates and marriage certificates. Also bring a copy of your University transcript, and any assessments that your employer may have had done that state that you hold the equivalent of a US degree. I'm not sure how hard and fast the whole degree thing is. I have an incomplete degree and about 10 years of work experience. This was sufficient. I don't know how you'd go with absolutely no degree and lots of work experience. Finally, you need to bring two US-sized passport photos. These are 5cm x 5cm, which are not what your average passport photo is like if you go somewhere and ask for a passport photo. Processing takes about 3 days, although you get an indication on the day as to whether you are successful or not. If you don't want to come back to collect your passport with the visa in it, you need to leave sufficient stamped, self-addressed envelopes so that the Consulate can mail the passports back to you. It's a bit hazy as to what constitutes 3 days, but assume 3 full working days, plus whatever time it takes for the postage, so up to 5 working days. Good luck with your visa application. Let me know how it goes, and if this has been of assistance.

I didn't blog immediately when I got back homei, mainly because the first days after my return (which was on Sunday) I was too busy feeling like shit.
The fair was rather straining, especially since I was there on my own and a normal fair day included about 3 hours of car driving (half of it in a horrible 7 line fair traffic management system) and about 9 hours of standing around, all tarted up with pantsuit, high heels, make up et al., smiling, looking attentive and not as bored (and in pain) as I was. (No, there are no pictures!!)

Anyway, enough whining. I am back and made an almost full recovery (Save some big bruises on my right leg, of which I have no idea where I got them. Probably bumped something against my leg when taking down the booth again.) and there are now much more pleasant times ahead. The Leipzig christmas market opened today and I plan to pay it a visit sometime this weekend. (Yea, I know, kitschy, sentimental, commercialised, ... but it's fun anyway, so shut up and have a gingerbread.).

The second highlight of this weekend will be the Skatalites concert I'll see on Saturday. For those who don't listen to Ska, the Skatalites can be considered to be among the "founding fathers" of today's Ska music. They were most popular around '63 - '65, today they are of course all pretty old guys (And girls they bring Doreen Shaffer, yay!!).
But they still do some considerable rockin! And it is to be supposed that there might even be a fair amount of enjoyable skankin' going on among the faithful followers of the acustic and sensual delight that is good Ska music.

I just uploaded a belpic that compiles on stable to my people.debian.org webspace, so that people using stable will be able to use belpic, too, and might be able to use their digital ID card to sign emails, or use the tax-on-web thingy of the Belgian government. The idea is to get this into backports.org, but I can't reach Norbert Tretkowski ATM, so it'll have to wait 'till he reads his mail. One thing is weird, though. To be able to build belpic for unstable, I had to change some things like (unsigned char **) in the code to (const unsigned char **), or it wouldn't compile. Now that I try to compile it on stable, I apparently have to reverse those changes, or it won't compile. Probably some definitions of one (or more) of the build-dependencies changed. Not that it's a problem, of course, but it is silly. On a slightly related note, Zetes N.V. (belpic's upstream) suggested I go ahead and maintain packages for them to put on the Government's website, too, so that people would be able to install it by downloading from belgium.be. This wouldn't just be the Debian packages, but also packages for other distributions (probably RPMs, then). Sounds like fun. This isn't at all official yet, but it might be some time from now.

So, Black Cat Networks have a bunch of nice dedicated servers and I've been working on various network installs for them. Debian was of course easy; there's a nice netboot.tar.gz that has everything you need (including configs for serial consoles). Fedora Core was a bit harder; there's mention about network boots and installs, but not a lot of docs. A pxelinux entry like:

label fedora
	kernel fc4/vmlinuz
	append initrd=fc4/initrd.img ramdisk_size=8192 console=ttyS0,9600n8 serial

does the right thing, with vmlinuz and initrd.img coming from http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/images/pxeboot/. Fedora's a bit annoying in that it doesn't offer you a selection of mirrors to network install from though, so you need to have worked that out for the install. FreeBSD however, was much harder. Firstly, there aren't any decent docs about it that I could find. Secondly, it really wants to use NFS, even though TFTP will be required anyway for the PXE boot stage. So, I ended up recompiling the pxeboot loader with LOADER_TFTP_SUPPORT enabled and LOADER_NFS_SUPPORT removed (though it still tries to do NFS mounts it seems). Of course, you can't do this under Linux easily. Nor can you do it on FreeBSD 4.10 it seems (I was recompiling the FreeBSD 6 loader). However you can on FreeBSD 5.4. You need the lib and sys source trees to do so. Or you can have my prebuilt copy, freebsd.0. pxelinux config looks like:

label freebsd
	kernel boot/freebsd.0

assuming you put it in a boot subdirectory under your tftpboot root dir. You then need http://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/6.0/6.0-RELEASE-i386-bootonly.iso to get the rest of the /boot contents from. Burn it to CD or loopback mount it or work whatever magic does the trick for you to get access to the files in that image. Then copy all of /boot on it to boot in your tftproot. You don't actually need boot*, cdboot, loader or pxeboot, but they're all small files. Then, add the following to loader.conf:

boot_serial="YES"
console="comconsole"
kernel_options="-h"
vfs.root.mountfrom="ufs:/dev/md0c"

So, now you can type "freebsd" at your pxelinux boot prompt and it'll boot up the installer. Rock. I don't quite understand why I had to include the kernel_options line above - I thought setting boot_serial would do that for me. However, it works. With the only real pain being having to recompile pxeboot and the lack of docs. Which I've now sorted for you. ;)

Yet another thread on keyring updates in Debian has gotten me thinking about key signatures, what they really represent, and other associated topics. For those of you who might not know what I'm talking about, a brief primer. Before someone can be admitted as a Debian Developer, they have to have an OpenPGP key (practically, a GPG key) signed by a current Debian Developer. That is, someone who is currently a DD has looked at a photo ID, compared the photo to the face offering a key fingerprint, and compared the name on the ID to the name on the key. If they all match, we have a signature. The other qualification for becoming a Developer is going through a process designed to determine whether you have the required competencies. Since this testing process is conducted electronically, not face-to-face, the primary means of identifying the person behind the answers is via the OpenPGP key they used throughout the process. So, what do we have out of this process? Two things, that I can determine:

• The signature says that someone who Debian already trusts (the current Developer) affirms that the name on the key belongs to someone who has the same name.
• The holder of the relevant key has passed the necessary competence checks. Effectively, the New Maintainer process certifies that a particular key is competent, to all intents and purposes. This is important, because it's that key that gives you all of the "privileges" associated with being a DD -- voting, package upload, etc. Your identity is effectively that key.

So, the problem at issue is this -- what do you do when you lose control of that key? You lose it, or it gets compromised, or it expires (whoops!), or whatever. For all intents and purposes, when you lose control of your key, you no longer have an identity, in Debian terms. Generating a new key (and hence identity) is straightforward -- a quick invocation of gpg and you're away. Unfortunately, all that gets you is a pile of bits. There's nothing that intrinsically links you to that key. That's what other people's signatures on your key is for. Then, it comes time to get Debian to accept your new key as belonging to you. This is a lot harder than trying to convince the RTA (DMV.en_AU('New South Wales')) to give you a replacement drivers' licence. Why should it be? You're doing effectively the same thing -- "I am $FIRSTNAME $LASTNAME, give me my (licence upload privileges)". The difference is that, in the Debian case, all of our identity is effectively tied up in the key we use to go through NM. The person behind the key is somehow secondary to that whole process. So when the key completes NM, we record it in the "people who can upload" keyring. When a new key (which is prima facie completely untrusted) should be put into the keyring, we need to ensure that it is qualified. How can that key prove qualification? Well, we can send the new key through NM (dear ghods, no!) or refer to the source document (as it were) -- the human being. We're looking for consistency between the person between the two keys. That's trickier than it looks at first glance. Why? The big one is the non-uniqueness of $FIRSTNAME $LASTNAME (or even $FIRSTNAME $INITIAL $LASTNAME, for those so blessed). Google for yourself one day, and you'll see what I'm talking about. Anyone who has the same name as you could, at first instance, pretend to be "you" (for some values of, anyway). It might seem fairly unlikely, but there are two DDs with easily-mistakable names, out of a pool of 1,000 or so. The probabilities are not in our favour on this one. Then, of course, there's fake IDs, which are a whole other ballgame. How does the government get around the problem of name clashes and identity-theft-by-ID? By using other metadata about you to more uniquely identify you. Your date of birth, street address, perhaps even a general physical description -- all of these can help to disambiguate all of the identically named people out there. Debian can't use that, though, since that metadata isn't initially collected, and so it can't be rechecked later. This does suggest a bit of a solution, though. I said that Debian doesn't collect that info, but that's not entirely true. There is an optional repository of Developer contact details stored for other DDs to access, so we've got something to work from. The Developer updates their own details (whatever they feel comfortable entering). But, of course, people signing your key need to know about all that before they sign the key, so they can check (for example) your residential address and date of birth on your photo ID. You might ask "but how is the info the developer themselves entered accurate?", and that's a good question. The answer is that the legitimate developer entered that info, so if someone with the same name matches that data, then it's reasonable that it's still the same physical person. It's not a real good solution, though. Not all developers enter full metadata (and I can understand why they don't want to). People also often forget to update their details, too, which could quickly cause all sorts of problems. What is a good solution, then? We could always go with a bit of biometrics -- if there was any solution that was sufficiently cheap, reliable, and distributed enough to be used to identify 1,000 developers distributed across the globe to a reasonable standard of reliability. I'll wait for a minute while you finish laughing and wipe your eyes dry. I have to say, I'm stumped. I'd hoped, while writing this, that by the time I was finished I would have worked something out. But nope, it's a problem that's way beyond me. But I think I've got a much clearer handle on the problem space, so with a bit of luck, my subconscious (or someone else's) will eventually produce a sensible answer.