Wandering Thoughts archives

My standard Gnome customizations

I don't use Gnome on my primary machine (it runs a peculiar, entirely custom environment), but I do use it on a number of secondary machines and I keep making more or less the same customizations each time. So I'm writing them down, if only for my own reference on the next machine.

• I disable gnome-terminal's blinking cursor.

• I turn CapsLock into an additional Ctrl. This is in the Keyboard preferences area, Layout tab, 'Layout options' button, and in the 'Ctrl key position' section. (It is not even cross-referenced in the 'CapsLock key behavior' section.)

• I add to the top panel widgets for gnome-terminal, locking the screen, and sshmenu, and then import my usual .sshmenu configuration file.

  On laptops, I also add the screen brightness applet and a custom launcher to run 'xset dpms force off', because various things have convinced me that this is the single best thing I can do to increase battery life.

  On desktops I usually add the weather applet, which feels vaguely lame but at least lets me be depressed at a glance most of the year.

• on desktops, I use gconf-editor to turn off the /apps/gnome-session/options/logout_prompt key, so that when I select 'log out' from the menu it actually logs me out on the spot without prompting me about things. I tend to leave it as-is on laptops so that I can easily select 'power down' or the like.

  (In the inimitable Gnome way, this used to be exposed as an actual preference but no longer is.)

• I add some Firefox extensions that I really can't live without any more: NoScript and usually All-in-One Gestures. Sometimes I apply my usual Firefox settings; it depends on how much I'm going to use the machine.

  (I am addicted to AiOG if I have a mouse, but on laptops it sometimes feels like it doesn't make all that much sense.)

Further laptop customizations:

• I turn off the X server's bell by adding an entry to the Startup Programs list (in the Sessions preferences area) that runs a script that runs 'xset b off'. I loath my laptop making noises in things like meetings just because one of many programs has decided to print a ^G to get my attention.

• I set the screen saver to activate as fast as possible and turn the display off as fast as possible when the laptop is on battery power. I usually use one or two minutes of idleness for the screen saver and one minute (the Gnome minimum) for screen blanking.

• on 'narrow' screens (which these days is anything less than 1280 pixels across), I take the personal information applet out of the top panel because it just wastes valuable space.

I do not set laptops to dim the display when they go on to battery power; I can do that myself if I need to, and I otherwise want the screen to stay at whatever brightness I find most readable.

Sidebar: my sshmenu dream

I find sshmenu reasonably handy, but as it is it has one little irritation; you have to add hosts to its menu. What I hoped for when I installed it was some sort of text widget that lived right in the top panel that you could type hostnames into and it would start ssh sessions to (in terminal windows).

This is probably a dream peculiar to sysadmins, since I wind up ssh'ing off to far too many machines to put into a menu structure. As it is I just put the most common machines into sshmenu's menu, and fall back to gnome-terminal and explicit ssh'ing for the others (which takes just enough extra work to be irritating, but not enough extra work to get me to find out how to write Gnome applets in Python or Ruby).

Why I would still like MC/S in Linux

I recently ran across MC/S vs MPIO, which is about why iSCSI's 'multiple connections per session' feature is apparently considered a bad idea and is not likely to be implemented in Linux, the short summary being that it is an iSCSI specific duplication of generic multipathing functionality. Unfortunately, I sort of disagree with this in practice.

In theory I don't care about how my multipathing is done, I just want something that makes general iSCSI multipathing work right. In practice, right now generic multipathing doesn't seem to be up to the job.

The starting bad sign for me is that the Linux iSCSI target developers will generally give you reasonably scary warnings about using multipathing for anything but failover. There's specific reasons, but I think that they can be generalized to something simple: you have to trust the initiator to get all of this generic multipathing stuff right, and it may not. (And I know that there are some initiators that do not get it fully right, because we use one.)

(Also, you have to trust the target to get all of the necessary supporting SCSI infrastructure correct, even the picky bits. It's possible that some targets are known to be incomplete there.)

The great attraction of MC/S for me is that it is conceptually quite simple and does exactly and specifically what I want, partly because all sides know just what is going on. Full generic multipathing is much more indirect and complex, and its very generality means that it necessarily has more chances to go terribly wrong.

(iSCSI being iSCSI, I'm entirely willing to believe that MC/S is actually a baroque pile of complexity once you read the actual specification. I haven't, so all I can go from is outside appearances.)