Always-on-top shortcut

It’s useful to sometimes always have a window be on top of all others. In my windowing systems, there is a window frame option for this. Usually, though, I prefer keyboard shortcuts. A friend told me how to set one up in compiz, but I was still mystified about setting one up in metacity. Then I found this guide.

Execute-Notify

Multitasking in the right manner helps one be productive. Do it too much, and quality declines as you get more stressed. Do it too little, and, well, you get less done. I think the crucial element is minimizing significant context switches while allowing as many things to proceed on automatic pilot as possible.

In particular, when executing long commands on the computer (like, say, compiling a binary), it is better to switch to a different activity (preferably with lower intellectual demands, so as to keep the coding context in one’s working memory) than to sit idly twiddling your thumbs. My problem when I do this, especially since I have a different virtual desktop for each context, is that I may forget to go back and check whether my compilation succeeded and my tests passed.

I recently found out (on emacsfoo) about notify-send, a useful command-line interface to libnotify that lets alerts pop up on the desktop. As is the case for many others, I like the idea of using this tool to notify me that my long-running jobs are finished, so I can switch back to my main context. Thus, I wrote a simple command-line utility (en, for “execute-notify”) that you can use to wrap an arbitrary command and be notified when it exits. I strove to make it fairly general and customizable, and may add more features to it as needed.

The simplest invocation is simply to prefix your command with en:

en  gcc -o myprogram myprogram.cc

If the compilation failed, you would see a message like this:

A typical failure message conveyed by 'en' without any options

There are options to control the notification parameters, like so:

en --expiration 0 --title Compilation \
   --command_label "the usual gcc command" \
   --icon_success /usr/share/icons/gnome/32x32/status/info.png \
   gcc -o myprogram myprogram.cc

A customized 'en' notification when the underlying command succeeded

Here’s the help text for the command:

$ en --help
en Execute a command and notify when finished
Usage: en [FLAGS...] COMMAND [ARGS...]
   executes COMMAND ARGS... and sends a notification to the status
   panel upon completion, indicating the result of COMMAND. The
   exit code of COMMAND is the exit of en.

Each flag to en begins with "--"; flags take zero or one
arguments. The first argument to en that is not interpreted as
a flag or value is taken to be the command to execute.

Possible no-argument flags are:
  --help  Show this message
  --debug Print debugging information about en

Possible one-argument flags are:
  --title Prefix to the "Success" or "Failure" title of the
notification

  --command_label Description of the command to be used in the
notification text in place of the command itself. Useful for
succinctly describing a long command, or for use with --exit_code
flag

  --exit_code Simulated exit code from COMMAND to use when generating
the notification, Setting this flag causes COMMAND to not actually
execute, and is useful for testing that the notification is
formatted as desired without actually invoking COMMAND or of the
form

  --PROPERTY_OUTCOME where PROPERTY is one of "icon", "urgency", or
"expiration" and OUTCOME is one of "success" or "failure".
All the properties are used in creating and dispatching the
notification, but the outcome used depends on the exit code of the
command being run.
   icon: the icon to be used in the notification
   expiration: the duration of the notification (ms)
   urgency: the notification urgency, as defined by send-notify

Example:
  en --icon_success /usr/share/icons/gnome/32x32/emblems/emblem-default.png \
    --expiration 600000 --title "Directory listing" ls

Enjoy it and let me know what you think!

Bad BIOS!

In my quest to get my motherboard (Gigabyte S-series GA-MA790FX-DS5) to wake-on-LAN, I tried upgrading the BIOS from Gigabyte’s download site from version F6 to version F8F. Bad idea! After the upgrade, the system would sometimes reboot spontaneously. This seemed to happen with more resource-intensive processes. The Gigabyte support folks were not really helpful (they just told me to check the cables), and, indeed, I am still working with them to fully enable the wake-on-LAN feature, which they claim is fully tested.

Since reverting the BIOS back to F6, the spontaneous reboot problems seem to have gone away.

Stir-on-LAN

I got Wake-on-LAN almost working on my desktop computer. It took some trial and error, but here are the essential steps:

  • I configured my Gigabyte S-series GA-MA790FX-DS5 motherboard BIOS to have PME Event set to enabled; this enables wake-on-LAN which means, apparently, that the NIC still receives a little bit of power in order to check for the Magic Packet. I also tweaked the ACPI configuration by setting the ACPI Suspend Type to be S3(STR), so that when I do a suspend (rather than hibernate or power-off), only RAM gets power and not the CPU.

  • I changed /etc/rc./init.d/halt so that it ends with:

    # Wakeup-on-LAN
    
    /usr/sbin/ethtool -s eth0 wol g
    sleep 5 # one source claims this matters
    
    exec $command $HALTARGS
    
  • I created /etc/pm/sleep.d/99network:

    # Restart the network interfaces after suspending
    # Author: Victor Chudnovsky (victor dot chudnovsky at g m a i l  dot c o m)
    
    case "$1" in
        thaw|resume)
            service network restart
            ;;
        suspend|hibernate)
            /usr/sbin/ethtool -s eth0 wol g
        sleep 5 # one source claims this matters
            ;;
        *)
            ;;
    esac
    
    exit $?
    
  • To allow waking up my desktop from the outside, I made sure my router allows WOL packets to reach the machine. One can do this either by setting the machine to be the DMZ server or by explictly configuring these packets to be routed through (typically on port 9)

  • Possibly unnecessary but it can’t hurt: Disabled the standard r8169 driver and instead installed the official r8168 RealTek driver for my onboard Realtek 8111B ethernet chip. I followed the directionsin the README, which essentially amount to the steps here.

  • Possibly unnecessary: I created /etc/pm/config.d/config with contents:

    SUSPEND_MODULES="r8168"
    

That was enough to enable suspend-to-LAN. To actually wake the computer, one needs a client that can send the Magic Packet to the wakeable machine. These clients thus need the IP address of the machine (or a broadcast address) and the MAC address of the NIC that is a wol-able.

  • I got an Android app for my phone, aWOL that allows multiple profies for various machines that can be woken up remotely.

  • I installed ether-wake and wol clients on various computers from which I want to wake up my desktop.

This set-up seems to work pretty well. There are some occasional issues I’m encountering that I’m still trying to debug:

  • Rarely, I’ve noticed that if I suspend or hibernate and resume too many times too quickly, these operations start failing with a Device or resource busy message in /var/log/pm-suspend/log, but if I wait for a while and try again, it starts working.

  • The remaining problem is this: if I’m powered off for too long, the card does not respond to the Magic Packet. This defeats the whole purpose of this feature, obviously, so I’m trying to figure out under what conditions this happens. I found this problem mentioned elsewhere, but no solution as of yet. I asked Gigabyte customer support, but have not heard back from them yet.

For more information, refer to the Xlife wol guide or the Wake-on-LAN mini-HOWTO .