.bloggandomene

I’ve begun using this amazing client to read my mail.
One thing I’m used to do is to keep all my contacts synchronized online with Google Contacts.

After a (small) research, I’ve run into goobook , a small python program that relies on gdata to perform queries onto Google Contact service.

It’s very handy and light so I’ve written the ebuild and I can say that it works like a charm.

If you are interested in configuring it, please keep reading.
Once installed you have to configure it properly in order to reach your account.

Fire up your favorite text editor and create a file named .goobookrc in your user’s homedir and put in there this content:

[DEFAULT]
email: youremailatgmaildotcom
password: yoursupahsecretpassword
max_results: 9999
cache_filename: ~/.goobook_cache
cache_expiry_hours: 24

That’s it. Goobook is configured.
Try it by running goobook query yourfriendnamehere. It’ll show the results if everything went well.

If you are, like me, a Mutt user, open your mutt configuration file and add the following lines:

# mail address completion
set query_command="goobook query '%s'"
bind editor <Tab> complete-query
macro index,pager a "<pipe-message>goobook add<return>" "add the sender address to Google contacts"

That’s it. This should be enough to set properly mutt to use goobook.
As you’ve probably already noticed, this will also configure your client to add contacts by pressing the ‘a’ letter on your keyboard.

All information written here has been taken from goobook official wiki page that contains something more.

This post is about a nice discovery I made when I upgraded my XEN dom0 kernel to the latest one (2.6.32-).
I suddenly noticed that the I/O performance was highly dropping down when moving few small files (~350MB) from one partition to another one of the same hard-disk.

I worried myself so I began investigating about the issue and, eventually, I posted on xen-users mailing list .

After few days I’ve been told that the problem was probably given by the I/O scheduler on the guest machine.

The solution is to disable domU scheduler and leave all the work to the dom0 scheduler. And it, actually, did the trick for me.

In order to do that, just add ‘elevator=noop’ to the kernel’s bootflag of your guest machine and check if the system becomes more reactive.

If you are interested into the whole dynamic or you’re simply willing to understand better the reasons why this happens, here’s the thread on XEN mailing list.

If you’ll find a possible explanation for such a slow-down.

Just to be curious: drop me a comment about if something changes or not on your systems.