Uncategorised

Fahrenheit 9/11

Went to see Fahrenheit 9/11 on Monday night. It was an interesting movie, but it was clearly aimed at a US audience. It did have a fair bit of information I hadn’t heard before, but in some areas he was obviously choosing which bits of information to include to increase the effect (eg. when listing the countries in the “coallition of the willing” he didn’t list Britain). Other bits seemed particularly relevant like the bit about the Bush administration playing with the terror alert apparently for political reasons, given what has happened so far this week.

Overall, I thought it was a good movie.

Firefox

Firefox is quite a nice browser, but the toolbars seem to have too much padding round the buttons in the toolbar. It looks like this is due to the double padding round the back and forward buttons.

It looks a bit better after creating a chrome/userChrome.css file in the profile directory containing the following:

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
.toolbarbutton-1, .toolbarbutton-menubutton-button {
padding: 5px !important;
}
.toolbarbutton-menubutton-button {
margin: -1px 0px -1px -1px !important;
}
.toolbarbutton-1[type="menu-button"] {
padding: 0px !important;
}

You might need to adjust the negative margins to match the xthickness/ythickness of your GTK theme in order to make it look okay.

The other cool thing is that some people are working on adding GTK stock icon support to the Mozilla code base. While the initial focus of this is to add stock icons to buttons in the dialogs, it sounds like it could be extended to toolbar buttons and other places in the future. This would make it fit in on the Gnome desktop a lot better.

Have been looking at the Subversion 1.1 release candidate, and it looks pretty good. This could be the point where more people start to seriously look at using Subversion as a CVS replacement.

This would be largely due to the new fsfs repository backend. This new backend doesn’t use berkeley db, and shouldn’t ever wedge like the BDB backend does occasionally. Furthermore, you don’t need write access to the repository to perform read only operations. This should make it a lot easier to set up systems where you have multiple ways of accessing the repository (eg. svnserve/ssh for write access, DAV and viewcvs for read access).

The fsfs backend stores each revision of the repository as two files in the repository (one for changes to the files/properties, and one to store revision properties), and doesn’t modify the files associated with previous revisions when performing a commit. This means that the the existing backup and mirror infrastructure that projects have set up for CVS repositories should work equally well for Subversion.

The “new file for each revision” policy also has some nice features. In the case of svn+ssh access where each committer can directly access the repository files, it means that the existing revisions in the repository can be made readonly without preventing people from committing new revisions (something that can’t really be done with CVS).

These administrative improvements should make it a lot easier to deploy Subversion, which in turn let more developers take advantage of its features.

An interesting essay on asylum seekers by Greg Egan (a local Science Fiction author). If you are interested in the subject, Dark Victory is also worth reading.

Made a few more changes to the Gnome viewcvs. Pretty much all of the original ugly colour scheme is gone now, and I got it to pretty print some more files with gnome specific file extensions.

We are maintaining the modifications in CVS using the standard vendor branch/main branch setup. Since the cvs import command is one that people screw up the most, I wrote some scripts to help with exporting viewcvs from upstream CVS and then importing it into our CVS.

When I went to test the script, it worked fairly well, except for the fact that some of the template files had been moved between the two pulls. Since there was no link between the two different file names, CVS wasn’t able to merge my local changes. Other than that, the merge went okay.

I wonder if Arch or Subversion would have been able to handle this situation any better, given that the upstream repository didn’t record that the file had been moved?

Did a little more hacking on my IPP client library, and wrote a small PyGTK program that lets you do simple management tasks (view all print queues/classes, view queued and completed jobs for printers, stop and start print queues, etc).

If you want to try it out, grab ipplib.py and printerlist.py. Put them in the same directory and run “python printerlist.py“. Seems to work pretty well for less than a thousand lines of code.

To get things working with CUPS’s authentication, I do the following for operations like Pause-Printer:

1. Submit request to the HTTP URI corresponding to the IPP one.
2. If the response has an IPP status code of client-error-not-authorized, then resubmit the request to the URI /admin/ relative to the previous URI (not changing the IPP message).
3. Return the IPP response message.

This seems to work quite reliably, so I might add the fallback to all the IPP requests.