I keep almost all of my notes and to-do lists in plain text files, so I can edit and search them with Vim, grep, and other standard Unix tools. I often indent lines in these files to create a simple outline structure, and use the autoindent and foldmethod=indent options to make Vim into a simple outliner. To get useful output when searching through these outline-structured files, I wrote a simple grep replacement. Given a text file with a Python-style indentation structure, ogrep searches the file for a regular expression. It prints matching lines, with their "parent" lines as context. For example, if input.txt looks like this:

2009-01-01
  New Year's Day!
    No work today.
    Visit with family.
2009-01-02
  Grocery store and library.
2009-01-03
  Stay home.
2009-01-04
  Back to work.
    Remember to set an alarm.

then ogrep work input.txt will produce the following output:

2009-01-01
  New Year's Day!
    No work today.
2009-01-04
  Back to work...

You can download ogrep from the outline-grep repository on GitHub, or just read the literate Haskell file. The code is almost trivial (40 lines of code, plus imports and comments); I'm publishing it just in case anyone else has a use for it, and because some of my friends were curious about how I'm using Haskell. I've now written a few "real-world" Haskell programs (compleat was the first). I'm finding Haskell very well suited to such programs, though this particular one would be equally easy in a language like Perl, Python, or Ruby. This is a one-off tool to fill a gap in my workflow; there are no configuration options or useful error messages. It would be fairly easy to extend it, though. For example, it might be handy to have an option to include children (as well as parents) of matching lines. I recently realized that ogrep often works for searching through source code too, which might generate some more unexpected use cases.

I read The Iliad recently; see my review of it here. This article isn t about The Iliad, but about Shmoop s coverage of it. I have never been a person who puts much stock on study guides before, and my own prejudice is that they have probably earned their reputation as useful for little more than a tool to help students pass exams without reading the material. However, I felt rather unequal to reading The Iliad; after all, it has been many years since I had been exposed to Greek mythology, and even then it was very brief. I had remembered from Amazon s blog that they are offering some of the classics with a Shmoop study guide built in. I figured the $2.39 would be worth it. But I m not sure it was. The resulting ebook has two sections: the main text, and the Shmoop overview. The overview contains essentially the information available for free on their site. This information is pretty good. It has some overviews of the entire book, plus summaries of each chapter. They helpfully provide the backstory in the chapter summaries, so I know why certain gods are on the side of the Trojans and the others on the side of the Achaeans. It helped me figure out the point to some of the actions described on the text. These are linked to at the beginning of each book (chapter) of the Iliad, which was a bit inconvenient because I prefer to read them after reading the main text. Nevertheless, it wasn t a big problem. The summaries were written colloquially, sometimes too much so. I grinned as the less grabbin , more stabbin summary of the Achaeans being told to salvage armor from the dead later and keep fighting now. I cringed as no way Jose , and rolled my eyes as it described how one of the heroes got owned . That would have been less clear than the original for many. I would probably have given the Shmoop edition 4 or 5 stars on Amazon were it not for numerous boneheaded mistakes they made. The commentary uses one translation (Lattimore), while the included text uses a different one (Butler). That s bad enough, but it gets worse: Lattimore uses the Greek names for the gods and heroes, while Butler uses the Roman ones. So you can be reading through the text, learning about Jove, Ulysses, Juno, and Mars. But the commentary refers instead to Zeus, Odysseus, Hera, and Ares. Now, some might have memorized the Greek and Roman names for everyone, but then such people probably aren t wanting a study guide. I finally had to print out a page to help me understand the study guide. That is terrible, and completely inexcusable. They should have used the same translation for the text as the commentary, or at least have provided parenthetical notes throughout the commentary. Next, they really did a poor job of the main text itself. They have apparently grabbed the Butler ASCII text from Project Gutenberg, and cut and pasted it into some editor. I say this because each line renders as a paragraph; that is, the text doesn t reflow to fit the screen as every single other book does. Worse, it s too wide for the Kindle. So you get one line full width, the next only half as wide as the display (some of the first having wrapped), then the next full width again, on down. Butler is a prose, not a poetic, translation, so this is pointless. Moreover, the line endings are exactly where they are at Project Gutenberg. So, what we have here is that somebody at Shmoop cut and pasted from their own website and Project Gutenberg, and nobody bothered to check if the resulting product was crap. At least with the new Kindle firmware you can read in landscape mode to prevent most of the lines from wrapping. Still, I m very annoyed at this. There are other flaws. They highlighted some passages in the text. Clicking on them goes to some commentary about it. OK, fine. But why are some passages highlighted in the text, and some mentioned in the chapter summary? There seemed no rhyme or reason. The highlighted passages commentary was iffy in quality. Sometimes it was useful, and sometimes it asked a question of the sort I might expect in a jr. high English question When has pride helped you in your life? or some such. Worse, not all of the highlights linked to the correct place, and they also suffered from the Greek/Roman name issue. In all, Shmoop has helped me understand The Iliad and place it in context. But they need to spend a lot more effort on copyediting. Even a couple of hours of someone actually looking at their Kindle product on an actual Kindle would have immediately shown these problems. They could have made a far better product with a few hours more effort.

I have been pondering the idea behind this article for a while, and finally had a bit of time to implement it. The basic idea is this: certain platforms have higher costs in terms of memory per concurrent connection. Those translate into increased costs in dollar terms.
Nota Bene: Having run LangPop.com for some time, I'm used to people getting hot and bothered about this or that aspect of statistics that are rough in nature, so I'm going to try and address those issues from the start, with more detail below.

• Constructive criticism is welcome. I expect to utilize it to revisit these results and improve them. Frothing at the mouth is not welcome.
• There is something of a "comparing apples and oranges" problem inherent in doing these sorts of comparisons. As an example, Rails gives you a huge amount of functionality "out of the box", whereas Mochiweb does much less. More on that below.
• I am not familiar with all of these systems: meaning that I may not have configured them as I should have. Helpful suggestions are, of course, welcome. Links to source code are provided below.
• You can likely handle many more 'users' than concurrent connections, which means multiple browsers connecting to the site at the same time.
• Programmer costs are probably higher than anything else, so more productive platforms can save a great deal of money, which more than makes up for the cost of extra memory. There's a reason that most people, outside of Google and Yahoo and sites like that, don't use much C for their web applications. Indeed, I use Rails myself, even though it uses a lot of memory and isn't terribly fast: I'd rather get sites out there, see how they do, and then worry about optimizing them (which is of course quite possible in Rails).

Methodology All tests were run like so: my new laptop with two cores and four gigs of memory was used as a server, and my older laptop was used to run the ab (Apache Benchmark) program - they're connected via ethernet. I built up to successive levels of concurrency, running first 1 concurrent connection, 2, 10, and so on and so forth. The "server" computer is running Ubuntu 9.10, "karmic". Platforms The platforms I tested:

• Apache 2.2, running the worker MPM, serving static files.
• Nginx 0.7.62, serving static files.
• Mochiweb from svn (revision 125), serving static files.
• Jetty 6.1.20-2, serving static files.
• Rails 2.3.5, serving up a simple template with the current date and time.
• PHP 5.2.10.dfsg.1-2ubuntu6.3, serving up a single php file that prints the current date and time.
• Django 1.1.1-1ubuntu1, serving up a template with the date and time.
• Mochiweb, serving a simple template (erltl) with the date and time.
• Jetty, serving a simple .war file containing a JSP file, with, as clever observers will have surmised, the date and time.

As stated above, it's pretty obvious that using Rails or Django for something so simple is overkill: Better Tests for the Future I would like to run similar tests with a more realistic application, but I simply don't have the time or expertise to sit down and write a blog, say, for all of the above platforms. If I can find a few volunteers, I'd be happy to discuss some rough ideas about what those tests ought to look like. Some ideas:

• They should test the application framework with a realistic, real world type of example.
• The data store should figure as little as possible - I want to concentrate on testing the application platform for the time being, rather than Postgres vs Sqlite vs Redis. Sqlite would probably be a good choice to utilize for the data store.
• Since this first test is so minimalistic, I think a second one ought to be fairly inclusive, making use of a fair amount of what the larger systems like Rails, Django and PHP offer.
• I'd also be interested in seeing other languages/platforms.
• The Holy Grail would be to script all these tests so that they're very easy to run repeatably.

Results With that out of the way, I do think the results are meaningful, and reflect something of what I've seen on various platforms in the real world. First of all, here we look at the total "VSZ" (as ps puts it) or Virtual Size of the process(es) in memory. Much of this might be shared, between libraries, and "copy on write" where applicable. The results are impressive: Rails, followed by Django and PHP eats up a lot of memory for each new concurrent connection. Rails, which I know fairly well, most likely suffers from several problems: 1) it includes a lot of code. That's actually a good thing if you're building a reasonably sized app that makes use of all it has to offer. 2) Its garbage collector doesn't play well with "copy on write". Which is what "Enterprise Ruby" aims to fix. Django and PHP are also fairly large, capable platforms when compared to something small and light like mochiweb. That said, excuses aside, Erlang and Mochiweb are very impressive in how little additional memory they utilize when additional concurrent connections are thrown at them. I was also impressed with Jetty. I don't have a lot of experience with Java on the web (I work more with J2ME for mobile phones), so I expected something a bit more "bloated", which is the reputation Java has. As we'll see below, Jetty does take up a lot of initial memory, but subsequent concurrent connections appear to not take up much. Of course, this is also likely another 'apples and oranges' comparison and it would be good to utilize a complete Java framework, rather than just a tiny web app with one JSP file. So what's this mean in real world terms of dollars and cents? As your Rails application gets more popular, you're going to have to invest relatively more money to make it scale, in terms of memory. For this comparison, I utilized the bytes/dollar that I'm getting for my Linode, which works out to 18,889,040.85 ($79.95 for 1440 MB a month). As we can see, to have a similar amount of concurrent users is essentially free for Mochiweb, whereas with Rails, it has a significant cost. This information is particularly relevant when deciding how to monetize a site: with Erlang and Jetty it would appear that scaling up to lots of users is relatively cheap, so even a small amount of revenue per user per month is going to be a profit, whereas with Rails, scaling up to huge numbers of users is going to be more expensive, so revenue streams such as advertising may not be as viable. It's worth noting that 37 signals, the company that created Rails, is a vocal supporter of charging money for products. There's another interesting statistic that I wanted to include as well. The previous graph shows the average cost per additional concurrent user, but this one shows how much the platform costs (using when there is just one user, so it acts as a sort of baseline: As we can see, Jetty is particularly expensive from this point of view. The default settings (on Ubuntu) seem to indicate that, for instance, the basic $20 a month Linode package would not be sufficient to run Jetty, plus a database, plus other software. I think that the Apache Worker number is off a bit, and may reflect settings made to handle a large number of connections, or perhaps a different MPM would make sense. Source Code / Spreadsheet The spreadsheet I put together is here: http://spreadsheets.google.com/ccc?key=0An76R90VwaRodElEYjVYQXpFRmtreGV3MEtsaWYzbXc&hl=en And the source code (admittedly not terribly well organized) is here: http://github.com/davidw/marginalmemory/

(a review of Homer s Iliad)

Here, therefore, huge and mighty warrior though you be, here shall you die. - Homer (The Iliad)

And with that formidable quote, I begin my review of The Iliad. I shall not exhaust you with a rehashing of the plot; that you can find on Wikipedia. Nor shall I be spending page upon page of analyzing the beautiful imagery, the implications of our understanding of fate and destiny, or all the other things that compel English majors to write page after page on the topic. Nor even shall I try to decipher whether it is a piece of history or a piece of legend. Rather, I intend to talk about why I read it: it s a really good story.

Sing to me, O goddess Muse, the wrath of Achilles, son of Peleus, which brought countless ills upon the Acheans.

As I d be reading it, I d think to myself: Ah ha! Now here we finally have a section of the story that doesn t speak to modern life. Perhaps it was a section the fear of being enslaved or butchered by conquerors, or about pride leading both sides to fight a war they need not have, or a graphic description of a spear going clear through someone s head or neck. And then, I d have to sit and think. Are we really so far removed from that? Here we are, in a supposedly civilized world. We use remotely-operated drones to drop bombs on people, and think it naught but regrettable collateral damage when the brains and intestines of dozens of innocent victims are scattered about, killing them, all for the chance of killing one enemy. But we aren t the only ones to blame; we live in a world in which killing the innocent is often the goal. People fly airplanes into skyscrapers, drop atomic weapons to flatten entire cities, and kill noncombatants in terrible numbers. And for what? A little power, some prestige, some riches, some vengeance, some wounded pride? Slavery is not dead, either. We that can happily afford Internet access most likely abhor the thought. What, though, can we make of the fact that people are starving in this world in record numbers? That our actions may literally wipe some nations off the map? Are those people as free as we are? Do our actions repress them? I suspect you can t read the Iliad without being at least a bit introspective.

Fear, O Achilles, the wrath of heaven; think on your own father and have compassion upon me, who am the more pitiable

One of the great things about reading the Iliad is that I can learn about the culture of the ancient civilizations. Now, of course, one can read about this in history books and Wikipedia. But reading some dry sentence is different from reading a powerful story written by and for them. I know that the Iliad isn t exactly a work of history, but it sure shows what made people tick: their religion, their morals, their behavior, and what they valued. I feel that I finally have some sort of insight into their society, and I am glad of it.

The day that robs a child of his parents severs him from his own kind; his head is bowed, his cheeks are wet with tears, and he will go about destitute among the friends of his father, plucking one by the cloak and another by the shirt. Some one or other of these may so far pity him as to hold the cup for a moment towards him and let him moisten his lips, but he must not drink enough to wet the roof of his mouth; then one whose parents are alive will drive him from the table with blows and angry words.

There are gory battle scenes in the Iliad, but then there are also heart-wrenching tender moments: when Hector leaves his wife to go fight, for instance, and worries about the future of his child if he should die. That s not to say I found the entire story riveting. I would have liked it to be 1/3 shorter. The battle just dragged on and on. And yet, I will grant that there was some purpose served by that: it fatigued me as a reader, which perhaps gave me a small sense of the fatigue felt by the participants in the story.

Why, pray, must the Argives needs fight the Trojans? What made the son of Atreus gather the host and bring them?

A question that was never answered, for either side: why are we so foolish that we must go to war? One tragedy among many is that neither side got smart about it until way too late, if ever they did at all. I read The Illiad in the Butler translation, which overall I liked. Some of these quotes, however, use the Lattimore one. This completes the first item on my 2010 reading list. I leave you with this powerful hope for the future, written almost three thousand years ago. Despite my criticisms above, we have made a lot of progress, haven t we? What a beautiful ideal it is, and what a long ways we have yet to walk.

I wish that strife would vanish away from among gods and mortals, and gall, which makes a man grow angry for all his great mind, that gall of anger that swarms like smoke inside of a man s heart and becomes a thing sweeter to him by far than the dripping of honey.

Sing to me, O goddess, the anger of Achilles, that one day his story may speak less to our hearts, for then will we have outgrown it.

Lenovo have announced their innovative new U1 Hybrid laptop [1]. It consists of a tablet-style device with a resistive touch-screen that runs Linux on a 1GHz ARM processor which attaches to a base computer that has a keyboard and a Core2 processor running Windows 7. They apparently have some special software to synchronise web browsing on both computers so you can maintain your web sessions when you detach the computers. How they manage to use the power of the Core2 CPU for javascript and flash intensive web sites while allowing the active browser sessions to migrate to a different OS must be a neat technical trick. Revision3 have a youtube review of the U1 which shows what it can do in terms of the hardware interface [2] Running two computers requires having two batteries, motherboards, etc which means more weight or means less battery life for the weight, whichever way you think of it the user is losing because of this choice. The idea of having two computers in one is one of these cool technical ideas which just won t provide a benefit for the users. The best thing for the users would be to have a single light-weight computer that provides an adequate amount of performance. A 1GHz ARM processor should give good performance when running Linux for most tasks (web browsing, office applications, and most games). So it seems that a good tablet with some USB ports and a matching USB keyboard would be a better option. Maybe you could have a spare battery integrated with the keyboard as most times when you want a full sized keyboard weight isn t such a big problem. The problem with MS-Windows in regard to such machines is that performance is poor and processors other than i386 and AMD64 have never really been supported (sure you can buy MS-Windows-based PDAs that have ARM and PPC CPUs, but the application support for them is minimal). These problems will never be solved. MS wants to compel users to continually upgrade their software, this requires always adding new features (bloat) while an older or less featureful OS is often a better option for lesser hardware. Vendors of proprietary applications will never support the range of CPU architectures that a free software distribution such as Debian or NetBSD supports (not that NetBSD is an ideal tablet OS but it does demonstrate what can be done if you want a portable OS). These inherent flaws in the proprietary software environment lead to some unusual hardware being designed to work around them such as the Lenovo U1. I don t have any reason to believe that the Lenovo is a bad machine, it sounds like a reasonable work-around for some of the problems that MS-Windows has forced on the industry. But I believe that it would be a much better machine if it was lighter, had a better battery life, and had a choice of keyboards all of which would have been achieved if it was designed as an ARM-only tablet machine that you can connect to an external keyboard. They could even have used a multi-core ARM CPU. But the market for such systems apparently isn t large enough for Lenovo (or anyone else) to ship ARM laptops for serious use. There have been a couple of netbooks released recently with CPUs that don t support the i386 or AMD64 instruction set, but they were aimed at web browsing use not general purpose computing. Almost everything that I do on computers could be done at least as well with a CPU that doesn t run an Intel-based instruction set, the only exception is virtualisation which doesn t seem to be well supported on architectures other than AMD64 nowadays.

• [1] http://lenovoblogs.com/insidethebox/?p=366
• [2] http://www.youtube.com/watch?v=-5DYuVN6nuY

Had you been on our yard tonight, you would have seen a strange sight. Me, dressed warmly (but not quite warmly enough), jumping on the icy and snowy hood of my pickup. Some maniacal fit? An obscure part of my 3-day-long taking out the trash routine? Not exactly. Before I tell you why I was doing such a strange thing and almost in the dark I feel compelled to take a detour through ancient Greek poetry. You heard right. I ve been reading ancient Greek poetry lately. Those Greeks were forever running around receiving signs and portents from the gods. If ever a bird flew by carrying a live snake, and you saw the snake bite the bird while looking over your left shoulder, you knew Zeus was telling you not to attack the enemy that day. Or something. And if you, fool that you are, attacked the enemy that day anyway, you should be not in the least surprised to find a spear through your shoulder in just a few pages time. If ever someone received a sign from Zeus in modern times, surely it was I, tonight. I say that because, as I was trying to close the hood on my pickup after charging its battery, the hood nearly snapped in two. The hood is supported by some spring-loaded brackets in the back, so to close it, you have to push down on the front. I did so, and was surprised that it was going down so easily. Then I realized, apparently in the nick of time, that only the front was going down. The back was staying put, aiming up in the air as ever. So I tried to straighten the hood back out. I then tried to get it down by pulling at it halfway back, but just couldn t get enough leverage to make it budge. So what next? Why, jump on it of course. I got it most of the way closed that way, then jumped/slid down, latched it in front, then crawled back up there to push down the sort of rusty mountaintop that had formed halfway down the hood where it was buckling. OK, sorted. So to recap By this point, I ve had the battery charging for 24 hours, inflated the tire, removed the bungee cord around the brake pedal, removed the battery charger, coerced the hood shut. Time to start it. I hop in, pump the accelerator a few times, and turned the key to start. I heard the sickening aaaaaaaaRRRRRRRRRRRRuuuuumphhh . of a weak battery. So it wasn t charged enough to crank fast enough to have any hope of starting in winter. So I go get the car, pull it up close, being careful to leave myself enough room to maneuver between it and the electric fence. I get out the jumper cables. Then it occurs to me: I have to open the hood again. DOH! I open it just a bit, and hook up the jumper cables. It turns over a bit faster. For just a bit. I get a small sputtering of life from it, but it fades faster than an enemy of Hector at the battle for Troy. So I have Terah come out and put her foot on the accelerator of the car while I try to start the pickup. This too proves futile. So I disconnect the jumper cables, close the pickup s hood with significantly less care than a 31-year-old rusty and nearly-broken hood deserves, roll the window back up, and go for plan B: 4 trips to the road with stuff in my car trunk, and leave the giant cardboard boxes that are covered with snow in the pickup bed for next month. Obviously I have displeased the gods. Forgotten to offer up a sacrifice to Penzoil, feared goddess of internal combustion, perhaps? Or perhaps it was just a sign that I need a new pickup? I m so convinced of the latter that I didn t even bother to replace the bungee cord. Postscript Terah walked in, and said, Ah, I thought I heard you writing a blog post. Yep. It s about pickups and the Greek gods. <very slight pause> Oh, of course it is.

5 years ago I founded my own company Freexian SARL with the goal to make a living out of my free software experience. I marketed the company as being specialized on the Debian distribution in the hope to combine my Debian work and my professional work. Given that Freexian is still alive I think I met the first goal. My free software experience allowed me to complete many projects: a large number of development projects for embedded devices running a custom Linux distribution (usually built with debian udebs), the development of a Debian derivative (SLIS) and some recurring tasks of remote system administration. However, even if I use Debian daily for all my work, very few of the projects that I complete for customers have direct results in terms of improvements for Debian (except some bugreports and some related fixes). And even when I m able to contribute something back to Debian, it s usually not in areas that I care about. My focus within Debian is on the technical and organizational infrastructure of the project: as a dpkg/dpkg-dev maintainer I try to improve the packaging infrastructure, as a QA member I maintain the Package Tracking System to ease collaboration, as an Alioth admin I ensure all DD can host VCS repositories for their Debian related projects, as a developers-reference co-maintainer I try to share good packaging practices, etc. Given this bias, it s difficult to find customer projects that would let me contribute in those areas. Thus I think I need to try another approach: the simplest solution would be to find sponsors for some of my own Debian-related projects (if you have something else to suggest, please leave a comment either in the blog or by mail). That said finding sponsors looks like a difficult task in itself. While I can imagine (for example) a company using Debian on embedded devices that would like to sponsor the rewrite of update-alternatives in C in order to get rid of the perl dependency in the dpkg package (if you know such a company, get in touch with me!), I don t see who would have an interest in sponsoring the time that I need to contribute new sections to the developers-reference manual. But who knows maybe I should just try and publicly solicit sponsorship for some of the projects that I care about. In any case, suggestions and comments are welcome! Partagez cet article / Share This

This has been a big decade for me. Ten years ago, I was living in Sunnyvale, in the heart of Silicon Valley; VA had just had its crazy IPO; my unvested options were worth over a million dollars on paper. I remember sitting in first class[1] on the way out of Atlanta after the holidays and wondering what one did with a million dollars. Avoid working too much? Have a lot of interesting computers? Build a distributed house[2]? Mostly I decided to not count my chickens, which turned out to be the right choice. Six months later, I started debian-installer, in many ways my biggest project to date. In spring of '01, VA was crashing; I was sick of the Valley; gloom was everywhere. I took the hint and quit, cashed in my options for five figures, not seven, bade forewell to the many people I'd come to know, and moved back east. By reading my old journal, I can tell that subconciously, I had long before decided what to do when it was time to leave the Bay Area. So without really thinking too much about why I was able to do this, about how not just my own family, but others were indirectly making it possible, I moved to a 150 acre wooded "farm", and mostly went off and did mostly my own thing for three years. This was such a huge life change. I lived in a building affectionatly called "the shack". It was renovated from a chicken coop in the 70's and leaked during heavy rain, but I preferred it to the main house (warmer). I went back to dialup for internet. I hauled groceries and most everything half a mile in by hand. There was an outhouse and washwater hauled from a creek. I cut barely enough firewood and readapted my body from California to cold. My main tech project during this time was mooix. In some ways my largest failed project, but it was neat to be able to go off and do such a thing. This was a blissful, reflective, peaceful, amazing time. Parts were a second childhood. Somewhere in there I properly confronted my mortality. And learned to use a chainsaw. And over the course of three years, I dug myself into a rut, a hole. I wasn't going anywhere. (Except for a month in Honduras, and my first DebConf in Oslo.) In '04, I found myself talking on the phone to a cosmonaut in a house that had been without power for days in a hard winter. I realized I was ready to leave the farm if I could figure out how to do it, and I almost took him up on the job working on his new Linux distro -- but at the last minute Oslo connections suggested I work for SkoleLinux instead, and so I did. Soon after moving into a rented house in town, I was jaunting off to Brazil for a month, a great time. Followed by a productive year where I got heavily back into debian-installer, started Debian's testing security tream, and generally worked a lot. The next summer I fooled around with an RV, and sort of fell into a job with ADS. But my time on the farm had changed me, I think. I ended up going back to the farm for a year and working part time from there. During this time I also started ikiwiki and other smaller projects. One day I came back from a camping trip and found the kitchen had been torn down in my absence. Reminded unsubtly that I was not the only one with a claim to the place, I got out, though I somehow suspect not for good. For the last four years, I've been more outwardly settled, buying a house in town, continuing to work at the same job, starting little projects like pristine-tar, mr, and etckeeper. About two years in I began to feel antsy sometimes (and had a minor medical scare), and set up the yurt as a relief valve so I can have crazy adventures in the cold woods again. Still, I sometimes feel that a big change is building up. From here, this decade feels like it contained endless changes, important decisions, interesting projects, strong experiences. The 90's, containing only little things like college and moving to California, pale in comparison. Maybe the naught's will be the decade I always remember.. or maybe not. Anything could be around the corner.

---

1. Bumped up due to an airline scheduling snafu, not because I was throwing money around.
2. Concept of mine perhaps not worth explaining here although it was oddly similar to how I ended up living at the farm. Good ol' subconcious..

I started to write this review last night, and went looking for Wil Wheaton s blog, where many of the stories came from, so I can link to it from my review. It was getting late, I was tired, and so I was a bit disoriented for a few seconds when I saw my own words flash up on the screen. At the time, his most recent story had excerpted my review of paper books. Wow, I thought. This never happens when I m about to review Dickens. And actually, it s never happened before, ever. I ll admit to owning a big grin when I saw that one of my favorite authors liked one of my blog posts. And Wil Wheaton is one of my favorite authors for sure. I enjoy reading others too, of course, but Wil s writing is something I can really identify with like no other. My parents were never in a London debtor s prison like Dickens were; I was never a promising medical student like A. C. Doyle. But I was, and am, a geek, and Wil Wheaton captures that more perfectly than anyone. After I read Just a Geek a few years ago, I gave it to my wife to read, claiming it would help her understand me better. I think it did. In The Happiest Days of Our Lives, Wil recounts memories of his childhood, and of more recent days. He talks of flashbacks to his elementary school days, when he and his classmates tried to have the coolest Star Wars action figures (for me: calculator watches). Or how his aunt introduced him to D&D, which reminded me of how my uncle got me interested in computers. Teaching himself D&D was an escape for the geeky kid that wasn t good at sports, as teaching myself Pascal and C was for me. Between us, the names and activities are different, but the story is the same. I particularly appreciated Wil s reflections on his teenage years. Like him, at that age, I often found myself as the youngest person in a room full of adults. Yet I was still a teenager, and like any teenager, did some things that I look back on with some embarrassment now. Wil was completely honest with himself he admitted crashing a golf cart on the Paramount studio lot, for instance, but also reminds me that he was a teenager then. He recognizes that he didn t always make the best choices and wasn t always successful with what he did, but isn t ashamed of himself either. That s helpful for me to remember; I shouldn t be unreasonably harsh on my 16-year-old self, and need to remember that I had to be a teenager too. I also identify with him as a dad. He wrote of counting the days until he could teach his boys about D&D, about passing on being a geek to his sons. I ve had a similar excitement about being able to help Jacob build his first computer. Already Jacob, who is 3, loves using the manual typewriter I cleaned up for him, and spent an hour using the adding machine I dug out on Sunday while I was watching the boys. (I regret that I didn t have time to take it apart and show him how it worked right then when he asked). And perhaps his 2nd-favorite present of Christmas was the $3.50 large-button calculator with solar cell power I got him as an impulse buy at the pharmacy the other day. He is particularly enamored with the square root button because a single press replaces all the numbers on the screen with completely different numbers! I can t find the exact passage now, but Wil wrote at one point about his transition from a career in acting to a career in writing. He said that he likes the feeling he gets when his writing can touch people. He s been able to redefine himself not as a guy that used to be an actor on Star Trek but a person that is a good author, now. I agree, and think his best work has been done with a keyboard instead of a camera. And that leaves me wondering where my career will take me. Yes, I m an author, but of technical books. Authors of technical books rarely touch people s hearts. There s a reason we read Shakespeare and Dickens in literature classes, but no high school English teacher has ever assigned Newton s Opticks, despite its incredible importance to the world. Newton revolutionized science, mathematics, and philosophy, but Opticks doesn t speak to the modern heart like Romeo and Jiuliet still does. Generations of people have learned more about the world from Shakespeare than from Newton. I don t have Wil s gift for writing such touching stories. I ve only been able to even approach that sort of thing once or twice, and it certainly won t make a career for me. Like Wil, I m rarely the youngest person in the room anymore. His days of being a famous teenage actor on a scifi series are long gone, as are mine of single-handedly defeating entire teams at jr. high programming contests. (OK, that s a stretch, but at the time it sure felt exciting.) But unlike him, I m not completely content with my niche yet. I blog about being a geek in rural Kansas, where there still aren t many. I m a dad, with an incredible family. And I write about programming, volunteer for Debian and a few other causes, and have a surprisingly satisfying job working for a company that builds lawn mowers. And yet, I have this unshakable feeling of unsettledness. That I need to stop and think more about what I really want to do with my life, perhaps cultivate some talents I don t yet have, or perhaps find a way to make my current path more meaningful. So I will take Wil s book as a challenge, to all those that were once sure of what their lives would look like, and are less sure with each passing year: take a chance, and make it yours. And on that score, perhaps I ve done more than I had realized at first. Terah and I took a big chance moving to Kansas, and another one when we bought my grandparents run-down house to fix up and live in. Perhaps it s not a bad idea to pause every few years and ask the question: Do I still like the direction I m heading? Can I change it? Wil Wheaton gives me lots to think about, in the form of easy-to-read reflections on his own life. I heartily recommend both Just a Geek and The Happiest Days of Our Lives. (And that has nothing to do with the fact that the Ubuntu machine he used to write the book probably had installed on it a few pieces of code that I wrote, I promise you.)

Everyone seems to be familiar with ebooks these days. I own a Kindle 2, and of course we ve spent weeks hearing how great the Nook will be, then weeks hearing how terrible it turned out to be. But nobody seems to be casting an eye back towards paper, so I thought I d rectify that here, especially since paper books have some serious stability issues that are often overlooked! Before I begin, I feel it wise to offer this hint to the reader: this review should not be taken too literally. If you have an uncontrollable urge to heave a volume of the Oxford English Dictionary at me as if I am some European prime minister, please plant your tongue more firmly in your cheek and begin again. Today I picked up a paper book to read just for fun The Happiest Days of Our Lives by Wil Wheaton. Long-time (since this spring!) Kindle user that I am, I immediately noticed the dashing use of color on its front cover, but when I opened it, I was disappointed that I couldn t scale the font size down from the default. It seems that paper books have only one font option what are all these Kindle forum posters complaining about with its six sizes of a single font? On the very first page, I encountered a word I wasn t familiar with (Namaste). I thought I knew what it meant from the context clues, and even had the thought that on the Kindle, I could just highlight it and confirm my guess. But my paper dictionary was in the basement, so I didn t bother looking it up until I wrote this post. (My hunch was reasonably correct.) Interface-wise, the paper book is solid, and crashes, lockups, or other malfunctions are rare. I have, however, noted severe stability problems when attempting to read outdoors, especially when it s windy (which, since I live in Kansas, is pretty much always). Pages start turning themselves, even without me making the turn page gesture. Sometimes the book will even lose its memory of my last page read. This is rather annoying, and might even involve a lengthy search for a suitable temporary replacement bookmark. Also, I haven t tried it, but I suspect that the trick of putting a Kindle in a ziplock bag to read at the beach or in the tub without risk of getting it wet would be impractical with a paper book. Paper does have its advantages. For one, it s faster to flip rapidly through pages on paper than on an ebook reader. If you know roughly where in the book something was written, but not the precise wording, searching can be faster on paper. On the other had, if you are looking for a particular word or phrase, the ebook reader may win hands-down, especially if the paper book has no index. Paper is so stable that some would argue that the extreme impracticality of making good backups isn t really a problem at all. But on the other hand, paper books degrade slightly each time they are used, and this condition can be aggravated by placement in bags for transport. Eventually, they will wear out. If my Kindle wears out, I can always restore David Copperfield from my backup copy to a new one. If my printed edition (all two volumes) of it wear out, then I have to hope that the used bookstore will still sell me another one for $10. Otherwise I d have to either drive 45 miles to find one for sale, attempt to deal with the DRM for paper books at a library, or wait a couple of days for Amazon to get it to my door. A fire or flood could be devastating. Paper books also have some advantages for showing photos; no ebook reader is close to the size and resolution of glossy paper photos books in a reasonable price. The contrast on most paper books is better than that of my Kindle, but some older ones are actually worse, smell dusty, and suffer from occasional display corruption as bits of them actually break off of the book device. As to cost, it is a mixed bag. Out of copyright classics are free as ebooks from Project Gutenberg and the like, while still costing money on paper. I have found that the accuracy of some of these paper editions can be rather questionable people have sometimes manually removed important bits of the story to save on printing costs, rather than let Google Books OCR mangle it for them automatically. On the other hand, used paper editions of more current works can be found for a fraction of the cost of the new ebook edition though you are often limited in selection of these bargains. But you can usually browse a paper book for a few minutes before buying it, which is rarely available for an ebook. What s more, libraries might let you borrow paper books for free. But you often have to expel greenhouse gases to get to them, and then they enforce DRM on you you only get to read it a certain amount of time before they start adding fees. You could easily wind up paying $2 if you keep it a week longer than you should have. With ebooks, of course, there is no free borrowing (and the Nook feature it too limited to count.) And you of course know that most libraries are run by the government, so they have your address. Trying to circumvent a library s DRM could wind up involving the police, so you had best comply. Making copies of a paper book is expensive and requires specialized equipment, even if you just want a copy for backup. Compatibility problems with paper books are rare, and are usually found among readers with poor eyesight. A few works can be found in large font editions, but most can t, so those readers are left needing expensive specialty magnifiers. All in all, I prefer reading books on my Kindle, but still read on paper when that s how I have a book.

a short update on my RC-bug squashing activities:

• #526210 scim-kmfl-imengine: "FTBFS with GCC 4.4: missing #include"
  apply patch from the BTS, upload to DELAYED/2
• #531715 gcin: "FTBFS with GCC 4.4: missing #include"
  add comment to BTS, later NMU'd by zack
• #534600 spatialindex: "spatialindex: FTBFS with GCC 4.4"
  apply patch from the BTS, upload to DELAYED/2
• #539543 hubbub: "FTBFS with GCC 4.4: 'cptr' may be used uninitialized"
  apply patch from the BTS, upload to DELAYED/2
• #546386 fam: "FTBFS with gcc4.4"
  apply patch from the BTS, upload to DELAYED/2
• #549223 chuck: "fails to build with gcc-4.4/newer eglibc"
  apply patch from the BTS, upload to DELAYED/2
• #550115 gbgoffice: "FTBFS: invalid const conversion"
  apply patch from the BTS, upload to DELAYED/2
• #553706 glob2: "FTBFS with GCC 4.4: 'class GAGCore::StreamBackend' has no member named 'getc'"
  apply patch from the BTS, upload to DELAYED/2

remarks:

• to be honest, these were all easy bugs, I just grabbed existing patches (by Martin Michlmayr, peter green, & several Ubuntu folks).
• reactions so far: one "thank you" mail, no other comments.

It was interesting to see Clint Adams describe love and dissatification with configuration management. At work I've got control of 150(ish) machines which are managed via CFEngine. These machines are exclusively running Debian Lenny. In addition to these hosts we also have several machines running Solaris, OpenBSD, and various Ubuntu releases for different purposes. Unfortunately I made a mistake when I setup the CFEngine infrastructure and when writing all the policies, files, etc, I essentially said "OK CFEngine controlled? Then it is Debian". (This has been slowly changing over time, but not very quickly.) But in short this means that the machines running *BSD, Solaris, and non-Debian distributions haven't been managed as well via CFEngine as the rest, even though technically they could have been. A while back I decided that it was time to deal with this situation. Looking around the various options it seemed Puppet was the way of the future and using that we could rewrite/port our policies and make sure they were both cleanly organised and made no assumptions. So I setup a puppetmaster machine, then I installed the client on a range of client machines (openbsd, debian lenny, ubuntu, solaris) so that I could convince myself my approach was valid, and that the tool itself could do everything I wanted it to do. Unfortunately using puppet soon became painful. It has primitives for doing various things such as maintaining local users, working with cronjobs, and similar. Unfortunately not all primitives work upon all platforms, which kinda makes me think "what's the point?". For example the puppet client running upon FreeBSD will let you add a local user, setup a ~/.ssh/authorized_keys file but will not let you setup a password. (Which means you can add users who can login, but then cannot use sudo. Subpar) At this point I've taken a step back. As I think I've mentioned before I don't actually do too much with CFEngine. Just a few jobs:

• Fetch a file from the master machine and copy into the local filesystem. (Making no changes.)
• Fetch a file from the master machine, move it to the local system after applying a simple edit. (e.g "s/##HOSTNAME##/ hostname /g")
• Install a package.
• Purge a package.
• Setup local user accounts, with ~/.ssh handled properly.
• Apply one-line sed-style edits to files. (e.g. "s/ENABLED=no/ENABLED=yes/" /etc/default/foo)

(i.e. I don't use cron facilities, I add files to cron directories. Similarly I don't use process monitoring, instead I install the monit package and drop /etc/monit/monitrc into place.) There is a pretty big decision to make in the future with the alternatives being:

• Look at Chef.
• Stick with CFEngine but start again with a better layout, with more care and attention to portability things.
• Replace the whole mess with in-house-fu.

If we ignore the handling of local users, and sudo setup, then the tasks that remain are almost trivial. Creating a simple parser for a "toy-language" which can let you define copies, edits, and package operations would be an afternoons work. Then add some openssl key authentication and you've got a cfengine-lite. For the moment I'm punting the decision but I'm 90% certain that the choice is CFEngine vs. Chef vs. In-House-Fu - and that puppet is no longer under consideration. Anyway despite having taken months to arrive at this point I'm going to continue to punt. Instead my plan is to move toward using LDAP for all user management, login stuff, and sudo management. That will be useful in its own right, and it will coincidentally mean that whatever management system we do end up using will have on less task to deal with. (Which can only be a good thing.) ObFilm: Terminator II

It was interesting to see Clint Adams describe love and dissatification with configuration management. At work I've got control of 150(ish) machines which are managed via CFEngine. These machines are exclusively running Debian Lenny. In addition to these hosts we also have several machines running Solaris, OpenBSD, and various Ubuntu releases for different purposes. Unfortunately I made a mistake when I setup the CFEngine infrastructure and when writing all the policies, files, etc, I essentially said "OK CFEngine controlled? Then it is Debian". (This has been slowly changing over time, but not very quickly.) But in short this means that the machines running *BSD, Solaris, and non-Debian distributions haven't been managed as well via CFEngine as the rest, even though technically they could have been. A while back I decided that it was time to deal with this situation. Looking around the various options it seemed Puppet was the way of the future and using that we could rewrite/port our policies and make sure they were both cleanly organised and made no assumptions. So I setup a puppetmaster machine, then I installed the client on a range of client machines (openbsd, debian lenny, ubuntu, solaris) so that I could convince myself my approach was valid, and that the tool itself could do everything I wanted it to do. Unfortunately using puppet soon became painful. It has primitives for doing various things such as maintaining local users, working with cronjobs, and similar. Unfortunately not all primitives work upon all platforms, which kinda makes me think "what's the point?". For example the puppet client running upon FreeBSD will let you add a local user, setup a ~/.ssh/authorized_keys file but will not let you setup a password. (Which means you can add users who can login, but then cannot use sudo. Subpar) At this point I've taken a step back. As I think I've mentioned before I don't actually do too much with CFEngine. Just a few jobs:

• Fetch a file from the master machine and copy into the local filesystem. (Making no changes.)
• Fetch a file from the master machine, move it to the local system after applying a simple edit. (e.g "s/##HOSTNAME##/ hostname /g")
• Install a package.
• Purge a package.
• Setup local user accounts, with ~/.ssh handled properly.
• Apply one-line sed-style edits to files. (e.g. "s/ENABLED=no/ENABLED=yes/" /etc/default/foo)

(i.e. I don't use cron facilities, I add files to cron directories. Similarly I don't use process monitoring, instead I install the monit package and drop /etc/monit/monitrc into place.) There is a pretty big decision to make in the future with the alternatives being:

• Look at Chef.
• Stick with CFEngine but start again with a better layout, with more care and attention to portability things.
• Replace the whole mess with in-house-fu.

If we ignore the handling of local users, and sudo setup, then the tasks that remain are almost trivial. Creating a simple parser for a "toy-language" which can let you define copies, edits, and package operations would be an afternoons work. Then add some openssl key authentication and you've got a cfengine-lite. For the moment I'm punting the decision but I'm 90% certain that the choice is CFEngine vs. Chef vs. In-House-Fu - and that puppet is no longer under consideration. Anyway despite having taken months to arrive at this point I'm going to continue to punt. Instead my plan is to move toward using LDAP for all user management, login stuff, and sudo management. That will be useful in its own right, and it will coincidentally mean that whatever management system we do end up using will have on less task to deal with. (Which can only be a good thing.) ObFilm: Terminator II

I'm a notoriously late adopter of new technologies. Sure, if I think that something is potentially a good idea, I'll go for it, but for the most part, I assume that things are stupid. I refused to use the WWW for many years, thinking it was idiotic. Now I use the WWW. I find microblogging to be inane and narcissistic at best, but I have derived mild amusement from Shaq on Twitter. Microsoft Windows is something I thought would be ridiculously unsuccessful, because it didn't do anything I would find useful. The list goes on and on, and includes something known in the popular vernacular as configuration management . I've been hearing about BladeLogic and Opsware for quite some time, and idly wondering who the incompetent fools are that need something like this. Back in my day we could manage 100 servers with relative ease; no centralized authentication (because it was a running argument about whether NIS sucked more than NIS+ or vice-versa), no cfengine, no prebuilt server images or any of that jazz. If, for some reason, we needed to make the same change to all servers at once, or some subset thereof, we would just script it. So when one of my acquaintances started raving about Puppet, I assumed it was equally pointless. We'll call him Downs. Downs exhibits a pattern of behavior where he will rave about something for a few weeks, sometimes without having even tried it first, and then eventually become disillusioned with it and start ranting with the same fervor with which he had insisted that whatever fad of the week was the greatest thing ever. It came as no surprise to me when he fell out of love with Puppet and started raving about how much better Chef is. In case you're wondering, he still has not tried Chef to this day. Finally someone convinced me of the value of Puppet. I do not think it is the Way and the Light, but I do see a few situations wherein it makes sense to sacrifice efficiency, flexibility, sanity, and system resources to gain a way of building a near-identical machine from scratch. Now, beyond the flaws inherent to a solution like this, Puppet does have some annoying flaws which I find unnecessary, and which Downs ranted about back when I had absolutely no idea what he was talking about. I disregarded his alleged preference for Chef, but I have heard intelligent people extoll the virtues of Chef, and to a lesser extent Bcfg2. So I took a very brief look at each of those, and was pretty much horrified by what I found. If I need something Puppet-like in the very near future, I will probably be choosing Puppet. I have no intention of running Puppet on machines I manage all by myself though. For that eventuality I am NIHing something with what I consider a better design. The current code is published, but it does not do very much, and requires linking with libdpkg.a which does not exist in any package (but Guillem's working on that, I think). I have no idea whether or not I'll have the motivation to finish it all by myself, but it is Free Software. This post is intentionally weak on details, or deets as the kids call them.

I'm using digikam to organize my pictures I took with my D90 DSLR. I always got the impression that the View -> "Zoom to 100%" menu shows not the full sized image (100%). When using another picture viewing program like okular and choosing View 100% there, I get a "bigger" image. Proof is here:



You can see okulars view on the left in the foreground. Digikams 100% view is in the background at the right. Both apps are showing the same JPEG picture. I don't know that Digikam is doing wrong there, but it's definitely not a 100% view that it shows. Time for a bug report, I guess...

UPDATE:
Oh well... wondering why all those people got the Copyright-Notice.png instead of the real picture, I finally discovered that I need to change the rewrite settings for the IPv4 vhost section as well. IPv6 users hadn't this kind of problem. So, better use IPv6 instead of IPv4, folks! ;-)

And thanks to sgran for pointing out <vhost 1.2.3.4 2001::1:2:3:4> syntax! ;-)

UPDATE 2:
The bug report is filed and registered as #562197.

UPDATE 3:
Problem solved! See bugreport.

After the arrival of family, and the big snow, and the digging out, the gathering at the farm was dimished from its usual numbers. Without power, the house was lit by kerosine lanterns, candles, and the fireplace, and this felt very right for a solstice celebration. Musicians played old tunes in the sitting room (with the youngest kids adding percussion), while others nibbled on turkey (from the field next door) and stuffed grape leaves (from Turkey). Later, the cracks of overloaded trees echoed through the valley as the bonfire blazed high and bright through the night.

snow on the bonfire

Several LXDE components have been updated recently in sid. They bring some new features and improve flexibility of customization. Below you have a summary of the most important changes:

• lxde-common 0.5.0-2:
  The nuoveXT2 icon theme has been removed from lxde-common and it is has been moved to lxde-icon-theme package instead.
  The startlxde script now executes 'lxsession -s LXDE -e LXDE' rather than 'lxsession -s LXDE' to reflect the changes in lxsession.
• lxsession 0.4.1-1:
  There is a new command line argument: -e. This let you set the internal name of the DE. This value is exported via the environment variable $XDG_CURRENT_DESKTOP. The DE name can be used to match desktop files which contain compatible OnlyShowIn and NotShowIn key values.
  The -s argument is reserved for session name only and was used to load related config files for the desktop session. For example, you can execute: lxsession -s Lubuntu -e LXDE This should load config files from Lubuntu directory, but the DE is still recognized as LXDE by applications.
• lxpanel 0.5.4.1-1:
  Now you can determine the visibility of applications in the menu by comparing OnlyShowIn and NotShowIn key values and $XDG_CURRENT_DESKTOP. This means, you can have lxpanel show Gnome menu by the following export XDG_CURRENT_DESKTOP=3DGNOME . Then lxpanel will show gnome applications instead of LXDE ones.
• Finally, lxnm and lxpanel-netstat-plugin are now deprecated.
  lxnm has been already requested to be removed from the archive and it is recommended to use wicd instead. lxpanel-netstat-plugin has also dropped from lxpanel in the upload 0.5.4.1-1.

Contributed by: Andrew Lee

Tutorials at the Garching Debian Stammtisch Munich traditionally used to have a lot of Debian Developers, but over the last couple of years quite a few of us who used to be students graduated and moved elsewhere or became very busy with their day jobs. We still meet for having a beer and a chat, but not as much as some years ago. We used to meet about once a month, but in 2009 we only managed to meet four times (however, we organized a Bug Squashing Party in November and had a special meeting as Lenny Release Party in February) As the meetings are really rather informal and not necessarily very Debian related, it is difficult to attract new people this way. So Johannes Wiedersich and I decided to try a more hands-on approach by having a second meeting in Garching, in the student-run bar on the campus of the Technische Universit t M nchen (TUM). The idea was to get more of the local science, mathematics and computer science students (as well as possibly interested faculty members) involved. We tried a first time about a year ago, but after two or three meeting in late 2008 and early 2009, we lost momentum. However, we began organizing the meetings again with the start of the winter term, and had two rather successful meetings so far. For the first meeting, we basically handed out some information on how to get involved locally (the Debian-Munich list, its subscription address, the wiki etc.) and discussed Debian in general and Debconf11 in Munich in particular. About half a dozen people showed up, and two of these attended the Bug Squashing Party later that month, and another one (a faculty member) got very active in Debconf11 organization. Thus, I was quite happy with the outcame of that meeting. Some days ago, we had another meeting, and this time I was doing a live-tutorial on Debian package building. As Johannes was ill, we did not manage to announce or publicize the meeting well in advance, so only three people showed up. Still, I think it went rather OK, and we will be doing another Debian package-building tutorial for the next meeting, and possibly other turorials/workshops afterwards (ideas so far include library maintenance, Debconf, how the Debian community is organized and how to get involved in it). As doing a live-tutorial on one notebook is a bit difficult if you both have to type on it and people should see what happens, we will either use some extra hardware next time, or move to some nearby seminar room with a projector, this will be announced in advance. So if you are on Garching campus or nearby and interested in Debian development (and Debian package-building in particular), come to the next meeting on January 13th! We decided to meet on the second Wednesday of each month, at 18h. Subscribe to the Debian-Munich list to get the invitation or watch out for the flyers on the campus.

In case you want to buy some (more) bottles of wine made for DebConf9, you need to hurry up. Also a bit more hurry is appropriate if you want it to be delivered til XMas :-)



(Picture credit belongs to Chris.)

I'm planing another (offline) sale at the 26C3 congress in Berlin at the end of the year, which might or might not work out. If it does, the number of bottles available for online ordering will be reduced significantly, and basically I'm only waiting for some details to be finalized for announcing this for real, so hurry up and mail order now - unless you have enough Debian wine bottles at home already :-)

Information how to order is available in our wiki at DebianWine. The profit made will be given to DebConf9, and as that has been dealt with finacially successfully, it will be given to DebConf10!