An Online Identity Crisis

Yesterday I was working with some folks in #fedora-java, and after confusion over my IRC versus FAS nicks, someone asked me how many different nicks I had.   The answer, unfortunately, is "at least four."  I realized a couple of years ago that I had created a problem for myself as far as online identities go.  I was never one to go signing up for new services to reserve my nick early, and I've not chosen particularly unique nicks.  So, this is me, currently:

• mull - an IRC-only nick that dates back to my college days, maybe 1999-ish, when folks in the #aalug channel were trying out new nicks daily for a while.  I have no idea why this stuck, and I've never used it anywhere else. UPDATE: I've now claimed "agrimm" on IRC, so you won't be seeing "mull" anymore.


• arg - I made a particularly huge mistake when I chose my initials for my FAS (Fedora Account System) ID, even though there was very little possibility I'd be able to use that elsewhere.   I suspect that a FAS account is one of the less trivial ones to change, too, so I'm probably stuck with this being a one-off.


• agrimm - the obvious first initial + last name choice, more easily obtained than initials, but still not universally unique.  I use it for email addresses and not much else, and I get a *lot* of misdirected email for people who share my last name.


• a13m - I started using this for twitter and some other random things when arg and agrimm were taken.  In case it's not obvious, this nick derives from my full name, in the style of i18n, a11y, etc.  While very short and almost never taken by anyone else, the relation to my name is subtle enough that most people don't make the connection.

I've clearly been overthinking this, but I really would like to converge on nicks which are clearly related (for example, the guy who has "arg" on FreeNode is "argv0" on Twitter... clever).  Any suggestions?

Beware of RHEL 6 / CentOS 6 kernels in Xen guests

A couple of weeks ago, I made my first attempt at creating a multi-hypervisor CentOS 6 image for Eucalyptus for demo purposes.  I was pretty sure I had the image creation thing down to a science with ami-creator, but it seems there's always room for error.   While I had all the correct drivers in the initrd (usually that's all that really matters), it turns out there's a kernel bug affecting device naming on Xen, and since ami-creator currently uses device names rather than UUIDs or labels, my image failed to boot.  For those who don't want to read the whole bug, it's stated concisely by Kevin Stange:

There was effective breakage between kernel-2.6.32-71.29.1.el6 and
kernel-2.6.32-131.el6.  When going from 6.0 to 6.1, the result is that if your
Xen domain configuration file specified sda1 as a device name, it was
previously renamed to xvda1.  After 2.6.32-131.el6, the device is named xvde1
instead (because the names xvda - xvdd are reserved for hda - hdd device
remapping).

In situations where the configuration file explicitly lists "xvda1" or uses
"hda1", "xvda1" continues to work. 

So it seems that there are multiple workarounds to the problem, and it will be fixed in the 6.3 kernel, which is all good.  However, I have to say that it's finally made me understand why some of my coworkers prefer their "single kernel" project, which aims to provide one kernel / ramdisk which can properly boot several distros on several hypervisors.  I'm still partial to running the distro-provided kernel whenever possible, but having a known-good fallback that will at least be able to access the root filesystem & network is nice, so thanks to the Eucalyptus Support / IT team for working on that.