In recent times, the Debian bug tracking system has been suffering from slowness due to having to handle much spam. When it takes many hours to get a response from the system, usability and productivity hurt a lot. Having waited for a response for an hour again, I wanted to rant about the evilness of spammers, but luckily I did not. My aunt had called me and I had forgotten to press "send" (specifically, I had pressed control-backspace, instead of control-Enter). Oops. So, instead, I'd like to express my gratitude to Blars Blarson for coping with the BTS spam load. Despite occasional hickups, he and others make sure spam is not something BTS users need to worry about much. Thanks!

As I wrote earlier, I've been playing with m68k assembly lately. My first program looked somewhat like this:

.LFORMAT:
	.string	"%c"
	.text
	.align	2
.LENDL:
	.string	"\n"
	.text
	.align	2
	.globl	main
	.type	main, @function
main:
	link.w %a6,#-4		  allocate a stack frame		
	moveq #65,#-4(%a6)	  Move 65 (ASCII A) to an address on our
				  local address space
.L0:
	move.l #-4(%a6),-(%sp)    push the address to the stack
	pea .LFORMAT		  push the format to the stack
	jbsr printf		  run printf
	add.l #1,#-4(%a6)	  add one to the letter
	cmpi.l #91,#-4(%a6)	  compare with 91 (ASCII Z + 1)
	jblt .L0		  if less, jump to label L0
	pea .LENDL		  push format to the stack
	jbsr printf		  run printf
	unlk %a6		  clear stack frame
	clr.l %d0		  store 0 in %d0 (return value)
	rts			  return
	.align 2
	.size	main, .-main

IOW, print out the alphabet. Nothing spectacular, and it worked. Then I decided to take it one step further, and rather than using an address in memory, I switched to using a register, which is supposed to be a tiny bit faster—even if that shouldn't be noticeable in this case:

main:
	link.w %a6,#-4		  allocate a stack frame		
	moveq #65,%d0		  Move 65 (ASCII A) to %d0
.L0:
	move.l %d0,-(%sp)	  push the address to the stack
	pea .LFORMAT		  push the format to the stack
	jbsr printf		  run printf
	add.l #1,%d0		  add one to the letter
	cmpi.l #91,%d0		  compare with 91 (ASCII Z + 1)
	jblt .L0		  if less, jump to label L0
	pea .LENDL		  push format to the stack
	jbsr printf		  run printf
	unlk %a6		  clear stack frame
	clr.l %d0		  store 0 in %d0 (return value)
	rts			  return
	.align 2
	.size	main, .-main

(that's only the main section, but please assume the rest is still there:-) When I ran that, it bombed. It would print out the A, and then whole lines of nothingness. When I ran it inside gdb, it wouldn't even print out the A. It took me quite some time to figure out what went wrong.

main:
	link.w %a6,#-4		   allocate a stack frame		
	moveq #65,%d7              Move 65 (ASCII A) to %d7
.L0:
	extb.l %d7	
	move.l %d7,-(%sp)	   push the address to the stack
	pea .LFORMAT		   push the format to the stack
	jbsr printf		   run printf
	add.l #1,%d7		   add one to the letter
	cmpi.l #91,%d7		   compare with 91 (ASCII Z + 1)
	jblt .L0		   if less, jump to label L0
	pea .LENDL		   push format to the stack
	jbsr printf		   run printf
	unlk %a6		   clear stack frame
	clr.l %d0		   store 0 in %d0 (return value)
	rts			   return
	.align 2
	.size	main, .-main

%d0 is used to store a function's return value. If I store my data in %d0, then the next time I call a function, that data is overwritten. Since I do call a function inside my loop, that function overwrites my data every time. Using a different register (say, %d7) fixes this. Right. Apart from the fact that it's totally non-portable, assembly language also has quite a few quirks that you don't learn about when taught structured programming. It'd be nice if there were a document somewhere that would explain how C functions expect to be called. I found out most of the above through trial and error, and through compiling stuff with -save-temps and looking at the result, comparing it with the 68k Programmers' Reference Manual. That works, but it's not really efficient—and not totally error-proof, too.

So, finally we got it out. You can buy right now from the web page http://www.nokia.com/770 and in US starting from 11.11.2005. It works with Debian GNU/Linux, so you will have a Debian machine in your pocket, right beside your Debian installation CD/USB key. If you applied for the developer program, you should be getting it soon. PS: If you think this is Spam, killfile me. But i still think this is fun, having Debian in my pocket.

It so happened that my ibook had a 8GiB free space area at the end of the hard drive, and therefore I decided to wanted to use that for MacOS X instead of the 2GiB partition that was used for it before. Trying to avoid problems with bad partitions, I booted from the OSX installation/rescue CD and opened Disk Utility.

To play safe, I locked the existing OSX partition for editing and then assigned the 8GiB free space area to a new hfs+ partition. When I committed, suddenly the existing partition label went blank. WTF??? Had Disk Utility decided it should format what that partition as well? Great, now I'd have to reinstall anyway instead of copying things over.

I rebooted to check partition numbers in linux, but instead of the yaboot prompt I got an alternating question mark / happy face, and after a couple of seconds it booted from the rescue CD again which was still in there. Apparently my bootstrap partition got messed with too. Not funny.

I powered off and inserted a bootable linux CD to chroot into the existing system and rerun ybin. However when I tried to mount the linux root partition it would not want to do so. I checked the partition numbers with fdisk and suddenly my stomach felt like it was tied into a knot: instead of using only the free space as told, Disk Utility had wiped the entire drive and created a 2GiB partition at the beginning and assigned the remaining 28GiB to the new partition instead.

So now I'm left with a ibook shaped paperweight for the time being. Luckily I did not keep anything really important on the laptop, but I did lose some uncommitted programming work, and some of my wife's old mail. Not to mention the time I'll lose by being unable to use it the first few days and having to reinstall it instead. So people: never trust a tool tailored for dummies to something as important as disk partitioning. And to Apple: FIX THE FUCKING PROGRAM SO IT DOES AS IS IT TOLD TO DO AND NOTHING ELSE!

Two Sundays ago, Jim and I walked down to Ubuntu Love Day. The Ubuntu Below Zero conference is being held at the Holiday Inn in Chinatown. That's the one with the fake Chinese tiles on the roof, which is sort of tacky. We found our way downstairs to the conference room and sat down. The previous night's revelries still had quite the effect, so I'm afraid I drifted in and out while listening to people speak. I thought I had rid myself of this habit, but apparently university has trained me to consider digital projectors as sleeping aids. I'll have to do something about this one day. I got to see some fairly interesting people: Mattias Klaus, whom I met earlier at Jeff Bailey's place; Fabio Di Nitto, who is incredibly jolly; Chris Peterman, who was with his classmates from Clarkson; Colin Watson, whom I thanked for working so hard on Debian; Jeff Waugh, who dressed up as an inmate; and plenty of others. Oh, I managed to meet Andrew Mitchell in person, but we failed to have a proper CHUG meeting while we were all in town. We broke for lunch, which was held in the hotel restaurant. A buffet, with some Chinese-style dishes, was being served. There, we had to negotiate with the unilingual (Cantonese) staff to find out what Jeff could eat. We had a special order of plain white rice brought for him and we were informed that it was safe for him to eat the stir-fried vegetables. I suggested to Jeff that he ought to keep a phrasebook on him whenever he travels. On each page, one per language, there should be a written description of what he can and cannot eat. Then, he just has to show this to waiters who don't speak English or French. For reference, the characters that mean "vegetarian" in Chinese are and . Most of the time, they mean "vegan", but there are some places where eggs and oysters are considered vegetarian. After lunch, Mark Shuttleworth gave Jeff a very nice birthday speech. He also gave Jeff a nice bottle of wine, which was very nice. And Matthias came up to give Jeff a bottle of fish-oil pills, which was very odd. Then, there were two Birds Of a Feather sessions, involving how to make an Ubuntu package and how to be an Ubuntu advocate. Being upstream to both these issues, I sat in the middle of the room and listened to both presentations at once. This was quite interesting, and slightly taxing. After this was done, we broke up once more. The plan for the evening was to meet for dinner in the hotel lobby. This transformed to meeting outside the front door. Jim, wlach, and I showed up and were greeted by this mass of people. Since there were stragglers and I knew where dinner was to be held, Jeff took a group of nineteen people in the metro. I followed about ten minutes later with a group of eighteen. We met up on St-Denis, and by this time we had lost some of the more impatient, and more hungry, people. Eventually, a group of twenty-three were milling about outside Le Nil Bleu. Angie had made arrangements for us to be served a set meal, and they had agreed to seat twenty-five of us. I went inside to let the staff know that we had arrived. When 20:30 came around, we were let into the restaurant and seated. I think the kitchen was still preparing food, because we had to wait about an hour before being served. Unlike my previous experience there with Jeff, the food was quite good this time and the service was very attentive. We enjoyed ourselves very much, and Jeff seemed to be having a very excellent birthday dinner. Some of the guests were not so happy, because the food was a little spicy for their European palates. Since gratuities are not standardised around the world, we discovered that some people had not tipped. To cover the embarassment, Angie and I made sure that the wait-staff were adequately compensated for their efforts. I'll be sure to go back to this restaurant again, but with a more significant crowd to ensure good service. After eating, a group of us including Matthias and Tollef went up to B l K , which was just a little north on Mont-Royal. That's a really interesting bar with beautiful tiled floors and ostrich heads on the walls. We enjoyed the lovely music, had a very good conversation there, and laughed until we were all exhausted. Since the Canonical people had to be awake for the 09:00 keynote speech the next day, they left early. Jim and I bid goodnight to them before we staggered home.

Stumbled across a blog post earlier today on a cool new “connection sharing” feature in SSH 4.0. Basically it multiplexs multiple SSH sessions over a single TCP connection so that subsequent sessions don’t suffer the key exchange and round trip setup delay. Given that I use SSH extensively to a small number of hosts pretty much continuously during my work day this sounds like a very handy feature for me. Read more at: http://little.xmtp.net/blog/2005/11/04/ssh-connection-sharing-c-visibility-share-libraries-and-gcc-attributes-oh-my/ In other knews, I’ve been doing some more hacking on darpwatch as a result of some patches I received, so there will be a new release happening soon there. I’m still battling away against Glade, GTK# and F-Spot in my quest to get all my photos exported out of gallery and into a nice F-Spot + Original setup. Updated PHPwiki packages have been built and have been pending upload for a week or two now, but my sponsor is quite busy at the moment, so there is a bit of a delay at that point inthe path. If you’re desparate for the new packages you can grab them from http://www.mattb.net.nz/debian/.

So I got pet peeved by Carlos Laviola in relation to by recent pondering about how MacOS X's SSH agent starts up on login. Perfectly reasonable grounds for complaint. I have had people contact me in relation to blog posts in the past, so it's obviously not impossible. People know I'm a Debian developer and can put two and two together and wind up at db.debian.org. Anyway, I'm the first to admit that my blog probably has too many of the Weblog Usability Top Ten Design Mistakes (something for me to work on). To date, I've been avoiding plastering my email address on my website because I didn't want to get it harvested. I try and use a per-list email address for this reason as well, and I haven't enabled blog comments because of comment spam, and because I haven't been clever enough to implement comments with Blosxom full stop. So I started getting an idea for reversibly encrypting my email address on my blog after reading about Hashcash for Wordpress the other day. I first started playing around with the Vernam cipher in High School, when I wanted to easily reversibly obfuscate some data for something. I'd read about this cipher in a magazine or something and seen it implemented in Pascal (it's not exactly hard). So I happened upon the idea of encrypting my email address with the Vernam cipher. Turns out another chap's already got a page for encrypting and decrypting on the fly with JavaScript. It even generates the JavaScript for putting in your own web pages. I had to use a different key to avoid getting dollar signs in the encrypted string, as this confused the tripe out of Blosxom (and me for a while when I tried to figure out what was going wrong). Then I thought it'd be nice to explain to people who had JavaScript disabled what they might be missing out on, so I fiddled around with some DOM stuff, and had some text get displayed if JavaScript was disabled. When JavaScript is enabled, this text is replaced by the decrypted text. So of course, like the Wordpress Hashcash, this is largely relying on the inability of spam bots to grok JavaScript. Once they can, this obfuscation technique is all for naught. Meanwhile, you can email me bit more easily now if you get the urge. View the source of my blog for an example of the implementation.

One of the things about the whole money thing and free software is the question of whether it’ll take all the fun and spontaneity out of hax0ring. As it turns out, that doesn’t even work when you try; so instead of doing dak work last weekend, like I’d planned and like the market was indicating, I ended up hacking on britney until about 5am Sunday morning, leaving the dak stuff to be spread over the week, instead. (After the last post, dak might seem cursed, but trust me it’s not. More on that RSN, but not just yet) For those playing along at home, britney is the name of the scripts used to update Debian’s testing distribution; basically it automates some of the hard problems of Debian release management. Naturally, this is a pretty tricky job – there’re over 200,000 packages in Debian unstable (spread across eleven architectures), with fairly complicated sets of interdependencies amongst them. It gets complicated enough, in fact, that the core analysis britney undertakes isn’t just too processor intensive to do in perl or python, it’s too memory intensive to use standard malloc for its data structures. (Cynical and Coding, and the UQ CS228 class of ‘98 will probably have some idea of the fun to come at this point…) The problem is that britney uses an absurd number of linked lists to resolve dependency issues, with each entry in the list being an independent block of a dozen or so bytes; and adding the usual malloc overhead to this can effectively double the memory usage. Worse, britney also likes to reuse memory quite a lot, does a fair bit of backtracking, and generally acts like the prima donna she is. Up until last week, britney’s memory was managed by the use of a parallel bitfield indicating whether memory was free or not: so britney would first allocate a 128kB block using standard malloc, note it’s all free, then every request for 12 or 52 bytes would result in some bits being twiddled; and every free would twiddle the bits back, so they could be reused later. This means two things: one is that the free invocation has to include the size of the memory to be freed as well as the address, and the other is that finding an appropriate sized block of freed memory can be awkward, leading to some degree of fragmentation. This fragmentation seemed to lead to britney having a gradual memory leak, which would mean that if the release managers were doing some complicated transitions gigabytes of memory would end up being used and OOMing; or, since britney runs on ftp-master and it’s probably not a good idea to have the OOM killer start on the machine that ensures the Debian archive’s integrity, the ulimit is reached, and britney aborts unhappily. Unfortunately, though, the use of a “roll your own” malloc means you can’t use the standard memory checkers to see what’s going on, so you’re left with guessing and hoping. And as a consequence the memory leak’s been around for ages, causing fairly regular minor annoyance. This changed last week when Micha Nelissen (neli) got into the act:

<neli> why does it need so much memory ?
<aba> neli: because it needs to check how the changes affect the installability count
<neli> aba: ok…but still does not seem like a big deal
<neli> how large trees are we talking then?
<aj> it has to do a lot of backtracking
<aj> how large is the longest dependency tree in debian?
<neli> backtracking only takes time, not space, right?
<aj> you need a list of things to backtrack over
<aba> neli: it also consumes memory, at least with the current dpkg-implem ntation
<aba> (well, there are ideas how to avoid this memory fragmentation, but that’s something else)
<aj> (it’s not actually memory usage, it’s memory fragmentation)
<neli> hmm, bad memory manager ?
<aj> imperfect, *shrug*

After poking around at getting britney to run locally, and doing some basic analysis on how it was used, neli decided to rewrite the memory manager to use chunk-size pools – so that a separate pool would be used for 4 byte allocations, for 8 byte allocations, for 12 byte allocations, etc. That’s possible due to two factors: one is that the special memory allocation is only needed for data structures which are all made from fairly small sizes, and are a multiple of the word size. It also means that fragmentation can be avoided completely – since you can use the “free” elements to store a free list taking up no extra space. Happily, that change also made the memory allocation much simpler. (It also shows the benefits of a fresh look at code; I’d been thinking of doing something similar for ages, but always been stopped because I couldn’t figure how to make it cope with the various different sized blocks I’d need. As it turned out though, I’d solved that problem ages ago when I wrote a separate allocator to deal with strings, which would’ve required my malloc to cope with a much larger variety of sizes) What it didn’t do was actually solve the memory leak. Which was pretty confusing, since the old memory checker had some tests to ensure that memory wasn’t really being leaked, and if the memory’s not being lost due to a missing free, or being lost to fragmentation, where is it going? At this point, the real benefit of having a simpler malloc implementation came across; because suddenly it was plausible to add some debugging code to allocate a separate pool for every memory allocation, and to report how much memory is being used at any point, per line of code. That gave me output like:

pool 8B/1:751; 1962683 used 1965960 allocated (99.8% of 22 MiB)

So I knew that line 751 (of dpkg.c), was allocating 8B chunks, had used up to 22MiB in the past, and was currently using 99.8% of that. (Actually, I made an off by one error initially, so the “8B” above is actually 12B, as you can see if you divide 22MiB by 1965960) That let me see two “leaks”. One turned out to be fairly easy to diagnose; as an optimisation, when I say “package foo is installable”, I note that “but we used bar to see that, so if we later update/remove bar, note that we’ll have to see if foo is still installable”. So the datastructure for bar ends up with a linked list of all the packages, foo, that relied on it. But I don’t check that list for dupes, so if I note that both bar and baz were required for foo to be installable, then update bar, when I recheck foo, I’ll add it to both bar’s and baz’s lists; which is fine for bar, whose list I cleared when I updated it; but not so fine for baz, because it’s now got two entries for foo. Having already added a check for dupes when trying to see if my guess was right, extending that check to skip the addition was pretty easy. The other leak required a little more investigation. It was in a fairly tight loop which could reasonably be using a fair amount of memory; but by the end of the loop it should all be freed. Adding some more debug code to the allocation functions confirmed the problem:

<aj> pool 8B/11:1231; 1618157 used 1703936 allocated (95.0% of 13 MiB, 9.05% current)
<aj> so it looks like ~9% of those allocations are never freed to me
<aj> 9.05% = used/alloc
<aj> where used is incrememnted on b_m, decremented on b_f
<aj> alloc is incrememneted on b_m, never decremented

The code was meant to either add the allocated block to a larger list that’s being traversed, or to free it immediately – the problem turned out to be that there were some nested ifs, and an internal if was lacking an else that should have freed the block. Fixing that changed the results to:

pool 8B/11:1228; 160 used 131072 allocated (0.1% of 1 MiB, 0.01% current)

Which both dropped the leak – only allocating a maximum of 130,000 nodes instead of almost 2,000,000 – and resulted in almost all the allocations that had ever been made, having been freed once britney had been running for even a fairly short while. As it turned out, though, the cure for the first leak was worse than the disease – checking for duplicates in a linked list turned out to take too long, and the memory wasted in that section wasn’t that big a deal. Using a red-black tree or similar instead would’ve been a solution, but so far doesn’t seem necessary. There haven’t been any OOMs since, happily; and even better, the reduced bloat seems to have made the overall checking a bit faster. Sweet.

Recently, I’ve been going through mozilla-firefox’s list of bugs and took a look to some of them. I got interested in #336411, since I’m regularly hit by this one myself (remember ? I said I got strange crashes with 1.5beta1). It appears that this strange crasher is in fact due to extensions using binary components. ColorZilla was the one killing my firefox. Why does it crash on debian’s firefox and not on upstream’s ? Simple : upstream’s is built with gcc 3.4, debian’s with gcc 4.0. Both C++ ABIs are incompatible. Now the question is : what can we do for that ? A quick fix could be to check before loading the component, if it’s linked to the incompatible libstdc++.so.5, but it’s almost as nasty as the bug itself… I’ve not really investigated possible solutions yet, but if you have some better ideas, you’re welcome. Another bug I got interested in is #211010 and its dupe, #256384. This one was really nasty. One of the kind I hate : bad programming practices. The interesting thing with this bug, though, was that it’s been revealed because of 3 other issues in 2 separate programs. The first issue is that autoconf decides to use echo 'something\c' over echo -n something when both ‘\c’ and -n are understood by echo. The second issue is that when giving some options with spaces to configure (like in --enable-optimize="-pipe -w -O2"), the associated variable gets backslashed spaces (i.e. "-pipe\ -w\ -O2") (thus, being an autoconf feature) The third issue is that the mozilla configure.in script tries to get rid of these backslashed spaces with echo $enableval sed -e 's \\\ g', triggering the nasty dash bug. A simple workaround, as stated in #256384 is to quote $enableval Now, for the dash bug itself. What happens with dash is that whenever you echo a ‘\c’ escape sequence, all subsequent echo commands stop printing after the first argument containing a backslash. For example echo test1 'test2\ttest3' test4 outputs test1 test2<tab>test3. In the case of our echo $enableval, since its value was -pipe\ -w\ -O2, it printed -pipe\ without any space after the backslash, so that it was not removed by the sed call. This value was then substitued in config/autoconf.mk.in to create config/autoconf.mk, where the ending backslash was interpreted as its shell meaning (continue on next line), thus breaking the variable, and build command lines. And for the bad programming practice ? The dash bug is due to a global variable that never got re-initialized, leaving the “terminate echo” (kinda) flag turned on (which is only checked when there is a backslash in the argument, since it is used to stop printing after, guess what… ‘\c’). No wonder why one of the first things you learn in programming classes is : never use global variables. (or at least, be very very very careful about what you do with them)

I’ve released randomplay 0.48. randomplay is my command-line ‘itch a scratch’ music player. It is most useful for maintaining a random shuffle over many sessions—for example, I use it to make sure I don’t ever hear the same song in any three month period. The new version fixes a bug that prevented randomplay from advancing to the next track when the player subprocess itself spawned a child process (e.g., with ‘play’ which spawns ‘sox’). I use a bit of a hack to kill the child task and it’s children, but the standard way of doing this in perl—kill HUP => -$$ doesn’t seem to work when randomplay is called from a shell script and the child process’ output is redirected to null. Here’s the code in question (with the fix to kill children and grandchildren recursively):

# KillAll recursively kills the request process ID and all of its children/grandchildren/etc.
# This is a bit of a hack--there should be a better way to do this, but I haven't found one.
# Normally, kill HUP => -$$ should do the job, except this doesn't work when randomplay itself
# is called from a shell script and all output from child processes is redirected to null.
# This subroutine assumes that shelling out to ps is going to work, which may not be totally
# safe--at the very least, it reduces the portability of the script.
# Any suggestions for a better way to do this are welcome.
sub KillAll  
  my $pid = shift;
  local $SIG HUP  = 'IGNORE';   # don't want to kill ourselves here--shouldn't happen, but just in case.
  if (open PS, "ps -o pid,ppid  ")  
     eof PS; # Force ps to run now. Otherwise it would run at the first read operation.
     kill HUP => $pid;
     foreach my $line (<PS>)  
       KillAll($1) if ($line =~ /^\s*(\d+)\s*(\d+)\s*$/ and ($2 eq $pid));
      
     close PS;
    else                  # if we can't read the process table, just try killing the child process group
    kill HUP => -$$;
   
 

Thanks to Christopher Zimmermann for the patch to kill children recursively.

Fascinating New Yorker interview with Brent Scowcroft, National Security Advisor to Bush 41. I wonder how the author, Jeffrey Goldberg, gets this degree of access: he’s apparently emailing back and forth with Bush 41, having coffee with Colin Powell, and engaging in frank discussion with Scowcroft for a significant period of time. This sort of reporting is the antithesis of what you see in most newspapers, where the reporter probably spends no more than a few hours piecing together information that is widely available. This is also consistent with everything I’ve seen in the New Yorker for the past few months I’ve been subscribing—high quality writing and primary source information that you won’t pick up just from reading blogs. In any case, it’s interesting to see all these conservative ideologues from the Reagan-Bush era turn on the neoconservatives. If Brent Scowcroft thinks the war in Iraq is misguided, does the current administration have any hope at all?

Some weeks ago the kernel on vore, Debian's sparc porting machine and sparc buildd, was exchanged and didn't run as stable as expected. According to the site admin he was able to fix these problems in the meantime. However, one week ago the machine became unavailable again. This time it's a connectivity problem with the switch port. Unfortunately the security buildd for sparc has no redundancy. Even though auric, the other sparc machine of the Debian project hosted at the same place, visi.net, was configured to run a buildd for the general distribution, it wasn't set up to pick up security as well. It is not know when the connectivity problem of vore will be fixed. However, this morning build logs for security updates were received from a new machine. It looks like somebody spent some time on fixing the issue without vore and alleviate the situation. Hope we'll have a sparc buildd soon again.

I am excited this evening. I just found a CD that I burned back in 1996 or 1997 or so. On this CD is some data I thought I had lost. It has copies of information on some floppies that can't be read anymore. But it also has the PowerPoint presentation I did as an 8th grader that got me to National History Day in Washington, DC. Not only that, but also the original high-resolution scans of the photos I used in that presentation. Some of these scans are of photos that date back to the early 1900s, whose owners may not be easily reachable today. I had been hoping to find this for years. I knew it was buried somewhere. And YES -- stumbled across it tonight. I will be posting some photos on this blog in the coming days. But first, I have to find a way to convert this ancient PowerPoint file to a format that OpenOffice can read -- so I get the correct story behind each photo. The scans were saved back in the days when a person got 8 characters to name a file. Not very descriptive. (And I remember how much space it took up on the hard drive I had back then, and how much I wanted to just delete those big picture files. Glad I didn't.)

OK, so I spent some fun time playing around with my 5g video iPod — time for more serious action now. I have created two patches today which add support for the video iPod to gtkpod, a GTK+ based, platform independent GUI for Apple's iPod.
These initial patches allow you to sync m4v video files to your iPod and watch them there. I will add support for all other video formats which work on the iPod, soon. The patches will be sent to the gtkpod maintainers, of course, in the hope that they can be included in the next release. Note: This is pre-alpha, barely-tested code! Use at your own risk! Installation instructions:

• Get the current CVS version of libgpod. Apply the following patch: libgpod_5g_video_ipod_support.patch. Compile and install libgpod.
• Get the current CVS version of gtkpod. Apply the following patch: gtkpod_5g_video_ipod_support.patch. Compile and install gtkpod.
• Mount your iPod (USB cable): mount -t vfat /dev/sda2 /mnt/ipod
• Start gtkpod (possibly as root, depending on your system) . Maybe you need to edit the settings and adjust the mount point for the iPod (/mnt/ipod is the default).
• Click on the "Read" button to read in the iTunesDB from the iPod, click on "Files" to add a video file (e.g. this Apple commercial from 1977), click on "Sync" to upload the file to your iPod.
• Quit gtkpod, unmount the iPod (umount /mnt/ipod), disconnect the USB cable.
• Profit!!!1

I get a "Destroying mmap buffer" error every time I sync the iPod, but that's probably a gtkpod bug, and it's non-fatal anyways. If you happen to own a video iPod, please test the patches and report whether they work! Thanks!

Today, a UPS delivery guy delivered a largish box, containing the Quadra 700 that had been donated to me by Sebastiaan Couwenberg (thanks!). The box was much larger than I expected, however. At first, I was afraid; if it ended up very large, I wouldn't have any space to put it anywhere. Fortunately, on opening the box, I found that it was, in fact, not very large, as the case is the same as that of the IIci (which is the smallest case I have—people who went to DebConf5 may remember what it looked like, since it stood in the hacklab the whole time); instead, the box contained more than I expected. Aside from the Quadra, the box also contained a keyboard, a three-button ADB mouse (I didn't even know those existed in the first place), and a monitor. Whee. I had four macs (of which one has a broken LC040, so is not usable), but only two ADB keyboards (of which only one is in perfect working order), one ADB mouse, and one monitor (which beeps annoyingly if it's been powered on for more than a few minutes). With this, that amount has suddenly doubled, which is very welcome. I'll probably move this monitor to the office, and move the one at the office home some time. Not just yet, though.

The X.Org security list has a web form, linked off www.x.org, to submit security concerns. Predictably, it gets a lot of spam and weird stuff. However, I'm utterly at a loss to explain this one:

Date: Wed, 2 Nov 2005 10:12:04 GMT
Message-Id: <200511021012.KAA11645@xoneweb.opengroup.org>
To: xorg_security@x.org
From: Dave Custard <davecustard@custardcreams.com>
Subject: X.Org SECURITY CONCERN: Custard Creams
My concern is that the custard creams are going to escape and
kill us all with their sweet custardy filling. I'm scared.
(form_Security)

I have heard of Gobby many times now, but when Daniel Stone blogged about it today, I finally decided to give it a try. For those who don't yet know what I'm talking about:

Gobby is a free collaborative editor based on libobby, a library which provides synced document buffers. It supports multiple documents in one session and a multi-user chat. It runs on Microsoft Windows, Mac OS X, Linux and other Unix-like platforms.

One apt-get install gobby later, I was astounded as to how mature it already feels. I think Gobby will be of great benefit when taking notes during conferences, talks and so on. It could also prove invaluable as a pair programming tool. Anyways, I already hear you crying "but SubEthaEdit has been doing this for ages", which is true. But:

• Gobby is GPL'd, SubEthaEdit is not.
• Gobby is a cross-platform tool, SubEthaEdit is not (I don't own no Mac, you insensitive clod!).

There you have it. (via Daniel Stone)