In my spare time, I’ve been working on two tools to make emacs more useful to me by leveraging two key features: the ability to save the desktop state and the ability to have emacs clients connect to an emacs server.

For the former, I wrote an emacs-lisp package called desktop-autosave. Once initiated, the package will periodically save the desktop under the name of your choice. The benefit of this is that you do not have to remember to save the desktop explictly yourself before you exit emacs or before you experience an emacs or system crash. Moreover, the next time you start desktop-autosave with that same name, the corresponding desktop is automatically loaded into your emacs workspace.

For the latter, I wrote a bash shell script called ee that will allow you to connect to a named emacs server (bringing up the server if it is not already running). The value of this package is that you can now invoke ee wherever you would normally have invoked emacs, and by just specifying the name of the desired server, you can easily set up as many emacs sessions as you have concurrent projects.

The real benefit comes when you use both packages together. In this case, you can use ee to bring up a named emacs server, and that server will save its desktop to disk periodically. As long as emacs stays running, you can keep connecting to the same server from as many clients as you wish. After your emacs server terminates (by exiting normally, by crashing, or by the machine being reset), you can use ee to once again bring up a server with the same name. In this case, emacs will load the automatically-saved desktop file from disk and you will have in memory all the files that you were working on previously on that particular emacs server. Nifty, no?

Feel fry to try these packages out. They are available on GitHub. If you find them useful or if you find bugs, let me know. Enjoy!

Transaction Check Error:
   package nss-softokn-3.12.4-19.fc13.x86_64 (which is newer than
   nss-softokn-3.12.4-17.fc13.i686) is already installed

The solution, which I found here, is to first do

sudo yum downgrade nss-softokn

I was eagerly awaiting Fedora 13, hoping that installing that would go off without a hitch. No such luck. The solution, as it turned out, was to try to install the problematic rpm directly and resolve the issues manually (in my case, a directory was supposed to become a symlink). But then a couple of other packages had issues, and I just decided to bite the bullet and reinstall. Luckily, my /home was in a different partition than /, so it wasn’t excruciating.

Things I needed to restore upon successful installation were

• /etc/{passwd,shadow,group,sudoers}
• mount points listed in fstabs, and links to same
• fonts
• printer, samba
• Chrome
• NX
• Picasa (still in progress due to a package dependency conflict)
• crontabs

I still like Fedora alright, but this upgrade process was painful (though possibly my fault for not cleaning around properly after mucking around in my system). I’m glad I’m on FC13; I got some cool customizations finally done, about which I’ll write later. I am, however, starting to wonder whether any of these would be easier on Ubuntu. Stay tuned…

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:

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

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!

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

• 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 .