So there’s this really annoying bug that a lot of GNOME users have been experiencing, including myself. The first issue is that the default GNOME layout binds the “Windows” key to Super_L/Super_R, which prevents you from using it as a modifier key. This is a relatively easy fix; run gnome-keyboard-properties and change “Layout Options->Alt\Win Behavior” to “Meta is mapped to the Win-keys” (or just about anything other than “Default”, apparently). Now, you can open up gnome-keybinding-properties and use away. But wait! It mysteriously only works for some of the actions. This is because essentially two keybinding backends are used, gnome-settings-daemon and metacity. Turns out, gnome-settings-daemon ignores Mod4 (which is what the Windows key gets mapped to as a Meta). Thankfully, it’s an easy fix! Grab my patch or if you’re running Ubuntu/Debian, you can install these deb’s which already have the patch applied and restart GNOME (these have only been tested on Ubuntu Hoary). Now, rejoice that you can finally have Windows+L mapped to “lock screen”!

After struggling with this lovely error (”XML Parsing Error: not well-formed” while pointing to a nonexistant location in my code) for a while hacking around on Wereboy, I became a little frustrated. So I created a clean profile and added the extension, where it worked fine. Turns out that profiledir/XUL.mfasl will apparently keep around uninstalled plugin chrome then later confuse itself, resulting in this sort of breakage. You have to delete/move it then relaunch Firefox to force a rebuild.

This plugin lets you post Tomboy notes to a weblog through the magic of XML-RPC. Attached is the source (goes in tomboy-[ver]/Tomboy/Plugins/) and a diff/patch against the cvs tomboy-[ver]/Tomboy/Plugins/Makefile.am.

Notes:

• needs XmlRpcCS. Mono 1.1.x users, check my guide for installing it.
• there’s no pref’s dialog, you need gnome-blog, it currently reads your gnome-blog settings from GConf
• currently only supports the MetaWeblog API (MovableType, etc.)
• does not support post editing
• currently just uploads whatever the text value of the note is. If your blog supports setting a default formatting style (like Markdown), just use that in your note and it should show up properly.

Some ideas for enhancement:

• keep track of postID’s in an extra XML field (like width and height are now). This would allow you to upload a post, then edit/update it within Tomboy.
• move pref’s to Tomboy’s preferences dialog and GConf settings?
• let you sync your notes with your weblog. This would update your blog with local Tomboy changes, as well as pull down other posts not made from Tomboy into Tomboy.
• maybe a different icon?

Enjoy, feel free to enhance/update/improve/etc.

And yes, this post was made with it.

I was trying to work on some XML-RPC craziness under Mono, and came across XmlRpcCS and a nice tutorial. Problem is, since I’m running Mono 1.1.4, I could reference the built XmlRpcCS.dll assembly at compile-time with no problems, but the resulting program would die with:

WARNING **: Could not find assembly XmlRpcCS, references from
  ~/source/monoblog/monoblog.exe (assemblyref_index=3)

This is because with Mono 1.1.x, it seems you must register signed assemblies with gacutil. In order to do this with XmlRpcCS, you need to do the following:

1. Download the XmlRpcCS source file and unzip it.
2. cd to the XmlRpcCS directory and run “sn -k XmlRpcCS.snk” to generate your keyfile.
3. Edit the makefile and change the CSFLAGS line to “CSFLAGS=-define:__MONO__ -delaysign-“

4. Edit src/nwc/xmlrpc/AssemblyInfo.cs and add the following lines:

   [assembly: AssemblyDelaySign(false)]

   [assembly: AssemblyKeyFile("XmlRpcCS.snk")]

5. Run make

6. Run “sudo gacutil -i XmlRpcCS.dll -package XmlRpcCS“

Now when you need to compile against XmlRpcCS, just add “-r /usr/lib/mono/XmlRpcCS/XmlRpcCS.dll“, and it should work fine.

After having read somewhere that installing gnome-volume-manager on Debian was all kinds of cool, I gave it a shot. Somehow, it wound up breaking udev so it no longer saw my DVD/CD-RW drive, which is pretty much the opposite of the intended effect. This probably has something to do with the fact that I’d been kludging this Debian install along for quite a while, from all sorts of fun migrating between 2.4.x and 2.6.x, to random USB hackery, to writing my own scripts to start up wireless properly, and so on. Deciding I’d hit the breaking point, I went ahead and installed Ubuntu Hoary. So far, it’s very nice. I had the foresight to put /home on a seperate partition back when I installed Debian, so everything I’d personalized for my login pretty much still works properly. I’ve already got Beagle and Tomboy (complete with C# DBus bindings out of the box) working, with no real hassle at all.

Update: Switched back to Beagle 0.0.8 so it would work with inotify, and it’s working much better now. And with the Firefox plugin provided by the Beagle project, it looks like it pretty much already does what I was looking for. Also got other things like mplayer, acroread 7, etc. up and running. Also got suspend/resume working again, however, my consoles are still messed up after running video-post. Suspend-to-disk appears to lock up completely as well.

Britt ran into me today while I was hacking around on a toy program of mine. Basically, I’d gotten fed up with having 5000 Firefox tabs open at once, with no proper way to search through my history or bookmarks, so I decided there needed to be a better way. I started playing with Gecko# and got a bit caught up in getting something half-usable out. Since the last thing the world needs is another web browser, I’ll probably just polish it off some more and put up the source to help out (or possibly confuse!) anyone else who wants to do some Gecko# hacking beyond a 5 minute browser. I did finally discover the old Mac app I was doubtlessly inspired by, TrailBlazer.

Anyway, onto the main reason for abandoning it, my conversation with Britt made me realize that even beyond the silliness of trying to create another browser, I was also reinventing the wheel in numerous other ways. It would probably be much easier to hack the functionality I’m looking for onto Beagle. Guess I’ll need to set up an inotify-enabled kernel.

Speaking of which, I need to do quite a bit of kernel hacking in less than a month anyway, with 3-4 large kernel modification projects ahead of me. Thankfully, due to my inability to read a syllabus, I finished all my projects for another course two weeks ahead of time, so I won’t have that looming over my head.

With everyone talking about the Colorization Using Optimization technology, I thought people without access to MATLAB might enjoy a usable program that employs it.

The MATLAB MCR (installs the shared libraries you need to run compiled MATLAB programs) for Windows is huge, so I made it into a torrent:

Download torrent [83.26MB]
View torrent stats

Windows build:

Download the compiled build here: colorize-win32.zip [1.55MB]

Then:

1. Download and run the MATLAB R7SP1 MCR Installer from the torrent.
2. Open up a command window, navigate to where you’ve extracted the executable and CTF file, and run “colorize.exe infile.bmp infile_marked.bmp outfile.bmp”
3. Wait a while, because this build uses the “exact” solver, it’s rather slow.

If Windows complains that CTF is not a registered file type and it can’t find the proper program, you may need to reboot. You can use the example bitmaps from the source zip linked on the original website if you want to see what input should look like.

Linux build:

Download the compiled build here: colorize-linux.tar.bz2 [3.6MB]

You don’t need the MCR for this build, all the required libraries should be included.

1. Put /path/to/colorize-linux/sharedobj on your LD_LIBRARY_PATH with export or setenv. (example: export LD_LIBRARY_PATH= /home/blah/colorize-linux/sharedobj:$LD_LIBRARY_PATH)
2. Run “./colorize infile.bmp infile_marked.bmp outfile.bmp”

I was doing some kernel development, and I was getting a little tired of rebooting my laptop into the new kernel after each build. Having heard about qemu, I decided to give it a go. I found a sample script for building a disk image to boot qemu off of, but it didn’t seem to work. For example, the uuencoded information in that script produces output that makes gunzip complain that it’s invalid. So I decided to roll my own disk image with the following commands:

dd if=/dev/zero of=diskimage.img bs=1M count=512
losetup /dev/loop0 diskimage.img
mke2fs /dev/loop0
mkdir mounted
mount /dev/loop0 mounted
debootstrap sid mounted/ http://ftp.us.debian.org/debian/

You should now have a nice base Debian install to diskimage.img. Clean up your mounts with:

umount mounted
losetup -d /dev/loop0

Then you can launch qemu with a command like:

qemu -hda diskimage.img -kernel /path/to/bzImage -append 
  "root=/dev/hda sb=0x220,5,1,5 
  ide1=noprobe ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe"

Ta-da! Once you’re done, make sure you shutdown with “shutdown -h now” before closing out qemu, or you’ll probably have to mount the image to loopback again and e2fsck it manually. You can also mount the image any time you’d like with “mount -o loop diskimage.img mounted” and muck about in the filesystem, or even act like you’re on it locally by using the chroot command after you’ve mounted it. If you get an error like:

Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0)

when you try to boot, make sure you have ext2 support built in to your kernel, also set CONFIG_IDE, CONFIG_BLK_DEV_IDE, and CONFIG_BLK_DEV_IDEDISK to be built in as well.

I upgraded mono to the latest Debian package (1.0.5-2), and it went and broke MonoDevelop.

$ /usr/bin/cli --debug /usr/share/dotnet/monodevelop/bin/MonoDevelop.exe
Creating DefaultWorkbench

(MonoDevelop:9543): Gtk-WARNING **: Error loading icon: Failed to open file 
'/home/data/resources/icons/Icons.SharpDevelopIcon': No such file or 
directory

I tried using the Ubuntu package (monodevelop_0.5.1-3_i386, one revision higher than the monodevelop_0.5.1-2_i386 provided by Debian), but it does the exact same thing (except the executable is placed in a different structure under /usr/lib/monodevelop, and the /usr/bin/monodevelop script uses mono instead of cli). Doing something silly like copying the /usr/share/dotnet/monodevelop/data directory to /home makes the icon error go away, but MonoDevelop still does not start. I even tried rebuilding the monodevelop package with the new mono install, but it does the same thing. I suspect it’s related to this bug.

Update: It has randomly decided to start working again.

$ uptime Uptime: 00:24:36 up 400 days, 5 min, 9 users, load average: 0.02, 0.05, 0.00

I’m amazed at how much abuse that system takes.