The tl;dr:

• Use recordMyDesktop to record video clips, but afterwards, re-encode them to AVI (see the script I used)
• Record audio to WAV, or convert compressed audio to WAV format afterwards.
• Use OpenShot to stitch clips together and layer audio and video tracks.
• Remember to reset the video length if you change the playback rate.
• Export to a Web + Vimeo profile for best results.

Stumbling Blocks

recordMyDesktop is a fairly simple tool, and allows you to record actions you're taking, and simultaneously capture audio. However, it creates an ".ogv" (Ogg Vorbis video file) -- which is basically useless for anybody not on Linux or FreeBSD. Additionally, I often like to record in segments; this makes it less likely that I'll make mistakes, and, if I do, I only need to record a small segment again, not the entire thing. recordMyDesktop is only for creating screencasts, not merging them.

So, recordMyDesktop went into my toolbox for the purpose of recording the video portion of my screencasts.

Which brings me to the next point: I also prefer to record the audio separately from the screencast portion itself; this way I don't get typing sounds in the recording, and I'm less likely to lose my train of thought as I'm speaking. To this end, I ended up using quite simply the "Sound Recorder" utility (gnome-sound-recorder). It's not great, but with a reasonable microphone, it gets the job done. I chose to record the audio as MP3 files.

However, this means that I now have video and audio tracks. So my toolbox needed a utility for overlaying tracks and laying them out on a timeline independently.

I looked at a few different free tools for Linux, including Avidemux, Cinelerra, and PiTiVi. Avidemux was not featurful enough, Cinelerra was too difficult to learn (it's more of an advanced user's tool), and PiTiVi kept crashing on me. So, I used the lazyweb, and tweeted a question asking what others were using -- and the unanimous response was OpenShot (http://www.openshotvideo.com/).

OpenShot hit the sweet spot for me -- it was easy to pick up, and didn't crash. However, I discovered problems when I exported my project to a video file. My video, regardless of whether or not I changed the playback rate, always played at about 2X normal speed. The audio always truncated 1 to 2 seconds before completion.

In doing some research, I discovered:

• There are known issues with Ogg Vorbis video files. Evidently, the compression creates issues when re-encoding the video to another format.
• Similarly, compressed audio can lead to issues such as truncation.

Since recordMyDesktop doesn't allow you to select an alternate video codec, I had to use mencoder to transcode it to another format. I chose AVI (Audio Video Interleave, a video container format developed by Microsoft), as I knew it had widespread support, using an mpeg4 codec (also widely supported). I used the following script, found at http://askubuntu.com/questions/17309/video-converter-ogv-to-avi-or-another-more-common-format, in order to encode my files:

for f in *.ogv;do
newFile=${f%.*}
mencoder "$f" -o "$newFile.avi" -oac mp3lame -lameopts fast:preset=standard -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=4000
done

That solved the video issue, but I still had to solve the audio issues. I quickly re-recorded one audio segment in Sound Recorder, and told it to use the "Voice,Lossless (.wav type)". When I used this version of the audio, I had no issues, other than the audio length being mis-reported within OpenShot. Instead of re-recording all segments, I installed the "Sound Converter" utility (`sudo aptitude isntall soundconverter`), and used that to convert all my MP3 files to WAV. Interestingly, OpenShot reported the audio lengths correctly this time; go figure.

Once that was done, I was able to start stitching everything together. A few notes, in the hopes others learn from my mistakes:

• Several times, I wanted my video to playback slower. This is very easy to do: right click on the clip, select "Properties", and select the "Speed" tab, and adjust as necessary. However, that's not all you need to do; you need to also re-adjust the length of the clip. Simply take the existing length, and divide it by the rate of play. As an example, if the length is 44 seconds, and you specify a 1/2 rate (0.5), you'd do 44 / 0.5 = 88, and set the length of the clip to 88s.
• If you find that OpenShot is reporting your audio clip lengths incorrectly, use another tool to find the accurate length, and then set the length to that. I typically rounded up to the next second, as most tools were giving the floor value from rounding.
• I chose to export using the Web + Vimeo HD profile. This worked perfectly for me. It created an mpeg4 file that I could preview in a browser, and then upload without issues. Your mileage may vary.

Hopefully, this will serve as a reasonable guide for others foraying into screencasts on Linux!

One possibility presented to us was the possibility of utilizing GPG signing of commit messages. Unfortunately, I was able to find little to no information on the 'net about how this might be done, so I started to experiment with some solutions.

The approach I chose utilizes git hooks, specifically the commit-msg hook client-side, and the pre-receive hook server-side.

Client-side commit-msg hook

The commit-msg hook receives a single argument, the path to the temporary file containing the commit message. This allows you to inspect it or modify it prior to completing the commit. Like all git hooks, a non-zero exit status will abort the commit.

My commit-msg hook looks like the following:

#!/bin/sh
echo -n \"GPG Signing message... \";
PASSPHRASE=$(git config --get hooks.gpg.passphrase)
if [ \"\" = \"$PASSPHRASE\" ];then
    echo \"no passphrase found! Set it with git config --add hooks.gpg.passphrase <passphrase>\"
    exit 1
fi
gpg --clearsign --yes --passphrase $PASSPHRASE -o $1.asc $1
mv $1.asc $1
echo \"[DONE]\"

This hook requires that you first add your GPG key's passphrase to your local git configuration, which can be done as follows:

% git config --add hooks.gpg.passphrase \"mySecret\"

Once this hook is in place, all commit messages are then clear-signed, leading to commit logs that look like the following:

commit f921f0defb18f8a5218d5c3346693dbb4179920e
Author: Matthew Weier O'Phinney <somebody@example.com>
Date:   Tue Mar 23 17:18:35 2010 -0400

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    how now, brown cow
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)
    
    iEYEARECAAYFAkupMCsACgkQtUV5aSPtKdqERQCeN5taRATpB4/XJZiP9Vs5FVNY
    PcoAn0OZbIIcn7nC01yxp9tY7HbxVVFu
    =C/Ju
    -----END PGP SIGNATURE-----

Server-side pre-receive hook

The pre-receive hook is a lot less straight-forward. This hook receives input via STDIN. Each line consists of three items, separated by a single space:

[previous commit's sha1] [new commit's sha1] [refspec]

Typically, only the new sha1 is of much use to us. Internally, git is actually keeping track of the new commit, even though it has not technically been accepted into the repository. This allows us to use tools such as git show to get information on the commit and act on that information.

What I needed to do was inspect the commit message for a GPG-signed message; if none was found, reject the commit outright, but if one was present, validate it against my keyring, and abort if the signed message is invalid.

I originally started by using git show --pretty="format:%b" [sha1] However, I discovered that git does something... odd... to commit messages. The first 50 characters or so are considered the commit's "subject" -- and any newlines found in the subject are silently stripped. This meant that I was getting, for my purposes, a truncated message that would never validate (as the GPG signature header was getting stripped); even including the subject in the format did not work, since the newlines within it were missing. The only way I found to get the full commit message was to use git show --pretty=raw [sha1]. This, however, gives me also the commit headers as well as the diff -- which means I have to parse the response.

What follows is a PHP implementation I did that does exactly that: grabs the full message and redirects it to a temporary file, parses that file for the commit message, and then acts on it.

#!/usr/bin/php
<?php
echo \"Checking for GPG signature... \";
$fh     = fopen('php://stdin', 'r');
$tmpdir = sys_get_temp_dir();
while (!feof($fh)) {
    $line = fgets($fh);
    list($old, $new, $ref) = explode(' ', $line);

    // Create a tmp file with the commit log
    $logTmp   = tempnam($tmpdir, 'LOG_');
    $body     = shell_exec('git show --pretty=raw ' . $new . ' > ' . $logTmp);

    $msgTmp   = tempnam($tmpdir, 'MESSAGE_');

    // Scan the commit log for a commit message
    $log = fopen($logTmp, 'r');
    $msg = fopen($msgTmp, 'a');
    $signatureDetected = false;
    while (!feof($log)) {
        $line = fgets($log);
        if (preg_match('/^(commit(ter)?|tree|parent|author)\s/', $line)) {
            // Skip the commit log headers
            continue;
        }
        if (preg_match('/^diff\s/', $line)) {
            // Stop scanning when we reach the diff
            break;
        }
        if (preg_match('/^\s+-+BEGIN [A-Z]+ SIGNED MESSAGE/', $line)) {
            // We have a signed message, so start appending it 
            // to a separate tmp file
            $signatureDetected = true;
            $line = preg_replace('/^\s+/', '', $line);
            fwrite($msg, $line);
            continue;
        }
        if ($signatureDetected) {
            // If we have detected a signed message, continue appending lines to
            // it. Commit message lines are indented, so strip indentation.
            $line = preg_replace('/^\s+/', '', $line);
            if ('' === $line) {
                $line = \"\n\";
            }
            fwrite($msg, $line);
        }
    }
    fclose($log);
    fclose($msg);

    if (!signatureDetected) {
        // No signed message detected; report and abort
        unlink($logTmp);
        unlink($msgTmp);
        echo \"no GPG signature detected; commit aborted\n\";
        exit(1);
    }

    $verification = shell_exec('gpg --verify ' . $msgTmp . ' 2>&1');
    if (!preg_match('/Good signature/s', $verification)) {
        // Failed to verify signed message; report and abort
        unlink($logTmp);
        unlink($msgTmp);
        echo \"invalid GPG signature; commit aborted\n\";
        exit(1);
    }

    unlink($logTmp);
    unlink($msgTmp);
}
echo \"verified!\n\";
exit(0);

There are likely more elegant ways to accomplish this, including solutions in other languages. However, it works quite well.

Conclusions

Git hooks are quite powerful, and delving into them has given me confidence that I can create some nice automation for the ZF git repository when we are ready to open it to the public.

That said, I don't know if we'll actually use commit signing such as this, as it has a few drawbacks:

• The commit signing is not really cross-platform. This can likely be remedied, but it would require that people on different operating systems and using different tools (such as EGit, TortoiseGit, etc) develop and provide signing mechanisms for the client-side.
• It introduces complexity for those developing patches. If developers begin without having the commit-msg hook in place, they then have to create a new branch and a squashed commit afterwards in order to ensure the final patches can go into the canonical repository.
• The two reasons above kind of defeat the purpose of moving to a Distributed VCS in the first place -- which is to simplify development and make it more democratic.

Regardless of whether or not we decide to use this technique, when researching the issue, I saw plenty of posts from people wanting to implement commit signing, but not sure how to accomplish it. Perhaps this post will serve as a starting point for many.

When working from home, I prefer to use a VPN split tunnel setup -- I'm behind a firewall all the time, and it's useful to be able to run virtual machines while still connected to my VPN (e.g., when doing training or webinar sessions). However, I noticed some months ago that this wasn't working. I assumed at first it was a change in our network setup, but others reported that the split tunnel was working fine. It's been particularly problematic when on IRC -- if the VPN drops, I lose my IRC connection, meaning I have to re-connect and re-claim my nick.

So, I did some searching, and found an interesting setting. In NetworkManager, "Configure..." then "Edit" your VPN connection, and navigate to the "IPv4 Settings" tab. Once there, click the button that says "Routes..." and select the checkbox next to "Use this connection only for resources on its network". Press Ok to close the dialog, then "Apply" to exit out of the VPN configuration. Re-connect to the VPN, and you should be all set.

Note: this will only work if your VPN server is configured to allow split tunnels. Additionally, only do so if you are behind a firewall. Practice safe networking.

I was given a linux VM image running a web server and some applications I needed to review. On top of that, I needed to do so over WebEx, so that I could share my screen with somebody else. This meant I needed the following to work:

1. Internet access for my Windows VM
2. Access to my linux VM from my Windows VM
3. Ideally, access to both guest VMs from my linux host
4. Ideally, internet access for my linux host

Since I'd only ever used one VM image at a time before this, I'd never had any issues; I could use NAT networking in VirtualBox, and have communication between my host and guest, as well as internet access for both. But NAT access does not allow the VMs to communicate with each other -- in fact, both received the same exact same IP address from my host, which meant that I had internet access from both, both could ping the host, but the host could not access either machine, and neither could access each other.

I did some research, and started reading on using network bridges, something I'd tried once before without success. Fortunately, the very first literature I started reading this time pointed out the reason why I'd failed before: network bridges over wireless adapters do not work, and I was using my wifi. I briefly considered using a wired connection, but realized that this was not an option: there are times I may need this sort of setup when I am unable to use a wired connection.

I then found an article that detailed how to setup Host Interface networking with VirtualBox. Host Interface networking was added in the 2.1.x series of VirtualBox, and basically allows you to use your host machine as a network gateway for your guest machines. The VirtualBox binaries available in Ubuntu are 2.0.x... so I had to uninstall them and download the official binaries from the VirtualBox site.

Setting up Host Interface networking worked for case 2 only; somehow, when it was active, my routing got completely borked. So, I did more research. The next thing I found suggested I needed to setup one or more virtual network devices (TAP), which would allow each virtual machine to have its own IP address, and communicate over the same network, while using the wifi adapter in my host machine as a gateway to the internet.

All the instructions I found setup a separate TAP interface for each virtual machine. I quickly discovered two things: first, I had to setup IP masquerading in my host's iptables rules so that the VMs would have access to the internet, and second, that while this would solve cases 2-4, the VMs still couldn't talk to each other. In the end, I found that I needed to setup a single TAP interface, and have all the VMs use this as their Host Interface -- and everything then worked. Almost. The other trick I discovered was that the TAP address should be on a private network that you're not a member of already -- including the private network space your router might use. The instructions I followed setup the network in the 10.0.1.X network, but this conflicted with my DSL modem, which was assigned a 10.0.0.X address, and meant that the guest machines had no access to the outside world; switching to 192.168.168.X fixed all issues.

Here are the step-by-step instructions (linux host):

• On the host:
  • Make sure you have uml-utilities installed
    • On Debian-based systems, "sudo aptitude install uml-utilities"
  • Create a virtual network interface
    • "sudo tunctl -t tap0 -u $USER" (where $USER is the user initiating the VirtualBox sessions
      • Make sure the user is in the vboxusers group:
        • Edit /etc/group, look for the "vboxusers" entry, and ensure $USER is listed as a member of the group.
      • Make sure the vboxusers group has rights to tun devices:
        • "sudo chgrp vboxusers /dev/net/tun"
        • "sudo chmod 660 /dev/net/tun"
  • Enable the network interface and assign it an IP address
    • Make sure the IP is not on a netmask in use elsewhere in your networking; I used 192.168.168.1, which did not conflict with anything.
    • "sudo ifconfig tap0 192.168.168.1"
  • Set up NAT forwarding:
    • "sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE"
      • Substitute the appropriate network interface based on what you're using on your machine.
    • "sudo sysctl -w net.ipv4.ip_forward=1"
• On your guest machines:
  • Setup TCP/IP networking to use static IP addresses in the network you've defined for the virtual adapter on the host. For example, if you used 192.168.168.1 on your host:

    Address:

    192.168.168.[UNIQUE]

    Netmask:

    255.255.255.0

    Gateway:

    192.168.168.1

• Assign DNS servers based on what you're using on your linux host. Check /etc/resolv.conf if you're unsure.

Now, one caveat: your TAP device will disappear when you restart your host box. To solve this, I added the following lines to my /etc/rc.local:

echo -n "Setting up tap0 interface..."
tunctl -t tap0 -u matthew
ifconfig tap0 192.168.168.1
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
sysctl -w net.ipv4.ip_forward=1
echo "DONE!"

This ensures that the TAP device is setup, and also that IP masquerading is enabled at boot time.

I'm writing this mainly for myself, but also hoping that it will save others the many hours of experimentation I had to go through to find the write combination of settings.

I'll say this: the setup is much faster! However, we had a few gotchas that surprised us -- it didn't setup our RAID array out-of-the-box, which led to a good hour of frustration as we tried to verify that the install wouldn't wipe it, and then to verify that we could re-assemble it. (We succeeded.) Additionally, we second-guessed a few things we shouldn't have, which led to needing to back out and reconfigure. But what was over a 12 hour install with Gentoo we accomplished in a matter of a few hours with Ubuntu server -- so it was a huge success that way.

Unfortunately, our mysqldump of all databases... wasn't, a fact we discovered only after importing it into the new system. I ended up losing my blog database and PEAR channel database. Fortunately, the PEAR channel has not changed at all in the past year, so we had an old backup that worked, and I had a snapshot of my blog database from three weeks ago I was able to use. As a result, there are a few missing entries, but for the most part, all works. If you commented on one of those missing entries, my apologies.

Now that the install is done, I'm also finalizing some design changes to my blog -- it's time to leave the black and white for more colorful grounds. Look for a revamp in the coming weeks!

My first idea was to add the directive 'Header add X-Server-Ip "%{SERVER_ADDR}e" in my httpd.conf. However, due to the nature of our load balancer, Apache was somehow resolving this to the load balancer IP address on all machines of the cluster -- which was really, really not useful.

I finally stumbled on a good solution, however: you can set environment variables in apachectl, and then pass them into the Apache environment using the PassEnv directive from mod_env; once that's done, you can use the environment variable anywhere.

In my apachectl, I added the line "export HOSTNAME=`hostname`". Then, in my httpd.conf, I added first the line "PassEnv HOSTNAME", followed by the directive 'Header add X-Server-Name "%{HOSTNAME}e"'. Voila! I now had the hostname in the header, which gave me the information I needed for debugging.

I'd been having some issues with fonts following a session at ZendCon where I hooked my laptop up to a widescreen display, and the updates fixed all those issues. Most things that worked before continued to work, and often in an improved way. The various new themes available -- from GDM to GTK to window manager themes -- make for some pretty displays, and I've found a new look for my desktop that I really like.

Among the improvements, it installed trackerd, a desktop search tool. I'd tried installing this on my own before, but ran into a ton of dependency issues I couldn't fix. Prior to this, I'd used beagle, which worked okay, but tended to overlook a lot of files. Trackerd, on the other hand, indexed my entire box overnight, and stays on top of new files easily. Couple this with the 'deskbar', and I now have the type of desktop search I've only seen in Macs.

Last night, I stumbled upon a forum thread detailing how to get X compositing working with ATI cards. This was something I've been continually disappointed with; my card supposedly supports it, but every time I've tried using it, I find it unusable -- lots of wierd screen artifacts, and a huge slowdown in responsiveness. After following the directions in the linked article, however, I now have compositing going -- window drop shadows, translucency for inactive windows, etc. It looks really nice, and doesn't seem to be slowing down the machine at all.

No review would be complete without a gripe though, right? And I've got a big one. In the past, one of the strengths of ubuntu for me has been that suspend and hibernate have just worked. With this upgrade, however, they no longer work for me. Evidently, a new kernel option was enabled that is supposed to speed up these operations... However, the available ATI drivers do not support this option, which leads, in my case, to a complete inability to suspend or hibernate, and for others, lockup on resume. Supposedly ATI will be releasing new drivers that will fix the issue, but there's no published time frame for when that will happen. Additionally, ubuntu made no announcements about the issue, and provides no workarounds. To me, this is a huge BC break, and should have been addressed prior to the release, particularly as there were many, many complaints about it in the weeks prior to the release.

Gripes aside, I find the new functionality fantastic, and look forward to ATI's release of new drivers for its Radeon series cards. Perhaps this release will keep me happy enough that I won't keep lusting for a shiny new Macbook too much.

Last week, we had an infrastructure change at work, and I basically realized that my Windows + coLinux setup was going to get in the way of productivity -- and that, at this point, there were now Windows applications tying me to that OS. So, I decided it was time to go back to Linux.

I'd used Linux as my primary OS for five years prior to starting at Zend, and have used a number of distros: SuSE, Mandrake (back when it was still Mandrake), RedHat, Slackware, Debian, Gentoo, and Ubuntu have all been on my machines at one point or another. I like Gentoo quite a lot, but it's a pain on desktops, where you may be needing to upgrade more often than once every few months or years. Debian-based distros are my favorite for desktop machines, as the packaging mechanism is first-rate, and they tend to have plenty of developer packages available. So, I decided to use Ubuntu again, as I've heard great things about their installer since I last used it. I chose the latest stable release, Edgy Eft; since Feisty Fawn is still incubating, I didn't want to risk instability in my day-to-day work environment as people finalize packages. On the other hand, I also wanted a reasonably up-to-date system. Due to Ubuntu's dedication to a regular release cycle, I figured that with Edgy Eft, I'd get the best of both worlds.

I was not disappointed. I had a working desktop installed in someting like 30 minutes, with a single reboot -- and that was simply to go from the live CD into the actual installed OS. Even better: the initial install recognized all of my hardware immediately, including the built-in wireless hardware, something I've never experienced before with any Linux OS.

That said, there were three minor issues I needed to correct:

• I was having issues compiling anything; every configure script I ran ended up reporting shell escaping issues or other related errors.
• I have an IBM T43 Thinkpad laptop with a 'Trackpoint' mouse -- basically a little joystick between the 'G' and 'H' keys that has mouse buttons just below the space bar. On Windows, you can use the middle mouse button as a wheel lock, allowing you to scroll with the mouse. This functionality was not enabled in linux, and I wasn't sure how to enable it.
• Suspend and hibernate were acting, well, funky. Basically, recovery never occurred completely, and I'd usually have no wireless access after resuming.
• Unable to mute the microphone

I was able to find solutions for all three relatively easily, fortunately, and I'm sharing the solutions below:

Compilation issues: shell escaping

I always compile apache and PHP by hand, as I can then control what I get precisely. This is important as it allows me to have multiple versions of PHP if I need them, each tuned to a different server. But as I tried to run the configure script for either, I was getting an error indicating that sed was not behaving properly due to the shell not escaping characters properly.

I did some research, and discovered some posts claiming that the version of bash shipped with Ubuntu had a bug, and that the only recourse was upgrading bash. Of course, there was not a new version in the repository, and I couldn't compile a newer version due to the shell issues.

So, I decided to see if there were another shell I could symlink /bin/sh to so I could recompile bash. And that's where the problem lay: /bin/sh was symlinking to /bin/dash -- a stripped down shell used by debian and ubuntu. When I symlinked it to /bin/bash instead, all the errors went away.

Summary: relink /bin/sh to /bin/bash if you need to compile programs on Ubuntu.

Trackpoint usage

I found several sites dedicated to laptops on linux, and one dedicated to thinkpads running linux. They were each suggesting that I'd need to (a) recompile X.org, and/or (b) add a kernel level driver. Once those were done, I'd be able to add some directives to my X configuration in order to have my wheel button enabled.

I'm not sure where I found the directives, but I decided to simply try them and restart X. Here they are:

# In /etc/X11/xorg.conf:
Section "InputDevice"
    Identifier  "Configured Mouse"
    Driver      "mouse"
    Option      "CorePointer"
    Option      "Device"               "/dev/input/mice"
    Option      "Protocol"             "ExplorerPS/2"
    Option      "ZAxisMapping"         "4 5"
    Option      "EmulateWheel"         "on"
    Option      "EmulateWheelButton"   "2"
    Option      "EmulateWheelInertia"  "50"
    Option      "EmulateWheelTimeOut"  "200"
    Option      "EmulateWheelClickToo" "true"
    Option      "YAxisMapping"         "4 5"
    Option      "XAxisMapping"         "6 7"
EndSection

With these settings in place, restart your X server (Ctrl-Alt-Backspace), and you're in business. I found that this actually provided better functionality than on Windows; I now can do all of:

• Use button two as a wheel lock, allowing vertical scrolling
• and also do horizontal scrolling (never could do that in Windows)
• and use it as a middle mouse button, allowing me to paste in X

Suspend and Hibernate

As I said earlier, each of these caused bizarre issues when I'd resume. The little 'sleep' indicator would blink continually, the wireless adapter would never work, and, if I tried to connect my vpn client, my machine would freeze. And suspend never truly suspended the machine; it would turn off the display, but the machine was still fully powered. It was a nightmare.

I remembered trying suspend2 last year, but with mixed results. I decided to look into it some more, to see if te project has matured. I was disappointed at first, because it looked like I'd need to build my own kernel, and I didn't want to do anything that would potentially impinge on my ability to work. And then I saw mention of a 'hibernate' program.

I did a quick search of the apt repositories, and saw that it was available:

$ apt-cache search hibernate
$ apt-get install hibernate

Once installed, I still had some configuration to do. GNOME has some utilities for battery/power management that can initiate suspend and hibernate, and GDM of course has them as well. However, they interact with the acpid process. I needed to figure out how to get acpid to work with hibernate.

This turned out to be pretty easy. First, replace /etc/acpi/sleep.sh with the following:

#!/bin/sh
/usr/sbin/hibernate --config-file=/etc/hibernate/ram.conf

The, replace /etc/acpi/hibernate.sh and /etc/acpi/powerbtn.sh with:

#!/bin/bash
# Skip if we're in the middle of resuming
test -f /var/lock/acpisleep && exit 0

/usr/sbin/hibernate --config-file=/etc/hibernate/disk.conf

This was only half the issue, however; while I was truly suspending and hibernating, and resuming, the wireless adapter was still not coming up by itself.

hibernate comes with a number of configuration files. One is called blacklisted-modules. I placed the following in it:

ath_pci
wlan_scan_sta
wlan

I needed to add some additional directies to /etc/hibernate/common.conf to make this work, and to bring the adapter down and up:

# Unload and load modules from the blacklist. These were already set.
UnloadBlacklistedModules yes
LoadModules auto

# Bring down and restart networking:
DownInterfaces ath0
UpInterfaces ath0

This solved the issue of the wireless adapter very nicely.

There were also a few other /etc/hibernate/common.conf directives I changed due to my machine's configuration:

# This is an IBM laptop, so turn this on:
IbmAcpi yes

# I use GNOME; lock the screen on resume:
LockGnomeScreenSaver yes

# I don't use vbe in my X configuration, so I turned these off:
EnableVbetool no

# And I wanted to display some messages:
Xstatus gnome
XSuspendText Preparing to suspend...
XResumeText Resuming from suspend...

One last issue remained. You may recall discussion of a VPN client earlier. Well, I discovered that when I tried to fire it up after resuming from suspend or hibernate, my machine would lock up. The way the VPN client works is that a daemon is run at machine startup that loads a kernel module; evidently, resuming from suspend caused some sort of issue with this. Fortunately, hibernate has some directives for this, and I added this to /etc/hibernate/common.conf:

StopServices vpnclient_init
StartServices vpnclient_init

StopServices stops a service located in /etc/init.d/ just prior to a suspend or hibernate process; StartServices does the opposite. With these directives in place, everything worked perfectly for me.

Muting the microphone

I use Skype regularly, and typically in meetings will mute the microphone when others speak. I couldn't find a way to do this easily at first.

The solution is that you need to enable some extra properties of the volume control.

First off, right click on the volume control applet in the system tray, and select 'Open Volume Control'. Then select the 'Edit' menu item, and 'Preferences' under it. You want to select 'Capture' and 'Microphone Capture'. After these are selected, close the dialog.

You'll now have a 'Capture' tab in the volume control applet. It shows a pair of sliders marked 'Capture'; below it are some icons, one of which is a microphone. To mute the microphone, click it; a red 'X' over it shows that it's muted. Clicking it again unmutes the microphone.

Summary

I now have all the functionality of Windows, and then some. Plugging in my flash drive loads it onto the desktop immediately, and also opens up a Nautilus window with it. I have a full range of unix utilities available to use for all of my documents. I've installed beagle, and have, arguably, better desktop search than when using Google Desktop. Xbindkeys allows me to create hot keys for launching common apps. I can use Gvim if I want to, instead of vim, and still have access to a shell within it. The mail-notification applet allows me to query my local maildir store as well as gmail. I can use zenity with atd to create alarms for myself.

And apps run much faster, I'm finding. I've been plaing with Zend Studio, which runs on Java, and it runs much more quickly than the Windows version ever ran for me -- meaning I may actually give it more than a cursory try.

It's good to be back on linux!

Except when an apt-get based install goes bad, that is, like it did Saturday evening. This is the tale of how I got it back up and running.

First off, I want to note that the narrative below shows the final, successful steps I took that got me back up and running. I actually had a number of failed attempts, but, like a scientist, kept changing one variable until I got a success. The below may or may not work for you, but it did work for me.

Now, to the incident: I'd been installing a few updates on my machine, including updates to mutt and some related programs. All of a sudden, my machine locked up, and I knew it was an irrecoverable lockup once the hard drive light ceased all activity and the clock failed to show any updates.

After reboot, my coLinux daemon silently failed on startup, and I couldn't determine if it was failing to start, or crashing after it booted. It took me a while to figure out how to run it from the command line, but that helped me diagnose the issue. To run the coLinux service from the command line, cd into the directory containing your coLinux executables, and then run colinux-daemon.exe -c yourConfig.xml (where yourConfig.xml is the name of your configuration file; best is to use the full Windows (not Cygwin) path to the configuration file).

Unfortunately, what I was getting was a kernel panic. I decided I needed to go into single user mode to try and diagnose the issue. Googling told me that I needed to add a trailing '1' to the bootparams directive in my coLinux configuration file:

<bootparams>root=/dev/cobd0 1</bootparams>

Unfortunately, the kernel panic was occurring prior to the init phase -- apparently, it was having issues with the journaling on the ext3 partition.

So, I was stuck. And then it hit me: if I could boot into a different coLinux install, I could add an additional block device with the root partition of my own, and then do some disk analysis. Fortunately, I had the original Debian image I'd downloaded to use with coLinux, so I started experimenting.

Sure enough, I was able to grab my partition, run an e2fsck on it, and even use tune2fs to remove and restore the journaling. The partition mounted fine and I was able to peruse the data without an issue.

But I still couldn't boot it, which left me in a bit of a situation: all my current work is on that machine, and I have my dual-apache setup on there (for PHP 4 and PHP 5). I needed to be able to boot it.

The first step was to create a new 10GB partition with a working Debian install on it. I copied the working Debian install (which is < 2GB), and found a utility called toporesize that could resize the partition to my desired 10GB. The process takes a fair amount of time, and, because it's disk and CPU intensive, heats up the laptop something awful, so I started it before bed and set aside the machine.

In the morning, I changed my coLinux config file to boot this image -- and it worked flawlessly. A quick df -l showed that the partition had indeed been resized. Now it was time to test apt-get to install those programs I'd been trying to update. All went perfectly.

I quit the session, added a block device for my old coLinux install to the coLinux configuration, and restarted the virtual machine. The device was found, and I mounted it locally so I could start rsyncing. I needed to rsync my /home and /usr/local trees, as well as some key files in my /etc tree (samba configuration, resolve.conf files, hosts file, and a custom apache initscript). Again, this was a time and CPU intensive operation; however, it was now morning, and time to be working, so I limited my activities to checking email while I waited.

The end result is that I have a shiny new install with all my tools, and, better yet, all my working data. Better yet, I now better understand how coLinux works, and know I can recover fairly quickly and effectively from failures in the future.

A co-worker told me about coLinux, a port of the linux kernel that allows it to run side-by-side with Windows on the same machine. It's kind of like vmware, only more optimized, and free. I'd looked at it, but was a bit daunted as I wanted to try and use my existing Ubuntu install with it, and was worried about messing up the machine.

I finally came to the realization, however, that I simply won't be using linux as my day-to-day OS until some of my tools are ported. So, I blew away my ubuntu install and made room for coLinux.

I'd heard that it was difficult to setup, but I found it fairly easy -- download the coLinux tools, get a filesystem image, add the service, fire it up. You then need to do a few other things -- bridge your network interface with the coLinux network interface, set your network IP for the coLinux install, setup your root password and any new users you want -- but then it's running. You can then use Cygwin to SSH into the install.

The basic coLinux filesystem is Debian, and based on an old Sid version. It is very stripped down, and has no developer tools. I had to apt-get a ton of stuff -- gcc, cpp, cvs, subversion, darcs, libtool, some development libraries, etc -- so I could start compiling things. I compiled Vim by hand, because if you want Vim with perl support in Debian, it insists on installing a ton of X related stuff. I then compiled Apache2, PHP4, and PHP5 by hand (and needed to get additional development libraries for some features I wanted). But the compiles worked flawlessly, and I now have coLinux running on the machine with a flexible development environment that I control.

(I've also figured out a way to run PHP4 and PHP5 seemingly on the same Apache install, side-by-side, but that's a topic for another day.)

While you can access the system via SSH, I find that's not terribly convenient for doing simple things like editing files. So I installed Samba in my coLinux install, and set it up with a few shares. With that in place, I can now access files directly from Windows -- editing them in gVim, etc.

I setup Exim via cygwin. However, I noticed when I'd try and send emails from my coLinux install via the cygwin exim, exim typically errored -- usually an inability to fork a process. So I installed it via coLinux instead, and all is hunky dory -- my PHP scripts can now send mail, and I have a local SMTP server for queuing and sending mail instead of having to rely on the company or personal mail server.

In reading on the coLinux site, I discovered that you can setup programs that utilize esd, and run esd off of cygwin. This has allowed me to once again use mpd as my preferred music player.

Since I'm constantly going into my coLinux install, I created a copy of the cygwin.bat script that adds a '-c "ssh myname@myCoLinuxInstall"' to the bash command; this allows me to click on a single icon in order to SSH into coLinux -- very handy.

All-in-all, I now have what I consider to be the best of both worlds -- access to the work programs I need, ease of configuration for a variety of tools (wireless, bluetooth, USB devices), and a robust server/development environment -- all on the same box.