Wednesday, July 22, 2009

Sane terminal behaviour with PgUp and friends

In gnome-terminal on Solaris 10, if you hit the PgUp key, it scrolls the window up. The PgDn, Home, and End keys similarly move the scrollbar.

That's the behaviour I want. It's also what you've traditionally had with xterm, dtterm, and the like.

Recently, it's become fashionable to pass PgUp and friends through to the application, so you get the application running inside the terminal emulator to do its own interpretation, and require the shift key to be pressed in order to get the terminal window itself to scroll.

I find that incredibly disruptive. I don't run anything inside a terminal that does its own scrolling (other than more, and I don't need to reach as far as the PgUp key to manipulate that). Most of the more advanced applications I run are graphical anyway.

So, how to fix? In my exploration of xfce, the Terminal application uses a newer version of vte which suffers from the above problem. So I set out to fix it, and it was relatively simple.

I used vte-0.20.5, and if you look at around line 5055 of vte.c, you'll see some code that looks like:

case GDK_KP_Page_Up:
case GDK_Page_Up:
if (modifiers & GDK_SHIFT_MASK) {
vte_terminal_scroll_pages(terminal, -1);
scrolled = TRUE;
handled = TRUE;
suppress_meta_esc = TRUE;
}
break;

simply remove the test for the shift:

case GDK_KP_Page_Up:
case GDK_Page_Up:
vte_terminal_scroll_pages(terminal, -1);
scrolled = TRUE;
handled = TRUE;
suppress_meta_esc = TRUE;
break;

for all four keys of interest, and rebuild.

My life is so much better as a result.

It's a shame that's not the default, but there are others who rely on the opposite behaviour. It would be nice if it was customizable - it's OK for me to build a separate copy for my own use on my own machine, but that's not very flexible. It would be neat if it could autodetect the terminal mode and do the right thing.

XFCE on Solaris 10

I'm getting somewhat unsatisfied with the various desktop environments available. The desktop is currently in the doldrums, presenting a dull and dreary landscape.

So, I thought I would give XFCE another look. OK, so it turns out that it is a little bit of work to get it running on Solaris 10. There's a bunch of prerequisites that you need to build first, and a couple of tweaks. So it was a bit tedious, but I got it to work fairly easily. My install notes are available to help others down the same path.

What I've got is essentially functional. I've not worked out why some of the menu and application icons don't appear, and a few of the window manager themes don't quite work (you get strange visual artifacts) but it's functional, meets my requirements (which may be different from other people) of being easy to use, has a reasonable choice of themes, isn't quite as heavyweight as some of the other desktops, and shows promise for the future.

Friday, July 10, 2009

Testing ZFS compression

One of my servers (it's a continuous build server) generates a significant amount of logfiles. About 150G so far, growing at over a gigabyte each day.

Now, logfiles tend to be compressible, so in preparation for migrating it to a new host (it's a zone, so moving from one physical host to another is trivial) I tested ZFS compression to see how well that would work.





TypeRatio
lzjb5.08x
gzip22.19x
gzip-116.37x


Now, the default lzjb gives you fair compression. That saves 80% of my storage, so that's pretty good.

Going to gzip compression the space saving is spectacular. Unfortunately the machine runs like it's stuck in treacle, so that's not exactly practical.

Which is why I tried gzip-1. You save much more space than lzjb, although not as much as the default gzip (which is gzip-6). Unfortunately, while the machine doesn't quite go as comatose as it does with the regular gzip compression, the performance impact is still noticeable.

Overall, while I wouldn't mind the extra compression, the performance impact makes it hard, so I'm going to stick with the regular lzjb.