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.

Only connect…

Buzz and Wave and e-mail, oh my!

How do we communicate when? There are no hard and fast rules, but these are the guidelines in the back of my mind:

Blogs are a great medium to go on at length about a given topic (whether it’s yourself or an arcane area of expertise) without targeting specific people and without expecting a reply. I suspect that with the rising popularity of social networking sites, there is less of a tendency than before for blogs to contain the minutiæ of everyday life.

E-mail is great for conveying any amount of information deliberately and reflectively, without a great sense of urgency. You can craft your message carefully, including all relevant points and making any needed arguments. I use this when I have a lot to say and I can wait for the reply.

Wave is ideal for collaborating on documents. Unlike e-mail, where replies are sequential, with wave you can comment inline and even edit the original post. I think this is great for giving feedback or co-authoring, but it has not yet taken off as a replacement for e-mail in my social and work circles.

Chat (instant messaging) is for those times when you need to interact with someone right now for something time-sensitive (which may be as important as “tell me how to restart the servers” or as trivial as “watcha doin’?”). Chat, by its nature, demands more attention than e-mail, but it is less intrusive than telephoning: your respondents can still ignore you, deal with other things simultaneously, and have their hands comfortably free to keep typing.

Chat status starts getting into social networking. You can advertise information that is not targeted towards a single recipient and for which you do not expect a response. I use it as an FYI to display what I’m doing or feeling or to point out something generally interesting.

Facebook allows you to keep “lightly in touch” with a large number of people. You make available your status or any other information you wish, and do not necessarily expect a reply. Likewise, you can see what other people have published and respond if you like. I use it to get a flavor for what’s going on in my “friends’” lives, and to let them know about mine. Interestingly, the meaning of “friend” has become diluted by this medium, as people that you may superfically know, or know not at all in real life, ask to join your network. You’re still somewhat curious about them (and I think it’s good, on both pragmatic and idealistic grounds, to interact with a broader range of people), and so they become your quote-friends.

LinkedIn is like Facebook, but geared more towards explicitly building a network of professional contacts. As with Facebook, I find pressure to dilute the meaning of a professional contact to someone I know only socially, but since this is a secondary social networking site for me, I have been able to keep my network pure.

Google Buzz, just released this week, is a new social networking medium whose biggest selling points, in my mind, are that it integrates with other Google services like Mail and Maps, and can more easily syndicate content from some other sources like Google Reader and Talk. I use it as I use my chat status, to give a general status message, but also to publish interesting or valuable information and see what replies I get. Buzz also lets you control who sees each Buzz, which is handy at times. At work, it is proving a good forum to non-invasively solicit cooperation and feedback from others.

Of course, the boundaries among these use cases are porous: Facebook has email, you can have your IMs waiting in people’s inboxes, and you can have a conversation with someone using blog comments. Still, I like to have clarity as to what tool I should be using, so I don’t have to think about it every single time.

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!