Blog - /Tech

I have a keyboard with a suspend button. I also have a desktop which I'd like to remain on all of the time, despite accidental presses of this button. Here is how I protect myself from the fumble-finger freeze.

• Run gnome-power-preferences &.
• Open the "General" tab.
• For the "When the suspend button is pressed" option, choose "Do nothing".

For a while I thought that this event was managed by acpid, but in fact it is managed by HAL, hence the need to change it via gnome-power-preferences.

I watched the Org-Mode Google Tech Talk video recently. It helped me to understand more of what Org-Mode was about. I thought I'd share some likes and dislikes concerning Org-Mode.

Like:

• Different agenda views. Very nicely done.
• Folding the entire structure of the document to make a "Table of Contents" of sorts.
• Colorized "TODO"/"DONE"/"WAITING" keywords.
• Generating an HTML table from an Org table that is embedded in a comment.
• Auto-realigning tables after hitting TAB.

Dislike:

• Meta+(left arrow, right arrow) key bindings. I use this all the time for navigating around documents in modes other than Org, and it annoys me that Org mode uses this to manipulate heading levels. This is easy enough to work around, with a few well-placed define-key statements.
• Focus on tables. Now that I'm out of college, I have no use for tabular data. Then again, the taylor + Calc example in the video was amazing.

Open questions:

• How does Org Mode deal with some text at the left margin which follows a heading? Does it get folded with the heading? I don't want to have to indent text just to get it folded.

So you've recently converted a darcs repo into a git repo. Good choice! Unfortunately, the conversion process made it so that people who used a short login name rather than a full name when committing now have the email address for their commits set to your own email address. Not good. Here's how to fix that, by changing the email address in their commits to be just their short login name.

git checkout master
git checkout -b rebased
git-filter-branch --env-filter \
  'if test "$GIT_AUTHOR_NAME" = $(echo $GIT_AUTHOR_NAME | cut -f 1 -d" "); \
  then export GIT_AUTHOR_EMAIL=$GIT_AUTHOR_NAME; fi' HEAD

If you like what you see, then it suffices to do the following to make the master branch point to the new commit history.

git checkout master
git reset --hard rebased
git branch -D rebased

For a while I thought I was using kqemu, but in fact was not. Here's how to fix that.

1. sudo module-assistant a-i kqemu
2. Edit /etc/modules and add the line:

   kqemu

3. modprobe kqemu
4. Make a new file called /etc/udev/rules.d/60-kqemu.rules. It should contain the line:

   KERNEL=="kqemu", NAME="%k", MODE="0660", GROUP="mwolson"

   Change the group to something appropriate for your setup.

5. Run udevtrigger to make the previous step take effect.
6. Run qemu, passing it the --kernel-kqemu option.

When I switched to Pulseaudio recently, I noticed that MusicPD started consuming way more CPU time than it used to. The culprit is the following lines in ~/.mpdconf.

mixer_type                      "alsa"
mixer_device                    "default"
mixer_control                   "Master"

The fix is to use the software mixer instead:

mixer_type                      "software"

Delving further into what makes Python difficult for me to debug, I think part of the problem might be the backtraces. Emacs Lisp and Perl backtraces display the affected functions and files from the inside out, while Python takes the unnatural step of reversing the order.

Another specific problem that I have with some Python programs is the sheer number of small classes that they are composed of, often with many classes per file. Better is to have one class per file, with that class having more than just 3 or 4 methods. If it has less, you are abstracting too much! (Aside: This is not to say that Java gets it right. Hell no. The compiler should not care what you name the file that happens to contain your class.)

As for replacing existing programs: I don't really care what language the program is written in, as long as it works. I enjoy Miro now, but when it was broken in the alpha days for Ubuntu Gutsy, it was a huge pain to try to figure out what was going wrong. Things that I enjoy extending and hacking on, such as blogging software (PyBlosxom), are prime candidates for replacement. In the case of PyBlosxom, I am going to try out ikiwiki. I have even done some initial work on getting Emacs Muse to work as a potential extension for it, so that I can push .muse files to my webserver using git, and have them published automatically once there. I still need to buckle down and write the Perl glue to connect to this Emacs Muse "compiler", though.

Dear Python,

I love some of your applications, but I hate debugging them. You enable programmers to write shitty and ill-advised objects and your advocates call it "magic". The magic is gone from our relationship — it's time to call it quits. Any Python program that I've ever wanted to extend or fix will now be replaced with something that is written in a saner language. Goodbye, Pyblosxom. Good times, MoinMoin. Good riddance, Bazaar — being a GNU project can't fix what ails you. Tailor, you are a horrible and poorly-documented siren of version control interoperability, and I have wasted enough time on you.