There is ongoing discussion about whether outsourcing is good or bad. The general assumptions seem to be that it is bad for people who work in the computer industry (more competition for jobs and thus lower pay) and good for employers (more work done for less money).<br /><br />I am not convinced that employers can get any benefit from outsourcing. The problem is that the pay rates for computer work are roughly proportional to the logarithm of the productivity of the person (at a rough estimation - it's certainly not linear). Therefore if you get an employee on twice the base salary you might expect ten times the productivity, and an employee on three times the base salary could be expected to deliver one hundred times the productivity. These numbers may sound incredible to someone who has not done any technical work in the computer industry, but actually aren't that exciting to people who regularly do the work. Someone who knows nothing may perform a repetitive task manually and waste a lot of time, someone who knows a little will write a program to automate it, and someone who knows a lot will write a program to automate it that won't crash...<br /><br />Programmers in Indian outsourcing companies are paid reasonably well by Indian standards, but they know that it's possible to do a lot better. So all the best Indian programmers end up either migrating to a first-world country or running their own outsourcing company (there are a lot of great Indian programmers out there, but they aren't working in sweat-shops). The Indians who actually end up doing the coding are not the most skilled Indian programmers.<br /><br />It might be better to hire cheap Indian programmers of average skill than cheap first-world programmers of average skill. But hiring a single skilled programmer (from any country) rather than a team of average programmers will be a significant benefit (both in terms of price and productivity). In addition to this there are the communication problems that you experience with different time zones (the idea that one team can solve a problem while the team on another continent is asleep is a myth) and with different cultures.<br /><br />I am not convinced that outsourcing does any real harm to good programmers in first-world countries. If someone does computer work strictly 9-5 and never does it for fun then they are not a serious programmer. People who aren't serious about computers will probably be just as happy working in another industry if they get the same pay. Moving a few of the average computer programmer positions to India isn't going to hurt anyone, especially as the industry is continually growing and therefore there is little risk of any given programmer being forced out of the industry. The people who are serious about computers (the ones who program for fun and would do it even if they weren't paid to do so) are the most skilled programmers, they will always be able to find jobs. Will outsourcing reduce the income for such people? Maybe, but earning 5* the average income instead of 6* shouldn't hurt them much.<br /><br />The final question is whether outsourcing is a good thing. I think it is good even though it's bad for first-world companies and not particularly good for programmers in first-world countries. Outsourcing benefits developing countries by injecting money into their economies and driving the development of a modern communications infrastructure (telephones, mobile phones, fast Internet access, reliable couriers, etc). I believe that the good which is being done in India by outsourcing money greatly exceeds the damage done to companies that use outsourcing services. Therefore I want this to continue and I also want to see outsourcing in other developing countries too. There is already a trend in outsourcing to eastern-European countries such as Russia, this is a good thing and I hope that it will continue.

I attend many presentations and have seen many that had a lower quality than they should have. Some things are difficult to change (for example I have difficulty speaking slowly). But there are some things that are easy to change that many people seem to get wrong and I will list some that stand out to me.<br /><br />Unreadable presentation notes. You have to use a reasonably large font for it to be read by most people in the room. This means probably a maximum of about 16 lines of text on the screen. I have attended some presentations where I couldn't read the text from the middle of the room!<br /><br />Too many slides. On a few occasions I have heard people boasting about how many slides they are going to use. An average of more than one slide per minute does not mean that you have done a good talk, it may mean the exact opposite. One of my recent talks had 8 slides of main content plus an introductory slide while waiting for people to arrive and a Q/A slide with my email address and some URLs for the end. The speaking slot was 30 minutes giving an average of a slide every 3-4 minutes.<br /><br />Paging through slides too quickly. If you have 60 slides for a one hour talk then you will have no possibility of going through them at a reasonable speed (see above). Even if you have a reasonable number of slides you may go through some of them too quickly. On one occasion a presentation included a slide with text that was too small to read, I tried to count the lines of text but only got to 30 before the presenter went to the next slide.<br /><br />Using slides as reading material for after the lecture. Sure it can be useful for people to review your notes after the lecture, and it's generally better to give them the notes than to have them be so busy writing notes that they miss somehting you say. But if you want to have something verbose and detailed that can't be spoken about in the lecture then the thing to do is to write a paper for the delegates to read. Serious conferences have papers that they publish (minimum length is generally 4 solid A4 pages) which are presented by a talk of 30 to 60 minutes. That way people get a talk as an introduction and they get some serious reference material if they want to know more. Also people who miss the talk can read the paper and get much of the value. Is it not possible for slides to take the place of a paper.<br /><br />Bad diagrams. Diagrams should be really simple (see the paragraph about readable text). It is OK to have diagrams that don't stand alone and need to be described, a lecture is primarily about talking not showing pictures.<br /><br />When simplifying diagrams make sure that they still represent what actually happens. Simplifying diagrams such that they don't match what you are talking about doesn't help.<br /><br />Animations. The only thing that is animated in the front of the room should be the person giving the presentation. Otherwise just do the entire thing in flash, publish it on the web, and don't bother giving a talk.<br /><br />Staged content, particularly when used as a <span style="font-style: italic;">surprise</span>. Having a line of text appear with every click of the mouse forces the audience to stay with you every step of the way. This may work for primary school students but does not work for an intelligent audience. Give them a screen full at a time and let them read it in any order that they like. This is worst when they someone tries to surprise the audience with a punchy line at the end of every paragraph. Surprising the audience once per talk is difficult. Trying to do it every paragraph is just annoying.<br /><br />One final tip that isn't as serious but is not obvious enough to deserve a mention. Use black text on a white background, this gives good contrast that can be seen regardless of color-blindness and with the bright background the room is lit up even if all the lights are off. The audience wants to see you and sometimes this is only possible by projector light. Also the more light that comes out of the projector the less heat that builds up inside, it can really mess up a presentation if the projector overheats.

There are two critical things that any anti-spam system must do, it must not lose email and it must not cause damage to the rest of the net.<br /><br />To avoid losing email every message must be either accepted for delivery or the sender must be notified.<br /><br />To avoid causing damage to the rest of the net spam should not be bounced to innocent third parties. To accept mail, process it, and then bounce messages that appear to be spam will result in spam being bounced to innocent third parties.<br /><br />The only exception to these two conditions is for virus email which can be positively identified as being bad and therefore they can be silently discarded. For any other category of unwanted mail there is always a possibility of a false-positive and therefore the sender should be notified if the mail will not be accepted.<br /><br />Therefore the only acceptable method of dealing with spam is to reject it at the SMTP protocol level. Currently I am not aware of any software that supports Bayesian filtering while the message is being received so that it can be rejected if it appears to be spam, it would be possible to do this (I could write the code myself if I had enough spare time) but AFAIK no-one has done it.<br /><br />The most popular methods of recognising SPAM before it is accepted are through DNSBL lists (DNS based lists of IP addresses known to send SPAM), RHSBL lists (DNS based lists identifying domains that are known to be run by spammers), and Gray-listing (giving a transient error condition in the expectation that many spammers won't try again).<br /><br />Gray-listing is not effective enough to be used on it's own, therefore DNSBL and RHSBL systems are required for a usable email system. Quickly reviewing the logs of some of my clients' mail servers suggests that the DNSBL <span style="font-weight: bold;">dnsbl.sorbs.net</span> alone is stopping an average of 20 SPAMs per user per day! The <a href="http://www.sorbs.net">SORBS</a> system is designed to block open relays, machines that send mail to spam-trap addresses, and some other categories of obviously inappropriate use. The number of false-positives is very small. On average I add about one white-list entry per month, which isn't much for the email for a dozen small companies. For every white list entry I have added I have known that the sender has had a SPAM problem. I have not had to add a white-list entry because of a DNSBL making a mistake, just because people want to receive mail from a system that also sends SPAM.<br /><br />I was prompted to write about anti-spam measures by an ill-informed and unsubstantiated comment on my blog regarding DNSBL services.<br /><br />If anyone wants to comment on this please feel free. But keep in mind that I have a lot of experience running mail servers including large ISPs with more than a million customers. The advice I give in terms of anti-spam measures concerns techniques that I have successfully used on ISPs of all sizes and that I have found to work well even when both ends use them. Make sure that you substantiate any comments you make and explain them clearly. Saying that something is <span style="font-style: italic;">stupid</span> is not going to impress me when I've seen it work for over a million users.

We're still in wt:Copenhagen today, but we head out this afternoon for our tour of the Baltic Sea. We've had a great time in the city so far, mostly due to staying with longtime Wikitraveller wt:User:Elgaard, who generously offered us the extra room in his apartment for the time we're here. There's something about staying in an actual human being's home while you're travelling to really recharge the batteries. After a week in hotels and restaurants, a little time in a real house can make you feel a lot more human. We took our time getting to Copenhagen from wt:Odense at the end of the Wikisym conference, mostly because I was really hung over. I'd spent the last night of the event drinking at the Irish pub in the pedestrian area, and I probably had 1-5 pints too many. Paul Yount calls Irish pubs "the first Open Source franchise", and it's true: you can expect certain things at a pub no matter where it is in the world. Although we started out with about 30 people, the crowd thinned through the night. I had a good time talking with Brion Vibber and Chuck Smith about the state of Esperanto-language wikis on the Web -- in a mish-mash of English and Esperanto, of course. (In case you were wondering: the state is "fine".) I also chatted Wikimedia Foundation politics with Angela Beesley; we both think Erik Moeller is going to make a good addition to the WMF board. After the pub shut down, I headed to the deathly silent casino in the sub-basement of the Radisson of Odense. The bar was eerily silent, and the gaming tables were intense and serious; I don't think people could have been more somber if they were organ harvesters gambling for body parts. The last hangers-on were Andrea Forte of Georgia Tech, Alex Schroeder of CommunityWiki, Sunir Shah of MeatballWiki, and Eugene Eric Kim, of Blue Oxen and HyperCore. In other words, some of the smartest people in the wiki world today -- we talked wiki politics and theory until the wee hours of the morning. They all switched to mineral water while I was still slugging down pints of Carlsberg Special, which is probably where I went wrong. Wikisym, for me, was one of the best conferences I've been to this year, and I've been to a lot. It capped off a long summer of conference-going, and this fall should be relatively tranquil. Which is great: I have a lot of work to do, based on the ideas I've picked up this season. tags: wikisym2006 odense copenhagen wiki

sterbro All of which is to say that I was feeling pretty crufty the next morning as we got on the train. Kindly Maj got us a late checkout and let me sleep in late, which helped a lot; a falafel sandwich around 11AM also cleared my head a bit. The train ride from Odense to Copenhagen was great, and by the time we got to Niels Elgaard Larsen's house in sterbro (a neighborhood of Copenhagen) I was pretty refreshed. Niels took us out to an early dinner at a restaurant called Pixie in a square by his house. Copenhagen has some pretty strict traffic laws, and the number of cars on the street is possibly the least I've ever seen for a major metropolis, leaving a lot of room for sidewalks, bike paths, and open parks and plazas. We got to chat with Niels over a fresh pasta dinner, and thence home to his house for beers and more talk. One great thing about visiting Wikitravellers is that they tend to be a) very smart, b) well-travelled, and c) interested in Free Software and Free Culture. Niels is no exception; he's active in the Danish and European Free Software and information freedom communities, and he's extremely interesting to talk to on the subject. We shared travel stories and talked about Open Source and Open Content later than I would have thought, based on my earlier-morning hangover. Probably the high point of the evening, for me, was when Niels shared a brilliant idea for a way to distribute Wikitravel guides in digital form for a very wide array of users. We've had a hard time settling on a mobile document format for Wikitravel guides, since mobile devices like PDAs and cell phones support standards so poorly. It's one of the most requested features for Wikitravel, but it's going to take a huge amount of work to cover even a fraction of the mobile device owner community. Except Niels had a genius idea for how to distribute guides in a simple, standard format that works on a mobile digital device many if not most travellers carry with them every time they travel. The idea: make guides that are downloadable JPEG images which can be copied to a SD card or Compact Flash or Memory stick or whatever, then stuck into a digital camera. If the camera supports zooming on images, and has a decent screen for review, the guides might be useful and readable. I'm going to try to do some experiments with the idea -- I think it could be a real winner. Adding 30-40 images to a camera today is pretty cheap, and if they're just text I think some aggressive compression can work well. tag: jpeg sterbro niels copenhagen wikitravel mobile

Copenhagen on foot Yesterday we did a big tour of the city on our own. In the morning, we had some breakfast at the Laundromat Cafe right next door to Niels's house, and I took the opportunity to clean a week's worth of dirty laundry. Nothing like a stack of clean clothes to make you feel more like a decent citizen. I was down to a bathing suit and the ICANNWiki t-shirt Ray King gave me at Wikisym. Then we headed out on the town to do some sight-seeing. First we hit the Kastellet, a fortress in northeast Copenhagen that's the oldest operational military base in Europe. It's got the distinctive star-shaped outline typical of old fortifications, and is surrounded by a lovely park with ducks and swans. We had lunch at a nearby caf , with large beers. (Gee, I'm getting worried about the pattern here.) After lunch we made an unscheduled stop at den lille havfrue -- the famous Litle Mermaid statue in the harbour. It was miniscule and surrounded by perhaps 100 onlookers, crammed into a tiny swatch of sidewalk. We stopped about half a mile away, took some pictures of the crowd, and moved on. We then hoofed it down through the harbour and across Nyhavn and a bridge to Christianhavn and Christiania. We'd both heard about the city-within-a-city run on anarchist principles -- kind of like a giant squat -- but neither of us had been there before. It was an interesting place -- packed with people, lots of food cooking a beer-drinking, caf s and restaurants all over the place, interspersed with art installations and little gardens. But it had the unkempt scumminess of a big squat, too -- especially on the main drag -- and there were a few too many pitbulls and gutterpunks for my tastes. Overall a good experience but I don't know if I'll go back. After our long walk we took the metro back to Niels's, where we napped until he and wife Chiquita got home. Chiquita is an investment banker from wt:Toronto who does a lot of business in Europe, where she met Niels a few years ago. They were married last year and have had a long-distance relationship -- visiting each other a week or so out of each month -- for the whole time. She's moving here this year, which I think will be nice for both of them. We had a good dinner at a place called Thomas's -- a buffet, which seems to be very popular here -- and then back home for a nightcap and bed. Amita June was overtired by the time we got her to bed, and she let us know that we'd pushed her too hard with a quarter-hour of heavy crying. But we all got to sleep pretty well afterwards, and at least the parents know that we should take it easy in the future. tags: copenhagen kastellet christiania little mermaid

Evaluating programming languages for playing with Debtags Since having workable bindings for the C++ Debtags libraries seems to be still a bit in the future, I'm planning to build a bit of native infrastructure in some higher level language. First step is seeing what language I could start playing with. The problem At the most basic level, in Debtags we have a number of packages, each of which have a set of tags. The way I usually save tags is a file with the format:

package1, package2: tag1, tag2, tag3
package3: tag1, tag2

That is, every line has a list of packages with the same tags, and the list of their tags. Since any script I'm going to write has to at least be able to parse the data into something like a package -> tags hash, then print it out. Let's see how perl, python and ruby perform. Tests C++ The reference point for the experiment will be the C++ implementation, tagcoll:

$ time tagcoll copy package-tags > /dev/null
real    0m0.421s
user    0m0.412s
sys     0m0.000s

Perl First attempt is with Perl, creating the script that parses into a hash of package => set of tags and prints the result. There are set modules for Perl on CPAN, but I have none handy at the moment. However, since they are implemented using hashes, I can approximate them by using a hash. Note that I also want to have a different copy of the tag set for every package, so that I can manipulate them in the future without unwanted side effects. Here is the code:

#!/usr/bin/perl -w
use strict;
my %db;
# Read the tag database
while (<>)
 
    chop();
    my ($pkgs, $tags) = split(': ');
    # Create the tagset using keys of a hash
    my %tags = map   $_ => undef   split(', ', $tags);
    for my $p (split(', ', $pkgs))
     
        # Make a copy of the tagset
        $db $p  =  %tags ;
     
 
# Write the tag database
while (my ($pkg, $tags) = each %db)
 
    print $pkg, join(', ', keys %$tags), "\n";
 

Here is the running time:

$ time ./parse.pl package-tags > /dev/null
real    0m0.448s
user    0m0.436s
sys     0m0.008s

Not so bad, comparable with tagcoll. Python Then comes Python. I'm not much of a Python fancier, but I'm rather attracted by the new set native type introduced with Python 2.4, which seems to have most of what I need nice and done. Here is the script:

#!/usr/bin/python
import sys
input = sys.stdin
if len(sys.argv) > 1:
    input = open(sys.argv[1],"r")
# Read the tag database
db =  
for line in input:
    # Is there a way to remove the last character of a line that does not
    # make a copy of the entire line?
    line = line.rstrip("\n")
    pkgs, tags = line.split(": ")
    # Create the tag set using the native set
    tags = set(tags.split(", "))
    for p in pkgs.split(", "):
        db[p] = tags.copy()
# Write the tag database
for pkg, tags in db.items():
    # Using % here seems awkward to me, but if I use calls to
    # sys.stdout.write it becomes a bit slower
    print "%s:" % (pkg), ", ".join(tags)

Here is the running time:

$ time ./parse.py  package-tags  > /dev/null
real    0m0.418s
user    0m0.376s
sys     0m0.036s

I'm pleased, very pleased. Using the native set seems to be not only handy, but efficient. Ruby Finally, Ruby. I like to use Ruby. In this case, however, it lacks a native set implementation, although it has a set module which is implemented using a hash. Here is the script:

#!/usr/bin/ruby
require 'set'
infile = ARGV[0] ? File.new(ARGV[0]) : $stdin
# Read the tag database
db =  
infile.each_line do  line 
    line.chop()
    pkgs, tags = line.split(": ")
    # Create the set using the Set module
    tags = Set.new(tags.split(", "))
    pkgs.split(", ").each do  p 
        # Is this a copy or a reference?  I need to find out.
        db[p] = tags
    end
end
# Write the tag database
db.each do  key, tags 
    # Ouch, Set does not do join by itself
    print key, ": ", tags.to_a.join(", ")
end

Here is the running time:

$ time ./parse.rb package-tags > /dev/null
real    0m1.637s
user    0m1.572s
sys     0m0.052s

I hope I got something wrong in the script, but I can't see what. Results As much as I don't fancy Python, it looks like it's currently the best choice for playing around with Debtags. I hope the native sets will bring me joy. If in the future I'll be asked "how come you chose Python for this Debtags thing?", I can point to this page.

GNUMP3d I’ve made a test version of GNUMP3d v3.0 available for people who wish to try it out in advance of a real release. This will most likely be the last GNUMP3d release I make, so feedback is appreciated. Once it is out I’ll hand the project over to other people who want it. (So long as they agree to keep the basic goals of the project alive, can program perl, and have some familiarity with the code). The project has quite a lot of users interested in it, so it deserves to live on. This project was the first program I packaged for Debian, and was the reason I joined the project in the first place…

As a Debian sysadmin, I enjoy greylistd because it is very simple to set up and quite efficient. However the current maintainer seems MIA, and did not answered to my mail in one month. So today, I decided to begin to fix some bugs which were in the BTS. A NMU has been uploaded to delayed/10. I'd like that someone take care of this package, and I don't think that I am the best person for that. But maybe it will end up with me as maintainer if no one is interested. But if you are, drop me a mail. ;)

A typical web page will consist of dozens of files - images, javascript, CSS. Web browsers usually load 2 files in parallel (recommended by the HTTP/1.1 spec to use max 2 keep-alive connections). If you are including many javascript files in your <head /> element, these will probably be loaded first, the images second. This is the effect of images appearing "late" over slow connections. However, if your page can be displayed without the javascript (which is very recommendable because of accessibility issues), you might want the browser to load the images first. If your page totally relies on JavaScript - bad luck for you. In order to improve your load times, you can use some simple techniques. For example by putting images on a separate server (e.g. images-amazon.com, yahoos yimg.com, static.flickr.com, photos1.blogger.com). This is a common practise for large sites, for several reasons:

• A web server serving exclusively static images can use a more lightweight, more performant web server software
• It can benefit from different caching strategies
• It can benefit from different hardware choice (e.g. slower CPU but more memory; raid not really needed, better to have two servers etc. pp.)
• Images usually make up a large chunk of the traffic - but they're easy to replicate to a worldwide mirror network
• Authentication, cookies etc. don't need to be sent
• Might be outsourced, since it doesn't contain business data
• Images can be loaded via separate http connections

The last point is the inspiration for this posting - while your web server is still busy building some dynamic web page or serving some Ajax requests, your image server could already be sending out the images. This might give the user the impression that your web site is much faster. Most users are broadband - but they still have some latency. In fact, latency has increased for many users with broadband due to interleaving on DSL lines, for example; ping is higher with regular DSL lines in germany than it was with modems or ISDN. Some relevant pages: HTTP/1.1 Pipelining [w3.org], Mozilla pipelining FAQ [mozilla.org]

Introductory notes about tagging A group of nice Swiss researchers are doing some research on Debian, and as part of their research they are about to tag around 400 libraries using Debtags. They feel that being able to distinguish projects by categories will help us to improve their analysis of component (library) reuse. They asked me if I had useful Debtags information for them besides the website and the Debconf5 paper, so I did some research and I share it here. The list archives have various useful posts:

• Thirteen tips from effective tagging, a commented link to an article about tagging websites on Del.icio.us tags.
• Many discussions about vocabulary structure.
• Tips collected while approving LOTS of tags

Also, the vocabulary itself has short and long comments for each tag, and the long comments sometimes have useful instructions. In order to contribute properly reviewed tags, I suggested to start by posting tag patches on the mailing list: after we discussed some of them and we trust each others, I'll be happy to give commit access to the svn repository. To create a tag patch, one can use tagcoll:

svn cat svn://svn.debian.org/debtags/tagdb/tags > tags
cp tags tags.edited
[...edit tags.edited...]
tagcoll diff tags tags.edited

Note that there are probably many new tags in the not-yet-revied database, so one may want to proceed this way:

1. svn cat svn://svn.debian.org/debtags/tagdb/tags > tags
2. remove from tags all the lines corresponding to the packages you're not interested in
3. wget http://debtags.alioth.debian.org/tags/tags-current.gz
4. remove from tags-current all the lines corresponding to the packages you're not interested in
5. tagcoll diff tags tags-current > changes
6. edit changes removing those changes that make no sense you can review the edits you made to the changes patch this way: svn cat svn://svn.debian.org/debtags/tagdb/tags tagcoll --patch-from=changes.orig > tmp1 svn cat svn://svn.debian.org/debtags/tagdb/tags tagcoll --patch-from=changes.edited > tmp2 tagcoll diff tmp1 tmp2
7. apply the reviewed patch to the svn repository: svn cat svn://svn.debian.org/debtags/tagdb/tags tagcoll --patch-from=changes copy > tags-patched
8. work from there

Everyone is of course free to use the list for any questions.

(and what we want to do to avoid similar problems in the future) A few days ago, a broken xserver-xorg-core was uploaded to dapper-updates. This caused, unsurprisingly, a large amount of bug reports. A fixed package was uploaded about 12 hours after the first bug report came in. We also pointed all the $countrycode.archive.ubuntu.com (se.archive.ubuntu.com, au.archive.ubuntu.com, etc) to archive.ubuntu.com to speed up the propagation of the fix. Even so, it hit far, far too many users. Incidentially, the distro team is currently in a sprint in Wiesbaden, Germany and we had a large discussion this morning about both how to handle such situations when they happen (and recover from them, mostly in the technical sense) and how to prevent them from happening in the first place. The latter is obviously more important as we won't have to recover if there is not a problem in the first place. Note that those ideas listed below were ideas and not finished procedures and we are going to write up a proper policy document. Ideas for prevention ranged form using $distro-proposed and explicit call for testers of that to getting more code review for updates. The current review process for updates to $distro-updates is a review by the release manager who accepts it into $distro-updates. This update passed that review even though the update was faulty, so even if we had another reviewer, it might have passed that review too. Using $distro-proposed does not prevent the problem from affecting anybody, it just changes the group affected with the goal that the group choosing to enable $distro-proposed will hopefully be able to recover more easily. Recovery ideas ranged from being able to put an update onto a user's machine whether he wanted it or not to snapshot/rollback support and having some kind of a "safe mode" where it would give you a kdrive-based VESA X server and tools to fix your system. I'm not sure what we would do if we managed to break one of those tools (or the "safe-mode" X server), though. We all agreed that being open about the problem, the cause of the problem and how we are working to solve it is important. Downplaying the severity or making jokes or sarcastic comments about the fix ("Ooops, we did it again") is bad and something we shouldn't do. (And I don't think we did it this time either.) No response is equally bad and something we should work hard to avoid. Hopefully, we will have a procedure in place in a little while which tells us how to handle such an emergency when it happens and we will be deploying safeguards to prevent it from happening again while not ending up paralysing us and making us unable to deploy updates to $distro-updates as this is something we need to be able to. While this post is fairly critical of the current set of policies and procedures, I have tried hard to avoid pointing fingers at anybody in particular. I would much rather have us have a positive and constructive discussion about how to avoid similar problems in the future than a discussion on who is to blame. The points and views in this post is also those of my own and not any kind of official communication from Canonical or Ubuntu.

In the pkg-scicomp project a few packages are in progress<br /><br /><ul><li><span style="font-weight: bold;">freefem++</span> a very powerful language to solve pde, right now the remaining issue is updating all files and fix the licence/copyright</li><li><span style="font-weight: bold;">trilinos</span> a meta-package that contains many numerical libraries with an emphasis on robust parallel algorithms. Right now 6.0.19 is in the box, I think I will wait for the version 7<br /></li><li><span style="font-weight: bold;">parmetis</span> well parametis is already taken care of by hazelsct but I wanted to modify it and provide some headers from metis. Patches will be sent to hazelsct.</li><li><span style="font-weight: bold;">arprec</span> an arbitrary precision numerical type in C++, I need to update to the last version which fixed licensing issues</li></ul>I am happy that it is possible to have a large numerical software suite in Debian which you will have difficulties to find in any other distro.

Today^Wnight i got access on a t2000.

Copyright 2005 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.19.0, 32760 MB memory installed,
Ethernet address 0:14:4f:f:3c:34, Host ID: 840f3c34.

different d-i install-tests are still running, detailed reports will follow ASAP

I’m suprised to see people calling each other sluts on the Debian Planet. Thankfully I’m not going to talk about sexism, or mention hot-babe. I was tempted. Briefly. On the right I’ve got a guy coming round to my flat to take a look at my broken window on Tuesday. I’ve done a fair bit of work today, and fixed some more bugs, but it is almost painful to work in that room, just because of the cold. I could use the heaters but it seems wasteful to turn them on knowing full well that the majority of the heat will just float straight out of the window. If I wasn’t such a slut I’d wear more clothes ….

On the whole I agree with Erich. Subprojects are key to preserving positive energy as a free software project scales. But I wouldn’t say the ill effects suffered by projects as they age is just “a matter of size”. And I wouldn’t de-emphasize the importance of guidelines like the CoC in countering those effects, though I’d agree it does not provide immunity by itself. Ubuntu benefits from the Debian social experiment having started first. So the people involved have the opportunity to learn from and improve on earlier efforts while their project is still young. The CoC is no panacea, but it is a clue that lessons are being learned; deliberate effort needs to be made to keep work fun, especially as a project grows and people begin to lose touch with each other. Putting these lessons into practice isn’t always easy, but I think it would help if as individual developers we’d reflect more on how we interact within our projects and work on making improvements. I appreciate the personal guidelines Erich shared and will adapt them to make them my own.

With the advent of Uncle Steve's Barbie, I was reminded of DebConf, and the fact that I was intending to setup a blog, if for no other reason than so that I could make this post, so here goes: Some of you will be aware that my father died on May 16th this year, which was during Debconf6. Given that I was in Mexico, while the rest of my family were dealing with the fact of his death in the UK, I'd have expected to feel somewhat lonely or isolated. I'd just like to say that, the fact that during the rest of the week people kept coming up to me and offering their sympathies was really amazingly supportive, and is deeply appreciated -- thank you all. Being surrounded by friends and knowing that we were engaged in doing something productive helped offset the loss to some extent. It also helped to know that my father had chosen the optimal time to die, having survived until the moment when his quality of life was about to evaporate, but not beyond. Since so many of you offered your condolences about my father, I thought you might like to have at least a flavour of the man, and anyway I'd like to publish the eulogy written by Steve McCullagh, which he recited at the funeral, because it sums up my father brilliantly. So, thanks to all of you that offered your support, also thanks to the organisers of Debconf6, and thanks very much to Steve McCullagh for his permission to publish the eulogy.

Opensource has some scalability limits. A recent blog post shows that e.g. Gentoo is suffering from similar effects as Debian. I believe this is a matter of size, so I doubt that Ubuntu will be immune to this just by it's Code of Conduct and similar things. There is this well-known idiom: "too many cooks spoil the broth" - I think this applies to Opensource work, too. Given that we all want "democratic" work, without having a cabal do the important decisions, I see only one way to resolve this. Subprojects. Just like a distribution doesn't inherit all the software package communities problems, we should try to avoid "aggregating" all the issues at a distribution level. And if you take for example Gnome, many developers are involved only in a few applications, and the communities in each application are probably not of the "critical mass". Examples of such subprojects in Debian include:

• installer work
• architecture porters
• team maintainance of large package sets

Maybe we can find a way to make more use of these effects, that smaller groups usually work together much better. I'm not sure yet how to add extra "sub-communities". Some like team maintainance oranize themselves, which is probably best. Some parts can move to freedesktop, becoming "upstream", and joining efforts with other distributions. Some were created on "alioth". So I think Debian is already on the right track here. Anyway, I'm not a "key player" in Debian, and I'm probably not going to change this. But I'll personally try to follow some simple guidelines to make life nicer for everyone.

• I try to not participate in flame wars. If a mailing list is frequently ridden by flame wars, it's best to leave it alone. There will just be new flamewars coming up again and again. Instead, I try to use mailinglists with fewer people, that maybe are more on-topic.
• I don't read threads that obviously got out of hand.
• I don't read debian-devel. It's a waste of time.
• I try to keep out of other peoples work. Either I become a "serious" contributor, or I let them do what they think it's best. I'm likely less capable of seeing how it all works together if I'm not closely involved. Pinging or filing "wishlist" bugs is of course okay, but you have to accept the decision of those doing the actual work.
• I try to keep stuff away from the full community. Discussing it within a smaller group (the people who actually do the job) is more productive, and you probably won't get much extra results from asking a larger group - but you'll end up with lots more fighting.

I spent the first 12 days of August at the German Junior Bridge camp^[*] in Rieneck. The reason I'm blogging about that in the "debian" section is that it felt very much like DebConf - lots of weird just-like-you people. We played about two tournaments per day, always using different scoring methods or other ways to make up pairs of players - we were not supposed to play with the same partner twice, though Frederic, my flatmate, and I were casted together for a second time in a young-plays-with-old tourney. In this sport, you are a junior until well past 30, and he was just above the cut of 35 of this event. We also bribed the good fairy to let Eva and me play together in the final masterpoint tourney. We didn't score especially well since we were quite tired, but hey :* The site is an old castle, now operated by a German Scouts organization. Somehow, the castle operates in a different time zone, breakfast was served at 12am, lunch at 7pm, and dinner at 11pm. DebConf should consider adopting that :) It would also be interesting to see if we could have a "performance" at the end, and who would run for Miss and Mister DebConf... The pictures I took are in my gallery. Sadly I didn't take a picture of the coffee tally list where one guy made two ticks in the "flatrate" column 8-) [*] beware, this is ugly html Update: Next year's bridge camp will be from July 26th to August 5th - please pick a disjoint range for DebConf...

Short summary: Server down.

Isn't Murphy absolutely lovely? Hardware will, of course, break on weekends.

The light in my kitchen's ceiling stopped working a month ago. I changed the light bulb, a week ago, but it didn't help, so on Friday I asked H ctor to take a look at it. Absolutely low priority. The cable was literally roasted, so he asked me to cut the power off, in order to replace the cable. I did, without remembering to propperly power off the server. What are journalling filesystems for anyway? The UPS battery used to perform much better, oh the decay, so the server is abruptly shut down after a couple of minutes. As H ctor was not able to "quickly" fix the kitchen light, and I was not in a hurry, and do not really care about the damn light, we just didn't look at it any further. So far so good.

Some hours later, at midnight (maybe that's technically Saturday, but it really felt like a Friday, I swear to the allmighty vegetarian spaghetty monster with no meat balls whatsoever), I try to power the machine up. And a sadly familiar ritual is about to be performed. Since I moved the server into "the run down attic I call home" I dreaded the moment I had to reboot the machine. It would come up, you could see the blue case fans light up and spin, the hard drives and CD drives be initialized, but no beep, no POST, no nada.

The ritual dance would consist of me submissively kneeling down to power on and off in a random sequence the back switch, the front one, the UPS, the reset buttom, curse, turn it completely off for random amounts of time, pull the cable in and out, curse some more... never really finding out when or what would make it fully come to life. But eventually it did, after 5, 10, 15 minutes, without any reproduceable pattern, it did. Not on Friday night. Or saturday. I spent most of the night (until 6 am) performing the ritual, googling like crazy, fustrated and eventually plain angry. All I could find was "the mobo is b0rked, exchange it". But I knew it was not. I knew the CPU was fine, the MoBO was fine, the memory was fine, because when I finally managed to get it to power up, all worked well!

But Miry came home and helped me out, coming up with a valuable clue: The mobo was not getting enough power form the PSU, so I got a spare PSU from H ctor and swapped them. The baby came up instantly. So I was very pissed off.

The good thing about it all is:
- I learned that power supply units sometimes fail. Even my wonderful, 100 EUR BQuiet! PSU.
- I missed completely all of the udev fun. Well, at least on my machines, but there's a couple of people I needed to help out today.

On Monday I got a new power supply, it is a joke of a plastic, for SM's sake! plastic!?, PSU with a couple blue fans. Pics of old nice one and crappy new one here. My sitting room looks like a space craft, and sounds like a plane is about to take off. The cats have not complained yet. They have not disconnected my land line (yet).
Update: The reason I bought this PSU is I have quite a big case, a case I can ride! So I needed Log cables. And I had to go for a cheapo modder plstic thingy, simply because I could not afford anything better.

I hate hardware.

Another thing that I want to do with Xen is scan systems for rootkits. For that, I'd like to create a snapshot, mount that and scan. However, the snapshot usually has dirty filesystems whose journals will be played back when mounting, I wonder if that could be used to escape detection; also, LVM will make the snapshot persistent, and refuse to bring up the LV in question after a reboot unless dm-snapshot is loaded, which it usually isn't. So I'd like to have temporary snapshots that get deleted after a reboot or when inactive for some time, so a bug in my scripts does not leave old snapshots around, or, in the worst case, stops my system from booting because my initrd does not have dm-snapshot. Also, because of potential bugs, I'd prefer that my scripts either don't have permission to delete snapshots they haven't created, or, if that's not possible, at least not have any mention of lvremove at all. The precedent for this would be temporary tables in SQL, so perhaps it might be an idea to introduce a session concept to LVM.