and the newbies are ... A long time ago, in a couple of blog posts far far away, we have introduced the DebConf Newbies initiative. I'm hereby happy to announce the actual DebConf newbies and I'm looking forward to meet them at the forthcoming DebConf10 in New York City:

• Jonathan Wiltshire
• Jon Bernard
• Arnaud Fontaine
• Ben Armstrong
• Arthur Loiret
• Serafeim Zanikolas
• Andreas B. Mundt

Now, folks, please be kind with them, they (still) don't know how crazy we can be(come) during DebConf. Above all: do not harm them (too much) at Mao. In exchange, they have already promised that they will fix all RC bugs that will still be open at the beginning of DebConf10 (or maybe I've just read that in their minds, I don't quite remember ...). Does that mean that DebConf10 travel sponsoring is completely OK as of now? No, not really. This initiative was specifically targeting DebConf newbies, but several DebConf "regulars" are planning to attend too. For some of them the amazing DebConf sponsoring team has already found enough resources to secure their travel sponsorship, for quite some others it is not the case yet. This is a pity, because we know from the past that having more Debian folks at DebConf means more hacking, a better distribution, and a better community, ultimately it means a better Debian. Some of the readers of this blog post will be in the condition to improve the situation: it is as simple as donating to Debian or, better, becoming a DebConf10 sponsor by simply mailing the sponsoring team.

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to. The motivation I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around. As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc. In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm-crystalhttp://www.fvwm-crystal... as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs. The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in. I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc but well, I did not like them, there were not powerful enough, too bugged or upstream was insane. Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack. I subscribed to the dwm mailing-list, in order to participate to its development, etc But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches. That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas The jdwm I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc On 5th September 2007, I created a git repository to host my code. That's gonna be awesome. Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word. The 1.x branch The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash. The 2.x branch The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch. At this time, between December 2007 and April 2008, the community was growing smoothly. But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them. One of the event that started to change my mind was the support for titlebars. When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc. And then users started to ask for more, like: "add titlebar on windows only when the window is floating". That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>? The 3.x branch Why At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration. So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here. But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library. His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB. Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format. Development It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly. It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine. We're still here Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June. One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user. For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows. Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen. But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good. But I admit that it built a bad reputation around awesome 3.x during its first month of existence. Future direction I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area. Conclusion My post title is "Taking the other direction" because I feel this way. I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard. When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user. Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway. And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes. I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble. We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable. And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not. You can even write and play space invaders. Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to. The motivation I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around. As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc. In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm crystal as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs. The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in. I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc but well, I did not like them, there were not powerful enough, too bugged or upstream was insane. Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack. I subscribed to the dwm mailing-list, in order to participate to its development, etc But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches. That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas The jdwm I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc On 5th September 2007, I created a git repository to host my code. That's gonna be awesome. Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word. The 1.x branch The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash. The 2.x branch The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch. At this time, between December 2007 and April 2008, the community was growing smoothly. But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them. One of the event that started to change my mind was the support for titlebars. When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc. And then users started to ask for more, like: "add titlebar on windows only when the window is floating". That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>? The 3.x branch Why At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration. So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here. But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library. His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB. Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format. Development It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly. It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine. We're still here Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June. One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user. For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows. Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen. But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good. But I admit that it built a bad reputation around awesome 3.x during its first month of existence. Future direction I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area. Conclusion My post title is "Taking the other direction" because I feel this way. I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard. When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user. Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway. And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes. I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble. We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable. And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not. You can even write and play space invaders. Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

Last week I sent a mail about the upcoming developement strategy for awesome. Long story short; we begin to work on awesome 3, dropping Xlib in favor of XCB, bringing out the first window manager using this bindings (if you do not count the demo one in the source repository ;-)). Thanks to the amazing grunt work of Arnaud Fontaine, we already have a working version of awesome using XCB, and it works very very well. Better API, better code, and even faster code. That is awesome. awesome 2.3-rc1 was released this morning so we'll begin shortly to work on the 3 branch and merge it into the master one.

These last weeks, Enrico and me have worked on a GUI frontend for pmnew. At the moment, the prototype is limited to the task of finding new packages to install. The goal of pmnew-gui is to have every little detail designed to be as smart as possible: for example, the list of packages shows at the top the packages that the system thinks you are interested in having comparing your system to thousands other systems. Screenshots http://people.debian.org/~enrico/2007-02/sshot-startup.png
http://people.debian.org/~enrico/2007-02/sshot-audio.png
http://people.debian.org/~enrico/2007-02/sshot-games.png Get it

bzr branch \
http://people.debian.org/~enrico/2007-02/pmnew-gui/

Setup The README gives some details about the setup. In short you will have to do the following steps:

apt-get install python-debian python-deb822 python-xapian \
python-apt python-glade2 python-gtk2
./update-data
./pmnew-gui

It works better if you have a network connection, and if you have popularity-contest installed and running. Feel free to send us feedbacks about the GUI. Links

• "The original brain dump"
• "The commandline draft"
• "Various ideas on improving package managers"

pbuilder tips Many thanks to Arnaud Fontaine for providing me with the solutions to all pbuilder problems I had during the last years. This is what happens to me: someone reports a bug in debtags, and it turns out that the bug needs fixing in libwibble. I start by fixing libwibble, then I need to recompile libtagcoll2-dev, then use it to recompile libept-dev, which I can finally use to rebuild debtags. A normal pbuilder setup would only take dependencies from apt sources, so I need to create an APT source with the packages I just built and feed it to pbuilder. Now, thanks to Arnaud's suggestion, I have the easy way to create the APT repository:

$ cat update-aptsource
#!/bin/sh
cd /var/cache/pbuilder/result
dpkg-scanpackages . /dev/null   gzip -9 > Packages.gz
echo "Running pbuilder update..."
su -c "pbuilder update"

Since pbuilder works in a chroot environment, the easiest way of making it access the repository is via http. First I put the new repository online:

ln -s /var/cache/pbuilder/result /var/www/debian

Then I add it to /etc/pbuilderrc:

OTHERMIRROR="deb http://localhost/debian/ ./"

Then I tell pbuilder to update the configuration inside the chroots:

pbuilder update --override-config

And finally I can build my stack of packages. This is probably not rocket science for many DDs. What I'm really appreciating here is using the minimum amount of pbuilder customization and of lines of code of extra infrastructure to maintain. Now, at every compile round, I just need to run that update-aptsource script to inject into the system the dependencies that I have just built. Update: Josh Triplett sent the configuration options to avoid using an HTTP server and use pbuilder's bind-mount facility:

OTHERMIRROR="deb file:/var/cache/pbuilder/result/ ./"
BINDMOUNTS="/var/cache/pbuilder/result/"

These days, i have worked a lot for the SoC in order to define the design of the web and mail interfaces, helped by Raphael Hertzog. Everything has been committed to the arch repository of the project. Now, i will post news about the progress of the SoC on my blog and on the soc-coordination mailing list. Web interface I have begun by the tree of the web interface. One of the feature of wotomae is to be editable by everybody. However, we must have an administrator's group for a tracker (for mass bug filling or the blacklist). I have worked with Raphael for writing mockups intended to give an outline of the web interface, and especially to detail the features of the most important pages. It is possible to define custom fields (upstream version...) where the datas are given using the mail interface by external scripts or by the user if it can be done easily. It is also possible to define visual preferences on custom fields. The implementation of the web interface will be written with Turbogears, which has interesting features, like :

• Internationalization
• Form validation
• Tests

Finally, I chose ZODB. Because the accounts database has to be share with other interface, which won't necessary use python, a secure XML-RPC API will be written for accessing the accounts' datas. Mail interface The goal is to obtain a flexible interface, allowing to make some tasks easier. At the moment, these commandes have been defined (some examples are availabe on the wiki):

• tracker for choosing a tracker where the commands will apply.
• assign adds packages and bugs to a previous selected tracker.
• lock assigns a package to a developper.
• setfield apply a field to a package.
• addcomment add a comment to a specific package.
• thanks ends the commands' list.

Any comments about the design are obviously welcome.

These days, i have worked on planet debian package. At first glance, it seemed easy to package but actually it wasn't, mainly due to debconf and FHS problems. A package is temporarily available at this address. The main features of the package is the usage of debconf to configure cron interval and also handles /etc/planet.conf for main options. Any comments are obviously welcome.

I was really glad to be accepted for Google Summer of Code. My (accepted) proposal was on DWTT (Distribution Wide Tracker Tool) and CRMI (Collaborative Repository of Meta-Informations about source packages) mentored by Raphaël Hertzog. I have worked a bit on DWTT today and have written a webpage on the Debian wiki about the project. I'm currently pondering which is the best python framework to use :

• Cherrypy/ZODB
• Turbogears/SQLObject.

Having recently used ZODB (this means Zope Object DataBase) in a project, I think it's a great object database because it's very tightly integrated with Python, which makes it easy to use for programmers. ZODB is python-specific though, whereas SQLObject backends (for MySQL and Postgres) makes it language-independent. In the next weeks i will work on DWTT design. Until june 16, I have a lot of school work, which is why I won't have enough free time to work on the project, hence a slowdown in the project.

I have to agree with Joey, I have the feeling that we’re not doing many “transversal” improvements and that we’re busy enough simply trying to keep up with new upstream version of software. That’s not completely true but I also wouldn’t want Debian to evolve in that direction. I think that less people are interested in doing large scale changes because the coordination with 1000 maintainers and 10000 packages is simply too complicated and taking too much time. Luckily we had significant improvements recently that should ease that coordination work. I’m thinking mainly of the usertags that allow us to use the BTS as big TODO list. But usertags are obscure to many people and not well documented yet. So there’s room for improvements: that’s why I proposed a project for Google’s Summer of code called “Distribution-wide tracker tools” (see list of accepted projects here). Check the project proposal of Arnaud Fontaine to have a more precise idea of what it could give. I want this infrastructure because I think it may help Utnubu to effectively coordinate the integration of Ubuntu improvements and because it may help Debian be more on the leading edge (instead of trying to catchup with derivatives). And last but not least, I believe many more people (with different level of skills) will be able to effectively work on some projects once the work to do has been clearly identified and registered in such a system. The project is about to start, so all ideas/comments are welcome of course!

Congratulations to all whose projects were accepted, Debian received 60 eligible proposals, many of those were great projects which we would have loved to accept but we only had 10 slots that are paid for by Google so the competition was tough. The accepted projects are:

• "Improve the boot system" by Carlos Villegas
• "Translation Coordination System" by Gintautas Miliauskas
• "BTS GUI front-end" by Philipp Kern
• "debian-cd-ng" by Carlos Parra Camargo
• Debtags, using AI classifiers for automating the tagging of Debian packages" by Alex de Landgraaf
• "Distribution wide-tracker tools (DWTT) and collaborative repository of meta-informations about source packages (CRMI)" by Arnaud Fontaine
• "Automation of Debian Based live-cd creation process" by Robert Pickel
• "Improve Britney, the scripts used to update testing" by FABIO TRANCHITELLA
• "Debian installer on Debian GNU/Hurd" by Matheus Eduardo B. Morais
• "BitTorrent Extensions" by Matthew Wronka

All the accepted projects received email to them and their mentor, if you are a student whose project wasn't accepted, we'd still be happy if you will do the project even without the funding, if you need a helping hand or a mentor we will surely be happy to help you out, contact me at baruch@debian.org. The plan is that students who have a blog or setup one for the Summer of Code will be added to Planet Debian so everyone can follow their progress on their quest to help Debian improve. Cheers and thanks to everyone who helped make this happen!
Baruch Even
Debian SoC coordinator

Woohoo. I just spent something like 6-8 hours today on squashing bugs, and some hours also yesterday.
I uploaded about 10 packages I guess, fixing at least 10 RC bugs ;-), plus some NMU from Arnaud Fontaine and Mohammed Adn ne Trojette who I sponsored.
I also wrote a security patch for webalizer. But finally, my hunting for RC bugs ended up with 2 hours of QA activity, pinging maintainers or asking for removal of some old and buggy packages. P.S: Maintainers, if I NMUed your packages, please don't blame me too much, that was a BSP with 0-day-delay-NMU. I just gave love to your packages. And some love doesn't kill anyone ! 8-)

FOSDEM 2006 This year, the days before FOSDEM were the stressful ones, as I got to organize accomodation. Initially, we wanted to have similar appartments as last year, but by the time I was less busy at uni to actually look into it, most of them were already booked, so we had to put up with a youth hostel instead. The positive sides of this were the much lower expenses and a location in the city centre, making us actually look at Bruxelles a bit in detail this time. "Us" were the Hurd people, including Martin "earliest Hurd adopter present" Michlmayr. I got to FOSDEM by car again, picking up Marcus Brinkmann, Neal Walfield and Olaf Buddenhagen on the way in Cologne. Finding the youth hostel seemed to be pretty hard as we just had a street address and a map without street names, but we managed to find it pretty quickly to my great surprise (driving around in Bruxelles usually ended up being a complete disaster over the last years). After a strange encounter with a Guillem Jover lookalike in front of the hostel, we met the other guys (Thomas Schwinge, Marco Gerards, Stefan Siegl and Ognyan Kulev) and had a discussion about Neal's and Marcus' plan to move to a persistent system. After dinner, I met the other Debian people in the Roi d'Espagne and hat some longer chats with Jeroen van Wolffelaar, Rob Bradford, Martin Michlmayr and Jordi Mallach, who I finally met for the first time and who did not cop out of FOSDEM this year as usual... The pub is getting more and more crowded each year, all the hackers barely fit even though they opened the balustrade this time as well. It was great to see everybody again and have a few beers. Martin and I then managed to find the way back to the hostel by foot. We had no developer room, and no talks in the Debian room either, so FOSDEM was a pretty relaxed event this year. I met some more familiar faces like Noel Koethe and Andreas Mueller and listened to a couple of talks, most notably Richard Stallman's and Jeff Waugh's keynotes and Hanna Wallach's talk about FLOSSPOLS. Stefan Siegl also managed to get GNU Mach working for both my 3Com PCMCIA NIC and my Orinoco PCMCIA WLAN card, confirming his title as Hurd "hacker of the month". On Saturday evening, we (at this time, Guillem Jover, Gianluca Guida, Bas Wijnen and Jeroen Dekkers had joined) had dinner with the french Hurd guys (Manuel Menal, Marc Dequenes, Richard Braun, Arnaud Fontaine and others) in an italian restaurant. At 10:40 PM, the waiter told us in a rather unfriendly tone that they would close at 11 and presented us with the bill, along with handing out the menu again so that we could look up our share. By the time the bill arrived the french part of the table (at 10:55 PM), the guys were pretty surprised by this whole business and complained loudly that they did not have a dessert yet and insistent on having one. After some more minutes of discussion, the waiter gave in and served their desserts, after which each of them paid his share with his carte bleue. I believe we left the restaurant around 11:30. On Sunday evening, we had dinner again (the french guys had left Bruxelles already) and then drove back to Germany after having desserts and coffee in a bar. We left Bruxelles at around midnight and arrived in Duesseldorf at 2:30 PM, so we were glad that Neal offered us to stay at his place. We had breakfast the next morning with him and Isabel and then I proceeded to drive back to Frankfurt in the early afternoon. FOSDEM rocked, as usual. After being with the Debian crowd for the first three years or so, and mostly sticking with the Hurd crowd last year, I think I managed a pretty good balance between the two this year. This will not have been my last FOSDEM.