Bernd blogged about the new version of gimp-plugin-registry he packaged, which includes the cool new GIMP Liquid rescale plug-in which I had to try out. It really rocks, though it is much slower than in that video.

Anyway, backports for etch are available at "deb http://layer-acht.org/debian etch backports" Those are simple rebuilds of gimp-plugin-registry and opencv.

If you replace backports with xorg or xorg-experimental you'll also find rebuilds of xorg for etch, either from lenny or from experimental. They are slightly outdated (built two weeks ago) and need to updated against the newer sources, but they work for me.

After Argentina-France on the first day, that one was planned to be one of the few big matches of first round. Of course, after the game won by South Africa (36-0), that seems pretty silly to say... The Springboks were definitely better than England, in all parts of the game. What stunned me, particularly after watching South Africa live , is their complete control on the game, which is a great improvement over their match against Samoa. South Africa scored three tries all of them great examples or organized attacks by the rear lines. Two tries for JP Pietersen, after 3 by Habana on first game: the South-African wing players rock. Despite this, the player of the game was definitely Jason Du Preez, the scrum half (hope this is the correct term in English) who organised all attacks from RSA. England was missing too many key players (several injured) to be able to be a menace for South Africa. They never were really dangerous, except maybe when the magic Jason Robinson has the ball in his hands (what a player!). I was particularly disappointed by their center back players, and even more particularly by Farrel. Ditto for Andy Gomarsall as scrum half. So, South Africa is now probably qualified with two quite easy games against USA and Tonga. England will have to fight to qualify and noone can tell if Samoa or Tonga can surprise them. Watching Samoa-Tonga on Sunday will be interesting and Samoa-England or Tonga-England are already key matches. A great rugby week-end is about to begin, again. Today, Wales-Australia is the match of the day, for sure, with wales playing home (some matches are not in France, but in Cardiff and Edinburgh). New Zealand-Portugal will be...interesting, though the only incertainty is the number of scored tries. And finally, Ireland-Georgia is of some interest for the French. Tomorrow, France could have hard times against Namibia. Of course, the challenge here is winning *and* scoring the bonus point. That match is 5 days before a key France-Ireland, so the challenge is also not wasting too much energy. Of course, tomorrow's top match for me is Samoa-Tonga while I whileprobably skip Fidji-Canada (too bad, I haven't seen those playing yet). BTW, if someone has a recording of the most intense match as of now (Japan-Fidji), I'd be delighted. Rugbystiquement v tre,

It’s a common story. A housemate starts torrenting some American television series of dubious artistic quality and/or legality, or perhaps starts calling their girlfriend on some fluffy non-free privacy invading spyware and your SSH sessions start to lag. Why does this happen? When the upstream channels become saturated, data must overflow into the modem’s buffers. This causes TCP acknowledgement (ACK) packets originating from your SSH client to be delayed, resulting in an increase in the overall round trip time. This phenomena is usually worse on cable connections as their modems’ buffers are generally larger. Avoiding the problem can be pretty simple — limiting your upstream bandwidth just below its maximum helps, and some smarter solutions involving prioritising ACK packets work even better. Although these are best achieved at your router, a number of applications have their own limiting features: every BitTorrent client will have one, and other tools such as scp (via the ‘-l‘ option) have them too.

Since the policy of the Debian planet is to not restrict content to Debian-related stuff, I switched the URL of my feed in PlanetDebian to include any English content that I might blog about. Don’t be afraid, I’m not going to overwhelm you with random crap. I’m currently trying to blog more in French instead. Since I maintain the French Debian planet, I decided to apply the same policy for the French version (and announced it here). At the same time I also created a planet for the French-speaking Debian users who happen to blog… it’s hosted on the same server at http://planet-fr.debian.net/users/ and its policy is a bit more strict as it only allows free-software related content. For all those reasons, I recategorized my articles so that I can now provide an english-only feed and a french-only feed. The first one is used on planet.debian.org and the second one on planet-fr.debian.net. Continuing on this blogging frenzy, I upgraded Wordpress to the latest version, I installed the subscribe-to-comments plugin and translated it to French. Thus it’s now possible to have a sane discussion in the comments of my blog articles!

Scientific papers always have a “related works” section, where the authors describe how the work they are presenting compares with what others did. In the Free Software world, this is nearly non-existent: in a way, it seems that many of us are thinking of their projects as competing products, fighting for market share. On a project web page, I would love to read something like:

This project is particularly well suited if you want XX. But if YY is more important to you, you might want to have a look at ZZ.

Or simply links to similar projects for other environments, etc. All in all, I think that the goal is to improve the global satisfaction. Not to win a few users, who won’t be totally happy, because the project doesn’t really suit their needs. While some projects cooperate and share ideas, like I think desktop environments do inside freedesktop.org, most just ignore each other. I am both a Debian and an Ubuntu developer, and I’m sometimes amazed that Ubuntu discusses technical choices that were discussed (and solved) a few weeks earlier in Debian. And it’s even worse with the other big distros out there. Couldn’t we try to improve this ? We could just create a mailing list, where developers from various distributions could present the way they do things. This would allow to discuss future developments (”We are planning to improve this, what are you doing about that ?“) or simply to improve people’s knowledge of the various distributions. Of course, this could easily turn into flamefests, but they are technical ways to avoid that, like moderating posts from trollers… Does something like that already exist ? Do you think that it would be interesting ? Would you like to contribute to such a forum ? Some examples of things that could be discussed:

• How many packages do you have, and how do you support them ? Do you have several “classes” of packages ?
• How do you manage your releases ? Goal-based ? Time-based ? Bug-count-based ?
• Which kind of quality assurance do you do ?
• How many contributors do you have ? Are they split into different “classes” ? Who has “commit rights” ? Can you give out “commit rights” restricted to subsets of your packages ? A organized sponsorship system for people who don’t have commit rights ?
• etc, etc, etc.

gimp-plugin-registry 0.3.1-1 Some hours ago the new 0.3.1-1 version of my gimp-plugin-registry package was uploaded to unstable. Thanks to Ari Pollak - not only for sponsoring the upload, but also for asking me to include the GIMP Liquid rescale plug-in, which is one of the most amazing plugins I've ever seen for The GIMP. If you have no clue what 'liquid rescaling' means, here's a YouTube video for you (if anybody finds a non-flash version of that video in the net - please let me know and I'll link it): (http://www.youtube.com/watch?v=6NcIJXTlugc) And again, if you'd like to see a plugin included, please let me know.

or why I need to start prioritizing ACKs...

Homebank has had a few problems getting through NEW due to legacy problems from the original Amiga version (and it isn't ready yet) but I've been trying it out anyway and comparing to gnucash. Bearing in mind that I have done upstream work in gnucash (i.e. I like gnucash enough to tackle the massively scary gnucash source code) and have (almost) got used to the regular dependency hell that it imposes on my sid installation, I'm finding homebank quite friendly.
(See #441110, #441103, #441129 and #441363 for recent examples of gnucash causing dependency hell - again.)
(1:0 to Homebank).
Homebank is closer to the Quicken model with categories but internal transfers between accounts are supported to give some impression of double-entry. (1:1) My main interest is in data import/export because I've long been looking for a way to create invoices from PIM data e.g. in a Palm Pilot or similar. Homebank supports a CSV data import for data that can be handled as an invoice. OK, there's no fancy invoice printing but that doesn't bother me (I never used the gnucash invoice print support) (2:1 to Homebank) - my invoices are all electronic and I have to use the client system (MSDOS!). What I need is to create my own records of the invoices within my financial accounts and Homebank may be able to do that with far greater ease than gnucash. My data exists primarily in my Palm because I take and change my bookings on-the-move. I want to be able to HotSync my Palm through a query interface (pilot-qof) and XSL (datafreedom-qsfxsl) direct into a financial application that can correlate that data with the payments made into my bank by the client and thence with data from my bank statements to prepare data suitable for my tax report.
I'm thinking that if I can get half of the ease-of-use of Homebank into the rigorous double-entry support of gnucash in a small program (gpe-cash), I'll be doing very well.
One limitation of Homebank is the "wording" - the translations appear awkward and unfamiliar but that can be easily fixed. The link between "Archives" and "automated transactions" isn't clear - I think it means "templates" and "scheduled transactions". (2:2)
Homebank can't do all the things that gnucash can do but that is a weakness in gnucash, not homebank. (3:2 to Homebank) IMNSHO, GnuCash tries to do too much and that leads to an oversized and overly complex codebase as well as a dependency list that puts OOo to shame. The graph support in homebank is a lot better than gnucash and that is not the fault of libgoffice, it is entirely down to the choices made by gnucash upstream developers. Homebank graphs are fast, simple, intuitive and informative, displaying useful info at the first attempt instead of having to wade through the Options dialogue in gnucash. (4:2 to Homebank).
If I can work out some simple scripting that combines these external tools into 'HomeOffice' support in Homebank, everyone wins.
I've never liked CSV as a data format and the homebank main files are XML (like gnucash). Unlike gnucash, the XML appears sane and usable for XSLT - raising the prospect of creating reports directly from the homebank data files.
Homebank upstream have been very supportive of the various requests to assist getting Homebank through NEW so I'm hopeful that if an XML import/export method was proposed it could be included in future - especially if the donkey work is done by external tools.
This would tie in well with datafreedom-qsfxsl and datafreedom-perl. Initially, I'll look at XML->CSV - ugly, I know but at least Homebank can import data to be used as invoices; gnucash cannot. (5:2 to Homebank).

At the end of round one:
Homebank : 5 GnuCash: 2.

Given that Hecl is very much tied to the Java ME platform, this question is pretty important to me. I was thinking about simply posting it here, on my line journal, but having recently started reading The Wisdom of Crowds, I decided to have a little fun with it, and created a "prediction market" on the Inkling Markets (a YCombinator startup) web site: http://home.inklingmarkets.com/market/show/6481 Of course, if you just want to comment on your answer, that's ok too. My thoughts on the current possibilities:

• Java ME. Widely available right now, but Sun has made a few false steps. For instance, the difficulty of writing something that runs everywhere is a high barrier for hobbyists or small companies.
• JavaFX. Apparently, this exists because Java is seen as being not quite scripty enough to compete with dynamic languages, something that I think is a legitimate concern. However, it currently is not deployed, so it's hard to say what its future will be.
• Web/Javascript. If mobile phones get better/cheaper connections, it would be easy to see them going the way of the rest of the world - rather than native applications, they'd simply be html/javascript apps. Doesn't work for games and some other things, but makes deployment very easy. The big if is the network operators and what they want to do about traffic costs. Apple, for the moment, seems to be taking this route.
• Python. Currently available for Symbian. I don't see it as a big possibility, but who knows.
• Qt. Troll tech is currently shipping a development device, the "green phone". Since it's proprietary, this one seems like a long shot too, but you never know.
• Other. GTK on Linux, Tcl/Tk... maybe even Hecl! In this field, things can be tilted upside down surprisingly quickly, although that's not quite so true for anything involving physical devices.
• None. Java ME becomes less popular, but nothing concrete supplants it, and we end up with a hodge podge of technologies, with no clear leader.

In any case, I think it's a space that's bound to be very interesting, and loaded with interesting possibilities. Update YC.news user jsjenkins points out a silly oversight on my part: Flash Lite. It slipped my mind completely, but is certainly an important player in this market. The Java folks have to be hoping that history will not repeat itself.

winpdb - a platform independent Python debugger A few minutes ago a mail arrived which told me, that my winpdb package migrated to testing, which was just another reminder to blog about it. winpdb is not just yet another Python debugger, it is actually the first really well working one I've used so far. One of my favorite features is the embedded debugging, which allows you to debug scripts which are embedded somewhere. I still have to try it with a Zope product, though - I'm really wondering if I could embed the remote debugger in there. That just brought us to another very useful feature - winpdb is a remote debugger. It connects to the real debugger (called rpdb2) using an encrypted and password protected tcp connection, which allows you to run rpdb2 under a totally different user, probably on some embedded box somewhere on the other side of the world. If you don't want to use a graphical frontend, rpdb2 is able to run the debug sessions in a 'screen' window. Although winpdb doesn't ship much documentation, it is very well documented. And in case you don't like winpdb or wx - pida ships with a debugger plugin which is in fact a gtk frontend for rpdb2. The following quote is part of a mail from Nir Aides, the author of winpdb. Although it may be biased, I think it'll probably give you some ideas in case you want to compare winpdb with some other common (commercial) debuggers. He kindly allowed me to quote it here:

I have just spent a couple of hours (instead of doing some real work…) with the commercial Python debuggers of Komodo IDE 4.1 and Wing IDE 3 beta, and (without declaring objectiveness) Winpdb seems currently better than both in several important areas:

* It is the only one of the three to support os.fork() (wingide debugger crashes)

* It handles thread debugging best in many aspects (e.g allows inspection of threads that are still running, stays with the correct thread when stepping, general usability, etc…)

* Its name-space browser is the most consistent and stable (in particular with describing class inheritance, very large objects, sets!)

* It is the only one that prevents breakpoints in invalid lines (Komodo does not care at all and Wing allows setting breakpoints inside remarks and thus possibly in other invalid lines). This is important since in Python it is sometimes surprisingly hard to tell (by looking at the source code) which lines are valid for breakpoints.

Not to forget that winpdb supports debugging of curses based applications, namespace modification and the coming version is supposed to have full unicode support. Happy debugging!

Today was the day we had tickets for *the* match of the day between South Africa and Samoa (59-7). Of course, the Springboks won this game after the Samoan players were exhausted of their battle after 60th minute. However, we really enjoyed a great game during 1st half (21-7) with solid play by RSA (without great vista, as usual, but, well, I'm not a Springboks fan) and ultra-solid defense by Samoa. And, well, as long as the Samoans have the ball in their hands, everything can happen, especially with Henry Tuilagi, impressive number 8, which has been acclaimed by the Parc des Princes public when finally quitting the game on 60th minute. Three great moments in the game:

• The Samoan try by Gavin Williams who made the whole Parc stand up and shout
• The Samoan team spending 10 terrible minutes in RSA camp, unfortunately without scoring but being pushed by 43000 people in the stadium (ie the 44000 attendants minus about 1000 South-Africans...), yelling out "Samoa" even though probably 99% of us aren't able to even point Samoa on a world map.
• The standing ovation of the public to the Samoan players at the end of the game when they came back and thanked us for the support

South-Africa is however much more organized, of course, and their attacks were terribly devastating sometimes, with Bryan Habana scoring 4 tries. They're however a little bit hesitating with the ball in hands and their defense wasn't *that* impressive. While writing this, I'm watching Scotland-Portugal (56-10) as we came back from the Parc des Princes. This game happens in St-Etienne, my home town. I imagine the noise and feast in town, where we still remember a famous Scotland-Morocco during Soccer WC 1998. Apparently, the Scots like St-Etienne. Apparently, Portugal resisted during about one half and they even scored a try and sometimes endangered Scotland. Good game by the Scots who can hope to qualify for 1/4th finals. Tonight, Ireland-Namibia. If we aren't too much rugbyfied, I'll watch even if the result is quite predictable. Both teams are in France's pool, so watching team will be interesting. And even now, 2h before the game, there are 25.000 Irish people in Bordeaux. Probably interesting noise over there. Another match today, which I didn't watch because we were on our way to the stadium: Wales-Canada (42-17). Canada was leading 12-7 on half-time and even 17-7 on 45th minute. So, well, not very brilliant for the Welsh. Finally, their most experienced players came back (S. Jones, Gareth Tholas and Collin Charvis) and they easily came back and overscored Canada...who never resigned and were very close to score again at the end of the game. Brilliant day and, believe us, watching rugby *in* the stadium is really a great experience (we don't do this often enough...).

mod_wsgi 1.0 Yesterday the official 1.0 version of mod_wsgi was released and uploaded to unstable (the binary package you want to install is called libapache2-mod-wsgi, in case you were wondering), so I think it's a good time to blog about it. Mod_wsgi is an Apache module which can host any Python application which supports the WSGI interface (the reference is also available as package). Major applications and frameworks which are known to work well with mod_wsgi include CherryPy, Django, Karrigell, Pylons, TurboGears, web.py, MoinMoin, PyBlosxom and Trac. In fact every application which provides a WSGI compatible interface should be able to be hosted with mod_wsgi. The module is very simple to use, is very well configurable, documented, has a very active and responsive upstream author and is suitable for use in hosting high performance production web sites, as well as your average personal site. There are two common ways of operation:

• Embedded mode - working in a way similar to mod-python: The Python code is executed within the context of the Apache child process.
• Daemon mode - similar to FASTCGI/SCGI solutions, but with the important difference that a separate infrastructure is not needed when implementing the WSGI application and everything is handled automatically by mod_wsgi. Of course this mode has a smaller impact on the normal Apache child processes and also allows to run applications under different users.

If you're running python web applications which provide a WSGI interface: go and give mod_wsgi a try! ~~DISCUSSION~~

Perhaps this conversation is a sign that we've been in the country for awhile:

"Terah, if you ever drive the pickup..."

"Why would I ever do that?"

"I don't know, but if you ever do, I just want you to know something. The reason there's a towel connecting the brake pedal to the steering wheel..."

At this point I had to wait for her laughter to die down.

"As I was saying, the reason there's a towel connecting the brake pedal to the steering wheel is that, unless you park facing uphill, the brake lights stay on all the time and will drain the battery."

More laughter followed.

I didn't even have the chance to tell her to remove the towel before she starts the truck. Oh well, guess she'll figure it out.

On the other hand, perhaps this is a sign that we haven't been in the country long enough:

Today as I went to lunch, I saw a long, narrow, light gray line across the door on my car. I was pretty annoyed that somebody would have pulled keys or something across it to do that. But as I got closer, I realized it was just a spider web. Terah and I park our cars a few feet apart, and every week or so there will be a spider web connecting the two of them when we go out in the morning.

Today, I spent the entire morning working on the iso-codes package. This package features, among others, the giant ISO-3166-2 list, with all subdivisions of all countries of the world, thus about 4000names. Alastair McKinstry built this list long time ago, from various sources, as the ISO-3166 maintenance agency, does not provide the official list freely. Therefore, the work we (Alastair, Tobias Toedter, Li Daobing and myself) are doing on iso-codes is of some importance as this is the only freely available list of ISO-639 (language names), ISO-3166 (country names and subdivisions) and ISO-4217 (currency names) available in a machine parseable format, along with translations in a lot of languages. We are indeed upstream for that list which is used in many Linux distributions. So, today, I went on the ISO-3166 maintenance agency newsletters (*these* are freely available) and used them to update the subdivision list for as many countries as possible. That involved *copy and pasting* from PDF files to text files so that names are preserved along with the correct various funky characters used in many languages. You can help this work. Just install the "iso-codes" package, then check /usr/share/xml/iso-codes/iso_3166_2.xml for your country and report anythink you consider being a problem as a bug against the iso-codes package. Please note that the ISO-3166 MA only uses official references from the national standard bodies of all countries, so please use official sources as your reference. Of course, patches are very welcomed because dealing with all these names without messing with the "funky characters" is not easy. Please also note that the ISO-3166-2 standard uses "romanized" names, so only Latin characters should be used (all variants of such characters are accepted, though). My conclusion of the day: the world is bloody complicated. There are even subdivisions (named "castles") for....San Marino, one of the smallest states in the world. Luckily, the Holy See (the reall smallest state in the world), doesn't seem to have subdivisions...so far. And the country with the highest number of official subdivisions is....Slovenia (184!).

debconf7 flashback Somehow I didn't find the time to blog during the last weeks, so there's a lot of stuff on my blog todo list. But let's start with a little flashback , back to Debconf7 in Edinburgh. Yesterday I got a film back from the lab with photos I've taken during the daytrip-day. As a few of you probably realized I was not on the train/boat to the island in the west, mainly because Andreas (afit), Julian (codemonk) and me decided to spend the day in Ediburgh, not only for some geocaching fun but also to see a bit more of this beautiful town and area. We've also been up on Arthur's Seat, Edinburgh, where I took this panorama: It will be published on placesofinterest.info, which is currently in public beta state, but definitely worth a look (just don't use IE, but I doubt you use non-free software, right?). I'll blog more about placesofinterest.info as soon as the page is finished. As usual, the pano was created with the help of The Gimp, hugin and enblend. The only commercial software involved was the software for the Imacon scanner at university. Original resolution: 24044×2551 pixel, stitched from 14 slides. If anybody is interested - large format prints for Debconf participants are available for the cost of paper and ink.

The Belgian Navy recently acquired a new frigate, baptized the Leopold I; and it's leaving soon on a training trip. The TV news just had an interview with the captain of this vessel, who declared that the function of a frigate is to protect "other vessels"; one of the examples he gave was "a carrier vessel". What he neglected to mention is that the Belgian Navy, in all her glory, doesn't have any carriers. In fact, it doesn't have any ships that are larger than frigates. But hey, at least this frigate has a helicopter pad, so maybe it qualifies. Then again, maybe not.

Russell thinks that trading emission "rights" individually would decrease emissions. The global emission market has shown quite the opposite happening, countries that have no industry and did not contribute to the problem now sell their rights to industrial countries, with the net effect being as if all these countries suddenly became industrialized over night. I don't think anything different would happen at an individual level. The fundamental problem is this: emission rights trading happens only when buying rights is cheaper than actually reducing your emissions. When this is relatively cheap, you remove any incentive to develop better processes in individual companies; if it is more expensive, most industries will remain at the status quo (no emission trading) while those where it still makes sense fiscally now have an alternative, which diminishes the market for technology companies specializing in filtering technology and process optimization (i.e. it becomes even more expensive to behave environmentally conscious). At the same time, the cost of buying these rights from individuals will be passed on to the consumer, the only way to get this money back will be to sell off their emission rights. From a macroeconomic perspective, no money ever changes hands, but you have effectively transferred the individual emission rights over to the industry. Looking at individuals, you are penalizing those that behave environmentally conscious and neither use their "rights" nor sell them. So, emission rights trading is a really bad idea.

I had been intending to write an entire series of posts about our corporate switch to Linux on the Desktop. To date, I wrote only one introducing the project and our reasons for switching from Windows. That was back in April.

Today I'd like to start talking about it all some more.

We have standardized on Gnome for our desktops. Given the Windows background of our user base, it was pretty much a given that we would have to use either Gnome or KDE. Something like fvwm or a non-integrated environment just wouldn't be a good option.

We evaluated both Gnome and KDE. The very "clean" appearance of Gnome was a nice thing for us. KDE seemed to be to "chatty", talked about entering in audiocd:/ when it shouldn't have needed to, and generally violated the KISS and principle of least surprise too often. That said, I continue to run KDE for my personal desktop because Gnome just doesn't have the flexibility that KDE does. It is too bad that Gnome has gone on this remove functionality kick, and KDE hasn't gotten the KISS religion yet.

Anyway, Gnome worked well for the most part. We have set some defaults in gconf for things like panel icons. We also set a few mandatory defaults. I fixed a couple of bugs in the vfs system related to nfs4 support, which manifested themselves as icons for files newly saved to the desktop never showing up.

We wanted to present a customized menu to people based on what their job function is. That is, we are using a single system image, so all apps will be installed on all machines. But we didn't want people to have to see a ton of software that they don't use. That was easily enough accomplished for custom apps by creating desktop files with mode 0640 and setting the group to the set of people that should see the program on their menu. We removed a few stock programs (such as the terminal) from the menu as well, using dpkg-statoverride. That was also quite easily done. However, I will say that the entire Gnome XDG menu thing is woefully under-documented.

We use Firefox for the standard web browser. It is integrated well enough with Gnome and we have no problems there, aside from sites that are IE-only. We solve that with a Windows terminal server, which I'll discuss later.

Our network printing was already based on Cups. The individual machines are set up as Cups clients only, which works fine. We did find, however, that gnome-cups-manager automatically installs a tray monitor for cups. This monitor puts little printer icons on the tray when printers are in use. Unfortunately, it figures out which printers are in use by polling the server, and it is turned on by default out of the box, with no good way to disable it short of dpkg-statoverriding it to 0000. You can imagine that hundreds of users times dozens of printers times numerous polls per minute created quite the load on the server. This was a really braindead design and the people that wrote it should have known better. It is also quite useless to have icons coming on for all the printers on the network, which on some networks could be thousands, and not even on the same continent as the user.

Printing is generally a bit iffy in Gnome. They seem to be transitioning between about 3 different printing toolkits, all of which have different print dialog boxes with different supported features and different ways of selecting printers. One chief annoyance is that the print box in evince (the document/PDF viewer) does not let people access printer-specific features such as hole punching and stapling. So we installed gtklp and xpdf for people. The people that print heavy PDFs are huge fans of gtklp these days; it's a nicer solution than we had in Windows. Nobody really likes evince. We also have had some trouble with evince generating PostScript output that some printers can't grok. It sounds like all this should be much better in newer versions of Gnome, which if true, would be welcome news.

The Gnome screenshot tool makes it easy to save off a screenshot to a file, or to drag it into an email, but it is difficult to print it (you have to save it first). That was a common complaint around here, so I wrote a little wrapper around xwd and gtklp for printing screenshots. People really like that because gtklp gives them lots of options about orientation and size of the image if they want it, or a simple "Print" button to click if they don't care. We set a gconf default to bind this to Ctrl-PrintScr and it works well. KDE's screenshot tool is much more capable, and if we were using KDE, we wouldn't have had any problem with screenshots.

The bottom line on Gnome is that we, and are users, are happy with it after we've made these customizations. But we have had to do more customization that we should have. I still think that Gnome has been better for our users than KDE, but I do wonder how long we'll be able to survive with our "no KDE libraries" policy, as people want ksnapshot, kolour, etc.

The first serious i18n effort for the Games Team is now bearing fruit. The newer version of the game hex-a-hop is now entering Debian. All the merit goes to Jens Seidel, who has developed the patches for making it work with SDLPango and to support all the spectrum of Unicode characters, instead of the limited ASCII set included in the game, as well as to all the people of Debian i18n who have done the translations (Helge Kreutzmann, Damyan Ivanov, Enrique Mat as S nchez, Bas Wijnen, Piotr Engelking, Yuri Kozlov and Clytie Siddall). The game has already been translated to Bulgarian, German, Spanish, Dutch, Polish, Russian and Vietnamese. Thanks Jens, both for taking care of the changes in the code needed to achieve this, and also for coordinating all the t10n and i18n process, as I don’t really have much experience in those areas.

vim-addons Joey wonders why vim addons are not enabled by default using the new Debian infrastructure. For single-user systems, Joey is right: enabling addons by default would be best. But for multi-user systems, I think disabled-by-default is better. Otherwise, installing an add-on would change vim's behavior unexpectedly for all users. (Unlike a daemon, which runs once per system; a vim addon is run by each user, every time they start vim.) This is especially bad because vim users tend to have carefully personalized configurations. Should the defaults cater to multi-user systems at the expense of single-user ones? Probably not, since admins of large multi-user systems are generally willing and able to figure out how to change their configurations, while many single-user machine owners need something that "just works". Perhaps the default configuration should load all installed addons, but local admins should be able to easily change this to load only addons enabled by the current user.