Now a bunch of bug fixing and a config converter and we can release!
Thanks to everyone who has been testing so far.

• Fix a bug in handling URLs dropped on the window
• Implement directional navigation
• Implement geometry hinting
• Fix a bug in group emitting that cause “Broadcast off” and “Broadcast to all” to become inverted
• Implement WM_URGENT bell handler

I’m really happy with how this is going. All that is left to have feature parity with trunk, I think, is some keyboard shortcut handlers.

I’d still love to get more testing results to make sure I haven’t missed anything, but at this rate I’m expecting to be able to land the epic-refactor branch on trunk this weekend, after five and a half months.

Then I’m going to write a tool to convert old config files and we can think about putting out a 0.90 beta release. Exciting stuff!

• -e and -x command line options
• all forms of drag & drop
• directional navigation
• some keyboard shortcuts

I’m pleased to say that the first two of these are now taken care of, but the latter two are still to be done. I’m less pleased to say that I haven’t had much external feedback about this branch yet, but I suspect that most people who might be interested probably don’t read my blog ;)

So if you know people who like Terminator and enjoy testing things out, all they need to do is:

bzr branch lp:~cmsj/terminator/epic-refactor
cd epic-refactor
./terminator

and give some feedback!

I think it’s finally time that we get some more eyeballs on it, mainly so I can check that I haven’t massively screwed something up. I know there is lots of missing functionality right now, and probably a bunch of subtle bugs, but I could use your help quantifying exactly what these are!

If you’re inclined to help, please branch lp:~cmsj/terminator/epic-refactor, cd into it and run ./terminator, then use it like you always would and file bugs, preferably indicating clearly in the bug that you’re using this branch and not trunk (maybe tag the bug ‘epicrefactor‘).

Things I know are broken right now:

• -e and -x command line options
• all forms of drag & drop
• directional navigation
• some keyboard shortcuts

Things I know are missing because they’re not coming back:

• Extreme tabs mode (sorry, it’s just too insane to support)
• GNOME Terminal profile reading (I’m trying to simplify our crazy config system and dropping GConf is a good way to achieve that)
• Config file reading. At some point I’ll write something that migrates old Terminator configs to the new format, but for now you’ll have to live without your old config file. The new one isn’t documented yet either, but it is a whole bunch better!

Now would also be a great time to start writing plugins for Terminator and telling me about them. I’m happy to ship good plugins, but more importantly I want feedback about the weaknesses/strengths of our plugin system. Right now you can only hook into URL mangling and the terminal context menu, but the latter of those gives you pretty serious flexibility I think. Obviously one massive weakness is a lack of documentation about the plugin API, but I’ll get to that, I promise!

So there we have it, another step along the way to me being able to merge this branch into trunk and put out a real release of 0.90 and then eventually 1.0!

In the same time period we’ve also seen a really gratifying amount of adoption – I believe our active userbase numbers in the thousands if not tens of thousands. I am forced to largely estimate these numbers for all the usual FOSS reasons, but it’s all based on one real metric – Ubuntu has about a million users reporting popcon data and over 10,000 of those have Terminator installed. I don’t actually think that they all use it, but nonetheless it’s the kind of number that makes you think “hey maybe I need to be doing more for these folks”.

And I do think that, and I am trying to do more.

Back in August I took a serious look at where we are and came to the same old conclusions – we lack one or two headline features that people keep asking for (barely a week goes by when I don’t get asked how someone can save a particular layout of terminals). These features are very subtle and deeply problematic with the existing code architecture – we’ve just been hacking in features as we can without any regard for architecture or future maintainability.

I decided that I’d had enough of being confused and frustrated by the status quo and so I started a side branch in my Launchpad /+junk/ folder called “epic-refactor” with the aim of refactoring all of Terminator from scratch. I’d read through every line of existing code and figure out what we were actually doing and how it could fit together more sensibly, then sketch that out in the barest form possible while I experimented with various Python techniques to arrive at an architecture that makes sense for our project, then port over the existing code feature-by-feature to the new architecture.

It’s now a little over four months since I started the epic refactor and looking at where I stand today I am really happy. It’s not ready to be merged into trunk yet, but the amount of work to get it there is less than the amount of work I’ve done on it so far. I don’t want to put a timescale on it, but I hope to be calling for some wider testing in 2-3 months or less.

Once we are acceptably close to feature parity with the current releases I’ll merge the epic-refactor branch over  and we can start to push forward with implementing the features that everyone wants, and finally get to the point of being able to comfortably release a 1.0 version.

I’d always thought that I’d hand over maintainership after a 1.0 version, but the last 4 months have been a whirlwind of programming discovery, so I might very well just stick around and see what people want on the road to a 2.0 release. Alternatively, the work I’ve been doing in the last few days on a plugin system might mean that I can kick back and watch everyone else implement crazy, awesome and sublime features I’d never thought of!

I’ll be back with more when I have written a configuration subsystem for epic-refactor, because by then I’ll be wanting your help to test!

I’m also going to write a separate post shortly about some of the interesting Python paradigms and ideas I’ve hit upon along the way. I’m sure none of it will be a revelation to anyone with serious programming chops, but for a rank amateur like me it would have been useful to have read four months ago ;)

No problems with that, right? Fontconfig says font sizes are a double (a high precision floating point number), but not all libraries/applications follow this.

In my testing of Karmic I’ve found two such things that particularly stick out:

• notify-osd
  • Assumes font sizes are whole numbers, so ends up using a tiny font
• Gwibber
  • Assumes font sizes are integers and completely fails to run if they are not

Obviously this won’t do, so I’ve checked that we have filed bugs (and in the case of Gwibber, a patch), but I seem to be meeting some resistance, or this just isn’t considered to be a high priority.

Thus a new Launchpad team is born, The Floating Fonters, for exiles such as myself who won’t kowtow to the integers. We even have a PPA with fixed versions of notify-osd and Gwibber, but no guarantees are included!

If you’ve ever typed on a thinkpad you immediately know why this keyboard is awesome :)

Slightly annoying perhaps, but ultimately a decision that’s hard to argue with and fortunately one that’s pretty easy to work around. I wish the author would clear things up once and for all because the tp_smapi module is desperately important for Thinkpad owners wishing to protect the life of their laptop battery. Given that my new X301 is tasked with a lifetime of 3 years, I am particularly keen to protect its battery!

The source for the module is still in the archive (and my understanding is that it will stay there, we just don’t want to ship it by default) as tp-smapi-source, packaged by Evgeni Golov (a thoroughly decent chap who is the current owner of the Thinkpad X300 I’ve posted about previously). You can install it with the command:

sudo apt-get install tp-smapi-source

Then run:

sudo module-assistant

and select the tp-smapi module to build and install. You are now just a quick:

sudo modprobe tp_smapi

away from having battery charge control options in /sys/devices/platform/smapi/BAT0/

Woo! If I get a chance I’ll try and produce a version of the package which uses DKMS (Dell’s Kernel Module management system which makes sure that additional modules like this are rebuilt automagically whenever you get a kernel update).

I want to push it into the PPA first to get a little testing before officially tagging the release. Please file bugs if you spot any!

There are a few little bug fixes, the first external code contribution, and configuration is now done via gconf so you can change the fonts/colours and search keywords. I did also add a source for FriendFeed, but it’s currently disabled because I don’t want to extend the amount of time it takes to collect data from the web too much.

The idea is really simple – it’s a screensaver for GNOME that displays recent posts about Ubuntu from Twitter and Identi.ca. That’s it!

The code and bugs and downloads live on Launchpad, and packages for Ubuntu 9.10 (Karmic) are in my PPA.

Please let me know what you think!

Obligatory screenshot:

Update: I had to remove the Jaunty package from the PPA because it turns out that I’ve been using GooCanvas features that aren’t available in the Jaunty version of GooCanvas. Sorry Jaunty users, you’ll have to wait until next month when Karmic is released and you upgrade!

You can find the download on Launchpad or see more at the Homepage. Enjoy!

Hopefully both will get merged soon! Now I need to figure out what I should poke at next in 2009 (my rough aim for the year being to produce more and consume less).

This time we merry band of elves bring you a delightful mix of bug fixes and new features. Here’s the change log:
* Bug fixes
* Simultaneous typing support
* Directional terminal navigation
* Improved search UI
* Graphical Profile Editor
* Bug numbers for launchpad.net are now URLs

Head over to the homepage or Launchpad for the goodness. I’ve already pushed out source packages to the Ubuntu PPAs, which should be spinning up buildds soon, so expect binary packages shortly. I’m sure we’ll filter into Debian, Ubuntu Jaunty, Fedora, FreeBSD and more soon enough :)

One such conversation was over lunch in a busy Google canteen with Kees Cook, one of our rocking security engineers and a thoroughly decent chap. After a while we came to the subject of Terminator and some of the features we’d like to implement, the ones that have been requested and we’re not particularly motivated to work on, and the odd ones.

I was trying to remember the things people have asked us to add, that for one reason or another we probably aren’t going to and mentioned one about the ability to navigate between terminals in a directional way: That is, rather than doing Ctrl-Tab to cycle through the terminals in the order they were created, you could press something to move to the terminal to the left, or above, right or below the currently focussed one.

On the surface it sounds like a good idea and probably not too tricky, but only if you think from the point of view of a grid. That really would be easy, but our UI is produced by way of a tree structure, not a grid. This means you need to do some proper thinking to figure it out. Kees’ face lit up and he said something like “that sounds like a graph theory problem!” and expressed an interest in working on it.

I’m very glad to say that in just under a week after we all went home from UDS, I’ve just merged his results into trunk.

Thanks very much to Kees for his code and helpful suggestions (such as resurrecting Marcus Korn’s simultaneous-typing branch, which I did one evening at UDS – rewriting it and then merging it into trunk). Also thanks to the other Terminator users I met there :)

So that’s two new features, although not really the big ticket ones that are holding back 1.0 ;)

Out of sheer curiosity last night I fired up the excellent powertop and decided to see how my system was doing. It was producing a couple of hundred fewer interrupts per second than it did in 8.04 (Hardy), and was using 1-2Watts less power.

Previously I have always resisted applying tweaks to my laptop that would attempt to reduce power, but since things were improving, the temptation was simply too great and I started digging out all the resources on this (by far the most useful being the tips on Intel’s grammatically horrific http://www.lesswatts.org/). I had two reasons for not doing this previously – firstly I didn’t want to deviate too much from a default install of Ubuntu (if only because it makes it much harder to reproduce bugs), but secondly I kept running into little weirdnesses. The most inconvenient of these was enabling AHCI link power management (which basically puts the hard disk bus to sleep when there is no IO); Enabling this and then suspending the laptop produced a 5 second delay on resuming because the kernel was forgetting it had put the bus to sleep and so had to wait for it to time out and be reset.

This particular niggle is fixed in 2.6.27 and so my 3-4 second resume times are preserved and I can save power! \o/

After a little while tweaking disk, AHCI, USB, filesystem, wireless, sound and ethernet options I ended up with a system which runs between 8 and 9 Watts when idle, down from 10-14 Watts, which I think is a pretty impressive saving and I’m very curious to find out from other Thinkpad X300 owners how well Windows performs in the power usage stakes – we always hear that Linux is a bit worse, but I’d be really quite surprised if the machine can run with very much less – it’s spending (when idle, obviously) 99% of its time in the deepest processor sleep state and is only generating about a hundred interrupts per second (about 70-80% of which are due to my using a 3D desktop and wireless).

fatal: bad ownership or modes for chroot directory

You may also have searched on Google for what to do about it and come away with very little useful information.

Well no more! I did the same thing and got bored of reading mailing list posts, so read the source code instead. The relevant section is in session.c:

    if (stat(component, &st) != 0)
      fatal("%s: stat(\"%s\"): %s", __func__,
          component, strerror(errno));
    if (st.st_uid != 0 || (st.st_mode & 022) != 0)
      fatal("bad ownership or modes for chroot "
          "directory %s\"%s\"",
          cp == NULL ? "" : "component ", component);

This is quite simple really, it’s stat()ing the directory specified for “ChrootDirectory” and all its parents up to / and checking that they are:

• owned by root
• not group or other writable
• (it also checks they are actually directories, but I’m going to assume you’re not stupid enough to try and chroot into a file ;)

Note my emphesis that these checks apply to the chroot directory itself and its parents and /, so if you are chrooting users into /srv/chroot/ then you need to ensure that /, /srv and /srv/chroot are owned by root and not writable by the group (even if it’s root, bizarrely) or other users.

Sorted.

Fortunately the USB specs allow devices to be put to sleep if they’re not being used and support that feature. Unfortunately many devices advertise they support it when they really don’t, so Linux is unable to automatically put every USB device to sleep.
Fortunately you can control the setting by hand, and this is how. Firstly, start off with a Terminal and run the command “lsusb”:

cmsj@kodachi:~$ lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 17ef:4807 Lenovo
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
cmsj@kodachi:~$

You can ignore the “root hub” entries, the interesting two are “SGS Thomson Microelectronics Fingerprint Reader” (guess which device that is ;), and “Lenovo” (this is the webcam).

So now we need to poke at those devices to enable their autosleeping. If we look at the entry for the webcam:

Bus 004 Device 002: ID 17ef:4807 Lenovo

I’ve highlighted “4807“. This is the Product value for this USB device (if you’re curious, the “17ef” part is the Vendor value and uniquely identifies the maker of this device).

Now we need to find out where abouts the webcam lives in the /sys/ filesystem (which is something the kernel provides to give applications lots of information about the hardware in your system).

The following command will put us on the right path:

grep 4807 /sys/devices/*/*/usb*/*/idProduct

Which, on my laptop, returns:

/sys/devices/pci0000:00/0000:00:1d.7/usb4/4-5/idProduct:4807

Take that information you get, and chop the “idProduct:4807” bit off the end, just leaving “/sys/devices/pci0000:00/0000:00:1d.7/usb4/4-5/” (yours will look a little different to this) and add “power/level” to the end.

You should now have something that looks pretty much like “/sys/devices/pci0000:00/0000:00:1d.7/usb4/4-5/power/level” and if you get the current setting:

cmsj@kodachi:~/Desktop$ cat /sys/devices/pci0000:00/0000:00:1d.7/usb4/4-5/power/level
on
cmsj@kodachi:~/Desktop$

you can see it is “on”, which means it will not be automatically put to sleep. To change that, run:

echo "auto" | sudo tee /sys/devices/pci0000:00/0000:00:1d.7/usb4/4-5/power/level

and test if your device still works (so if it’s a webcam, fire up “cheese“, or if it’s a fingerprint scanner that you use, test if it still accepts your finger). If everything is good then you can put something in /etc/rc.local so the power saving will be set up every time you reboot your computer:

echo "auto" > /sys/devices/pci0000:00/0000:00:1d.7/usb4/4-5/power/level

and that’s it! Repeat this for all the USB devices in your laptop and enjoy the power saving (run “powertop” about 10 minutes before you start doing this so it has time to get a good average of your power usage, then see how much difference this makes. It could be up to 0.5Watts per device). Note that this won’t work particularly well for external USB devices you plug in, becuase the /sys/ path won’t exist until you plug the device in, so you’d need to do the above steps every time you connect it.

Hopefully HAL will start whitelisting devices which can be suspended, but I don’t know of any work in this direction at the moment.

The source tarball is up, of course, and the Hardy/Intrepid PPAs should have packages by the time you read this.

The page for the script is here