Looks like I can now post full entries without them being cut off but links still don't work in readers. I think it is a problem with my feed.

This is a test post as I want to see if my entry now appears in full and to see whether linksappear in the feed, so sorry for the obnoxious nature of this post. tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt

Sometimes what circulates on the Internet, such as this little visual comparison may not accomplish much, except create a whole lot of smiles. That is good enough for me.

Looks like I can now post full entries without them being cut off but links still don’t work in readers. I think it is a problem with my feed.

Sometimes what circulates on the Internet, such as this little visual comparison may not accomplish much, except create a whole lot of smiles. That is good enough for me.

If you happen to be near Bremen, Germany around the 5.-7. September 2008 and have an interest in solidary economy, free software, renewable energies and the like you might want to stop by at the 3rd Congress on Solidary Economy (German website). I haven't been at the first two of these congresses but I was invited as a speaker for this one, so I'll be around at least on Saturday and probably also on Sunday. I'll mainly be on a panel on free and open source software which will take place on Saturday evening at 20:00. (Prime Time :)) But I've also let myself be talked into joining another panel at 17:00 which is somehow ubuntu-related (Communtu). I am not yet sure if I'll have much to contribute there, I am neither a ubuntu specialist nor particularly fond of it, but the organiser said he wouldn't mind and he'd welcome critical remarks just as much, so, we'll see. I am really looking forward to being a speaker on an event again! Ever since I started my PhD I've been much too busy to attend (leave alone prepare talks for) as many events as I'd have liked. I hope the situation will improve next year when things get rolling with my PhD. (Currently still in a "topic orientation/find a project/write proposals" state ...)

Xorg 1.4 in experimental is supposed to have input device hotplugging.Does anyone have a Howto for Debian? I tried it, but I couldn't get it to hot-plug my USB mouse, so I'm back to using the regular mouse driver for it again, using the /dev/input/mice in-kernel-hack for hotplugging.P.S. on a recent kernel, you might want to add

blacklist snd_pcsp

to a custom file in /etc/modutils/, in order to avoid your PC speaker showing up as regular audio device. You don't want your regular apps to consider your legacy PC speaker as audio device usually.P.S. No, my blog doesn't have comments. Just send me an email (you know, 'legacy' email) via erich AT debian org.

I first read about Y Combinator while browsing Paul Graham s website. I am a huge fan of his and have tried many times to bring him to Brazil for FISL (unsuccessfully so far). By that time I was updating a lecture of mine where I quote something from his Hackers and Painters essay and sudenly I noted an YC link on the left, and decided to click to learn what was that. Y Combinator is a venture capital firm to help start-ups. It was built on the concept that not much money is needed for first-stage start-ups ( from idea to company , as they call it). Quite a concept! I lost track of it until yesterday, when I read this blog post summarizing one of its events for start-ups. I found it amazing how far it came in such little time. They ve already funded about 100 start-ups, some of them really interesting. Of those presented in that post, Posterous is one I found most interesting. They create instant blogs just by sending emails to some address. There s no sign-up procedure Just send the email with any attachments and voil . There you have: a new blog. Many others are really interesting (PollEveryWhere, IDidWork, Frogmetrics, just to name a few), so I really suggest reading that post. I think Y Combinator is another great idea from Paul Graham, and I will be following it more closely, as a way to keep myself updated Who knows maybe I can get them to come to FISL to present that! ;-)

So it looks like the project I’ve been laboring on has been getting some attention:

Ever thought it was difficult to write software for Linux? For multiple distros? InternetNews reports that the LSB is making a push for their next release (due out later this year) that should help make all that much easier.

They even link to our project status page. Cool! Of course, good publicity invites criticism. This time, there seem to be two themes. William Pitcock seems to have the most succinct summary:

To put things simply, the LSB sucks. Here s why:

• The LSB spec depends on RPM. I mean, come on. Seriously. Why do they need to require a specific package manager? If package handling is really required, then why not create a simple package format that can be converted on demand into the system package format? Or why care about packages at all?
• The LSB spec invents things without consulting distros. Like the whole init scripts thing. But that s not as bad as depending on RPM or requiring a specific layout.

(See also Scott James Remnant.) Let’s take this one part at a time. Today’s topic: packaging. Part of William’s problem may be that he doesn’t understand the spec. The LSB doesn’t require a specific package manager, or a specific package format. It doesn’t even require that the distribution be set up using package management at all! The spec only requires that LSB-compliant software be distributed so that any LSB-compliant distribution can install it. That could be tarballs with POSIX-compliant install scripts, an LSB-compliant install binary, a shar archive, a Python script with embedded base64 binaries, whatever. One of the options allowed is an RPM package, with a number of restrictions. The restrictions are key, because they effectively define a subset of RPM that acts as, to quote William again:

…a simple package format that can be converted on demand into the system package format…

The difference being, of course, that we didn’t reinvent the wheel and create our own; we used a popular format as the basis for ours. Scott raises another concern:

While much of the LSB can be hacked into a different distribution through compatibility layers and tools, such as alien, what ISV or other vendor wants to provide a support contract against a distribution that has such kludges?

I’m not sure if he’s referring specifically to packaging or to the standard in general. As regards packaging: the reason we specify a strict subset is because we can test that subset, and we’ve tailored it to the needs of tools such as alien. The theory goes that alien isn’t a kludge when it comes to LSB packages. But, as already mentioned, if vendors aren’t comfortable with supporting RPM, they have a number of other options. As it turns out, most of them are doing just that; the feedback we’re getting from most ISVs is that packaging (whether LSB-subset RPM, full RPM, or Debian) is just not worth the effort. Coming up: part 2…

Steven Brust is a big tease. His most recent Vlad Taltos novel is full of tease for two reasons:

• He jumps back in the timeline so that we hear nothing of Lady Teldra.
• The acknowledgements of the novel mention the use of some "emacs macros" with no hint of what they are, or why he uses them.

It was a fun read though, and didn't make me as hungry as the previous volume did. (Mmmmmm pies food.) I always liked him as an author, and he rocks for publishing Dzur around the time I was telling local people "Too many people seem to write novels in which nobody really eats. Forget all that action, dialog, and exposition. Lets have a bunch of folk sit down and eat an exceptionally well described meal." (Many things that people do are never described in books. We all know why. Still on the same subject I love the scene in Terry Pratchetts Pyramids where Teppic puts his outfit on. "And slowly falls over". Nice) ObFilm: Blade

The Linux kernel has a number of code sections which look at the apparent size of the machine and determine what would be the best size for buffers. For physical hardware this makes sense as the hardware doesn’t change at runtime. There are many situations where performance can be improved by using more memory for buffers, enabling large buffers for those situations when the machine has a lot of memory makes it convenient for the sysadmin. Virtual machines change things as the memory available to the kernel may change at run-time. For Xen the most common case is the Dom0 automatically shrinking when memory is taken by a DomU - but it also supports removing memory from a DomU via the xm mem-set command (the use of xm mem-set seems very rare). Now a server that is purchased for the purpose of running Xen will have a moderate amount of RAM. In recent times the smallest machine I’ve seen purchased for running Xen had 4G of RAM - and it has spare DIMM slots for another 4G if necessary. While a non-virtual server with 8G of RAM would be an unusually powerful machine dedicated for some demanding application, a Xen server with 8G or 16G of RAM is not excessively big, it’s merely got space for more DomU’s. For example one of my Xen servers has 8 CPU cores, 8G of RAM, and 14 DomUs. Each DomU has on average just over half a gig of RAM and half of a CPU core - not particularly big. In a default configuration the Dom0 will start by using all the RAM in the machine, which in this case meant that the buffer sizes were appropriate for a machine with 8G of RAM. Then as DomUs are started memory is removed from the Dom0 and these buffers become a problem. This ended up forcing a reboot of the machine by preventing Xen virtual network access to most of the DomUs. I was seeing many messages in the Dom0 kernel message log such as “xen_net: Memory squeeze in netback driver” and most DomUs were inaccessible from the Internet (I didn’t verify that all DomUs were partially or fully unavailable or test the back-end network as I was in a hurry to shut it down and reboot before too many customers complained). The solution to this is to have the Dom0 start by using a small amount of RAM. To do this I edited the GRUB configuration file and put “dom0_mem=256000” at the end of the Xen kernel line (that is the line starting with “kernel /xen.gz“). This gives the Dom0 kernel just under 256M of RAM from when it is first loaded and prevents allocation of bad buffer sizes, it’s the only solution to this network problem that a quick Google search (the kind you do when trying to fix a serious outage before your client notices (*)) could find. One thing to note is that my belief that it’s kernel buffer sizes that are at the root cause of this problem is based on my knowledge of how some of the buffers are allocated plus an observation of the symptoms. I don’t have a test machine with anything near 8G of RAM so I really can’t do anything more to track this down. There is another benefit to limiting the Dom0 memory, I have found that on smaller machines it’s impossible to reduce the Dom0 memory below a certain limit at run-time. In the past I’ve had problems in reducing the memory of a Dom0 below about 250M, while such a reduction is hardly desirable on a machine with 8G of RAM, when running an old P3 machine with 512M of RAM there are serious benefits to making Dom0 smaller than that. As a general rule I recommend having a limit on the memory of the Dom0 on all Xen servers. If you use the model of having no services running on the Dom0 there is no benefit in having much ram assigned to it. (*) Hiding problems from a client is a bad idea and is not something I recommend. But being able to fix a problem and then tell the client that it’s already fixed is much better than having them call you when you don’t know how long the fix will take.

Share This

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'm back (for several days now) from Argentina and DebConf 8 to Portland. Too long a journey and too short a trip, as always. It was great to see everybody again as well as to meet a number of new folks from the local community. Here's hoping that DebConf 8 inspires more involvement in Debian from Argentina! It was my first time to this wonderful South American country, which made it even more melancholy to have to leave after such a short time and to be making this trip without Patty. Random observations about Argentina, for posterity:

• The 6-hour bus ride from Buenos Aires to Mar del Plata looks an awful lot like Iowa. Except for the occasional palm tree and the fact that it's 20 C in winter.
• Well, ok... Iowa also tends not to have quite so many cows. Or country grills (parrillas) right next to pastures...
• All the towns along the route are named after generals or colonels?
• All the police on the highway wear OSHA green vests.
• Following the German with the voluminous guidebook is an effective way to acquire generous portions of bife de chorizo.
• People from Bah a Blanca seem to have a somewhat more paranoid opinion of what constitutes a "dangerous neighborhood" than I do. :)
• "Buenos Aires" appears, I'm sad to say, to be a marketing lie. There was nothing bueno about the aire on the autopista on the ride to the airport. But the air in Mar del Plata was quite nice, and the people were the best!

As always it was a pleasure to take part in another annual DebConf, an event which is such a positive force for rejuvenating the Debian community. And BTW, Biella, NYC is not the only US city entertaining a bid for DebConf 10.

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.

All "low quality" videos (which in fact have better quality than the streams had) from DebConf8 are now available for download at the usual location. Enjoy!

I expect the rest of the high quality ones to appear during the next 48h, after that I'll start with the remaining post processing, which will take a bit longer, probably some weeks, hopefully only a few though :-)

Currently there are 57 events available in low quality (4,9G in size) and 30 in high (14G). The SPI event is the only one I know that is missing, but I still need to check if we have it on tape and if there are more missing.

If you notice any non-obvious problems with these videos, please don't tell me, but do describe the problem in our todo list. Thanks!

To make that a bit more clear: There is only one kind of obvious problem: more than one file per event. It's obvious that these need to be merged. All other issues, like a completly missing event, missing beginning of an event, or silence instead of audio, etc. should be noted in our todo-list. Your help here is very much appreciated.

I like aptitude. Okay, I just understand 10% of its features and I can’t live without apt-get (e.g. apt-get source) or apt-cache (e.g. apt-cache search) but for resolving broken dependencies it’s heaven-sent. It just seems like upgrading to Lenny using aptitude (I just learned about “U” to toggle an update - I’ve always used apt-get for that purpose) is a bad idea at this moment. Thanks to Daniel et al for this great piece of software anyway. Just if you upgrade to Lenny I’d recommend apt-get for the moment. It’s now four hours later and I managed to forcefully install slapd’s dependencies, recover the Samba LDAP schemas and get over all kinds of weird error messages. Bacula failed to upgrade the database (I swear it had worked before with dbconfig-common) so all I had was my emergency afbackup. Not to mention that I had to work on the server console because due to lack of LDAP I couldn’t fix that from my laptop. Do I need to mention that my TFT monitor at my server just died today? Don’t think so.

I’ve ordered some USB charging leads for various portable devices, mainly because I’ve already got mains-USB and car-USB power adapters (they came with a bluetooth headset that charges from USB) and I agree with things like this:

“management of an individual charger for each device is becoming a pain in the backside. Since the USB power form specification is a standard, ANY charger with sufficient load capability should be able to charge ANY device.” (from USB As A Power Source)

but I’ve also heard that charging from USB is greener - or more precisely that because your computer’s power supply is running anyway, it uses less electricity to plug battery chargers onto the Universal Serial Bus than to plug in “wall-wart” DC adapters. But is this claim true? Claims from USB recharging product sellers concentrate on the obvious “less waste compared to disposable batteries” strength, although some smarter chargers cut power to charged devices - it’s not clear whether the mass-market USB battery chargers do this, but the reasons and the electronics don’t look that complicated. China (not famous for environmental protection yet) now requires USB-charging of mobile phones while a mobile phone industry body has recommended the same approach in general. However, there are concerns about whether Power over Ethernet is making networks less green, which might be true for USB if devices demand more high-power sockets and device makers don’t include intelligent control electronics (which people generally don’t want to pay for). Is USB charging greener than mains charging? I’m not sure and I haven’t found any great answers - can you? I guess in the worst case, I can try some tests with a power meter later…

Venezuela’s biggest and most important ISP, CANTV, was my first serious email provider, since it is tied to my ADSL connection, and I previously used several different dial-up providers (T-Net, IFX Networks) with no specific interest in email. CANTV mail service used to be provided with the highest standards of quality in the country, particularly as per malware and UCE control, and general abuse surveillance. Hey, even one of the former insider guys is quite known inside our FOSS community! I’ve previously (1, 2) blogged about the huge problems CANTV is facing with their mail service. They don’t answer, and sometimes even bounce, mails to abuse or postmaster, and temporarily suspended or degraded their abuse statistics web site. All in all, they are providing a poor customer service and are being listed in several blacklists all around the world. Sometimes I get warnings from mailing lists since their border MTAs are refusing to deliver messages to the mailboxes. So if you sent me my signed PGP public key, please forgive my ISP for probably bouncing your message. I thought I could live with this problem, since it’s probably temporary, but today a friend from El Salvador told me that all of his mail to cantv.net addresses is bouncing with this message.

Diagnostic-Code: smtp; 550 5.7.1 ...>... Mail from
    168.243.89.79 refused: Vea http://abuso.cantv.net/bl/dul.html

So after taking a look at the whois record for that block, and doing a lookup on the reverse entry for 168.243.89.79, I think that a proper conclusion would be Venezuela’s biggest ISP is currently blocking most mail from El Salvador. And probably other countries. Terrible news. And please use my at debian.org mail address if you need to get in touch.

Debian Integrated Solutions. (DIS, pronounced "dish".)

Or at least, that's what seems to become the result of this thread on thedebian-custom mailinglist (and some RL discussions at DebConf8).

I've not yet participated in the renaming discussions, at the moment I can only say what others already said: the terms "custom" and "distribution" both have several problems and renaming won't be easy. Now that I've said that, it occurs to me that I do have something to add: renaming established names is never easy, but can very well be worth the effort, if the established name is problematic / has shortcomings and the new one is way better.

And there I have my doubts. TTBOMK or IME, neither Debian Med nor Debian Edu qualify as "solutions", but are a (great) basis to build solutions...

Hmm, I mostly started to write this blog post, to make more people aware of this discussion and not to add new arguments. This should better be done on the debian-custom mailinglist. Please reply there :-)

In not totally unrelated news I'm back in Europe and catching up on my various backlogs. Tomorrow I plan to connect the harddrive with the Debconf8 videos and start/continue with that backlog... If you notice any problems with the already released videos, please don't tell me, but put them in that wiki page. Thanks!

I'm doing some contracting work at a local firm, and one of the little details that I have been pleased with is the fact that they seem to do introductions for people. On my first day, I was taken around and introduced to everyone, despite the fact that I probably won't be there long term (depending on where we go and when). Today, they were showing around a guy who will be doing a sort of student internship there, and once again, they stopped by my office. I appreciate that a lot, and think that it's a good thing for a group of people to at least have a bit of an idea who newcomers are. One of the things that I have always loathed, and vowed to do differently should DedaSys ever be more than myself, is feeling like an animal in a zoo when The Boss brought someone into the office to take them on a tour, pointing at us developers and talking about what we do, with no reciprocity. "This is Dave, one of our open source guys, who is really into Linux. He once roamed the temperate forests of Oregon and his mating season is from early January to late December." We get pointed at and talked about, and the other person remains a Mysterious Stranger. Granted, it's not always possible to disclose everything, but I think that you can still do a lot to make people feel respected without spilling the beans on a big potential customer or investment.