I'm just back from ExoClimes 2010: Exploring the Diversity of Planetary Atmospheres. An excellent conference: the PDFs of the talks and posters are now online, and they are putting the videos of the talks up soon. But in particular the organizers deserves thanks for bringing exoplanetary scientists and observers together with climate modelers doing Earth (and Mars, Titan, Venus, ...) models. The last talk on Friday was by Peter Cox on Climate change and exoplanet sciences that was far better than expected for the "graveyard shift". One theme of the conference was the need for a 'heirarchy' of models, from simple energy-balance models to full circulation (GCM) models: using progressively more complex models to understand more bits of whats going on. Exoplanet workers mostly use simpler models, progressing now to GCMs, while Earth modellers are moving beyond GCMs to "Earth system" models including biology, etc. Peter pointed out the two styles of work: the exoplanet modelers are short of data, and risk being too speculative. We know little of what the planets are like, and concentrate on implementing physics in the models to see what they might be like. Earth modelers on the other hand are if anything swamped with data: the tendency here is to make the model fit the data, by adjusting parameters until it does so. The danger of this approach is that the model will then not work away from current present-Earth conditions. Tim Lenton pointed out some work that was done with the Met Office model, where they took the radiative transfer part of the model and tested it for other planets, and paleo-Earth conditions. The model blew up : it wasn't capable of x2 or x4 current CO2 levels. (This has since been corrected). Over dinner there were interesting discussions on the different styles within the communities. While the underlying GCMs used come from the Earth sciences, its quite common within the exoplanetary community for a researcher to work on all parts of the model: dynamics one day, radiative transfer the next. In Earth climate work people have become more specialized and someone is a 'radiative transfer' person, and won't touch other parts of the code (even if they can follow them in the huge codes we have today!). On the other hand, there is a greater tradition of model inter-comparison in Earth sciences, where we compare the model outputs to each other for some known test cases ( Held & Suarez, the CMIP5 project, etc.) Apart from some initial work by Emily Rauscher, little has been done on this in exoplanetary models; it was agreed more of this would be a good idea. Radiative transfer (the interaction of 'sunlight' with the atmosphere, where it gets absorbed, scattered and re-radiated) in particular seems to be an area that could benefit from this. In this middle ground Francois Forget showed the work on the LMDZ model and applying GCMs to terrestrial planets. They've successfully applied this model to Mars, Titan, and partially to Venus (a much tougher problem, due to its heavy clouds giving a long radiative timescale). There are problems with correctly explaining super-rotation though. This is where the atmosphere rotates faster than the planet: on Venus for example the planet rotates every 243 days, while the clouds rotate around the planet every 4 days. Sebastian Lebonnois described the possible mechanisms for Venus and Titan; Johnathan Mitchell so did some interesting work on this recently. Different regimes are involved for different rotation rates of the planet. Ralph Lorenz pointed out the lack of "real paleo-Earth" climate work at the moment. While geology has inspired a lot of work on the atmospheric composition, what with the different gas mixtures (meaning earth-model radiative transfer codes don't work) and the faster dynamics meaning super-rotation could apply (Earth's day was about 8 hours long in the Archean era), we don't have a model of the climate yet. It looks like we should treat Earth as an exoplanet. Tags astronomy, climate, exoplanets, conferences

---

It is a while since we managed to get below the 1000 stable RC mark. Last weekend we managed the next mark, that is we are below 900 now! Obviously my effort during the RCBC did take us a fair step in that direction, but I don't want to take full credit for it. The last bit that got us below the 900 happened through an event of last weekend: The current point release of lenny. Be aware that the BTS doesn't know about proposed-updates, so bugs closed through uploads to there only are seen when they hit the main pool which is the reason for point releases. It were something around 25 RC bugs that were closed by that. I haven't checked who exactly is to thank here, but looking at the non-DSA packages one finds some perl packages and at least two font packages. Thanks to the corresponding teams for their help! I plan to continue these efforts, so if you think it's a good idea you might want to flattr it. I think this quote sums up the motivation behind this pretty well:

<jwilk> Yay, only 900 bugs to fix and we can release lenny! Oh wait...

/debian permanent link Comments: 0

I'm back in town. After approximatly 4 full days of use, the first battery bank dropped to 9 volts, my cutoff point for safe use. Which turned out to be below the safe use point of my laptop power adapter, which burnt out while I was busy listening to music and adding power-saving caching stuff to my mpd setup. Irony not appreciated, world. I decided to come back while the other bank is still relatively full.

my modest PV array

Hurrying downtown to grab lunch in between work on Branchable, I noticed it was a beautiful sunny day, and I realized that this makes such days even better, because besides enjoying them, I know I'll be enjoying the yield on chilly nights sometime later. Well, in theory. Actually, the very antique charge controller in the house was dead and bypassed, so I removed it. I called its manufacturer wondering if it could be refurbished, but they suggested it belonged in a museum. So I've ordered a new controller, a Xantrex C-35. Until that comes, pretty days like today will charge, or possibly over-charge the batteries, which will then drain back out at night.

I must admit, I do not really get the point of the ongoing discussion about having an official Facebook page. In my understanding it should be a source of information about Debian for Facebook users, technically a mirror of www.debian.org/News and debian-devel-announce@lists.debian.org. Yes, Facebook is a piece of non-free, data-harvesting sh*t. But there are users, maintainers and developers who use that service (they also use Twitter, Xing, Linkedin, StudiVZ, MeinVZ and so on). Why should we prohibit them to have an official source of information on their platform? If there is someone who wants to run that kind of service: go for it! Or would we prohibit someone to run a mirror of ftp.debian.org on a Windows machine just because the surrounding environment is non-free ? Most probably, that wouldn t be an official mirror listed on www.debian.org/distrib/ftplist, but it would still contain the official set of packages, signed with the official key of the archive. Btw, is @debian on Twitter official ? And please, do not compare this situation to SourceForge, GitHub, Google Code etc. It s just not the same! On SourceForge etc one relies on a non-free service as the primary way of distribution (that s not perfectly true for DVCS based services, as here one can push the tree to every service one has access to). On Facebook we d just have a mirror of the already freely available information. ) do not forget: almost every machine used for hosting/developing/whatsoever Debian has non-free hardware, firmware etc!

In the last few years the Israeli government founded some work on openoffice.org by Tk Open Systems Ltd. During the years, the work has resulted with an Israeli version , released after the official release and includes a lot of patches to improve support for Bidi and Hebrew specifically. Although most patches were submitted to the hamburg , a lot of them weren t used and are still waiting for inclusion. The funding the that projects stopped a year ago (9/2009), and the last release of the Israeli version is 3.1.1. Since then we had a quiet period in which 3.2 and 3.2.1 were released. While still enjoying the fruits of the projects in these version, it seems that it s time for the community to take over, as we lost hopes for yet another funds from the government. In may Netanel and I started talking about taking over the Hebrew translation, and in June we got Hebrew added to the openoffice.org pootle server. We started with about 80%, and got to 86% in time to get to the list of languages getting a language pack built for. This was a first achievement as Hebrew didn t have a language pack since early on the 2.x versions. I believe that working as part of the openoffice.org l10n group and with openoffice.org release schedule will only benefit for the Hebrew translation process. We used the language pack to test the translation and improve it. We also were able to get to 89% with the help of more volunteers.I believe it s now much more consistent than before. In the process with manually checked Writer thoroughly, while Calc and Impress got less attention due to the time frame. But we fixed some major translation issues in all of the three components. While testing the translation we also started to report Bidi issues we saw in 3.3 beta, hoping they will be fixed for the final release. For example, the main openoffice.org screen on windows has is getting repainted wrongly when moving the mouse over the options (text, spreadsheet..). This looks very badly as this is the main screen! See issue #97556 for details In addition to report new issues, we also started to keep track of the already opened issues regarding Bidi and Hebrew. I m following the issue system for a few years now, but seeing the list of issues organized in the wiki gave me a better orientation in the problems we have. E.g. finding some related or similar issues and mention each other in the comments, when someone goes to first one, he could also fixed the other as the problem is similar and probably comes from the same code. Organizing also the already closed bugs in 3.x, gave me a some kind of a changelog for the Bidi and Hebrew related issues. In that manner, version 3.1 was a very good for Bidi, thanks for a lot of efforts and work with the Bidi meta issue #79434. The wiki page is in Hebrew, but looks quite OK with Google translate (see here). Hoping to have 3.4 a major release (Bidi wise), I ve opened issue #114236 as another meta issue for Bidi related issues. I ve kept Hebrew specific issues out, as to get it more general and also relevant for Bidi users in other languages. Any help of those issues will be more than welcome (starting with votes and ending with patches).
Filed under: i18n & l10n, Israeli Community, Openoffice.org

It has been a pretty exhausting time since my last blog post in my area of Debian land . If you followed the news you should have seen some of it. Last weekend there was the point release. For those I have the (good?) position to sit in the middle of the working queue, where the hardest part (sorting out which stuff to include, getting it all build, etc) is already done. Still, due to the amount of steps neccessary to take its usually a multi-hour thing. This one release was even slower, as we had to wait for hours until the package lists had all been built - unfortunately the thing writing that keeps berkeley db files of data around as cache - and uses the FULL path to the files as key. How stupidly annoying when the path changes during a server move. Ohwell. The other big part that got a tiny bit of press coverage was the move from www.backports.org over to backports.debian.org. This was actually waiting for me for a good longish while already (err, well, since well before DC9 this was decided to happen) but now I finally got myself moved. This turned out to be much more work than I ever feared (which is part of the reason why it took so long), but some numbers:

• At the start the code changes between the revision running on oldbpo compared to HEAD: 303 files changed, 21227 insertions(+), 468357 deletions(-) (There had been 1723 commits in the master branch since the last time bpo got it, thats about a quarter of all we have in master!)
• Database schema version oldbpo: 5, HEAD: 35
• sub-sub-sub-optimal damn old shell scripts for the cronjobs.

The db update alone took me a week to figure out which steps to do in which order. Good to have an automated system, if you the manage to have the updates run specific to the main archive. Ups. When I was done with the database (during which I managed to just erase all work done by formorer and rhonda on the webpage, ups^2) I had some code and config cleanups to do, and especially manage to get it all running with a new path layout. Much less complicated, but enough work to do, before I finally was far enough to get it all move so far that formorer could start testing it and we could turn off the old system. At this time I had to fix up our shell scripts for our cron jobs, but that (with one exception) was a nearly straight forward easy task. And on Wednesday I managed another goal - backports is fully running the master branch of dak, the exact same code as on ftp-master. The cronjobs are slightly different, as well as the config (of course, duh), but otherwise its the same. My current goal and the last things left on this move todo is to change the cronjobs so that debian as well as backports do run the SAME scripts, but their configs list which tools should be run when. Considering that my dinstall cron already contains something pretty much a state machine I think I m insane enough to get this in shell, but when I told that to Mark (you know, the second ftpmaster :) ), I heard something very much like vomiting (you know, 700km between us, this might mean something) and then the plea to use a real language for the task. Oh my. I like my shell. :)

---

There is one big black cloud on the horizon to see. I have to do something similar for security. They are at a dak (and database) version pretty similar to what bpo had. They do need to support this obnoxious spare new format too before they can support security for squeeze, so there is no way I can ignore that archive for much longer. I already asked DSA for a vm in which I can play (not good to interrupt security archive for long), but probably wont start on this before the upcoming FTPMaster meeting. Pretty busy otherwise. Wellwell, I hope it will be less painful, as I now know the steps already. :)

Backlight control is one of those things that you'd think would be simple, but ha ha this is computing so of course it's an utter disaster and everything is a huge mess. There's three main classes of backlight control in the x86 world, all of which have drawbacks:

• ACPI specifies a mechanism for backlight control, and the majority of modern machines implement it. It has the advantage that the brightness query interface is generally aware of anything else in the system which may have changed the brightness, so it's unlikely to get out of sync with reality if the platform tries to do something odd like change the backlight itself in response to an ambient light sensor or some other event. The main drawback is that there's typically a fairly small number of available backlight values, usually somewhere between 8 and 20.
• A platform-specific mechanism. This used to be more popular before the ACPI backlight interface took off, but some machines still require it. The idea here is that there's some sort of platform-specific way of requesting a backlight change, ranging from a vendor-specific ACPI method through to triggering system management calls by magic register writes. These methods usually (but not always) keep in sync with other firmware changes, but rarely provide any more brightness steps than the standard ACPI interface.
• Many mobile GPUs have backlight control registers built in. These usually give you a range of several thousand possible values, but using them will almost certainly leave you out of sync with reality if the firmware touches them at all. To make things worse, the firmware control of the backlight may occur after the gpu - so you could end up with two different controls that both need to be full in order to get maximum brightness. The worst case scenario is that the firmware gets confused by the values not being what it programmed and you end up with a hung machine.

Right now, if there's an ACPI backlight interface then that's usually the only thing we'll show you. We can do that because we can identify if there's an ACPI backlight interface when we parse the ACPI tables at the start of booting, and that information can be registered before we start setting up any other backlights. The problem comes when we have no ACPI backlight interface. We don't have any idea whether there's a platform mechanism until a platform driver loads, which could be at any time. As a result, we've been reluctant to expose GPU-level backlight control because doing so would often give you two separate backlight controls and no indication as to which should be used. Userspace doesn't really have a way to make that decision either, so everyone ends up unhappy.

This is especially problematic with some machines which provide no ACPI or known platform control (or, in the case of some Samsungs, only provide platform control if you have a special Linux BIOS that Samsung won't give you) but can control the backlight via the gpu. Right now you get nothing, because giving you something would potentially break other systems and the needs of the many etc. Sorry! But this is obviously problematic in the long term, especially because multi-GPU machines tend to have multiple ACPI backlight interfaces, so I've been working on a better approach.

When a backlight device is registered, it appears under /sys/class/backlight. If it's an ACPI device it has a symlink pointing to some random ACPI device. If it's a platform device it's pointing at something like "dell-laptop" which is approximately unhelpful when it comes to figuring out what it controls. If it's a GPU-level device then it probably points at the PCI device, which is helpful except in the case where you have multiple backlight controls on a single GPU. So, by and large, you have no good way to identify which backlight control is preferable unless you keep a huge list of all possible backlights along with some scoring.

The first thing I've added to improve this is a "type" attribute. This tells you whether a given backlight is firmware-level (like ACPI), platform-level (like the various laptop drivers) or performs raw register writes (like a GPU driver). That lets userspace decide which interface is preferable. It'll typically be the ACPI interface, because that's the most likely to keep synchronisation and so avoid bizarre brightness bugs. The next thing has been to start fixing up the parent links. There's nothing we can do for the platform level devices, but the ACPI drivers could at least point at PCI devices rather than into ACPI space. That means that multi-GPU systems can now identify which interface to use based on the currently active GPU. Finally, I've started pointing the GPU-level backlight controls at the specific output rather than merely at the PCI device. This probably makes little difference for laptops as such, but once we start exposing backlight control for monitors that support ddcci it'll make things much easier as we'll know which backlight control corresponds to which monitor.

I've then written a small library that accepts information about the output and picks the "best" backlight for the device. It's obviously based on a pile of heuristics and there's a couple of bits of API that I suspect need to be nailed down yet, but it means that this code only needs to be written once. It's then simple to glue this into X drivers, which means that they can expose a "Backlight" xrandr property on each relevant display. That means that backlight control is then handled at the session level with the X server acting as the privileged agent, which simplifies a bunch of things and means we can finally let hal die entirely. Long-term this means we'll have unified backlight control for all of your displays, which is a wonderful thing.

Summary: We kind of suck right now, but there's a reasonably clear path to getting better.

This took a bit of searching, so it's here for reference. I'm sure it'll catch out people who upgrade from Lenny to Squeeze as the initial presentation can be deeply mysterious and frustrating.

I keep my pbuilder stuff outside /var/, so I have a file /home/neil/.pbuilderrc and until recently, this worked fine. Naturally, pbuilder needs sudo to call it, so sudo pbuilder update was a routine command. Then it suddenly stopped working and it was mysterious, pbuilder was looking for /home/root/.pbuilderrc which was just weird. root/.pbuilderrc might make a little more sense, /home/root is just plain wrong.

First, blame pbuilder, no, not changed recently - certainly not since I last ran the command successfully. Hmm.

sudo then? Recently updated, aha, the changes listed in the PTS describes something being documented in NEWS.Debian relating to pbuilder - dig, dig, the answer (indirectly) was in the README. Need to add a command to user lines in sudoers:

, env_keep+="HOME"

Also, act on this guidance in sudo visudo:

# Uncomment to allow members of group sudo to not need a password

Even more nastily, sudo does still need a password (because I've set rootpw later) but this line is still required.

Now restart sudo sudo invoke-rc.d sudo restart which is horribly recursive. (Yes, I did mess up visudo at one point and have to use just plain su to get back access.)

Ho hum. It works, so why do I feel that I've done something bad?

(comments still disabled because of spammers - captchas simply don't work, neither does OpenID, so don't blame me. Those who know me already know how to contact me. The details aren't exactly hidden.)

If you do care about having good samba packages in squeeze, you can help. If you're in a hurry and don't want to read the blah-blah, just skip to the end of this story and read the last paragraph. Thanks to the confidence of the release team, we (samba packagers) have been "authorized" to upload samba 3.5.4 in unstable, thus targeting having that version in squeeze. Up to July, we were indeed targeting 3.4.8 for squeeze, on the assumption that, as usual, samba upstream releases need some maturation before being strong guarantee that no regression happens. In July we were ready to move and finally upload in unstable the 3.5 packages we kept in experimental until then. The final decision was to be taken during DebConf10. It was roughly taken with Steve Langasek, but....I couldn't upload immediately (most people know that working on major packages during DebConf is a dream)...and had holidays afteer. In the meantime, the freeze happened so we got theoretically screwed... Still, I could manage to convince the release team that long term support for samba 3.5 will certainly be better than 3.4...and that functionality in that version (particularly several Win7-related fixes and a much improved code for printing support) and we got a notice "please upload to unstable and come back to us in a few weeks". That happened, finally. So, now, we need YOU, samba users and admins, to test these packages. Merging our packaging branches was hard (thanks, Steve Langasek, for your help) and glitches are always possible. So, please TEST these packages by installing samba, winbind, libsmbclient and friends from unstable....and report bugs, preferrably the release critical ones....

(... achieve Debian world domination without endorsing Facebook) Yes Raphael, we can.
Nobody said it would have been easy, to reach Total World Domination endorsing Free Software only, but that's not a reason to stop trying. I've recently stumbled upon a very nice article by Benjamin Mako Hill, titled Free Software Needs Free Tools, which I believe it's the best possible commentary to the proposal of having an official Debian Facebook page. Of course there is nothing wrong in having non-official, or let's call them "fan" pages, about Debian on Facebook. As a matter of fact we already have one, as you point out. And I also agree that it would be better to know who is behind that page. Individuals, including Debian Developers, are obviously free to use whatever media they please to spread the cause of Debian. After all, as individuals, each of us decide upon her own personal trade-offs (for instance, a trade-off of mine is to have both identi.ca and twitter accounts and to post only to the former with forwarding to the latter). There is no way to have an official Debian Facebook page and pretend that we are not, de facto, endorsing Facebook. That's why I believe having official Debian presence on Facebook, or on any other non Free Software platform, will just weaken our cause. It will send out the message that Free Software it's something which is good for others to use, but not necessarily for Debian as a project. That does not mean that we live under a rock and that we consider social networks useless to promote the Debian cause. It just mean that we should be picky in choosing social networks that respect our Free Software principles, as we are picky in choosing licenses that are DSFG-free. For instance, I'm glad to mention here that the Debian publicity team has recently obtained access to http://identi.ca/debian and will start using it soon. Subscribe! PS This post also gives me a chance to comment on a so called "community page" of mine on Facebook. As I've briefly commented a few days ago I've nothing to do with that page. TTBOMK its content is just automatically injected from Wikipedia. The "Stefano Zacchiroli is on Facebook" claim on the upper left is true only in the sense that there are other people with my name on Facebook. IANAL, but such a claim (not the page in itself) will probably be considered an abusive advertisement in many countries around the world. update: re-word the identi.ca/debian paragraph, to better blend with surrounding text
update: mention "Debian" in heading

A long time ago, when I was first introduced to email, I was using the Mail program from Unix. I quickly converted to Elm, then Mutt, which were both better in terms of interface. Then I found out about Gnus, and I wouldn't dream of letting it go now. However, Gnus has started showing its age several times, and several times have I needed to upgrade the way I was using it: first because I needed to sort and split email, then because I took the sorting out of Gnus and into Procmail for more advanced filtering (including spam filtering), then because I switched to storing the emails on an IMAP server so I could read them remotely from several computers. My setup as of a few days ago was functional, but since I have grown over time to splitting emails into several hundred folders, checking for new messages was becoming more and more boring. So it's time to jump in with all the cool kids and switch to a modern solution: still Gnus of course, but with Dovecot, OfflineIMAP for synchronisation, and let's add email searches into the mix while we're at it. My web searches didn't turn up a simple step-by-step HOWTO, but I assembled bits from different places, and here's my attempt at documenting my new setup. Goals

• Gnus
• Offline operation
• Searching through emails
• and make it fast!

Assumptions

• Email gets delivered (by SMTP or fetchmail or whatever) to a remote server, which can be accessed through IMAP.
• The client is running some sort of standard Unix-like system; Debian GNU/Linux for me, but it should also work with a BSD or Solaris or something else.
• There is enough space on the client to have a copy of the whole email store (or at least of the folders you want to use with this setup Gnus can of course access the others through the slower IMAP server).

Dovecot setup We'll use Dovecot as a local IMAP server. And since we're lazy, we'll access it over a pipe, and dispense with the network part.

• Install Dovecot (aptitude install dovecot-imapd on Debian systems and related).
• Disable its automated running unless you need it for other purposes; on Debian, set ENABLED=0 in /etc/default/dovecot.
• Decide on where you'll store your emails locally; typical place would be $HOME/Maildir.
• That's it!

OfflineIMAP setup OfflineIMAP is basically an optimised two-way synchronisation mechanism between two email repositories . We'll use it in IMAP-to-IMAP mode.

• aptitude install offlineimap, or similar.
• You'll need a ~/.offlineimaprc file, with contents based on the following example:

 [general]
 accounts = MyAccount
 pythonfile = .offlineimap.py
 [Account MyAccount]
 localrepository = LocalIMAP
 remoterepository = RemoteIMAP
 # autorefresh = 5
 # postsynchook = notmuch new
 [Repository LocalIMAP]
 type = IMAP
 preauthtunnel = MAIL=maildir:$HOME/Maildir /usr/lib/dovecot/imap
 holdconnectionopen = yes
 [Repository RemoteIMAP]
 type = IMAP
 remotehost = mail.example.com
 remoteuser = jsmith
 remotepass = swordfish
 ssl = yes
 nametrans = lambda name: re.sub('^INBOX.', '', name)
 # folderfilter = lambda name: name in [ 'INBOX.important', 'INBOX.work' ]
 # folderfilter = lambda name: not (name in [ 'INBOX.spam', 'INBOX.commits' ])
 # holdconnectionopen = yes
 maxconnections = 3
 # foldersort = lld_cmp

• You will of course need to replace the remotehost, remoteuser and remotepass values with your own. If you want to synchronize only a subset of the IMAP folders, uncomment and adapt one of the folderfilter lines; the lambda can be any Python code you like, I guess.
• Run offlineimap. See the emails coming in and being replicated to your local store.
• Run MAIL=maildir:$HOME/Maildir /usr/lib/dovecot/imap. You should get * PREAUTH [CAPABILITY ... STATUS] Logged in as your-login. Type * LIST "" * in there. You should see a list of all the folders.
• The .offlineimaprc mentions a .offlineimap.py, which is where we're going to store some additional code used by OfflineIMAP. Here's a sample:

 # Propagate gnus-expire flag
 from offlineimap import imaputil
 def lld_flagsimap2maildir(flagstring):
   flagmap =  '\\seen': 'S',
              '\\answered': 'R',
              '\\flagged': 'F',
              '\\deleted': 'T',
              '\\draft': 'D',
              'gnus-expire': 'E' 
   retval = []
   imapflaglist = [x.lower() for x in flagstring[1:-1].split()]
   for imapflag in imapflaglist:
       if flagmap.has_key(imapflag):
           retval.append(flagmap[imapflag])
   retval.sort()
   return retval
 def lld_flagsmaildir2imap(list):
   flagmap =  'S': '\\Seen',
              'R': '\\Answered',
              'F': '\\Flagged',
              'T': '\\Deleted',
              'D': '\\Draft',
              'E': 'gnus-expire' 
   retval = []
   for mdflag in list:
       if flagmap.has_key(mdflag):
           retval.append(flagmap[mdflag])
   retval.sort()
   return '(' + ' '.join(retval) + ')'
 imaputil.flagsmaildir2imap = lld_flagsmaildir2imap
 imaputil.flagsimap2maildir = lld_flagsimap2maildir
 # Grab some folders first, and archives later
 high = ['^important$', '^work$']
 low = ['^archives', '^spam$']
 import re
 def lld_cmp(x, y):
   for r in high:
       xm = re.search (r, x)
       ym = re.search (r, y)
       if xm and ym:
           return cmp(x, y)
       elif xm:
           return -1
       elif ym:
           return +1
   for r in low:
       xm = re.search (r, x)
       ym = re.search (r, y)
       if xm and ym:
           return cmp(x, y)
       elif xm:
           return +1
       elif ym:
           return -1
   return cmp(x, y)

The first part of this file adds a new flag that OfflineIMAP will propagate back and forth. By default, only the standard IMAP flags are propagated; we also want to synchronize the gnus-expire flag that Gnus uses to mark expirable articles. It's a hack, but it works for now (maybe someday OfflineIMAP will propagate all the flags it finds?). The second part of that file can be dispensed with (and won't be used unless the foldersort option is uncommented in .offlineimaprc): it's only there to ensure that some important folders are propagated first, and some others go last. I don't know exactly how they are sorted by default, but I'd like the most important ones to come first, so I can start reading them while the archives and the spam are still being fetched. Gnus configuration

• You need to set up a select method for the local IMAP server. The method will be nnimap, the address can be whatever you like (it's just a name anyway), and you only need two options: nnimap-stream, set to shell, and imap-shell-program, which you set to "MAIL=maildir:$HOME/Maildir /usr/lib/dovecot/imap".
• Then browse the server, subscribe to the folders, and so on.
• From time to time, run offlineimap from a terminal, so you get the new messages, delete the old ones, and so on.
• What's that? You hate running stuff by hand? So do I. To run OfflineIMAP in a loop, uncomment the autorefresh option in .offlineimaprc. The value is the duration (in minutes) between two runs.
• Even starting OfflineIMAP is too much work? offlineimap.el to the rescue! Grab it, put it where Emacs will find it, and add the following to your .emacs:

(require 'offlineimap)
(add-hook 'gnus-before-startup-hook 'offlineimap)

Bonus: email searches The simple way:

(require 'nnir)

This goes in your .gnus. Then your group buffer will get a new command. Mark some folders with #, then M-x gnus-group-make-nnir-group (or use the G G shortcut), and type in a set of keywords. This search is performed by the IMAP server (Dovecot), which may or may not be very efficient, especially if you select many folders. Bonus+: email searches, faster The real cool kids use Notmuch nowadays, at least for email indexing and searching. It's fast, it allows complex queries, and it's generally cool. The downside is that it uses up quite some disk space for its indices, in addition to the actual emails. For that reason I'll keep it to my main computer, and I'll stick to nnir on my laptop (which has the same setup apart from that).

• aptitude install notmuch, yada yada.
• notmuch setup, tell it where you stored your Maildir. If you're only going to use Notmuch for searches, I suggest setting tags= to an empty value in .notmuch-config afterwards. We don't want Notmuch to intrude.
• notmuch new will get it indexing the messages you already have.
• Of course, being lazy is being cool, so let's uncomment the postsynchook line from .offlineimaprc.
• Now add (require 'notmuch) to your .gnus. Also (define-key gnus-group-mode-map "GG" 'notmuch-search), for the shortcut.
• But seeing just the message that matches is not enough, sometimes we want the whole thread. Here's a snippet of Lisp for your .gnus, based on Tassilo Horn's configuration. Do a Notmuch search, enter one of the results, type C-c C-c, you'll get transported to the folder where that message was, with the context. Note this requires code from org-mode, so you might need to install that.

(require 'notmuch)
(add-hook 'gnus-group-mode-hook 'lld-notmuch-shortcut)
(require 'org-gnus)
(defun lld-notmuch-shortcut ()
(define-key gnus-group-mode-map "GG" 'notmuch-search)
)
(defun lld-notmuch-file-to-group (file)
"Calculate the Gnus group name from the given file name.
"
(let ((group (file-name-directory (directory-file-name (file-name-directory file)))))
  (setq group (replace-regexp-in-string ".*/Maildir/" "nnimap+local:" group))
  (setq group (replace-regexp-in-string "/$" "" group))
  (if (string-match ":$" group)
      (concat group "INBOX")
    (replace-regexp-in-string ":\\." ":" group))))
(defun lld-notmuch-goto-message-in-gnus ()
"Open a summary buffer containing the current notmuch
article."
(interactive)
(let ((group (lld-notmuch-file-to-group (notmuch-show-get-filename)))
      (message-id (replace-regexp-in-string
                   "^id:" "" (notmuch-show-get-message-id))))
  (if (and group message-id)
      (progn 
  (switch-to-buffer "*Group*")
  (org-gnus-follow-link group message-id))
    (message "Couldn't get relevant infos for switching to Gnus."))))
(define-key notmuch-show-mode-map (kbd "C-c C-c") 'lld-notmuch-goto-message-in-gnus)

Wrap-up This setup can be replicated on several computers, of course. I have it on two, and there's no reason I couldn't have more. The flags do get propagated back and forth, including the Gnus-specific expirable flag. Accessing the local Dovecot is much faster than going through the DSL to the master IMAP server, and I'm pretty convinced that OfflineIMAP and its multi-threading is also faster than Gnus is, even talking to the same remote server. The email searching with Notmuch is a nice bonus, especially since they're fast too (and this despite my 8-year-old computer). There are a few minor glitches. I can live with them, but I should let you know anyway.

• offlineimap.el keeps an OfflineIMAP process running (if using autorefresh), which causes Emacs to complain about when you want to exit.
• OfflineIMAP propagates the new folders from the remote server to the local store, but not the other way round. Folders created from Gnus won't be propagated, so they'll only be visible on one computer.

Apart from that, I'm pretty happy with this new setup. So I hope this documentation will be useful to others, so I can spread the happiness around. Send your thanks to the authors of the software involved (Gnus, Dovecot, OfflineIMAP, offlineimap.el, Procmail, and so on). Let's see how many years I'll keep that system!

... or, 'yellow pages.be'. Or something. I like it that there is an on-line version of the Belgian yellow pages. Who wants to look up a phone number in a huge book, anyway? And that's ignoring the fact that it isn't any good for the environment. I also like it that the yellow pages are now no longer distributed by default on paper. You can still get them, if you so wish, but you have to explicitly request them. Of course, searching an on-line database is also faster than flipping through pages until you find what you're looking for. What's more, you can limit your search to your location rather than whatever shops just happen to be in the version of the book that is distributed to your house. That makes it much more efficient, since rather than all thousands of computer shops in the whole province, you'll find the computer shops in your municipality. Or the ones that are in a radius around your address, if you choose that option. Rather, that would be the case. But for some unfathomable¹ reason, truvo, the company behind the yellow pages, decided to make the option that gets you the names and numbers of companies that serve your region, rather than companies that actually are in your region, as the default. And since there's really n o limit to what companies can enter as the 'region' they serve, you suddenly get a name for a shop hundreds of kilometers away when all you wanted was to find the closest grocery store. D'oh. 1 Yes, yes, I can guess that money has something to do with it. But whatever, that don't matter.

Ok, this happened, chromium-browser was removed from testing and will not be included in Debian squeeze. Some days ago (before the hard freeze) I contacted the release team and asked about a possible inclusion of Chromium 6 in squeeze. The main reason of this request is that in April there was at least one major refactoring of the SVG code (webkit). The internal webkit copy is too outdated in chromium 5, and backporting any future SVG security patches (and unfortunately the story says they are frequent) is very hard. I got no answer, and after one week of silence and the hard freeze announcement, I realized that chromium 5 is not supportable and decided to upload chromium 6 in unstable (It was already in experimental). I asked the Release Team to unblock chromium-browser 6.0.472.53~r57914-3 or remove chromium-browser 5.0.375.127~r55887-1 from testing. Well, after one hour they removed chromium-browser from testing. I failed, my efforts to get chromium in Squeeze were in vain. Debian failed, a modern and much appreciated web browser will not be included in our next stable release.

• Italian

Related posts:

1. Why would you prefer chromium-browser in sid over google-chrome
2. Chromium ready for unstable

It was back in July that I got my amateur radio license, and I haven t written much about it since. It s about time I do. I ve been really enjoying it. I am now wishing I hadn t put off getting into it for so many years. It s a lot of fun and promises to be a lot of fun for a long time. Why? I am frequently asked, What can you do with amateur radio? Yes, you can talk to people all around the world, but of course you can do that with the Internet. Talking to people all around the world can be done with no infrastructure in between, so that s a pretty neat feature, but not compelling to everyone. I have realized that the question is poorly-framed. I had asked that question myself for a long time and only recently realized that I was asking the wrong question. I think the better question would be, What makes amateur radio fun and a good way to spend your time? One thing I ve discovered is that the amateur radio community has an amazing sense of community. Hams, almost universally, seem to love helping out each other, whatever the task may be: setting up antennas, learning how to operate a radio, even fixing a flat tire. I ve seen this directly, and heard about it from others, time and time again. There s an excellent article out there by Nate Bargmann called Why I consider Amateur Radio an asset in my life that makes for good reading. There is a lot of fun in amateur radio. It was quite exciting the first time I talked to someone out of state, realizing that the piece of wire in my trees, and 100W of transmitter power, were all it took to get a message 700 miles away. And even more exciting when I talked to a person in Kazakhstan the same way. No satellites, no phone lines, no undersea cables just my antenna, his, and radio waves. Then there s the fun in talking to somewhat random people. It s not completely random, as I m only talking to people that have passed a test there are about a million of us in the USA. (And for the long-distance HF communication, a more rigorous exam is required, so the number is probably less than that.) But when I call CQ an invitation for anyone listening to reply I never know who will reply. I ve talked to a retired Canadian museum curator, a Mississippi farmer, a resident of Long Island, Russians participating in a contest, two Hawaiians participating in a different contest, and the list goes on. Some of these have been brief contacts lasting only seconds, while others have been conversations that stretch on towards an hour. I liken amateur radio to buying my first iPod. I had never owned a portable MP3 player. I had always figured, why bother? How often am I away from a computer or a CD player? But once I got one, I realized how nice it was. It was convenient to just store my entire library on there and not have to try to sync it across multiple devices. It was convenient to not have to carry CDs with me in the car, and to listen to music at places I hadn t tried to before. The same sort of thing applied to getting a Kindle, and to amateur radio. I didn t realize how much fun it would be until I tried. Some Memorable Moments Towards the end of showing you some things that have been exciting, here are a few memorable moments from my ham radio experience so far. Saturday night was one. I was tuning around listening to anybody to talk to. I heard some people calling CQ in heavy accents. I eventually realized that the All-Asia contest was going on, and figured out how to participate. I made my first voice-mode contact with people on a different continent and it was with Kazakhstan! Within a few minutes, I also talked with three stations in Russia. I had not expected that. I ve made contact with several stations in the Indianapolis area, where I used to live. It was particularly fun to talk to W9IMS, located at the Indianapolis Motor Speedway, which operates around race times only. Again I discovered that station simply by tuning around on the band. I took a 5W handheld radio with me to New York City during my trip there for Debconf. It was a lot of fun to talk to random New Yorkers while visiting, and they were all very interested in my impression of the city, what I ve done so far, and what they thought I ought to do. Some offered specific tips (such as which train from Manhattan to Brooklyn offers a good view while elevated). A local ham, W0BH, gave me some basic training on how to operate during amateur radio contests. During these contests, hams try to make contact with as many other hams in as many places as they can. I didn t think this sounded like a lot of fun. Until I tried it. It was indeed a lot of fun, and interesting being occasionally that rare Kansas station that a bunch of people are trying to talk to at once. One evening, we lost power. I tried calling the electric company, but there was no answer over there for some reason. We re out in the country, and there are no neighbors visible that can inform us whether it s a big problem that the power company probably knows about, or whether it s localized to us. So after wondering what to do for a minute, I thought I d get on the radio and ask. (We own a backup generator for these situations.) Almost right away I heard from a person driving in his pickup. He told me he saw a widespread outage, and heard on his police scanner about other towns that were down for the same reason. I wouldn t have known otherwise.

A few days ago I talked about how noisy my new Dell Studio 15 was but I can now report back with the beginnings of a solution to that problem, and it doesn't appear to be ACPI related. The first clue I needed was that if I switch to the proprietary fglrx drivers for the Radeon the fan quite quickly drops off to a much more reasonable level. It seems the fglrx drivers have issues, however, in particular I get big black patches on my screen. This video corruption happens especially in Firefox, but sometimes in other applications as well. They also appear to screw up my suspend/resume, which is probably even more annoying to me. The second clue that I needed was that Radeon power management support has only just made it into recent kernels. Thanks to Michael Kirkland for providing me with both of those clues :-) Looking under /sys/class/drm/ I find a whole bunch of stuff, but in particular there are /sys/class/drm/card0/device/power_method and /sys/class/drm/card0/device/power_profile. Looking through the kernel source code I can see that power_profile can be set to low, mid, high, auto and default, while power_method can be set to either dynpm or profile. Trying out all of these values, it seems I get the quietest result with the profile method and either the low or mid profile. The dynpm method is nearly as good, and I would think it should really be the default for a 'Mobility' chipset. From the detailed benchmarking that Phoronix did I wonder if it shouldn't be the default for everyone. For myself, I see some small 'tearing' artifacts occasionally when running with the low profile. These disappear when I run with the mid profile, and since that seems to have pretty much the same temperature (and noise) results I'll go with that one. Though the laptop often does still make more noise than I would prefer it to, it is no longer annoying everyone in the room. Not unexpectedly this seems to have a huge impact on power use, too. It appears that the laptop should now give me around 4.5 hours when I do everything I can think of to lower the power use, whereas before it was more like 2.5 hours. Now I guess I can get back to hacking on DAViCal...

C++0x has a workload of new features[2]... Today I'm having a look at lambdas. Lambdas are available in g++-4.5, for now only available in experimental. What are lambdas? You can think of it as something akin to a struct with operator(). But it's a more than that: it's closer from a closure, something that Scheme fans are very familiar with: the closure code block captures its outter environment in its body. Closures are a very powerful tool that are being retrofitted in many languages (for instance Java). They can be used as building blocks for many useful programing idioms such as continuations. Enough for theory, let's have a look at this new beast. How do they look like?

  [](int i)   return i + 1;  ;

This is the increment lambda. You can declare a lambda in any function or method. Written like this, the lambda compiles[1] but it's not very useful: it's an anonynous lambda that is neither stored nor used. How to read this? The square brackets open the declaration of a lambda. Then you declare lambda parameters and its body. Nothing suprising so far except for the declaration opening. Using a lambda To use it add arguments, for instance:

  [](int i)   return i + 1;  (0);

would compute the value 1. Storing a lambda The type of a lambda is automatically deduced. You can hint its return type if you need to. To store it you need to use another new C++0x keywork, auto, that was taken back from C:

  auto inc = [](int i)   return i + 1;  ;
  std::cout << inc(0) << std::endl;

Notice that calling a named lambda is not different from calling a function. If you need to hint the lambda return type you can use ->:

  auto mult = [](int x, double y) -> double   return x * y;  ;

Capturing environment You can use lambdas to capture outter environment. A more complex, not working, example:

  void f()  
    int x = 5;
    [](int w)   return w + x;  (0);
   

Tha lambda declaration + invocation does not work, because the x variable we're referring to is declared in the outter scope. To enable capture of the outter scope, we can rewrite the previous example like this:

  void f()  
    int x = 5;
    [=](int w)   return w + x;  (0);
   

The = sign in the square brackets (which are really the capturing clause) means we will copy every variable from the outter scope. Hence we can access x from our anonymous lambda. Now what if you want to change x?

  void f()  
    int x = 5;
    [=](int w)   return w + ++x;  (0);
   

This does not compile: the environment is read-only by default. If you really want to increment x then you need to write:

  void f()  
    int x = 5;
    [=](int w) mutable   return w + ++x;  (0);
   

Yes, mutable. The value returned from the lambda is what you would expect. But guess what? x value is not changed when the lambda returns. Indeed, we've copied outter scope variables by value. To really affect outter scope you need to change the capture clause:

  void f()  
    int x = 5;
    [&](int w)   return w + ++x;  (0);
   

We use the ampersand to capture the environment by reference, and thus we can change x value. We could also be more explicit about what we want to capture:

struct A  
    int z;
    A() : z(0)  
    void f()  
      int x = 5;
      [this, &x](int w)   z = w + ++x;  (0);
      std::cout << "x: " << x << ", z: " << z << std::endl;
     
 ;

The lambda in f() explicitely mentions environment variables which are captured by value: this, because we change this->z, and also the local variable x. Complete example It's easier to write functionnal-style code. As Sarah just said: 10 years from now everyone will realize how powerful functional programming is, then we'll be the masters of the universe!

#include <algorithm>
#include <iostream>
#include <vector>
int main(int argc, char* argv[])
 
  std::vector<int> v =   1, 2, 3  ;
  // Show then increment
  std::for_each(v.begin(), v.end(), [](int& e)   std::cout << e++ << std::endl;  );
  // Show content now
  std::for_each(v.begin(), v.end(), [](int e)   std::cout << e << std::endl;  );
 return 0;
 

[1] Use g++-4.5 --std=c++0x to activate C++0x mode
[2] More complete g++ C++0x feature list available here

After a bit of work, I got the sheeva plug working the way I wanted it to. First of all, I grabbed a spare 1G USB flash disk I had laying around and installed Debian squeeze to it by following tbm s instructions here: http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html After debian was installed to the USB disk, I removed it from the plug and used dd on my laptop to create an image of the filesystem. I mounted the filesystem as a loopback device and created a jffs2 partition image from it after doing a bit of minor tweaking. I placed the USB disk back in the plug and booted to it. Using this intermediate filesystem and the mtd-tools package, I wrote the new jffs2 image to the NAND mtd device. I then modified the uboot environment to suit, saved, and now have a working setup. Detailed instructions are below. pre-requisites Connect the plug to your network with the rj-45/cat5 cable. Connect a USB flash drive to the plug. I used a 1G drive, but 512M should be sufficient. Install the tftpd package on a machine on your network. You ll also need screen on the machine that you use to connect to the plug s serial terminal. I ll assume these are the same host. You need the IP address of the tftp server. In this example, we will assume that the IP is 192.168.1.2 and that you will assign 192.168.1.200 to the plug. $ sudo apt-get install tftpd screen Place uImage, uInitrd, and uBoot in the /srv/tftp directory: $ sudo wget -O /srv/tftp/uImage http://www.cyrius.com/tmp/beta1/marvell/sheevaplug/uImage
$ sudo wget -O /srv/tftp/uInitrd http://www.cyrius.com/tmp/beta1/marvell/sheevaplug/uInitrd
$ sudo wget -O /srv/tftp/uBoot http://wp.colliertech.org/cj/wp-content/uploads/2010/09/07/uboot.bin Connecting to the serial console We are now ready to boot the plug. Note that you have to be quick with the screen command. I recommend you type it out and get ready to press the enter key. You have to interrupt the bootloader in order to enter the u-boot console. Attach the power and immediately enter the following command: $ screen -S sheeva /dev/ttyUSB0 cs8,ixoff,115200 If you did this right, you should see a prompt like this: Marvell>> update uboot As per tbm s instructions, you can now update the uboot if needed. Instructions for that are here: http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html I ll put them inline here for completeness.

Marvell>> setenv serverip 192.168.1.2 # IP of your TFTP server
Marvell>> setenv ipaddr 192.168.1.200 # IP of the plug
Marvell>> bubt uboot.bin

be sure to answer n to the question about env parameters. Now reset the device. Don t forget to interrupt the bootloader so we can get back to the prompt:

Marvell>> reset

Let the device know that you will be running a mainline kernel and set the arcNumber:

Marvell>> setenv mainlineLinux yes
Marvell>> setenv arcNumber 2097
Marvell>> saveenv
Marvell>> reset

Install Debian to the USB disk Interrupt the boot process once more. We are now ready to run the debian installer. I ll leave the details as an exercise for the reader. The following should put you into the installer, which you are probably quite familiar with by now. NB: I will assume that you will use a single ext3 partition for the entire system. This will make it easier to build a jffs2 image out of the resultant partition on the USB disk.

Marvell>> setenv serverip 192.168.1.2
Marvell>> setenv ipaddr 192.168.1.147
Marvell>> tftpboot 0x01100000 uInitrd
Marvell>> tftpboot 0x00800000 uImage
Marvell>> setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most
Marvell>> bootm 0x00800000 0x01100000

build a jffs2 image Once the installation has completed, power down the plug and remove the USB disk. Put the USB disk in the machine you used to get the console on the plug and note what device the kernel assigns to it. In my case, it was given sdc, so debian is installed to /dev/sdc1. I will use these values for this example. If the filesystem was automatically mounted, unmount it. Create a disk image of the partition and mount it as a loopback device.

$ sudo umount /dev/sdc1
$ dd if=/dev/sdc1 of=/tmp/debian.img
$ mkdir /tmp/mnt
$ sudo mount -o loop /tmp/debian.img /tmp/mnt

You can now remove the USB disk and return it to the plug. Modify the /etc/fstab file. The root filesystem will be /dev/mtdblock2 and of fs type jffs2. My fstab file looks like the following:

proc            /proc           proc    defaults        0       0
/dev/mtdblock2 /               jffs2    errors=remount-ro 0       1

We can now create a jffs2 image from the mounted and altered fresh install:

$ sudo mkfs.jffs2 -l \
  -e 0x20000 \
  -X zlib \
  --eraseblock=128KiB \
  --pad \
  --output=/tmp/rootfs.jffs2 \
  --compression-mode=priority \
  -n \
  --squash \
  -r /tmp/mnt

write jffs2 to nand Now that we have an image to flash to the NAND, let s boot off of the USB disk. It should now be attached to the plug. Power on the plug and use screen to get a console. Interrupt the bootloader and enter the following commands:

Marvell>> setenv bootargs_console console=ttyS0,115200
Marvell>> setenv bootcmd_usb 'usb start; ext2load usb 0:1 0x01100000 /boot/uInitrd; ext2load usb 0:1 0x00800000 /boot/uImage'
Marvell>> setenv bootcmd 'setenv bootargs $(bootargs_console); run bootcmd_usb; bootm 0x00800000 0x01100000'
Marvell>> run bootcmd

Log in as root with the credentials you configured during the install. You will need to install a few packages in order to complete the nand flash. You can then ssh to the host on which you created the jffs2 image and cat it to stdout, piping this to nandwrite:

$ sudo apt-get install mtd-utils
$ ssh user@192.168.1.2 cat /tmp/rootfs.jffs2   sudo nandwrite /dev/mtd2 -p -

You now have a jffs2 image on the nand. Configure u-boot One more reboot to set u-boot s environment, and you will be done. Power down and remove the USB disk. Power on and get the serial console using screen. Break into the bootloader and enter the following commands:

Marvell>> setenv bootargs_console console=ttyS0,115200
Marvell>> setenv mtdpartitions mtdparts=orion_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)
Marvell>> setenv bootargs_root root=/dev/mtdblock2 rw rootfstype=jffs2
Marvell>> setenv bootcmd 'setenv bootargs $(bootargs_console) $(mtdpartitions) $(bootargs_root); nand read.e 0x00800000 0x00100000 0x00400000; bootm 0x00800000'
Marvell>> saveenv
Marvell>> reset

You should now be good to go.

I started to give flattr a try, too. It is a social micropayment site and the similarity of its name to the verb flatter is on intention. It is meant to say thanks in small amounts month by month to "things" you like. One such thing I created is my blog you can find the link to it below every entry. To be able to flattr someone one needs to create an account on the site and put money into their account. After that it's possible to follow the flattr button links. If you are reading my blog on my site and have JavaScript enabled you just have to click the flattr part of the image (not the number) to do so. If you are reading it through my feed or with JavaScript disabled you will have to click a second time on the flattr site to make the flattring happen. Another thing I've created is Debian BTS: cleaning up. I use this link in my mails to the Debian BTS for my stable RC cleanup efforts, or general proper closing of bugs that aren't getting archived. Through the help of UDD I've created me helpful overview pages of bugs that need attention for this. The third thing I've created is Package Maintenance. If you are a fan of one of the packages I maintain and want to thank me for taking proper care of it, feel free to also click this one. Please be aware that this shouldn't be seen as an Upstream appreciation if one of the projects I package for Debian uses flattr themself then you should definitely (also) consider flattring them for their own. About Upstream projects that use flattr: One of the packages I invest quite a lot of effort into started using flattr: wesnoth. They have put the flattr button on their entry page at wesnoth.org, here is the direct link to their first and general thing: The Battle for Wesnoth. Please be reminded that the things you did flattr in a previous month can again be flattred the next month. This is especially true for general purpose things like what I am using currently. Others might create things for every single blog entry, or very specific tasks, to allow people to flattr them more often in a month and get a bigger share of the cake. So keep in mind which things are general ones and consider returning to them. Enjoy!

/debian permanent link Comments: 1

This summer of 2010 has been memorable. It started with a difficult period following the hospitalization and death of my mother, a series of very intense and equally memorable conferences catapulting me out of my funk and ending with a trip to Ireland, perhaps one of my most pleasant trips ever. I have always wanted to go there, as I have some good Irish friends and I was also quite attracted to the place due to its history, so when the opportunity came for me to go, I did not hesitate to book my ticket. I was not left disappointed in any way, shape or form, although since I barely experienced the gray, misty, and rainy weather Irish is famous for, my experience may admittedly be a bit skewed. These are some of things I did and some of my fragmented thoughts about Ireland and some photos, proof that the weather was UnIrish Ireland and The Irish: Well I can t as no one can speak of The Irish as if they were some unitary group but I did learn a lot about Irish history and managed hang out with a number Irish folks (even a family) and one thing that seems to mark Ireland as distinct, what makes it stand out from the rest of its Western European brothers and sisters, is the pervasive sense of history bleeding into the ambiance, perhaps because it is so tragic. The short version of the history, if you don t know it, is that the Irish, especially the Catholics, got repeatedly screwed by the British monarchs/rulers/planters/government/ for nearly a thousand years, the last five hundred of those being particularly harsh and ugly, a cycle of slight gains crushed by various forms of tyranny and violence at least until part of the country achieved independence (Northern Ireland is a bit of a different story). I may have gone a bit out of my way to learn about Irish history, more than I have done for any other place, but this historical consciousness seemed to be inescapable, precipitating into all sorts of conversations and places. To take one example, I went to see Gaelic Football, one of the two beloved national sports (the other being hurling), and the minute you learn anything about this sport, you learn that it is intimately bound with the Irish fight for independence and nationalism. The Irish are also very warm, kind, and outgoing. They also seem to curse an awful lot as well, so much so cursing is a bit of a national pastime, which yes, I (f*cking) loved as I tend to have a bit of a foul mouth myself, curbed I will admit, in recent years and in the classroom. It crept up in a lot of places but was most pronounced during the All Ireland Semi-Final Gaelic football game when the ladies (not lads, mind you) behind me were constantly yelling at the referee, hurling the c-word (rhymes with trunk) whenever they made a call they disagreed with. EASA/Maynooth.: I went to Ireland to attend the largest Anthropological meetings in Europe, and in specific an all day panel on digital anthropology, which seemed like a great opportunity given we are a a bit of a minority. The conference was impressively large with roughly 1200 attendees (can you believe there are that many anthropologists?), smoothly run, and the all-day panel on digital media was quite lively and I got to meet some really interesting folks. I was a tad sad to find out Maynooth is the only university in Ireland with an Anthropology department (for crying shame lads!!!) but at least it is located in a darn stunning university: the old quarters of the campus are strikingly beautiful. Anonymous: I have done some work on Anonymous and well when I found out there was going to be a raid/protest at the Church of Scientology (a pretty dismal, and run down church), I got in contact with Irish anon to let them know I was coming. Although someone first decapitated me (at least in character with their norms, right?), when I showed up in person, they were not only civil but really quite hospitable (greeting me with one of my favorite songs). Overall it was a great day. I was reminded of important differences among Anons (Irish Anon s take their anonymity pretty seriously, the New York Anons do not) and also good to experience the social life and metabolism of a protest, especially one attended by folks who have lost family to the church. Dublin: Since I stayed with my friend and his family in Dublin, this is where I spent most of my time. I was able to hook up with various friends, including one from graduate school who just got back from years of fieldwork in Rwanda and hearing about his experiences and stunning but stunningly sad project made me feel like mine in comparison was Child s Play (in fact, it really was). I got to see the Debian crew (many who work at Google) and I finally paid a visit to the office, which was exactly how I imagined it to be (good and abundant food, good lighting, lots of toys and bikes, lots of Star Wars posters.. Yep, it could have been in Silicon Valley). But I was surprised at the young age of the marketing and sales folks who were hanging in their lounge when I ran into them. In fact when I saw them I thought like I was looking at my freshman class or something! It was great to see the Debian folks (though no one I met was actually Irish), as well, one of my favorite things to do whenever I visit a foreign city. I walked my heart out in the city getting a blister in a shoe that I thought was blister proof and while not as picturesque as some other European cities, it has a ton of character and no shortage of Guinness and pubs (no surprise there). My favorite places/things were: The National Library (great exhibit on Yeats, but make sure to use the multi-media as that is where all the information is stuffed), St. Stephen s Park (overflowing with chubby ducks and lovely flowers), the prison Kilmainham Gaol (would not advise a visit if you are feeling in any way down, there is some heavy shit you learn during the tour), the simple stained glass that seemed pretty common, and finally the Long Room in Trinity Church, which you enter after the Book of Kells (I realized just how much I adore books when I visited this old library stuffed from floor to ceiling with old old old books). The West Coast: I did not think I was going to head out west but after hurricane Earl started its burst along the eastern Seaboard and I was able to change my ticket for free so I stayed a few more days. I went to the Burren and the Cliffs of Moher both totally stunning, really majestic. As is often the case with these type of these natural wonders, I am often left elated and awed but such strikingly wondrous places also seem to subsequently spur a more melancholic state of mind and heart. Friends, Family, and Dogs: While in Dublin I stayed with my friend A. and his extremely hospitable family, which included, a brother, a father, and three Irish mutts, one of which, Buster (pitt bull/lab mix), pretty much stole my heart. Buster s true love, is food, so much so he almost poised himself to death a little while back snorting down something he shouldn t have costing the family a pretty penny to save him. My friend no longer lives there but came from Berlin and it was a real treat to not only spend days layered upon each other with a friend (it has been an awful long since I have done that outside of conferences) but also meet his family. You learn a lot about your friends that way and in this case, there is some serious and I mean serious intellectual jousting that happens, sometimes bordering on warfare but generally it plays out in more contained, civil and fascinating fashion. Now I understand why my friend is armed with seemingly endless knowledge: it was needed for purposes of defense at home. So in essence, a great, great trip and a fantastic way to end a memorable summer and transition into what I hope will be a bit of a monkish (I call it monk mode) period for this academic year. I am (so so so) fortunate enough to have a fellowship at the Institute for Advanced Study and am going to try my darnest to take advantage of the fact I am not teaching (Hell Yes!) and hide away and accomplish all that I have set out to do.