Painful upgrade

For the past couple of months, I’ve been trying to upgrade to Fedora 12, but the process has not been working. The chkconfig package, in particular, has been refusing to install. This left my system in a not quite perfect state, where occasionally all programs would begin to crash until I rebooted in rescue mode and did a chroot /mnt/sysimage /usr/sbin/prelink -ua. A major pain. I could not find a solution online.

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…

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.