Older blog entries for robertc (starting at number 98)

My desktop machine blew up, so I got a lovely fresh install of Jaunty. And, X and Gnome still disagreed by default about my actual screeen size... it was unreadably small with the default fonts. I've posted the following instructions before - these are basically unchanged except that the location of the fonts dialog has moved.

Tip for folk that would like X to show fonts (i.e. the GDM log in screen) in the correct size: Teach X about the dpi setting!

Step 1: run xdpyinfo and look for the dimensions: line. There will be something like this:

dimensions: 1280x768 pixels (266x161 millimeters)

resolution: 122x121 dots per inch

Grab a ruler and measure the screen you have. If it matches the millimeters reported by X, then skip step 2.

Step 2: edit /etc/X11/xorg.conf, and locate your Monitor section:

Section "Monitor"

Identifier "Generic Monitor"

Option "DPMS"

DisplaySize 265 160

EndSection

Add in a DisplaySize like I have there. Now logout of your GUI and restart X - you can run /etc/init.d/{g,k}dm restart from the console, or do what I do - just hit ctrl-alt-bkspace so it restarts. Your login screen should change appearance slightly - either the fonts and regions will get bigger if your dpi was set too low, or vice verca.

Step 3: (For KDE users, someone please tell me what it should be, for GNOME read on)...

Run xdpyinfo again and find the Resolution: line. Ignore the fact that it may not be square, grab one of the two numbers ( I suggest the higher)..

Go to System, Preferences, Appearance, and the Font tab. Select 'Details'. There is a Resolution field there. Put in the single number you chose. Changes should take effect immediately.

Applications I know of which benefit from having this set correctly:

xpdf, gnome-* (panels are readable etc etc), firefox.

Launchpad has just upgraded their bzr server to bzr 1.13. This makes the signficant performance improvements in bzr 1.13 available when pushing and pulling from branches hosted on launchpad. 1.14 has further improvements in the client, so if pushing to launchpad is slow please consider upgrading your client to 1.14 (which about to enter beta).

This has irritated me for a while in configure.ac. You've probably seen this pattern before:

AC_INIT([foo], [0.0.1])
MAJOR=0
MINOR=0
MICRO=1
MY_VERSION=$MAJOR.$MINOR.$MICRO
AC_SUBST(MAJOR)
AC_SUBST(MINOR)
AC_SUBST(MICRO)
AC_SUBST(MY_VERSION)

I finally hit my annoyance threshold for this, and the answer is pretty obvious. (If its not, or you think there is a simpler one, give it a shot - I'd like something more pithy).

AC_DEFUN([MAJOR], [0])
AC_DEFUN([MINOR], [0])
AC_DEFUN([MICRO], [1])
AC_DEFUN([MY_VERSION], [MAJOR.MINOR.MICRO])
AC_INIT([foo], [MY_VERSION])
AC_SUBST(MAJOR)
AC_SUBST(MINOR)
AC_SUBST(MICRO)
AC_SUBST(MY_VERSION)

Its not a big deal to be duplicating version numbers, but not duplicating at all is nicer.

Certain amount of hyperbole, but still a great perspective on software-as-a-service vs service-as-a-service in Iceland.

Microsoft Skull-fucks Iceland’s Economy, Contracts Syphilis

Entertaining too :)

Customer service... and vodafone. Something fundamentally missing here.

Vodafone's website is slow - 50% of the time you can't even login. 15-20 simple page clicks.

Ringing customer service - you get a IVR system that is intensely frustrating. It can't handle simple things like "Your website sucks" (it asks if you want to inquire about iphone 3g's). 10 minutes later and it actually offers a menu. Finally, some way to get through to a human.

Having stopped doing paper bills, you have to sign up to this website; several thousand words of legal terms and conditions later - 99% unrelated to paying bills - and you can't configure it to email you, unless it also SMS's you. WTF. Customer service don't know why this is required. And the website doesn't tell you its required, it just refuses to accept the form unless it's ticked.

Seriously, someone setup a viable, flexible, mobile provider in australia, with good international roaming - give me a ring.

Well, advertising for the win right?

Was looking up a song I vaguely remembered via youtube, and I noticed that > 30% of the search results are taken up by a single advert for a film (Liam Neeson in Taken, ironically) which sits at the top right, leaving the rest of the column blank.

SHEESH

What the git vs bzr discussion is about IMO is usability. The following blog post about DTrace on linux talks about the same issue, and I'd like to use Bryan's words:

"Over and over again, we made architectural and technical design decisions that would yield an instrumentation framework that would be not just safe, powerful and flexible, but also usable. The subtle bit here is that many of those decisions were not at the surface of the system (where the discussion on the Linux list seems to be currently mired), but in its guts."

->

"Over and over again, we made architectural and technical design decisions that would yield a Distributed VCS be not just safe, powerful and flexible, but also usable. The subtle bit here is that many of those decisions were not at the surface of the system (where the discussions going on at the moment seem to be currently mired), but in its guts."

I keep running into folk whom I knew of, that use bzr, but I did not know that they use bzr.

Right now there is a lot of discussion going on about DVCS in various projects. While I imagine most bzr users just want to get on with their coding (after all thats what bzr is good at :))... it would be fantastic if you could blog that you use it, and folk at GUADEC wear the T-shirt!

Also, I'm at GUADEC, and I'm extremely happy to answer questions from anyone, bzr user, git user, or even svn user :)

Well, the gauntlet is down (BTW - desktop power integration. Cool!). The use case Ted talks about is actually quite interesting - we were at UDS last month, waiting on a SVN server that was apparently so slow we could have walked to it and copied stuff onto harddisk more quickly. (Really. No kidding). bzr was idling and blocked on network IO the whole time... kudos for the plugin Ted!

For my response, may I present a new index format, (branch url) 70% smaller than bzr's current default, equally fast at most workloads, up to 20 times faster at others. I started this this week, and John jumped in in overlapping time periods, but I think it counts!

Note that the perfromance wins are a component improvement - other things we haven't addressed yet can make the index improvements less visible. But several early adopters have told me that they see a 25-30% reduction in 'time bzr log > /dev/null' or other commands.

To install:

bzr branch http://bazaar.launchpad.net/~lifeless/+junk/bzr-index2 ~/.bazaar/plugins/index2

bzr branch https://bazaar.launchpad.net/~jameinel/+junk/pybloom ~/.bazaar/plugins/pybloom

To use:

cd <repository you want to experiment on>

bzr upgrade --btree-plain

(or --btree-rich-root for bzr-svn users).

A version of this will be going to trunk soon, and it will be able to upgrade from any repository that you have that uses the plugin as long as you keep the plugin installed.

Dear lazyweb number 3.

So far, I've asked:

high latency net simulations - great answers.

python friendly back-end accessible search engines - many answers, none that fit the bill. So I wrote my own :).

Today, I shall ask - is there a python-accessible persistent b+tree(or hashtable, or ...) module. Key considerations:

- scaling: millions of nodes are needed with low latency access to a nodes value and to determine a nodes absence

- indices are write once. (e.g. a group of indices are queried, and data is expired altered by some generational tactic such as combining existing indices into one larger one and discarding the old ones)

- reading and writing is suitable for sharply memory constrained environments. ideally only a few 100KB of memory are needed to write a 100K node index, or to read those same 100K nodes back out of a million node index. temporary files during writing are fine.

- backend access must either be via a well defined minimal api (e.g. 'needs read, readv, write, rename, delete') or customisable in python

- easy installation - if C libraries etc are needed they must be already pervasively available to windows users and Ubuntu/Suse/Redhat/*BSD systems

- ideally sorted iteration is available as well, though it could be layered on top

- fast, did I mention fast?

- stable formats - these indices may last for years unaltered after being written, so any libraries involved need to ensure that the format will be accessible for a long time. (e.g. python's dump/marshal facility fails)

sqlite, bdb already fail at this requirements list.

snakesql, gadfly, buzhug and rbtree fail too.