My previous blog entry about Test Driven Distro Development (TDDD) was rather rambling. Here is the condensed version, plus some further thoughts. I would like to automatically determine whether "testing" is minimally ready to be released, at any given point in time. To implement this, I would like to see Debian get tools that would allow us to define specific minimal functionality that should work in a Debian release, and automatically verify that it does. I would like us to use these tools to determine whether a release is ready for release, with manual override from the release team. Ideally, we would use the tools to prevent breakages from moving into "testing", so that it gets closer to always being releasable. Getting test coverage sufficiently high that we can replace the release team's judgement abour releasablity will never happen: Debian is rather too large and and complex for that. However, we can reap much benefit from even relatively small coverage. Here is my initial suggestion for the minimal criteria that should be satisfied, at all times, in "testing". They are aimed at making sure that even if something else breaks, at least the basic stuff works well enough that one can log in and fix things.

• there are no open ports in a base install
• logging in via getty works
• logging in via ssh works, if openssh-server is installed
• su, sudo, ls, cp, mv, rm, and vi work at least in some typical use cases
• web pages can be accessed from outside the system, given suitably configured apache2
• after automatic login into a graphical desktop environment, all the crucial per-session programs start up, as well as web browsers and other GUI programs that almost everyone expects to be part of a desktop environment
  • if there are good GUI testing tools, we may want to test in more detail, but that may have to wait for later

These are minimal criteria. They're not meant to verify that everything in Debian works. After these work, adding more coverage is not just possible, but reasonably easy in many cases. Want to make sure DNS gets configured right? Write a test that logs in and does a lookup inside the test system. After the tools have evolved, writing a simple test like that should be only a line or two. The tests I am talking here are system tests, or acceptance tests for the whole system, not just for individual packages. Unit tests would test individual functions or methods or classes; integration tests would test groups of them, or possibly entire programs; system tests test groups of programs/packages. The point is not to verify that every package works in every possible case, but that the system as a whole works. Most package-specific functional tests should be part of the package's own test suite. We should also run those, but that's somewhat orthogonal to the vision I'm trying to articulate here. At least the following scenarios should be tested (the above tests should be run after each scenario):

• install "stable" and upgrade to "testing"
• install "testing" using latest d-i release, and upgrade to current "testing"
• use an install from the previous successful test run, and upgrade to the current "testing"
  • this answers the question "if testing worked yesterday, does it still work if we add these new packages"

It may be useful to run the tests against "unstable" as well as "testing". However, rejecting an upload to "unstable" may be less wise than preventing packages from being copied from "unstable" to "testing". Exactly how this the development processes should adopt TDDD is an interesting question, but a reasonable toolset should be adaptable to anything we want to do. (Indeed, it would be possible to structure the toolset so that it isn't specific to developing a distro: a "system-test" tool that a sysadmin could use to verify that a server works would probably be useful to some people. Perhaps such a tool exists and could be adapted for TDDD?) Running these tests for security updates to "stable" would obviously also be a possibility that should perhaps be considered. Running these tests would happen something like this:

• generate a suitable virtual machine disk image, configured in the proper way for the test
• run the image under virtualization (or on real hardware if that can be remote-controlled suitably)
• run the tests against the image
• if tests fail, archive the image (or sufficient information to reproduce the start image)
  • also, automatically file bugs against all packages involved in the test, and e-mail debian-devel-announce with the names of the people who uploaded the new versions of packages compared to the previous successful test run, Cc'ing their spouses and parents for further shaming, and also Cc'ing the Debconf organization team so they can stood up before an audience armed with rotten tomatoes and eggs (this bullet point is here only to see if anyone actually reads my blog posts)

I would further like to see Debian make it possible to have isolated branches for development. This would help with, for example, large transitions that take a long time. The transition could be prepared in a branch of its own, and when it's ready to be pushed into unstable, the automatic tests outlined above could be used to verify the transition doesn't break anything too critical. (If the tests fail, the push fails; if necessary, that can be overridden manually, but that should be rare.) In my view, branches would greatly benefit Debian development, but they're not necessary for starting to implement TDDD. My condensed versions are still too long.

Hi, been offline for a while and now after my mid-term exams I m glad to tell that I ll be working on this year s GSoC project called: Compute Clusters Integration for Debian Development and Building . The main idea for this project is to give Debian developers and downstream developers a set of tools for helping them to leverage the power of a cloud-based infrastructure for their development duties. This is specially targeted to porters, multi-arch and cross-development, So I ll ask such teams for feedback on the subject over the next days. People at Eucalyptus has been very helpful and willing to cooperate with us to make this project a success. We expect to get them involved on the packaging and probably as Debian contributors, if not developers, also. Next week is the official coding phase start, but I ve been talking and working together with my mentor Steffen and the Eucalyptus people already. We ll be starting working on the qemu ARM images, reusing and resuming the job did by Dominique Belhachemi in the past GSoC. Of course I welcome as much feedback as you might find useful. I plan to post a project update every two weeks.

Bug: never been to DebConf. Fix: DebConf newbies. Last year we have funded the DebConf newbies initiative to encourage Debian contributors who have never attended DebConf, to actually do so. There are plenty of reasons for doing that; as I wrote back then: My personal belief is that attending DebConf increases the enthusiasm of attendees and ultimately will make them better Debian citizens. It surely happened to me years ago: in the beginning of my Debian membership (as DD, since DMs did not exist back then) I just cared about my pet packages. It was only after meeting the Debian crowd in person at a FOSS event (LinuxTag 2004, IIRC) that I got really enthusiastic about Debian, gradually increasing my involvement in the project. I've never regretted it. This year, we are doing DebConf newbies again (see also Ganneff's blog post on the topic, for extra goodies). Deadline for applying (via newbies@debconf.org) is June 18th, although you should better register before May 19th to the conference proper to get sponsored accomodation.

---

Update: fix deadline date

I was hosting my projects on several Trac instances on a dedicated server. However, since several months, spam was pourring.

Trac & spam

How to fight spam with Trac There is not built-in mechanism in Trac to fight spam. However, plugins enable to setup several ways to stop spam (or at least, reduce it). One of them is Akismet, a web service who can tell you if some message is a spam or not. It is able to catch most of the spam. A bayesian filter complement this service. A learning step is mandatory and can become cumbersome when the vast majority of the tickets you receive is just spam. I used those two mechanisms on my Trac instances. Another path is to require an account to post a ticket. Creating an account each time you want to create a ticket for some software is burdensome. I did not want to do this to the poor souls that have found a bug in one of my projects. An alternative is to setup a public account and adding somewhere in the page some instructions on how to use it when you want to open a ticket but don t want to open an account.

Removing spam Despite Akismet and the bayesian filter, I still got two or three spams a day. I catched them in my RSS flow or in my email if they were not classified as spam. There are two steps to remove the spam:

• tell the bayesian filter by using the administration panel in the web interface,
• remove the spam from the database using some SQLite commands directly on the server hosting the Trac instance.

Indeed, Trac does not propose the possibility to remove a ticket. Of course, there are plugins, but you must find them, install them, find how to configure them, etc. Cumbersome.

GitHub GitHub is a popular source code hosting service which uses Git as a backend. This is a proprietary platform but a lot of open source projects have migrated to it, thanks to its features and the good performances. Everybody is on GitHub. This was the ideal opportunity.

Features First, GitHub allows to host Git repository. You push your Git repositories. There is a nice and fast web interface to browse them. However, I still keep an instance of cgit. Then, GitHub is very popular because they drive people to fork projects. With one single click, you can fork your favorite project. You get a copy which is synchronised with the forked project. There is also a wiki (accepting many markup syntaxes). This wiki is also available through Git. At last, GitHub offers a minimalistic ticket system. You open a ticket, you make some comments, you can add a tag or two and you can close it. That s all. Quite light. But enough for small projects like mine. However, there is more! Do not open a ticket to send a patch. There is no way to attach files to tickets. You need to fork the project, create a branch with your patch and request a pull for your branch. This will appear as a ticket but your commits will be linked to it. The author can then review and comment your branch, ask for some changes and if he wants to integrate it, a simple merge is sufficient. He can even do it using the web interface. Convenient. Socially, you can comment commits, tickets, projects and subscribe to a lot of events. You can receive and answers tickets by mail. However, an accound is mandatory to open a ticket. Since there is a lot of projects on GitHub, this account should be useful for a lot of software. To cut a long story short, even if GitHub is a proprietary platform, it offers nice and interesting features. More and more projects migrate from Google Code to GitHub even if there is less features on the latter.

Migration I have searched for tools to migrate automatically tickets from Trac to GitHub. For example, there is SD. At last, I have done it manually. GitHub API is well documented and there exists bindings in various languages including Python but it is a very limited API. You can t choose the number of the ticket nor its date. I have also rewritten README files to use the markdown markup and avoid the use of wiki pages when possible. I have also put some URL redirections with the help of nginx. In conclusion, even if maintaining Trac instances was not a lot of work, one thing that I do not have to do anymore. And no spam on GitHub, I assume.

Images Moved

So I've retired my old picture hosting sub-domain, and moved all the files which were hosted by the dynamic system into a large web-root. This means no more uploads are possible, but each link continues to work. For example:

• http://picshare.steve.org.uk/2OrKrfem9XQWz.jpg

Happily the system generated "random" links, and it was just a matter of moving each uploaded file into that static location, then removing the CGI application. The code for the new site has now been made public, although I suspect there will need to be some email-pong if anybody wishes to use it. Comments welcome.

MySQL replacements?

Lets pretend I work for a company which has dealings with many MySQL users. Lets pretend that, even though it is true, such that I don't have to get into specifics. Let us pretend that we have many many hundreds of users who are very happy with MySQL, but that we have a few users who have "issues". That might be:

• mysqld segfaulting every few months, with no real idea why.
  • Transactions are involved. So are stored proceedures.
  • MySQL paid support might have been perfect, or it might have lead to "yup, its a bug. good luck rebuilding with this patch. let us know how it turns out kthxbai."
  • Alternatively it might not have been re-producable.
• Master-Master and Master-Slave setups being "unreliable" such that data inconsistencies arise despite MySQL regarding them as being in sync.
  • Good luck resolving that when you have two almost-identical "mysqldump" outputs which are 6Gb each and which cause "diff" to exit with "out of memory" even on a 64Gb host.
  • Is it possible to view differences in table-data, via the binary records? That'd be a fun project .. for a masochist.
• Poor usage of resources.
• Heavy concurrancy caused by poorly developed applications in a load-balanced environment, leading to stalling queries. (Wordpress + Poor wordpress plugins I'm looking at you; you're next on my killfile).

To compound this problem some of these installations may or may not be running Etch. let us pretend they are not, just to simplify things. (They mostly arent' these days, but I'm sure I could think of one or two if I tried) So, in this hypothetical situation what would you recommend? I know there are new forks aplenty of MySQL. Drizzle et al. I suspect most of the forks will be short-lived - lots of this stuff is hard and non-sexy. I suspect the long-lived forks are probably concentrating on edge-cases we've not hit (yet), or on sexy exciting things like new storage engines and going nosql like all the cool kids. Realistically going down the postgresql road is liable to lead to wholly different sets of problems, and a significant re-engineering of several sites, applications and tools with no proof of stability. Without wanting to jump ship entirely, what, if any, are our options?

PS. MySQL I still mostly love you, but my two most recent applications were written to use redis instead. Just a coincidence... I swear. No, put down that axe. Please can't we just talk about it?/p> ObQoote: "I've calculated your chance of survival, but I don't think you'll like it. " - Hitchhikers Film.

Like last years initiative from Joey we have another opening for DebConf Newbies . Turns out this year it is me doing the main work for it, so here we are: If

• you never have been to a DebConf, or
• you last saw the conference in 2007 (Scotland)
• you can schedule a week off in July
• fear you might not make it with the normal sponsorship process ( they will never ever pick ME, im too small an ant in this project )

then this is for you. To apply for this funding, email newbies@debconf.org before 18th of June. The earlier you mail, the better, as funding will be given out in a first-come/first-serve way. In your email include an estimate of your travel costs, from where you travel from and the amount you are unable to fund yourself. I also need to know the dates you plan to arrive and leave. Please indicate if you will also need sponsored food and accommodation. (At the time of this writing you can still get sponsored food and accommodation by simply registering with the conference, so if you read this before May 19th please ensure to register NOW). Please also ensure you register with the conference now (see DebConf11 registration, even if your plans are not fully secure at this time. There is no punishment if you can not attend later - simply do not follow the reconfirmation process shortly before the conference.

That was a damn busy week. It was mostly centered about attending SambaXP, the annual Samba user and developers conference, in G ttingen, Germany. The only free software conference I attend with expenses paid by my employer, Onera. This year was the 10th edition and, as last year, to the "who was there for the nth edition" game, I won by staying alone as they asked who attended all editions of the conference. :-) That was a great week, with time spent with people as interesting as Andrew Tridgell, Jeremy Allison, John Terpstra, Volker Lendecke, Kai Blin, to name a few. A good opportunity, again, to get input from our packaging work for that big piece of software, as well as getting visibility about the future of Samba. I also had a great, even if short talk, with the kind Karolin Seeger, the release manager of Samba for 3 years now. We talked about....children, as she's now a mother since last year (with a non negligible impact on her professionnal life, as often in Germany). Great meeting, too, with Brad Kuhn, from the Software Freedom Conservacy, who had a keynote about GPL licence enforcment activities. It becomes more and more sure that Samba3 and Samba4 will reconverge together after the Samba Team releases Samba 3.6. It brings plans for our packaging work: I think we'll stick with having samba 3.6 in wheezy while the brand new shiny Samba4 probably stays separate in some way. Our users (and /me first) clearly need stability in the file and print services first. Of course, I did some packaging work there: samba 3.6.0pre3 was uploaded to experimental, about 10 days after its official announcement. I also worked on the samba *binary* package bugs, triaging them as usual. We now have 51 bugs opened against the samba binary package: 18 unclassified, 11 moreinfo (several likely to be closed as unreproducible or user error), 1 wontfix, 8 with a pending patch and 13 forwarded upstream. I'm also thinking about a possible way to ask about SMB2 support in samba: it won't be activated by default in 3.6 (mostly because us, distros, requested for that and, by "us", I mean Debian, RHEL, SuSe and their derivatives, so quite a large consensus). Still, it would be good to put some light on SMB2 support and a debconf question about it could be a solution (not shown by default and defaulting to no SMB2). I also worked quite extensively on packages maintained by No l K the, Ralf Treinen and me, aka "the pkg-running team". I did setup a git repo for my new "garmin-ant-downloader" package, that allows downloading track files from Garmin Forerunner 405 GPS watches (guess what is the brand and model of mine!). My first packaging git repository! Thanks to Ralf for his advice and help in this. I triaged bugs in the other two packages we maintain: pytrainer (more bugs forwarded upstream) and garmin-forerunner-tools (which was later uploaded by Ralf). I also setup a team mailign list so, now, we're a real team...:-) Few activity on the l10n front: a few Smith reviews are in progress and I completed 1 or 2 French translations, and reviewed some others. Regular activity, then. The only specific stuff is that I'm now pushing harder for the French DDTP effort, doing many reviews and translations there. We try to reach 100% in the "popcon500" packages. Later, we'll try to head at reaching the hieghts reached by the Italian and German teams, who are, on this l10n activity, way ahead from us. Finally, during the SambaXP conference, and as usual (except last year because of too heavy work duties), I visited my German friends, living "close to" G ttingen, accomppanied by Luk Claes and his friend and colleague Ivo, who were also attending SambaXP. Great barbecue at Andreas and Kathrin Tille's place, facing the Wernigerode castle at sunset. And the best sp tzle ever at Meike and Alex Reichle's place in Hildesheim, with a french touch on the salad's dressing as well as great Chilean wine brought by Meike's coworker Wolfram. Always a great time to see these good friends even if that means driving a few hours (and being flashed....twice!...by german speed cameras on the way to and back Andreas place!) To complete the week, I ran a 34km/800m+ trail today in the Rambouillet forest, completing it in 3h31. I'll probably blog separately about running updates as it is now quite some time that I didn't. Guess what? I'll be sleeping well tonight...

This is just a diary of a random day sort of post. Nothing all that particularly unusual, but then perhaps if I only blog about the unusual, the typical gets lost. This week started out with temperatures as high at 99F. Today we didn t even reach 60, and tonight will be cold almost to freezing. It s Kansas, so while we remark on the strange weather, we re not particularly surprised by it. This morning, Jacob and Oliver went over to play across the street. Jacob then went with Terah to a birthday party for one of his classmates, while Oliver helped plant some trees with his grandparents. I was at home this morning, which gave me a small but welcome break from the past week: we had something going on 6 out of the last 7 evenings, and little time to do anything else. So I got out the Kindle and read from War and Peace. I started at the kitchen table while eating some granola, and then sat on the couch. The day was cold, windy, and overcast, and I like to use natural light, so there were only a few places to sit with enough light. I sat there reading the account of Napoleon s capture of Moscow in 1812, the characters lives uprooted by those events, and stories of violent mobs forming. And, of course, Tolstoy s essays on the mistake of overstating the importance of famous figures in history were common. I am now about 3/4 through War and Peace, which means I ve read 1,044 pages and have (only) 348 to go. As I got up to try to find slippers or a blanket for my cold feet at one point, I remembered a conversation I had while eating lunch this week. I was reading on the Kindle while reading, and a person I knew happened to walk past. She asked what I was reading. I said simply, War and Peace. There was this stunned silence, so I added, for fun. It s great! Which is true. She said, Oooookay, John, you just enjoy that then and went on her way. This isn t the first time I ve had a conversation like that about this book. It seems to be held up as some example of long, dry, literature that people are made to read but don t want to. I think that only long is accurate here. Anyhow, pretty soon Oliver arrived and, much to my surprise, said Doh! (meaning no ) when I asked him if he was ready for lunch. Instead he stood there looking at me sweetly. Taking a guess, I said, Oliver, would you like to watch train videos? Yeah yeah yeah yeah! So we did. He particularly enjoyed the steam engines today, and eventually was ready for lunch at 12:30. Jacob and Terah got home just as he was finishing. Oliver got his nap, and I played with Jacob for a bit. Ever since he had heard of the British wedding in preschool, he s been interested in weddings, so I showed him pictures from Terah and me at our wedding. This was a big hit. Then he went with Terah to decorate a Sunday School room at church, so I read a bit more Tolstoy. Tolstoy s characters sometimes are prone to not just changes in mood but changes in outlook and worldview changing from cold, logical, and uncaring to warm and loving, or from despair at the vanity and shallowness of humanity to elation at the simple honesty of a peasant and renewed trust in the human spirit. At first I marveled at this tendency in certain characters, but on reflection, and in consideration of the timeline of the novel, which spans several years, it didn t seem quite so strange. Things can happen to change the mood of individuals, or even a country; I can remember the national mood changing after 9/11, and again after Obama s election, for instance. I also felt a contrast with some of the characters who, due to their decisions or circumstances, lost things that mattered while chasing things that weren t as important. I felt fortunate to be at this place, with Jacob, Oliver, and Terah, and decided that we all ought to do something fun in the evening, but hadn t quite figured out what. And about that, the clouds started to break and Oliver woke up from his nap. I went up to his room, and much to his delight, played peekaboo with him for quite awhile. Eventually he was done with that game, but spotted my phone, so I helped guide his finger to launch Youtube and watch a train video over the wifi. This was certainly a Big Deal to him. After Terah and Jacob got back, I figured it was time figure out something fun to do. And what could be more fun, I decided on the spur of the moment, than a drive into town to pick up some cans of Silly String for the boys, neither of which had ever used it before. So we went to a restaurant, then bought the surprise toy (I hadn t told them what it would be beforehand), then went to an ice cream place, and finally back home. Oliver loved it. He needed my help to press the nozzle to make it come out, but still had a great time and shrieked with delight. Jacob then tried out his can, and stood in one place spraying his bright green strings all over the place. Then he took to running around the yard spraying string randomly in every direction until he finally completely emptied out the can. And after that, he gathered up some of the different colors of string and rolled them up into a ball which he was very proud of. A nice day.

There is actually some buzz around Gnome 3 and the new release of Ubuntu switching to Unity. I thought this was a good occasion to make this small post to tell that I still uses FVWM whose latest version was released a month ago. FVWM is a very old window manager. So old that nobody really knows what the F stands for. It comes with a ugly configuration by default and can be configured to look even uglier. However, FVWM is powerful and highly configurable. Moreover, it is pretty lightweight.

My FVWM configuration My configuration of FVWM is available on GitHub. It requires the use of fvwm-crystal. If you are running Debian or Ubuntu, there is a package for this. This is a set of powerful configuration files for FVWM which add a lot of goodies and themes. Unfortunately, the project site seems to have disappared. You can still grab the sources from your nearest Debian mirror. While those configuration files were great, I did not like to have such a complex desktop with all those icons and menus. However, what is great with fvwm-crystal is you can overlay your own configuration. If a file is present in your home directory, it will take precedence over the one installed on the system. So, I just wrote a new recipe. What you may want to steal from my configuration is the ability to alter the configuration depending on the fact that you are using one or two screens. With one screen, you get:

• an application panel (a launcher bar) on the upper left corner,
• an icon manager (which will contained iconified windows) on the upper right corner,
• a systray on the left of the icon manager
• a pager (which shows various desktops) just below it,
• two icon managers (which act as a taskbar) on the bottom, one for regular applications and the other one for terminal windows.

With two screens, the organization is different. The two icon managers at the bottom are on their own screens. The pager is between the two screens and the other elements are on the upper left of the right screen. If I am using a single screen and I plug another one, I do something like this to get my setup updated:

1 2	$ xrandr --output VGA-1 --auto --output DVI-I-1 --auto --right-of VGA-1 $ killall trayer ; FvwmCommand Restart

I also uses conky, a light-weight system monitor. It is started in my .xsession, not through FVWM.

Building wallpapers for dual-screen One difficulty with a multi-head setup is how to get the background set properly? . I have made a small script for generating one. Use it like this:

1	$ ./build-wallpaper.py -d ~/.fvwm/wallpapers -c -t ~/tmp/mywallpaper.png

It will randomly select two wallpapers and put them together to look nice on your dual-screen setup. It will also correct the aspect ratio, either by cropping the image or centering the image. You need the following dependencies to make script work: python-xpyb and python-imaging. UPDATE: Thomas Adam pointed to Nitrogen, a graphical wallpaper utility supporting multi-head setups. It is a great tool if you want to set manually your wallpaper but it does not allow to select a random one. Nowadays, I grab most of my wallpapers from InterfaceLIFT.

You know, GNOME Shell and I are not really strangers to each other for a long time now. I have been using it almost daily as my main desktop since late 2009, when I started shipping it to Debian experimental. That means that I had ample opportunity to both get used to it and witness the huge improvements it had with every new release. My general feeling towards GNOME 3 is this: . Yes, I love it! I love the new themes, I love the window borders, I love the top panel, the overview, the dynamic workspaces, I love the Me menu, I love the clock and the calendar, the system indicators with the beautiful symbolic icons, being able to search for applications in such a nice way, the window animations, the multi-screen support, the new nautilus, the dash, looking glass. It s hard for me to even express how thankful I am and how much admiration I have for the awesome folks who helped bring this to life. Thanks so much! After all this time, there are only two things I can say I dislike about GNOME3, apart from some minor wishlists: the alt-tab behaviour and the message tray. Let me expand on those. Message Tray Of the very few things I dislike, there is only 1 I hate and cannot see myself living with: the accordion animation in the message tray. No, really, it s such a terrible, terrible idea. Every single time I try to use that thing I overshoot while moving the mouse to the left, then overshoot again moving the mouse to the right because the frigging icon has moved. It s no good knowing that I can click in the text or in the empty area to its right, it feels wrong. It s terrible that my actual target is moving at all. Every single time I use it is a small frustration for me it s as if the message tray was playing games with me, laughing at me for not having good enough mouse pointer driving skills even more than the infamous sub-menus used to. And I had to go through that penance whenever I wanted to find the person I was chating with to resume the conversation. I wrote an extension that disables the accordion animation by simply not showing the title at all when you hover the icon, and I patched GNOME Shell s CSS to make the icons a bit bigger, so that it s easier for me to hit them with the mouse. It s clearly not ideal, and you still have to click the various people icons to figure out which of your friends who were lazy enough to not add a picture to their IM profiles is that one, but it s still much better than chasing the (smaller) ones around to figure that out. Perhaps we should have the icons be bigger and always have the title bellow them? I don t know, I trust the awesome designers who designed the awesomess that s everywhere else will come up with a great idea. Alt Tab The number 1 feature of workspaces for me has always been locality being able to not see all of the other applications and windows that are open elsewhere. This lowers the amount of noise when I m trying to find something. The overview is very nice in this matter only windows in the current workspace are shown, and even when you have an extra screen, the windows in there appear in that screen. The alt-tab behaviour, on the other hand, of showing all windows and apps, even with the separator, bothers me. It s really useful to have when you want to go to a specific window no matter where it is (I usually use the dash for that, though), but it adds noise when you want to go to a specific window _in this_ workspace, which is the most common use case for my usage. So I copied the alt-tab code over to an extension and modified it so that only windows in the current workspace would be considered. In addition to that, with the windows in the extra screen always being there no matter what workspace you re in (which I think is an awesome idea), they are effectively in all workspaces, so they add constant noise even with my extension. It s also weird to have to look at the main screen to switch to a window in the extra screen. There s a huge discontinuity. What I would prefer is having alt-tab to follow the mouse regarding screens only show windows in the extra screen if you hit alt-tab in there, making sure the selector thing appears in there as well.

While swearing at my bank's automated phone attention system, I was thinking that taking advantage in the fact they already usually say that "the call will be recorded to improve service quality" call center operators/programmers should record all user activity and, just for laughs, play back the grumbles angry users shout at the system. Of course, at random intervals, on loudspeakers, over the crowded call centers. Oh, they do it already?

After a bit of work, today I decided to start using mpm, the mancoosi package manager, to upgrade my laptop. My first use of it on a production system - until now I run all my experiments in throw-away virtual machines - and it works ! Not rocket science here. During the last month David Kalnischkies (of APT fame) visited our offices in Paris and together with zack worked out a communication protocol between apt-get and the mancoosi cudf solvers (EDSP). I guess somebody is going to announce all details about this endeavor soon. This cooperation enabled us to advance in the integration of apt-get and the mancoosi technology. Reusing the same protocol and backend I developed to translate the apt problem to cudf (and to call a suitable solver), I've re-wrote large part of mpm and added the possibility to generate the installation plan before calling dpkg and really installing the selected packages. Below notice the intermediate calls as Inject Model , Simulate, Compare Models . These are at the moment stubs that are going to call the simulation framework developed at mancoosi. The food : Reg the installation plan, this is an xml file that will be passed to a simulator developed by the university of L'Aquila to make sure that the installation script (well, a model of them), will not cause any problem during the installation. The format is a very simple xml file as follows : Soon APT will ship a patch to use the very same infrastructure of mpm (yeii !!!). This will on one hand make mpm useless as package manager on its own. It is a simple hack in python and I never tough to compete with its big brothers. On the other hand I think it will stand as a nice workbench to experiment with new ideas, to prototype new features and to make it easier for poeple that are not c++ experts to play with the APT library (thanks to python-apt) in a semi structured environment. The code is in the mancoosi svn if you want to have a look.

After a bit of work, today I decided to start using mpm, the mancoosi package manager, to upgrade my laptop. My first use of it on a production system - until now I run all my experiments in throw-away virtual machines - and it works ! Not rocket science here. During the last month David Kalnischkies (of APT fame) visited our offices in Paris and together with zack worked out a communication protocol between apt-get and the mancoosi cudf solvers (EDSP). I guess somebody is going to announce all details about this endeavor soon. This cooperation enabled us to advance in the integration of apt-get and the mancoosi technology. Reusing the same protocol, and backend I developed to translate the apt problem to cudf (and to call a suitable solver), I've re-wrote large part of mpm and added the possibility to generate the installation plan before calling dpkg and really installing the selected packages. Below notice the intermediate calls as Inject Model , Simulate, Compare Models . These are at the moment stubs that are going to call the simulation framework developed at mancoosi. The food : Reg the installation plan, this is an xml file that will be passed to a simulator developed by the university of L'Aquila to make sure that the installation script (well, a model of them), will not cause any problem during the installation. The format is a very simple xml file as follows : Soon APT will ship a patch to use the very same infrastructure of mpm (yeii !!!). This will on one hand make mpm useless as package manager on its own. It is a simple hack in python and I never tough to compete with its big brothers. On the other hand I think it will stand as a nice workbench to experiment with new ideas, to prototype new features and to make it easier for poeple that are not c++ experts to play with the APT library (thanks to python-apt) in a semi structured environment. The code is in the mancoosi svn if you want to have a look.

There's something rather glorious about a simple outdoor shower. Not as perfect as a waterfall, but more convenient. I put it together in lego mode, just snapping bits together until it seemed right. The water barrel collects the flow when the shower is not in use and also serves as ballast. And yes, there is duct tape. It's fed down from the small spring house, so the water is always nice and cold, and gravity flow gives it just enough force. I hope it will run for a couple more months at least.
Not that the alternative isn't nice too..

LightDM's a from-scratch implementation of an X display manager, ie the piece of software that handles remote X connections, starts any local X servers, provides a login screen and kicks off the initial user session. It's split into a nominally desktop-agnostic core (built directly on xcb and glib) and greeters, the idea being that it's straightforward to implement an environment-specific greeter that integrates nicely with your desktop session. It's about 6500 lines of code in the core, 3500 lines of code in the gtk bindings to the core and about 1000 in the sample gtk greeter, for a total of about 11,000 lines of code for a full implementation. This compares to getting on for 60,000 in gdm. Ubuntu plan to switch to LightDM in their next release (11.10).

This is a ridiculous idea.

To a first approximation, when someone says "Lightweight" what they mean is "I don't understand the problems that the alternative solves". People see gtk and think "Gosh, that's kind of big for a toolkit library. I'll write my own". And at some point they have to write a file dialog. And then they need to implement support for handling remote filesystems. And then they need to know whether the system has a functioning network connection or not, and so they end up querying state from Network Manager. And then they suddenly have a library that's getting on for the size of gtk, has about the same level of complexity and has had much less testing because why would you want to use a lightweight toolkit that either does nothing or is 90% of the size of the alternative and crashes all the time.

Adding functionality means that code gets larger. Given two codebases that are of significantly different sizes, the two possible conclusions are either that (a) the smaller one is massively more competently written than the larger one, or (b) the smaller one does less. The gdm authors have never struck me as incompetent, even if some people may disagree with some of their design decisions, and the LightDM authors don't seem to have argued on that basis either. So the obvious conclusion is that LightDM does less.

And, indeed, LightDM does less. Part of this is by design - as the proposal to the Gnome development list shows, one of the key advantages of LightDM is claimed as it not starting a Gnome session. And from that statement alone, we can already see that there's been a massive failure of understanding the complexity of the problem.

Let's go back to the comparisons of code size. LightDM's simple GTK greeter is about 1000 lines of code. gdm's greeter is almost 20,000. Some of this is arbitrary shiny stuff like the slidy effects that occur, but a lot of it is additional functionality. For example, some of it is devoted to handling the interface with AccountsService so gdm can automatically update when users are created or deleted. Some of it is providing UI for accessibility functionality. Some of it is drawing a clock, which I'll admit may be a touch gratuitous.

But if your argument is that your software is better because it's doing less, you should be able to ensure that you can demonstrate that the differences aren't important. And the differences here are important. For example, one of the reasons gdm starts a local gnome session is that it wants gnome-power-manager to be there to handle power policy. Closing the lid of my laptop should suspend the system regardless of whether it's logged in or not. LightDM takes a different approach. Because there's no session, it has to take care of this kind of thing itself. So the backend daemon code speaks to upower directly, and the greeters ask the daemon to implement their policy decisions.

This is pretty obviously miserable. Now you've got two sets of policy - one at the login screen, and one in your session. How do I ensure they're consistent? The only sane solution is to ignore the functionality the backend provides and have my greeter run gnome-power-manager. And now how about accessibility preferences? Again, if I want to have the same selection of policy, I need to run the same code. So you end up with a greeter that's about as complex and large as the gdm one, and unused functionality in the backend. Lighter weight through code duplication. We have always been at war with Eurasia.

The entirety of LightDM's design is based on a false premise - that you can move a large set of common greeter functionality into a daemon and just leave UI presentation up to the greeter code. And if you believe that, then yes, you can absolutely implement a greeter in 1000 lines of code. It'll behave differently to your desktop - the range of policy you can implement will be limited to what the daemon provides, even if your desktop environment has a different range of features. It'll have worse accessibility for much the same reason. And eventually you'll end up with a daemon that's absolutely huge in order to attempt to provide the superset of functionality that each different desktop makes use of.

The only real problem LightDM solves is that it makes it easier to write custom greeters, and if you're really seeking to differentiate your project based on your login screen then maybe your priorities are a little out of line. I'm sure that Ubuntu will release with a beautiful 3D greeter that has a wonderful transition to the desktop. It's just a shame that it won't do any of the useful things that the existing implementations already do.

And if you think that when LightDM finally has the full feature set of gdm, kdm and lxdm it'll still be fewer lines of code and take less memory - I hear the BSD kernel is lighter weight than Linux. Have fun with it.

I've installed Debian sid in a FreeBSD 8.2 jail and I'm seeing this weird effect:

root@debian:~# aptitude upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
                                         
User defined signal 1
root@debian:~#

This will randomly kill the normal aptitude gui, while other things like vim or dpkg-reconfigure using the 'dialog' gui will work normally.

Google is useless. strace doesn't work. ktrace gives
21131 100410 aptitude-curses CALL stat(0x9ef968,0x7fffffffe810)
21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0"
21131 100410 aptitude-curses STRU invalid record
21131 100410 aptitude-curses RET stat 0
21131 100410 aptitude-curses CALL open(0x9ef968,O_NONBLOCK,<unused>0)
21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0"
21131 100410 aptitude-curses RET open 3
21131 100410 aptitude-curses CALL fstat(0x3,0x7fffffffe810)
21131 100410 aptitude-curses STRU invalid record
21131 100410 aptitude-curses RET fstat 0
21131 100410 aptitude-curses CALL fcntl(0x3,<invalid=2>,FD_CLOEXEC)
21131 100410 aptitude-curses RET fcntl 0
21131 100410 aptitude-curses CALL getdents(0x3,0x1b9e630,0x20000)
21131 100410 aptitude-curses RET getdents 24/0x18
21131 100410 aptitude-curses CALL getdents(0x3,0x1b9e630,0x20000)
21131 100410 aptitude-curses RET getdents 0
21131 100410 aptitude-curses CALL close(0x3)
21131 100410 aptitude-curses RET close 0
21131 100410 aptitude-curses CALL rmdir(0x9ef968)
21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0"
21131 100410 aptitude-curses RET rmdir 0
21131 100410 aptitude-curses CALL write(0x28,0x7fffffffeb20,0x38)
21131 100410 aptitude-curses GIO fd 40 wrote 56 bytes
0x0000 4026 a000 0800 0000 0200 0000 0800 0000 0000 0000 0800 0000 0000 0000 0000 0000 2818 0803 0800 0000 a0f9 9d00 0000 0000 0100 0000 @&..............................(...................
0x0034 0000 0000 ....

21131 100410 aptitude-curses RET write 56/0x38
21131 100410 aptitude-curses CALL sigprocmask(SIG_SETMASK,0,0x7fffffffeaf0)
21131 100410 aptitude-curses RET sigprocmask 0
21131 100410 aptitude-curses PSIG SIGUSR1 SIG_DFL


Anybody has an idea?

root@debian:~# uname -a
GNU/kFreeBSD debian.home 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Wed Apr 6 09:52:09 CEST 2011 root@frost.local:/usr/obj/usr/src/sys/PEVANEYN x86_64 amd64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GNU/kFreeBSD

This entry was originally posted at http://pvaneynd.dreamwidth.org/140395.html. Please comment there using OpenID.

IPv6 adoption is increasing, and along with it come a new set of behaviours and defaults that system administrators and users must learn and become familiar with. I was recently caught out by Linux s handling of IPv6 router advertisements (RAs) when forwarding is also enabled on the interface. It took me a while to figure out and searching for obvious terms (such as those in the first half of the title of this post) didn t immediately yield useful answers, so here is my attempt to help shed some light on the subject. By default Linux will ignore IPv6 RAs if the interface is configured to forward traffic. This is in line with RFC2462 which states that a device should be either a Host or a Router. If you re forwarding packets you re a router and you re therefore expected to be sending RAs, not receiving them. This policy does make a certain amount of sense but there are obviously situations where it can be useful to accept RAs and still forward packets over the interface[0]. The confusing part is that the Linux IPv6 stack allows the accept_ra sysctl to be set to 1 (enabled) at the same time as the forwarding sysctl is set to 1, yet all incoming RAs are ignored with no hint as to why. If you re not aware that the default behaviour is to ignore RAs when forwarding is enabled it looks very much like autoconfiguration has simply broken. The key piece of information is that makes everything as clear as mud is realising that the forwarding and accept_ra sysctl s are not simple boolean enabled/disabled flags like many of their brethren. There are instead three possible values for each, all clearly documented in sysctl.txt, when you take the time to read it. Ironically the documentation states the type of the values as BOOLEAN even though they re not at least it helped me to feel better about my hasty assumption that the sysctl s were boolean values.

accept_ra BOOLEAN
Accept Router Advertisements; autoconfigure using them. Possible values are:
0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements
even if forwarding is enabled. Functional default: enabled if local forwarding is disabled.
disabled if local forwarding is enabled.

The documentation for forwarding is similar, but much longer, so you can refer to the link above to see it. Conclusion: If you want to autoconfigure IPv6 addresses on an interface that you re also forwarding IPv6 traffic over, you need to set accept_ra to 2. No doubt there are more IPv6 quirks and defaults like this waiting to trap me in the future [0] Arguably you really don t want to be autoconfiguring addresses on your router ever, but that s a philosophical debate that isn t really relevant to this post.

Two weeks ago, PostgreSQL announced the first beta version of the new major 9.1 version, with a lot of anticipated new features like synchronous replication or better support for multilingual databases. Please see the release announcement for details. Due to my recent moving and the Ubuntu Developer Summit it took me a bit to package them for Debian and Ubuntu, but here they are at last. I uploaded postgresql-9.1 to Debian experimental; currently they are sitting in the NEW queue, but I m sure our restless Debian archive admins will get to it in a few days. I also provided builds for Ubuntu 10.04 LTS, 10.10. and 11.04 in my PostgreSQL backports for stable Ubuntu releases PPA. I provided full postgresql-common integration, i. e. you can use all the usual tools like pg_createcluster, pg_upgradecluster etc. to install 9.1 side by side with your 8.4/9.0 instances, attempt an upgrade of your existing instances to 9.1 without endangering the running clusters, etc. Fortunately this time there were no deprecated configuration options, so pg_upgradecluster does not actually have to touch your postgresql.conf for the 9.0 9.1 upgrade. They pass upstream s and postgresql-common s integration test suite, so should be reasonably working. But please let me know about everything that doesn t, so that we can get them in perfect shape in time for the final release. I anticipate that 9.1 will be the default (and only supported) version in the next Debian release (wheezy), and will most likely be the one shipped in the next Ubuntu LTS (in 12.04). It might be that the next Ubuntu release 11.10 will still ship with 9.0, but that pretty much depends on how many extensions get ported to 9.1 by feature freeze.

My previous website was generated (dynamically) with mod_autoindex, a module from Apache targeted at rendering an index page for the files contained in a directory. Pretty basic (but themable). Here is a new revamped web site using Hyde, a static web generator written in Python.

Static or dynamic ? It has been a long time since almost everybody is creating dynamic websites. Most often, they are powered by some blog engine written in PHP like DotClear or WordPress. Infrequently, they are crafted with bare hands using one s preferred language. Nowadays, hosting a dynamic website is pretty easy. There are a lot of cheap virtual servers solution that allow you to get a root access. However, dynamic websites have some drawbacks:

• Security need to be monitored tightly, especially security upgrades; some platforms are more often vulnerable than others.
• Dynamic websites may have some problem to handle increased load.

With a static website, security problems are easier: there are far less components to monitor and most of them (for example, the web server) are pretty solid and well audited. A site powered by nginx can handle several thousands of new connections per second without any special tuning. Getting this kind of performance with a dynamic website is far more difficult. Scaling is also easier. Just add more webservers and copy the content. No database, no synchronisation mechanism needed. Hosting can even be done on simple platforms like Amazon S3, even if there is now more appropriate platforms for this like Amazon CloudFront. Moreover, even a static website can receive comments using a system like Disqus which leverages the use of Javascript to add comment system to any static page.

Hyde Hyde is a static website generator written in Python. There exists a lot of those beasts. On StackOverflow, a question about this got some interesting answers. You will also find a fairly complete list on this blog. If you like Ruby, I assume that nanoc and Webgen are good candidates. Let s go back to Hyde. It was rewritten recently and the documentation is a bit incomplete. You will need to read the source code or look at examples (like the shipped one or this site) to understand how things are handled. Everything is handled by a plugin system. I hope it will not become a mess in one year (I play a large part in this). Hyde takes your files, apply a lot of filters on them and generate the final website. It uses Jinja as a template system, Markdown for markup syntax, Less to write CSS in a more efficient way (and to minify them), UglifyJS to minify Javascript, etc. It is also possible to add metadata to files (title, author, creation date, etc.). But since everything comes as a plugin, you can use any technology you like. In the end, you can tune all knobs but you need to do most of the work (HTML, CSS, Javascript), as well. Conveniently, there is a small web server that rebuild modified files on the fly. This comes handy but this is a common feature with this kind of generator.

New website Here is a new website crafted with Hyde. It is translated both in French and in English. This is done with the help of a small plugin plugin. I am quite happy about the result. Technically, there is one minified CSS file, one minified Javascript file and the dependencies (like jQuery) are loaded with the help of yepnope.js which will become part of Modernizr. I don t want to support Internet Explorer 6, but I plan to support Firefox 3, Internet Explorer 7 and recent versions of Chrome and Safari. For the design, I have always been undecided. I am pretty impressed by some raw website but also by some others more elaborate. Since I am not a talented graphic designer, I have tried to keep things plain and simple. If you are interested, sources are available on GitHub !