Amaya writes about the fact that the political process in many countries is extremely flawed and is failing their citizens [1] (although she doesn’t actually express it in that way). She asks how a revolution can be done right. If we look at the historical record, after the French Revolution came the Reign of Terror [2], after the English Civil War Oliver Cromwell [3] took power - his actions are widely regarded as genocidal, and as for the Chinese and Russian revolutions - it seems that the majority of the population didn’t benefit much (if at all) from them. Generally it seems that the only times that a revolution seems to give a good result is when the situation was really bad before AND when the government failed basic measures such as ensuring food supplies. The independence for the Indian sub-continent which derived from Ghandi’s work can be used as a counter-example. However the ongoing low-level warfare between India and Pakistan is due to a failure of the process. It seems to me that the required first step towards changing a rotten political system with a minimum of bloodshed is to improve communications. If the majority of the citizens know what is really happening in their own country, how their standards of living compare with those in other countries, and what deals are made between their government and the governments of other countries then they can attempt to work out the best way to improve things. The free software community is already doing a good job of facilitating communications. The key areas are to have computers that act on behalf of their users (not using proprietary implementations and Digital Restrictions Management to make them act on behalf of corporations and the state), to support strong encryption with public implementations, to be generally as secure as possible, and to run on the cheapest possible hardware so that everyone gets access.

• [1] http://amayita.livejournal.com/187581.html


• [2] http://en.wikipedia.org/wiki/Reign_of_Terror


• [3] http://en.wikipedia.org/wiki/Oliver_Cromwell

Share This

Recent news are confirming that Debian’s choice to not comply with Mozilla’s trademark policy and rename Firefox to Iceweasel was a good one. When the issue came up two years ago, most people focused on the wrong issue of Mozilla demanding to review the patches we apply, and while two years ago that would have been an actual burden, I must say they have improved in the last months on the patch review (and even inclusion) side. If they had changed the license for their logo (which was the actual uncircumventable problem), I might have considered changing the name back. That would obviously have been a mistake, as Mozilla has found another creative way to badly behave. I’m so glad we chose the Iceweasel road. Now, speaking of this infamous EULA, I filed a bug a while ago, because the EULA would also show up on unbranded builds, which was “resolved” invalid. Apparently, the main reason for keeping the EULA is because of the use of services that require an EULA, such as safebrowsing. The only terms related to this that I can see are:

5. WEBSITE INFORMATION SERVICES. Mozilla and its contributors, licensors and partners work to provide the most accurate and up-to-date phishing and malware information. However, they cannot guarantee that this information is comprehensive and error-free: some risky sites may not be identified, and some safe sites may be identified in error.

Does that really require to read the rest of the legal boilerplate ?

Here's one more post for my own little "advertising section", where I introduce gender-related projects that I think are a good idea but deserve some more publicity. So, last time we had geekspeakr.com, this time I'd like to introduce to you the Eleonore Digital Project. In a nutshell they are organising a project where groups of students all over Europe work together in creating an educational 3D computer game that deals with the life of Eleanor of Aquitaine. Each team is assigned an episode or a certain aspect of Eleonore's life and they will research this, draft a concept and finally create their respective part or episode of the game. Doing this they will only work with free software, namely Debian as the Operating System, OOo, Blender etc. A longer (and better) description of what they want to do and the motivation behind all of this can be found in their project description or on the Eleonore Project site itself. In my opinion the project seems to be a really good idea and I wish them the best of luck! What I like most about it is that it is not exclusively for girls, so that it does not create a kind of "artificial biotope" for girls to work in. Instead it aims to rise the girls ratio by means of a project topic that (so I assume) mostly appeals to girls. And I am especially happy that when looking for a topic that appeals to girls they came up with something better than fan homepages, foto love stories, and what else you find in "girls IT projects" these days. I am pretty sure that reading and researching on the life of one of the most influential women in European history is going to do them much more good that creating princess-themes webpages! I am also quite happy that they picked Debian as their operating system. I think Debian being used in a school project is a nice example that it is in fact not as "user-unfriendly" as it is often claimed to be! I've also introduced the project to the Debian Women Project and Miriam had the very good idea to also forward it to the Debian Games Team, so I hope we'll get some good cooperation here.

To solve performance problems I've now started to switch my SMTP servers from using the "forkserver" version of qpsmtpd to using the "prefork" version. Under testing qpsmtpd-prefork performed significantly better than the qpsmtpd-forkserver for handling incoming SMTP connections. The loadavg of one machine has dropped from a constant 2.xx to 0.4x! I'd love to see what the asynchronous server would behave like, but that would require re-writing all my plugins to work in an asynchronous manner which would be a significant undertaking. (It would be nice if the qpsmtpd package available to Debian would allow you to choose between the two version of the server - I will file a wishlist bug.) ObQuote: Dune

OK so I've knocked up a simple blacklist:

• http://blacklist.steve.org.uk/

The source code behind it all is open. Currently it is setup to import IPs which denyhosts has downloaded every hour, and it will also receive updates from several systems under my direct control. If you wish to begin submitting your own reports you may get in touch, or read the documentation in the source repository. I'll document that on the site itself publically in a couple of days. So far I see several people have rsync'd my zonefile a few times. I guess the domain name was a bit predictable. ObFilm: The Great Muppet Caper

For about eight years, I was a very happy WindowMaker user. It was very lightweight, aesthetically pleasing, and I had interiorized its behaviour and keybindings so much, I didn't feel I'd ever switch away. I periodically tried (forced myself even!) to use any of the other, more en vogue environments... Experimented using Gnome for a week, KDE for a week, XFCE for a week (so I would have enough time to learn their ways)... And always came back to my good, well-known wmaker.
In 2006, when we held DebConf6 in Mexico, I saw how other people worked with ion3. I fell immediately in love with it. Not because it is prettier, snappier or has nicer widgets than other window managers - but because it is enormously more usable. Quoting Tuomo Valkonen, the ion3 author,

Ion is not perfect and certainly not for everyone, but neither is any user interface. Usability is subjective.

Using a keyboard-oriented, tiling window manager represented -for the first time in 20 years (I had my first contact with a Macintosh in 1986)- a radical user interface change. For my way of working, I just don't need a desktop, I don't need having a background space or overlapping windows. What I need is a way to functionally organize the windows I have open at any given time, quickly switch between them (and not depending on the mouse, please!), maximizing screen space and all that. ion3 was godsent.
Now, in 2007 there was (yet another) huge flamefest. Valkonen basically does not want distributors distributing any version of ion3 that's not the latest, and introducing changes not approved by him - He basically demands ion to be non-free. So, it was moved to the non-free section of Debian where only Womble decided to keep giving it support. And, of course, by September 2007 Julien Danjou announced he had written another window manager: Awesome.
My main motivation for switching away from ion3 is that... I don't want to use non-free software. But I was very comfortable with ion3. It was only after I saw many other people using Awesome at DebConf8 I decided to bite the bullet and switch. It looked at least as comfortable as ion3.
But... Well, I cannot come up with better phrasing than what Joey said when he switched to Awesome, almost exactly a month ago. When changing between the mainstream window managers, the differences are mostly cosmetic. But with these really different window managers... I cannot but reproduce Joey's words:

I wish I had a good analogy to explain to my nontechnical readers what changing to a new window manager is about.
One way to think about it is that it's like driving a car down the road, and suddenly swapping the steering wheel and brakes out for a tiller and gear shifter. And having to downshift for braking until you learn that the brakes moved to the turn indicator lever. By trial and error.
But that's really only part of it. Another way to look at it is adopting a new philosophy. Or, in some cases a cult. (In some cases, with crazy cult leaders.) Whether they use Windows or a Mac, or Linux, most computer users are members of a big established religion, with some implicit assumptions, like "thy windows shall be overlapping, like papers on the desktop, and thou shalt move them with thy mouse".
So, changing to a new window manager is a process of being dumped into a different environment, where nothing works like you've come to expect, and trying to construct a mental model that you can use to make sense of it. But it's also a process of modifying that environment to behave the way you like.
And when done whole-heartedly, this doesn't just mean trying to make it like the environment you were used to before. It means trying to absorb the underlying philosopy of the window manager, and think up new ways of doing things, inspired by that philosopy, and modify the environment to allow doing those things.
So ideally, "I switched to a new window manager" doesn't mean "my screen has some different widgets on it now". It means "I'm looking at the screen with new eyes."

So, what's so different?
Besides learning some new keybindings (expected, of course), Awesome has several suggested layouts to help you organize your workflow, usually (although not always) consisting of a main area and a side area, tiled side by side (or one above the other, or several stranger ways). This sounds rigid, but it is incredibly comfortable - and I've only been an Awesome user for three days!
But what sets Awesome apart from basically anything else is the concept of tags. Whey you see an Awesome session, you recognize something similar to the very well known workspaces concept we have had in any Unix-like environment for many years, right? Well, but they are not workspaces. They are tags. What is the difference?
When I work with workspace, each of my windows can be in a different workspace. So in one, I'll have my mail-related stuff. In another one, I might be browsing. In another one, I have my development things, and I might be following some logfiles in yet another one.
Awesome allows you to use tags for categorization in much a more flexible way.
For example: I am mostly a web-oriented developer. I usually need four things when developing a system: A browser, Emacs, the log for my development server, and a console where I can peek and poke at my objects and interactions. Of course, cramming them all into the same screen makes no sense - It would be better to follow the good ol' desktop metaphore, and just switch the focus and raise the window, right?
In Awesome, I can have them all set to the maximum screen size - _and_ use the most common combinations as well. Each of the windows can be tagged to more than one workspace (and yes, this is immensely more flexible than the always visible hint on traditional WMs).
To begin with, I'll give each major process a tag to itself, to work full-screen. Emacs is on tag 1, my browser on tag 2. The log and the console share a terminal (i.e. via screen or terminator).
This console by itself is not too useful, so I'll set it to tag 4, and we will go back to it later.
So if I'm building a view or following online documentation, I will add tag 3 to both Emacs and the browser.
I'm also setting tag 4 to the browser - That allows me to use it next to my terminal, following the results of my website-clicking.
And, of course, tag 5 will be set to Emacs and to the console, so I can quickly check any quick API-related question that does not need the documentation or look at a newly written method.
By the way, have you noticed CapsLock is the most stupid key invented, ever? Ok, I gave a good use to it: It's called Mod4. Imagine it is just an extra Ctrl, Alt or Meta key.
So, Mod4-1 gives me Emacs. Mod4-2 gives me the browser. Mod4-3 gives Emacs+browser, Mod4-4 gives browser+console, and Mod4-5 gives Emacs+console. And, of course, the handy Mod4-0 gives me all of my open windows tiled side by side.
Even this is a pattern of being a newbie, I know - I could keep 4 and 5 free, and just tag several simultaneous tags to be active. How? Switch to tag 1 exclusively (Mod4-1), and activate tag2 as well (Ctrl-Mod4-2). There, I have Emacs and browser side by side. Want to get the console instead of the browser? Simple. Ctrl-Mod4-2 (toggle off tag 2), Ctrl-Mod4-3 (toggle on tag 3).
Anyway - As you can see, I am excited at finding a very new and nice tool to help me work better. Today I was playing a bit with the Awesome widgets, but that's something to be talked about later.
In Debian, we are at a crossing point: Awesome is just reaching ion3's popularity. And I'm adding my two main machines' votes to Awesome.
This is Awesome. Quoting (yes, one last quote) the official Awesome site, This gonna be LEGEN... wait for it... DARY!.

The FSF is celebrating the birth of the idea that is GNU. There is a video which I have mirrored here for local users. So I plan to sing "Happy Birthday to GNU" on 27th September 2008 as well. It seems like some people are not quite so happy. One correspondent wrote that it was not the 25th birthday of the "GNU Operating System" since that would mean the GNU+HURD which he feels is still not ready. In my opinion the term "GNU Operating System" represents in loose terms "a free alternative to Unix" (free as in mukta). And that idea was born 25 years ago.² I think that the HURD was just the "concept of a notion of an idea" 25 years ago. (The first article about the HURD was on the net about 1990 or so). Moreover, in comparison with Unix of 25 years ago, the GNU+HURD combination could be considered "ready". Thus, there is indeed much to celebrate. For example,

1. There is not one --- there are many free alternatives to Unix. In fact, there are perhaps no non-free Unixes visible anymore! Does this owe a lot to the resolution made by RMS 25 years ago? Absolutely. Of course, it also owes a lot to the resolve of the hackers who followed up on this and took it well beyond what he had in mind.
2. One can run the GNU tools + HURD combination to get an environment as good or better than what was available as Unix 25 years ago. Does a general member of the public really need to do this? No. There are currently a number of far superior solutions. Does the software community need this? Yes. (See below.)

I think that there are a lot of people who disagree with RMS and FSF today on a number of issues --- and these detractors may even be right. Perhaps this makes some people begrudge FSF celebrating the 25th anniversary/birthday of GNU. I offer the following points for their consideration:

1. The vision and resolve RMS and the FSF put behind the vision --- starting 25 years ago --- have got us here.
2. The FSF's astuteness in getting a rather well-known person like Stephen Fry ¹ to celebrate GNU. If any of the distros had managed it, it would have been considered a coup!
3. While Linux may be the dominant player in Unix today, the alternatives like *BSD, Solaris and even the HURD have an important role to play in the development of free software.
4. That chocolate cake looks really delicious. :-)

So here's to (at least) another 25 years for GNU!

Yesterday I made a new release of the chronicle blog compiler. This fixes a bug in the handling of comments. Previously comments were sorted badly, when they crossed a month boundary. Now they are always sorted first to last - which makes reading entries with multiple comments more natural. Other than that I've been readying for the launch of a new MX machine for my mail filtering service. The process went pretty smoothly, and so I'm happy.Still have that paranoid feeling that something will break, but at the very least I'll hear about it quickly thanks to the SMS-alerts! ObMovie: Brief Encountery

SF.net now supports OpenID. Hooray! I'd like to make a comment on a thread about the RTL8187se chip I've got in my new MSI Wind. So I go to sign in with OpenID and instead of signing me in it prompts me to create an account with a name, username and password for the account. Huh? I just want to post to their forum, I don't want to create an account (at least not explicitly, if they want to do it behind the scenes fine). Isn't the point of OpenID to not have to create accounts and particularly not have to create new usernames and passwords to access websites? I'm not impressed.

I was playing racquet ball with Kendall yesterday, and I was running backwards, towards the front wall to try and get behind the ball, and my right ankle rolled underneath me as I was putting my right foot down. There was a really nasty internal crunching sound, and it hurt like hell, so I thought that maybe I'd broken it. I was able to walk home from the Club, so I figured it wasn't broken, but the swelling was pretty bad. Several hours later at Urgent Care, they confirmed with an x-ray that it wasn't broken, so it's now strapped up and in an ankle brace. I have to keep off it for 10 days. I seem to have pretty bad ankles in terms of rolling. I quite often stop myself from stepping down on my foot when the ankle's rolled inwards slightly. Back in May I rolled my left ankle a bit, just crossing the street, and it's still sore.

One of my favorite things to watch are the “making of [movie, documentary etc] segments that are now routinely included in any DVD. It is nice to look behind the curtain and see exactly what choices are made, what is excluded, and why they are made. I wish that more books, especially academic ones, had a “making of” section, giving a window into these choices. We are not exactly encouraged to include this commentary in the book itself but one can find this type of insight in author interview. I recently read one such interview with the author of Two Bits: The Cultural Significance of Free Software. The interview is on his site and the original is here. There are a couple of things that I found particularly interesting, such as how to treat iconic figures such as RMS and ESR [not as researchers, for example ] and the importance of letting your research and thinking brew over a fairly long period of time, despite the pressure of publishing fast, quick and dirty, which is especially strong with anything “digital.” The book is hefty and long, but as is emphasized in the interview, it is also pragmatic and readable. If folks on Planet have not yet checked it out and are not ready to commit to a long book, I would checkout Chapter 6 on the creation of the copyleft. It is sure to please academics and geeks alike.

There’s one thing that the Apple Mail client gets right which I’ve never seen anything else try to do - the way it formats messages. Most mail clients seem to offer plain text and HTML as user selectable options and do exactly what they’re told regardless of the content of the message. If HTML is enabled they always send a mail with both text/plain and text/html renditions of the message. Normally the plain text version is a fixed, 80 column version. This is wasteful of bandwidth, especially since very few users actually use any formatting at all, and means that mail programs that don’t do HTML have to treat the mails as though the fixed layout the sending system chooses is important even when it results in poor layout (for example, on mobile devices with small screens). What Apple Mail does here is to only enable the more complex formatting options if they add information that can’t be represented in the less complex formats. By default mails are sent in text/plain with the format=flowed option to let the reader know it can safely reflow the text and no HTML alternative is generated. If something that can’t be represented using format=flowed is included in the message then a HTML alternative is generated - transparently and without user intervention. This is good partly because it’s nice to see format=flowed used, it’s a nice technical solution to the problem, but mostly because it’s great user interface design. Most Apple Mail users will never notice if it is or isn’t generating HTML e-mail, they’ll just see that it’s doing what they expect and won’t have to deal with an option that they probably don’t understand or have much of a view on. Other users won’t be troubled with HTML generated by Apple Mail users unless there is some content in the formatting. It’d be good to see more MUAs implementing similar behavior, at least optionally.

Reportedly, the USA is falling behind the rest of the world in bandwidth:

The 2008 median real-time download speed in the U.S. is a mere 2.3 megabits per second. This represents a gain of only 0.4 mbps over last year s median download speed. It compares to an average download speed in Japan of 63 mbps, the survey reveals. US also trails South Korea at 49 mbps, Finland at 21 mbps, France at 17 mbps, and Canada at 7.6 mbps, and the median upload speed was just 435 kilobits per second (kbps), far too slow for patient monitoring or to transmit large files such as medical records.

But don’t tell Chris Blizzard’s commenters. He writes about Comcast’s annoucement of a 250GB/month bandwidth cap, and gets an earful from commenters from Canada and Europe:

A boo hoo hoo. Major Canadian ISPs have had a limit of 60 GB for months, if not years. Oh wait probably the same way as most of the world manages on 10-20GB, for far more money than you re paying for $250. Not a lot of sympathy from this corner Yep, no sympathy from here either in Australia, with the only _independant_ ISP left, $280 AUD gets you 100GB. $50 with a major telco (the rest of the ISPs here) gets you 5GB. eg with my current ISP, a 8 MB line with a 300 GB monthly cap costs 20 GBP/month. A 8 MB line with unlimited bandwidth costs 160 GBP/month. Quite a difference! I pay the equivalent of $40 a month for 30GB, and extra GB on top are $3 each. That s with Plus Net (http://www.plus.net). I m in South Africa paying about $130 for a 10GB cap.

So who’s really better off? By my calculations, if a Canadian ISP provides 7.8 mb/s with a 60 GB cap, that’s about 17.5 hours per month of sustained maximum bandwidth before you’ve blown your limit. By contrast, an American ISP with 2.3 mb/s and a 250 GB cap gives you about 247 hours per month of sustained maximum bandwidth. Perhaps part of the answer is that only one country–Canada–shows up in the list of “faster countries” and in the comments section of Chris’s post. That could explain the apparent disconnect; maybe Great Britain and Australia are worse off than the USA, while Finland and Japan are better off. Still, this does bring the question to mind: which is better, raw speed, or the ability to actually use it without fear?

Today I finally made something for phpMyAdmin :-). First I've updated Czech translation of 3.0, so it is not that behind as it used to be (only some PBXT strings are missing right now) and then I fixed some potential issues which Thijs has found (thanks to him for his great security work not only for Debian). Later I focused a bit on demo server. As we already have new setup script from GSoC (made by Piotr Przybylski), links to setup script have been updated and I also reorganised links to all demo versions including direct login links for cookie based authentication. I hope it is now a bit easier to navigate and choose which demo version you want to test :-).

It is most irritating when the Laptop choses to blank its display at the exact moment when I unplug the mobile phone charger located behind it. That is all.

scons claims to be a better replacement for make, or rather especially autofoo magic. Unfortunately, it isn't. To me a proper build system should definitely be able to clean up behind itself. The reasoning flying around for why scons isn't able to do so are quite hilarious, ranging from that it doesn't know what it generates (how does it generate them in the first place?) to that it's extensible and thus can't be done properly (then the extensions are broken and should add their clean informations in a hook or such, too). I haven't seen any valid reason for why it shouldn't be able to do so—yet we still seem to need to clean up cruft lying aroud like .scons* files and directories, config.log and of course the build/ directory. People, if you really want to do some proper build system, don't forget to make it clean up after itself. It shouldn't be the requirement of application developers to fix that (which doesn't really work because a scons target trying to clean the files makes scons crash).

I’d been having problems connecting my laptop to my router to the Phone Coop using a new network cable that I laid under the floor just after the new heating system was installed. It’s a 1970s building - cat-5 wasn’t installed with the original wiring and mains homeplug networking is tricky on this wiring layout. The growing number of people with WiFi and video senders on my hillside (70% of UK users “never or rarely switch off their broadband wireless routers”) seems to be causing more interference and slow-downs, so it seemed worth installing a wired connection while the floors were up. The connection seemed to work fine, but then kept stopping for 20 seconds at a time - that’s just long enough to break network connections, but barely long enough to start up debugging tools, let alone get useful output. I was pretty sure the cable wasn’t at fault - Paul tested it with his fancy test gear when he completed the wiring for me. That left the hardware: my much-hated Belkin F5D7630 and the Realtek 8139 in the bizarre Compaq Evo N1015v. I’ve still not got around to replacing that Belkin and it’s been behaving itself well enough recently, while the Compaq has run smoothly once I actually got Linux onto it. I found the end of this Ubuntu Forums thread which pointed to this archlinux bulletin board thread which suggested pnpbios=off pnpacpi=off in the boot options. After adding that, the 20-second network pauses have stopped. But why? The ACPI and BIOS in this laptop are generally troublesome (and it looks like this also happens on some Presarios), but what in particular is going wrong this time? Will I suffer ill effects from switching off PNP options? Time will tell, I guess.

I took a note of the various talks I attended at DebConf, with the aim of writing a few notes about each so that I could try to explain to my work mates exactly what I get out of going. However I think a lot of the benefit is about general face to face contact with fellow DDs and random conversations that happen. Having worked from home for over 3 years I'm finding it quite nice to be back in an office with people working on the same things as me; there are conversations that you will have over a quick cup of coffee or in the corridor that you wouldn't bother typing on IRC or email or picking up the phone for. Debian is a lot like a large organisation full of telecommuters and DebConf provides a vital opportunity for us to have those "minor" conversations that prove quite useful and to remind each other what we're actually like in person. I didn't end up writing a lot of notes during the talks so these are just snippets after the fact. If I'd been more organised I'd have done a write up on a daily basis rather than leaving it all until the week after. A lot of the below is fragmented thoughts, but the longer I leave it the less relevant it gets and the more chance I forget something. It'd have been up faster if I hadn't been fighting Movable Type to try and get some sort of headings. Sunday
Introduction, Marga The "Welcome to DebConf" bit. Marga got up and talked about how at DebConf4 (Brazil) she hadn't been a DD and now she was and how it had been a life changing event. She'd thought she was to blame for DebConf8 in Argentina, but trawling mail archives had shown it was originally Mart n's idea. She hadn't realised at the start quite how much work it would be. Steve's DPL talk, Steve McIntyre The DPL welcomes us to DebConf and talks about Debian's achievements, some of the results of his team survey (the teams largely say they need more manpower. Not really a huge surprise.). NM/User Survey BOF, Paul Wise Paul emailed debian-user, debian-newmaint and various other places (I think) asking about people's experiences as a Debian user or applicant to New Maint. His final results aren't yet published and I got the impression a disappointing number of our users had replied. The NM problems these days seem to be largely down to a lack of AMs, at least according to the stats on nm.debian.org. Meet SPI board - bdale, maulkin, jimmy, michael, others A chance to meet those of the SPI board who were present. The usual "If you're involved with Debian you should seriously consider joining SPI". Some discussion about the fact that although SPI was originally mostly Debian these days other projects are making more and more use of it - OFTC, PostgreSQL and Madwifi for example. Not a huge amount of new information for me. I've been an SPI member for some time and I think they perform a vital role for Debian. They've had issues in the past but it's really good to see them overcome and more projects on board. Monday
http://hp.com/go/debian, bdale Bdale talks about the history of Debian and HP. And makes the point that HP aren't doing any of this to be "nice"; their primary responsibility is to their shareholders. Not surprising, but it's good that even with that criteria at the fore front Debian ends up a good idea for a large multinational. Managing 666 packages, Mart n Ferrari Mostly centered around the pkg-perl experience and the tools/workflow they have to help manage things. Impressive web tool (DEHS) to help track packages with new upstreams, issues or pending uploads. Quality Assurance in Lenny + 1 I can't remember a lot of this, which is a bit bad. I remember a discussion about whether we should release with orphaned packages, or if they should be removed. The argument for not removing them seemed to revolve around a theory that if they weren't buggy then what was the harm, the argument for was that if they were unmaintained and not really used than how did we actually know they weren't buggy, and was it reasonable that they potentially held up library transitions etc? Bugs in large packages Don Armstrong and ways in which the BTS can help people with lots of bugs. This (thankfully) doesn't affect me, but it was interesting to hear Don talk about his work on the BTS and his various ideas. I was sorry I'd missed his talk on SOAP access to it; I shall have to find time to watch the video. Tuesday
Debian and Ubuntu, Mark Shuttleworth The usual interaction with Debian stuff, including how we interact with our upstreams. If a bug is raised with an Ubuntu package then it might well be appropriate to raise it with Debian and upstream as well, but each set of people should be able to use their own bug reporting systems rather than having to go to a foreign system. I don't think it was actually said, but I guess the idea is that launchpad is the thing that will do this gluing together. He also talked about Ubuntu as an "experiment" rather than a fork of Debian; something that has potentially different ideas about how to do things but that these ideas may lead to things that should be fed back into Debian. The point was made that even if you consider Ubuntu a fork they've forked 9 times now; it hasn't been a case of forking once and diverging wildly since thast point. I have a few thoughts on all the whole Debian/Ubuntu stuff which I should really try to form into something coherant and post. I think it's important to take Mark's talk in the context of bdale's "Shareholders come first" point. Derivatives round table Didn't stay for most of this. Ubuntu, Debian-EDU (which I hadn't realised was a derivative rather than a team within Debian, but apparently there are various things it was much easier for them just to patch now and try to work towards a generic solution later), someone from Extramadura and someone from the Munich government Linux stuff. I'm sure I've missed someone off. tdebs/i18n This was a useful BOF. It helped that we said no to the usual video team requirement that if you want to speak you had to wait for the microphone. This works fine for a normal talk, but really impedes the flow of conversation in something like a BOF. tdebs are something that have partly come from a need of Emdebian to reduce installed package size and partly from the desire of the i18n team to be able to update package translations without having to do a full binary NMU of a package. We had some of the FTP team, the release team, the i18n team and Emdebian there and I think some progress has been made. There'd been various conversations had before this meeting which I think helped people think about the issues and objections so that we had answers by the time we all sat down together - an excellent example of the use of DebConf. DebConf9 C ceres Various bits of discussion about next year's DebConf in Extramadura. Temperature is likely to be an issue for me as they reckon it could easily get up to 40C! I'll melt! Venue sounds good; some queries regarding late night hacklabs and net connections to same, but I'm sure the networking team will sort it all out as usual. ;) DebConf10 bids Venezela and New York were both pitching. Lots of people don't want to travel to the US or think they'll have problems doing so (I hadn't realised there was such an issue for people from South America). I suspect various people will have issues with Venezela as well; I heard expressions of doubt over their political stability expressed. However I'd be happy to go to either (and preferably both! DebConf10 + 12 perhaps?) Speaking of which, what ever happened to the Sarajevo bid? If they're reading, have you considered DebConf11? Wednesday
A day trip to an Argentinian ranch and lunch was an asido. Fantastic food and a pleasant afternoon spent sitting in the sun chatting to people. That evening was the formal, but thanks to having stayed up until after 4 on Tuesday I had to wimp out and go to bed fairly early. Not until I'd seen the DPL dance though. :) Thursday
Internationalization in Debian I forget most of this other than pretty graphs from Christian regarding what's translated and what other languages we might have; e.g. you can consider South America to be covered largely by Spanish and Portuguese, or you can consider it to not be covered very much at all by the local indigenous languages. dh-make-webapp: yeah right! Mainly what I took away from this was "It'll never happen thanks to the fact that every web app author uses a different system" and that more work needs to be done on the web apps best practices document. I don't really do web apps, but having them easily installable on my systems is a good thing so I hope some standardisation within Debian comes from this. Best practises in team-maintaining packages Various team members got up to talk about work flow in their teams. Not unsurprisingly different things seem to work for different people. Predictable PRNG in the Vulnerable Debian OpenSSL Package Lucian giving his Black Hat talk about the OpenSSL issues we faced earlier this year. Some queries about automated testing and that it should have found this, which originally I agreed with until I thought about it - you'd have to have run > 65536 tests and compared all the data to find this; something like the FIPS tests against a single run wouldn't have shown any issues. Lucian wanted feedback on ensuring he was presenting the Debian side of things acceptably as well. Keysigning Run by Don Armstrong. Nothing to really remark except I think key signing attendance is dropping off after things like the Helsinki experience. Also I've now managed to get my new RSA key signed by keys other than my own (and I'll try to get sorted out to sign keys myself soon). Friday
LessWatts Intel's drive towards reducing power usage. Odd to hear such things from someone who wasn't Matthew Garrett and I think I'd heard most of it before. Debian technical policy update Sorry Manoj, I should have been paying more attention. Debian Policy is something I think is important, but I'm not enough of a nitpicker to really feel I can contribute a whole lot. Virtualisation in Debian - Present and future This was depressing. What I took away was "We had 2 forms of virtualisation in etch (Xen + vserver) and we're supporting neither for Lenny". As someone running a Xen machine this is problematic. The host does have the hardware support that would allow kvm, but I'm worried about smooth migration (it's a colo box). There was some mention of Xenner, which isn't packaged for Debian. I took a look at doing so but there are some worrying items in the TODO list (like, oh, locking to enable reliable SMP) and I've spectacularly failed to get it compiling so far. I should have another go. Emdebian update Neil Williams about where Emdebian is and waved his Balloon3 about. Some interest from the Openmoko guys and discussion about why it might be better than OpenEmbedded. And equally what it couldn't do that OpenEmbedded can manage (mainly very small installs; a minimal Emdebian install is 24MB+ and with X that goes up to 75MB+ I believe). netconf I'd never actually seen Martin talk about netconf before. Am impressive flow of control diagram. It all sounds quite complex for little benefit at present, but if he pulls it off then I can see it being a much more flexible replacement for the likes of Network Manager. Saturday
Lenny - The Road To Release Neil played with putting the heads of the release team on random images. And tried to tell us all how to behave during the release process in terms of what should and shouldn't be uploaded etc. Most of it is just common sense, but apparently everything he talked about he'd experienced. Also pointed out we were supposed to release in 3 weeks and didn't even have the appropriate kernel in testing yet so it's probably not going to happen. Colour me surprised. Sustainable Computing Low power consumption/affordable computing. Interesting points about the OLPC being used in the middle of nowhere with no chance of an Internet connection being close by compared to neighbours in large cities where people can't necessarily afford top of the line computers or individual connections - in this sort of scenario mesh networking is really viable in terms of getting people connected up. Multi winner voting Manoj needs pretty diagrams, probably drawn by Martin Krafft. ;) Semi-interesting discussion about multi-winner voting (e.g. SPI board elections) and how the current Debian voting system is completely tied to Debian's infrastructure eg the LDAP setup. Manoj would like to make it more generic so it could be used by other groups as well as for different sorts of votes in Debian.

I got several emails in reply to my previous post on representing Sudoku problems as package dependencies. Several people asked about the algorithm that aptitude uses to solve these problems. A slightly out-of-date discussion package management and the aptitude algorithm can be found at http://people.debian.org/~dburrows/model.pdf. One question was interesting enough to deserve a follow-up blog post: Wolf T. referred to the page http://norvig.com/sudoku.html and asked how long it would take aptitude aptitude to solve the hard Sudoku problems on that page. He suspected that aptitude would do basic constraint propagation and then be forced to exhaustively search all the possible solutions to the problem. In brief: the answer is that it doesn't work by default, but not for the reason he suggested, and you can make it work with a few command-line arguments. In order to try this out you'll need a new version of the Sudoku reducer that can parse the problems on that Web page: debsudoku2.py. If I do a straight conversion of one of those problems and then run it through aptitude, it goes spinning off and never comes back. But aptitude is coded to avoid exhaustive searches; otherwise it couldn't solve dependency problems in reasonable amounts of time. In this particular situation, though, aptitude is clearly performing an exhaustive search; here's one series of status outputs:

open: 5124; closed: 4993; defer: 0; conflict: 374
Resolving dependencies...
open: 10090; closed: 9942; defer: 0; conflict: 398
Resolving dependencies...
open: 14726; closed: 14888; defer: 0; conflict: 440
Resolving dependencies...

Here open is the number of partial solutions that aptitude wants to examine, and closed is the number that it's already examined. aptitude isn't making progress here and it isn't finding solutions; in fact, it's creating, on average, about two new partial solutions for every one it examines. Why is aptitude doing this? Its resolver isn't a brute-force algorithm; in fact, it looks remarkably like the Sudoku solver discussed at http://norvig.com/sudoku.html. On each step, aptitude takes a partial solution, picks one dependency, and resolves it by installing or removing a package. This is pretty much equivalent to filling in one not-filled-in cell; in fact, in the conflicts Sudoku reduction, it's exactly equivalent. There is one difference, though, and it stems from a difference in the problem domains of Sudoku and package management:

Not all dependency resolutions are created equal.

In Sudoku, any solution to the puzzle will do. Not so in package management; solving a dependency problem by removing every package on the system will produce a formally correct answer and a very unhappy user. Even results that are not utterly disastrous could be annoying to the user, so the resolver needs to somehow aim for good answers. The page on Sudoku solvers suggests sticking to whatever value you placed in a cell, unless that doesn't lead to any solutions at all. This is technically known as a depth-first search. The problem with taking this approach when resolving package dependencies is that an apparently safe choice can end up requiring undesirable actions later on (like removing large swathes of the system). For this reason, aptitude tries to strike a balance between sticking to its current line of reasoning, and abandoning it when it seems to be turning out badly (this makes it a form of best-first search). On typical Debian archives, the package relationships are simple enough that it's OK if aptitude does this from time to time; it makes the search a little more thorough (thus costly), but the ability to back out of questionable branches is very valuable. But it looks like when aptitude is applied to Sudoku puzzles, it has trouble settling on a single series of choices. It keeps thinking that the solutions are getting worse, so it backs up and tries another branch, but they don't look any better over there, so it backs up and tries another branch, and so on. The option Aptitude::ProblemResolver::StepScore sets how hard aptitude will try to stick to the same line of reasoning. Its default value is 70, which is reasonable for package archives, but turning it up to a large value such as 10000 will cause aptitude to use a straight depth-first search, just like the Sudoku page recommends:

$ aptitude -s -o 'aptitude::problemresolver::stepscore=10000' -o 'aptitude::auto-install=false' install puzzle

Setting auto-install to false is a workaround for another odd corner case/bug that happens to bite this Sudoku problem: for technical reasons, doing this lets aptitude know that it should avoid solutions that cancel the installation of puzzle. Otherwise you have to sit there telling it no for a bunch of solutions you aren't interested in. Future versions of aptitude will probably provide a way to explicitly give hints to the resolver. With these options, aptitude was able to solve the hard Sudoku puzzles that I gave it in anywhere from fifteen seconds to a minute and 47 seconds. In contrast, the straight Sudoku solver does 30 problems in a second. Why is aptitude so slow? Based on skimming debug traces and looking at the run-time behavior, I conjecture that there are several reasons:

1. The aptitude search algorithm is very heavyweight. In the case where it takes over a minute, it only actually examines about 5,000 possible solutions. I don't know exactly where all this time is going, but I do know that the resolver does a lot of work on each step, for instance to try and detect dead ends that it hasn't reached yet. This is the conflicts counter that appears while the resolver is running. This pays off tremendously in terms of allowing aptitude to skip huge amounts of work (it may be why aptitude can solve Sudoku puzzles at all!), but it means that the resolver takes a long time for each potential solution it looks at.
2. The Sudoku page suggests taking the cell with the fewest number of possible entries as the choice. I distinctly remember writing code to do this in aptitude, but it looks like I threw it out at some point or never committed it. I don't see why it should be any worse than the current approach, though (which is to pick an arbitrary dependency); maybe it just got misplaced at some point. Implementing this behavior decreased the time required to solve one puzzle from a minute and 45 seconds to just under a minute; I've committed this change to the post-lenny branch.
3. The Sudoku resolver has the advantage of being able to very quickly identify illegal moves. aptitude's resolver can learn this information, but it takes time and it can't apply Sudoku-specific optimizations. For instance, the Sudoku solver knows exactly which values can be placed in a given cell at any time. aptitude has to actually consider each of the cells that's available as a possibility and prove to itself that, e.g., 4 and 6 can't be written in the same cell at the same time. And although it can learn this information, it takes time to do so and it takes time to see whether any of the past conflicts that it remembers are present in a given solution.

As I noted above, I've already checked in one change to the resolver's behavior. It might also be worth seeing what happens with a massive increase in StepScore, so I've pegged it at 10000 on my computer to see whether the results I get are noticeably worse. The third item above -- the fact that aptitude needs to do more work to understand which packages can't be installed -- is interesting. The Sudoku solver is very proactive about this: it keeps track at all times of which cell values are legal, and updates these sets every time it transitions. In contrast, aptitude constantly re-checks all the possible moves it could make to see which ones are currently legal. I think that the resolver's speed could be boosted a little by doing the following:

1. Cache the currently legal solutions of each dependency at the time it's inserted into the queue.
2. When a new search node is generated by resolving a dependency, drop the formerly legal moves that are knocked out (for instance, by installing a different version of the same package).
3. Come up with a quick way of re-testing new conflicts (the global list of dead-ends) so that search nodes that are already in the queue can be checked against the conflicts that were added since they were queued.

These changes won't make aptitude able to solve problems that it couldn't solve before, or at least not very many of them, but they should make the resolver faster on every problem it encounters. However, I don't think I want to actually implement them. It would be tricky to confirm that the resolver got faster on real dependency problems (since it's normally almost instantaneous), the changes would make the resolver code more complex and fragile (less readable, less maintainable), and there's a real chance of breaking something. Unless there are cases where the resolver is currently too slow on real package archives that don't involve an exponential blowup, I'm going to shelve the idea for now.