Recently, I made available information about Gammu and Wammu in machine readable formats (currently DOAP and PAD). In order to fully use advantage of PAD, I decided to push both Gammu and Wammu to some PAD enabled sites I found. At least it should give it a bit more visibility in Windows world. When I started looking for these sites, I was surprised that there is so much of them. Yes it is quite easy to setup such site as ASP provides PHP scripts to make such site, but I expected that people would be a bit sane and would not start 1001th software catalogue. But anyway, let's submit my software there to spread the world a bit ;-). The important site (at least as far as I remember them from times when I was using Windows) like Tucows or cnet downloads, have some lengthy review process, what is okay for me. But more funny are random small sites, where you immediately get 5/5 stars or sticker 100% Vista Compatible. Who cares, let's see if it will really attract some users.

Last night I managed to finish up a rather satisfying improvement to ext4 s inode and block allocators. The ext4 s original allocator was actually a bit more simple-minded than ext3 s, in that it didn t implement the Orlov algorithm to spread out top-level directories for better filesystem aging. It also was buggy in certain ways, where it would return ENOSPC even when there were still plenty of inodes in the file system. So I had been working on extending ext3 s original Orlov allocator so it would work well with ext4. While I was at it, it occurred to me that one of the tricks I could play with ext4 s flex groups (which are higher-order collection of block groups), was to bias the block allocation algorithms such that the first block group in a flexgroup would be preferred for use by directories, and biased against data blocks for regular files. This meant that directory blocks would get clustered together, which cut a third off the time needed for e2fsck pass2:

Comparison of e2fsck times on an 32GB partition

Pass	ext4 old allocator						ext4 new allocator
	time (s)			I/O			time (s)			I/O
	real	user	system	MB read	MB/s		real	user	system	MB read	MB/s
1	6.69	4.06	0.90	82	12.25		6.70	3.63	1.58	82	12.23
2	13.34	2.30	3.78	133	9.97		4.24	1.27	2.46	133	31.36
3	0.02	0.01	0	1	63.85		0.01	0.01	0.01	1	82.69
4	0.28	0.27	0	0	0		0.23	0.22	0	0	0
5	2.60	2.31	0.03	1	0.38		2.42	2.15	0.07	1	0.41
Total	23.06	9.03	4.74	216	9.37		13.78	7.33	4.19	216	15.68

As you may recall from my previous observations on this blog, although we hadn t been explicitly engineering for this, a file system consistency check on an ext4 file system tends to be a factor of 6-8 faster than the e2fsck times on an equivalent ext3 file system, mainly due to the elimination of indirect blocks and the uninit_bg feature reducing the amount of disk reads necessary in e2fsck s pass 1. However, the ext4 layout optimizations didn t do much for e2fsck s pass 2. Well, the optimization of the block and inode allocators is complementary to the original ext4 fsck improvements, since it focuses on what we hadn t optimized the first time around: e2fsck pass 2 times have been cut by a third, and the overall fsck time has been cut by 40%. Not too shabby! Of course, we need to do more testing to make sure we haven t caused other file system benchmarks to degrade, although I m cautiously optimistic that this will end up being a net win. I suspect that some benchmarks will go up by a little, and others will go down a little, depending on how heavily the benchmark exercises directory operations versus sequential I/O patterns. If people want to test this new allocator, it is in the ext4 patch queue. If all goes well, I will hopefully be pushing it to Linus after 2.6.29 is released, at the next merge window.

For comparison s sake, here is a comparison of the fsck time of the same collection of files and directories, comparing ext3 and the original ext4 block and inode allocator. The file system in question is a 32GB install of Ubuntu Jaunty, with a personal home directory, a rather large Maildir directory, some linux kernel trees, and an e2fsprogs tree. It s basically the emergency environment I set up on my Netbook at FOSDEM. In all cases the file systems were freshly copied from the original root directory using the command rsync -axH / /mnt. It s actually a bit surprising to me that ext3 s pass 2 e2fsck times was that much better than e2fsck time under the old ext4 allocator. My previous experience has shown that the two are normally about the same, with a write throughput of around 9-10 MB/s on for e2fsck s pass 2 for both ext3 file systems and ext4 file systems with the original inode/block allocators. Hence, I would have expected ext3 s pass2 time to have been 12-13 seconds, and not 6. I m not sure how that happened, unless it was the luck of draw in terms of how things ended up getting allocated on disk. So I m not too sure what happened there, but overall things look quite good for ext4 and fsck times!

Comparison of e2fsck times on an 32GB partition

Pass	ext3						ext4 old allocator
	time (s)			I/O			time (s)			I/O
	real	user	system	MB read	MB/s		real	user	system	MB read	MB/s
1	108.40	13.74	11.53	583	5.38		6.69	4.06	0.90	82	12.25
2	5.91	1.74	2.56	133	22.51		13.34	2.30	3.78	133	9.97
3	0.03	0.01	0	1	31.21		0.02	0.01	0	1	63.85
4	0.28	0.27	0	0	0		0.28	0.27	0	0	0
5	3.17	0.92	0.13	2	0.63		2.60	2.31	0.03	1	0.38
Total	118.15	16.75	14.25	718	6.08		23.06	9.03	4.74	216	9.37

Vital Statistics of the 32GB partition

312214	inodes used (14.89%)
263	non-contiguous files (0.1%)
198	non-contiguous directories (0.1%)
	# of inodes with ind/dind/tind blocks: 0/0/0
	Extent depth histogram: 292698/40
4388697	blocks used (52.32%)
0	bad blocks
1	large file
263549	regular files
28022	directories
5	character device files
1	block device file
5	fifos
615	links
20618	symbolic links (19450 fast symbolic links)
5	sockets
312820	files

Related posts (automatically generated):

1. Fast ext4 fsck times This wasn t one of the things we were explicitly engineering...
2. Wanted: Incremental Backup Solutions that Use a Database Dear Lazyweb, I m looking for recommendations for Open Source backup...
3. Ext4 is now the primary filesystem on my laptop Over the weekend, I converted my laptop to use the...

Last night I managed to finish up a rather satisfying improvement to ext4 s inode and block allocators. The ext4 s original allocator was actually a bit more simple-minded than ext3 s, in that it didn t implement the Orlov algorithm to spread out top-level directories for better filesystem aging. It also was buggy in certain ways, where it would return ENOSPC even when there were still plenty of inodes in the file system. So I had been working on extending ext3 s original Orlov allocator so it would work well with ext4. While I was at it, it occurred to me that one of the tricks I could play with ext4 s flex groups (which are higher-order collection of block groups), was to bias the block allocation algorithms such that the first block group in a flexgroup would be preferred for use by directories, and biased against data blocks for regular files. This meant that directory blocks would get clustered together, which cut a third off the time needed for e2fsck pass2:

Comparison of e2fsck times on an 32GB partition

Pass	ext4 old allocator						ext4 new allocator
	time (s)			I/O			time (s)			I/O
	real	user	system	MB read	MB/s		real	user	system	MB read	MB/s
1	6.69	4.06	0.90	82	12.25		6.70	3.63	1.58	82	12.23
2	13.34	2.30	3.78	133	9.97		4.24	1.27	2.46	133	31.36
3	0.02	0.01	0	1	63.85		0.01	0.01	0.01	1	82.69
4	0.28	0.27	0	0	0		0.23	0.22	0	0	0
5	2.60	2.31	0.03	1	0.38		2.42	2.15	0.07	1	0.41
Total	23.06	9.03	4.74	216	9.37		13.78	7.33	4.19	216	15.68

As you may recall from my previous observations on this blog, although we hadn t been explicitly engineering for this, a file system consistency check on an ext4 file system tends to be a factor of 6-8 faster than the e2fsck times on an equivalent ext3 file system, mainly due to the elimination of indirect blocks and the uninit_bg feature reducing the amount of disk reads necessary in e2fsck s pass 1. However, the ext4 layout optimizations didn t do much for e2fsck s pass 2. Well, the optimization of the block and inode allocators is complementary to the original ext4 fsck improvements, since it focuses on what we hadn t optimized the first time around: e2fsck pass 2 times have been cut by a third, and the overall fsck time has been cut by 40%. Not too shabby! Of course, we need to do more testing to make sure we haven t caused other file system benchmarks to degrade, although I m cautiously optimistic that this will end up being a net win. I suspect that some benchmarks will go up by a little, and others will go down a little, depending on how heavily the benchmark exercises directory operations versus sequential I/O patterns. If people want to test this new allocator, it is in the ext4 patch queue. If all goes well, I will hopefully be pushing it to Linus after 2.6.29 is released, at the next merge window.

For comparison s sake, here is a comparison of the fsck time of the same collection of files and directories, comparing ext3 and the original ext4 block and inode allocator. The file system in question is a 32GB install of Ubuntu Jaunty, with a personal home directory, a rather large Maildir directory, some linux kernel trees, and an e2fsprogs tree. It s basically the emergency environment I set up on my Netbook at FOSDEM. In all cases the file systems were freshly copied from the original root directory using the command rsync -axH / /mnt. It s actually a bit surprising to me that ext3 s pass 2 e2fsck times was that much better than e2fsck time under the old ext4 allocator. My previous experience has shown that the two are normally about the same, with a write throughput of around 9-10 MB/s on for e2fsck s pass 2 for both ext3 file systems and ext4 file systems with the original inode/block allocators. Hence, I would have expected ext3 s pass2 time to have been 12-13 seconds, and not 6. I m not sure how that happened, unless it was the luck of draw in terms of how things ended up getting allocated on disk. So I m not too sure what happened there, but overall things look quite good for ext4 and fsck times!

Comparison of e2fsck times on an 32GB partition

Pass	ext3						ext4 old allocator
	time (s)			I/O			time (s)			I/O
	real	user	system	MB read	MB/s		real	user	system	MB read	MB/s
1	108.40	13.74	11.53	583	5.38		6.69	4.06	0.90	82	12.25
2	5.91	1.74	2.56	133	22.51		13.34	2.30	3.78	133	9.97
3	0.03	0.01	0	1	31.21		0.02	0.01	0	1	63.85
4	0.28	0.27	0	0	0		0.28	0.27	0	0	0
5	3.17	0.92	0.13	2	0.63		2.60	2.31	0.03	1	0.38
Total	118.15	16.75	14.25	718	6.08		23.06	9.03	4.74	216	9.37

Vital Statistics of the 32GB partition

312214	inodes used (14.89%)
263	non-contiguous files (0.1%)
198	non-contiguous directories (0.1%)
	# of inodes with ind/dind/tind blocks: 0/0/0
	Extent depth histogram: 292698/40
4388697	blocks used (52.32%)
0	bad blocks
1	large file
263549	regular files
28022	directories
5	character device files
1	block device file
5	fifos
615	links
20618	symbolic links (19450 fast symbolic links)
5	sockets
312820	files

Related posts (automatically generated):

1. Fast ext4 fsck times This wasn t one of the things we were explicitly engineering...
2. Wanted: Incremental Backup Solutions that Use a Database Dear Lazyweb, I m looking for recommendations for Open Source backup...
3. Ext4 is now the primary filesystem on my laptop Over the weekend, I converted my laptop to use the...

If you haven t already read about it, DebConf 10 will be in the USA. More information about the bid can, currently, be found in our DebConf wiki. I myself are not happy with this decision, I would have preferred a non-US bid to win. No matter which, but unfortunately in the end we only had one non-US bid in the final meeting (which I was chairing together with Marga), and while this was a pretty good one, it still lost in comparision The whole meeting was very long, it took us 3.5 hours to get the decision. And if the three bids (the possible fourth dropped out before the meeting started) wouldn t have prepared as well as they did this year, it could have easily been 5 or 6 hours. I think it also helped a lot that we forbid everyone, besides few global orga team members and 2 people from each bid, to speak during the meeting. For the chatter and all stuff outside the meeting we made an extra channel and had one of the global orga team members forward any meeting relevant questions. Just looking at the amount of traffic the other channel had during the meeting this was certainly a good idea. We went on by having the bid people introduce themself and then gave everyone time to read the prepared pages of the bids, saving us from copy/paste into the channel, just having a few comments from the venue team inside the channel. Faster if people read it from a website. And after each bid described their own weak points, and what they think is good in the other bids, we had a question session. First part was moderated, 5 minutes per bid, questions related only to the bid. And then a free-for-all 10 minute session, where everyone in the channel was able to speak. Those first steps took nearly exactly one hour, which means the following two and a half hour we used entirely for the discussion how to rate the various topics from our priority list. Some of those topics had been pretty easy to decide as everyone agreed, like that the Quito bid wins for accommodation costs. Or Quito losing for network connectivity, while that had been a huge discussion between New York and Boston who would be better there. Same for food stuff, in cities like these it is practically impossible to say that one is better than the other. After some time (about 2 hours) we had all our topics covered and it was clear from it that the Quito bid couldn t win anymore, so they dropped out here. The rest of us had a 5 minute break and then continued the discussion for about 15 minutes, until it was crystal clear we wont be able to find a way out. We changed the discussion mode from Global team together with the bid teams to Global team only to finally get a decision. Took us another 10 minutes before we had the decision.

---

Now we have a venue for DebConf where a lot of people wont visit because of the country it is in. Some people sure do that out of a general I hate the US behaviour, I don t know (nor do I care), some others share concerns I have. Mine is mostly with their crap border system. Imagine you are going to visit some place as a tourist, and this place has nothing better to do than to mark you as criminal, by taking your fingerprints, a lot of personal (and totally irrelevant) data and storing that for decades (if not more). A border that can steal your laptop (and/or the data it is on). And whatever else. All that to work against terrorism . As if any of this crap would help. Its pure bullshit, but the usual level politicians have, no matter which country on this world. And I see no reason to put up with this. Truth is, I would rather quit my job before traveling there. The DC10 team puts a lot of hope into the new government to remedy some of the crap the US is doing / had setup during the brainless twit Bush. I wish their hope would come true, but I would place a fairly high bet that this won t happen. No government is taking back actions from their predecessor that are claimed to help security, even if they don t. No matter how much change they promised. (Yes, should their hope really come true and the US no longer thinks you are a criminal just because you want to visit this country, I will change my mind about going there. I just don t believe this will be the case). It probably can t hurt to take a year off and do something different. I don t know what I will do, will be quite a change not taking a whole month off to go to conference I do a little work for (2 weeks conference plus 2 weeks tourism in the country DebConf is in, a habit I started in Mexico ). Or to spend months before it doing work to get it running. I can t even imagine doing this stuff of normal holidays I hear others talking off, traveling to one location and bake yourself in the sun somewhere in a hotel, doing nothing. Brrr.

---

Now, as some may know, im one of the admins for the debconf.org domain and machine park. Just to avoid more people asking: I won t let my work there be affected from my dislike that the NYC bid won. They will get the same service every other DC had. Well, except that they have to do more admin work, as I will not neccessarily do all of it, especially not the local part, but just enable them to do it whenever neccessary and/or possible.

Two small tricks that I feel should be circulated more widely, because Google only disclosed them to me after a few false starts: To figure out which processes are writing to the disk, I eventually found /proc/sys/vm/block_dump (see also chapter 5 of the Laptop Mode FAQ) which does exactly what I was hoping to find: it shows down to the level of process and file where disk writes are coming from. (Turns out, that kded and PowerDevil are currently appending to the .xsession-errors file regularly, keeping the disk busy on my new toy. Unlimited scrollback in konsole was the other culprit, but that one is switched off easily.) Since I want to start backup on my netbook when it comes online at home, I figured the DHCP server was the likely place to trigger this. But the execute feature to start hook scripts on the DHCP server (see the dhcp-eval man page) was only added quite recently, so google first showed me a huge load of discussions involving tail on syslog and parsing its output. (I also found the simple event correlator which might be useful where run command features are not available.)

I recently upgraded my home router box to Debian Lenny. Everything went fairly smoothly, with a few exceptions. My NFS mounts no longer worked because apparently wildcards are no longer allowed in IP addresses in /etc/exports; the export addresses needed to be translated to subnet format (e.g., 192.168.98.* becomes 192.168.98.0/824). But after a power failure last night, the router box rebooted and I was no longer able to access the Internet from any clients on my LAN. Strangely, I could ping or traceroute external hosts and perform DNS lookups, but web surfing and ssh timed out after an initial handshake. I noticed by telnetting to port 80 of an external host, I got an error back from an invalid HTTP request (e.g. oeunthioues ), but if I sent a standard valid request (GET /index.html HTTP/1.0), the connection just hung with no response. I won t recount all the false leads I had in diagnosing this problem. It turned out that the Internet-facing NIC on my router box had been reset to a low MTU. By setting the MTU on the LAN clients to that low number, or raising the MTU on the Internet-facing NIC back to 1500, the problem was solved:

# ifconfig eth2 mtu 1500

After restarting networking on the router box, the MTU was again set back down to 576, which is apparently the default MTU for an X.25 network. I have no idea why the interface is getting that value by default (where it wasn t before), so I just added a hack to /etc/network/interfaces to fix it:

iface eth2 inet dhcp
  post-up /sbin/ifconfig eth2 mtu 1500

Interestingly, pre-up didn t work. Hopefully I ve included enough relevant terms in this entry that others with this problem will find it. It was hard to diagnose because no errors appeared in any log file, and I had partial but not complete connectivity from internal clients to the Internet. My first guess was that it was due to the iptables upgrade, but in fact it was entirely unrelated. Technorati Tags: Debian, Lenny, iptables, firewall, router, MTU

I came across the following from the ext3-users mailing list. The poor user was stuck on a never-updated RHEL 3 production server and running into kernel panic problems. He was advised to try updating to the latest kernel rpm from Red Hat, but he didn t feel he could do that. In his words:

I m caught between a rock and a hard place due to the EMC PowerPath binary only kernel crack. Which makes it painful to both me and my customers to regularly upgrade the kernel. Not to mention the EMC supportability matrix of doom.

That pretty much sums it all up right there. The good news is that I ve been told that dm-multipath is almost at the point where it has enough functionality to replace PowerPath. Of course, that version isn t yet shipping in distributions, and I m sure it needs more testing, but it ll be good when enterprise users who need this functionality can move to a 100% fully open source storage stack. About the only thing left to do is to work in a mention of the Frying Pan of Doom and the recipe for Quick After-Battle Triple Chocolate Cake into the mix. Related posts (automatically generated):

1. Tip o the hat, wag o the finger Linux power savings for laptop users It s interesting to see how far, and yet how much...
2. How active are your local Linux User s Groups? At the Linux Foundation, I recently had been brainstorming with...

I came across the following from the ext3-users mailing list. The poor user was stuck on a never-updated RHEL 3 production server and running into kernel panic problems. He was advised to try updating to the latest kernel rpm from Red Hat, but he didn t feel he could do that. In his words:

I m caught between a rock and a hard place due to the EMC PowerPath binary only kernel crack. Which makes it painful to both me and my customers to regularly upgrade the kernel. Not to mention the EMC supportability matrix of doom.

That pretty much sums it all up right there. The good news is that I ve been told that dm-multipath is almost at the point where it has enough functionality to replace PowerPath. Of course, that version isn t yet shipping in distributions, and I m sure it needs more testing, but it ll be good when enterprise users who need this functionality can move to a 100% fully open source storage stack. About the only thing left to do is to work in a mention of the Frying Pan of Doom and the recipe for Quick After-Battle Triple Chocolate Cake into the mix. Related posts (automatically generated):

1. Tip o the hat, wag o the finger Linux power savings for laptop users It s interesting to see how far, and yet how much...
2. How active are your local Linux User s Groups? At the Linux Foundation, I recently had been brainstorming with...

Michael Anissimov writes about the theft of computers from the Los Alamos nuclear weapons lab [1]. He suggests that this incident (and others like it) pose a great risk to out civilisation. He advocates donating towards The Lifeboat Foundation [2] to try and mitigate risks to humanity. They suggest pledging $1000 per year for 25 years. It s interesting to note that people in Pakistan pay $8 per month for net access that better by most objective metrics than that which most people in first world can get [3]. It seems that we need to remove the cartel for the local loop to get good net access, either deregulate it entirely or make it owned by the local government who are more directly responsive to the residents. Bruce Schneier wrote a post about a proposed US law to force all mobile phones with cameras to make a click sound when taking a picture [4]. The law is largely irrelevant, as it s been law in Japan for a while most phones are already designed in that way. One interesting comment from MarkH was: But if congress REALLY wishes to benefit the public, I suggest that all guns in the U.S. be required, before each discharge, to make loud sounds (with appropriate time sequencing) simulating the flintlock technology that was common at the beginning of U.S. history, including cocking, use of the ramrod, etc. This would give fair warning of an impending discharge, and would limit firing rates to a few per minute. ROFL Brief review of a Google Android phone vs an iPhone [5]. The Android G1 is now on sale in Australia! [6]. LWN has an article about the panel discussion at the LCA Security Mini-conf [7]. Jonathan Corbet has quoted me quite a bit in the article, thanks Jonathan! Peter Ward gave an interesting TED talk about Hydrogen Sulphide and mass extinctions [8]. The best available evidence is that one of the worst extinctions was caused by H2S in the atmosphere which was produced by bacteria. The bacteria in question like a large amount of CO2 in the atmosphere. It s yet another reason for reducing the CO2 production. Michael Anissimov has written a good article summarising some of the dangers of space exploration [9], he suggests colonising the sea, deserts, and Antartica first (all of which are much easier and safer). Until we gain the ability to create huge (miles wide or larger) air bubbles in space enclosed by rapidly self-healing transparent membranes, it will be cramped and overwhelmingly boring. You ll spend even more time on the Internet up there than down here, and your connection will be slow . A confined space and slow net access, that s like being on a plane.

• [1] http://www.acceleratingfuture.com/michael/blog/2009/02/80-missing-computers-at-nuke-lab-watchdog/


• [2] http://lifeboat.com/


• [3] http://blogs.dialogic.com/2009/01/community-networks-the-robinhood-approach.html


• [4] http://www.schneier.com/blog/archives/2009/02/making_cameras.html


• [5] http://www.terdmonk.com/2009/02/16/yet-another-android-review


• [6] http://www.terdmonk.com/2009/02/15/android-here


• [7] http://lwn.net/Articles/315974/


• [8] http://www.ted.com/index.php/talks/peter_ward_on_mass_extinctions.html


• [9] http://www.acceleratingfuture.com/michael/blog/2009/02/space-that-boring-and-dangerous-place/

I was going to reply to this in the mailing list, but after I spent half an hour furiously typing this, I thought it might be better to put it into a blog, for a slightly wider audience, perhaps a more permanent life and partly in an effort to end this thread on a more or less constructive note. The backchat for this is that the LCA 2009 video has started to go up on the web, and some talks have some gaps in the audio stream... Russell Coker wants to make a constructive suggestion, as follows: On Wed, 2009-02-25 at 18:02 +1100, Russell Coker wrote:
>
> I've pasted in the below paragraph (the third time I've included it in this
> thread) to reiterate my point. Note that I am not asking you to re-do any
> videos, I am making a suggestion for future people.
>
> # I suggest that in future when preparing such videos the sections with no
> # sound be omitted and replaced by a short note explaining the omission,
> # something like "sorry, due to technical difficulties four minutes of sound
> # were not available". Having a second ogg file for the lip-readers would be
> # an option although I expect that the demand would be minute.
> As someone who has not been at all involved with the production of the LCA videos, but who has been intimately involved with the process of streaming DebConf 6, 7 & 8, I think this sort of additional effort will only happen if people voluntarily do it themselves. Just the task of *watching* all of the produced videos is a huge job for one individual, but as a community of individuals it is quite likely that at least one individual in the community watches each video. If each person who was offended by the quality of post-production work took it upon themselves to fix up only one video then it is probable that we would see some changed. Otherwise I'm afraid it is unlikely. Further in his e-mail, Russell Coker wrote:
>
> My observation was that the microphones were put down AFTER they ceased
> operating. A non-functional lapel microphone is no better than a non-
> functional hand-held microphone.
>
> Having a large supply of new batteries would be one way of alleviating the
> problem (I believe that some of the instances were due to flat batteries).
> Another possibility is having two microphones on hand so that if one died the
> other could be turned on.
>
> A wired microphone that doesn't rely on battery power would probably be the
> most reliable option. That of course might not fit with OH&S issues. Most speakers are uncomfortable / unfamiliar with wired microphones. Spares are essential, of course, but the problem can usually be avoided by having a checklist for the audio person to confirm several things: Before the start of the talk:

• check that batteries are good enough to last for the full length of the coming talk.
• check sound levels are correct for this speaker
• confirm sound is going through to recording
• check the speaker knows how to turn the mic off/on

At the start of the talk:

• confirm sound is going through to recording

At the end of the talk:

• Turn the mic off to save battery.

There are probably a couple of things that I've missed, but if you start with a checklist you pretty soon modify it into a *good* checklist, and it *really* helps when people are under fire. In fact lapel mics are not the best microphones for these kinds of presentations. The best mics are the ultra lightweight 'headset' models which place a the mic near to the speakers mouth. These do not suffer when the speaker turns their head hard to the left or right, at which points a lapel mic stops getting their speech. They also work well with that more hirsute minority so over-represented in our particular community (alas, that this set no longer includes Bdale :-) Of course DebConf has a large team of volunteers for streaming the conference, and has developed these kinds of procedures over a number of years. At DebConf there are usually only two main streams, each of which involves:

• The director, operating the video mixer
• Speaker camera operator
• Audience camera operator
• Slides to video convertor
• Sound mixer operator
• Talk timer, to warn speakers at t-10, t-5 & time is up.
• Two roving people responsible for getting audience mics to people talking in the room.

Ideally that really is 7 people (times two streams), and you can get by if you can't find all of the last three, but the other four are increasingly desirable. We mostly manage to do that with volunteers for two streams at DebConf, but for five or more streams at LCA it is inevitably a lot harder, and the quality necessarily has to be cut back to match the resources available. While it is true that sound is critical to this communication, it is unfortunately also true that most people's (even most geek's) eyes glaze over when presented with a mysterious box with a mere 6 sliding potentiometers, let alone when there are 36 of them, each associated with another 8 rotary knobs, and a rats nest of cables worthy of the worst network nightmare they've seen, and where everything appears to be literally held in place with duct tape. So it is not so surprising then that while it is relatively easy to find a gadget mad geek capable of operating a camera, or even experienced with operating a camera, finding people with experience operating a sound mixer is an order of magnitude harder. At LCA the operation appears superficially to often involve a (single) speaker camera operator with a very basic sound mixer which has been configured once by an overworked person who is unobtainable during the actual talk to solve any audio problems. These people are volunteers, and are doing their best, but it simply isn't possible to get a consistently high quality of video and audio in those circumstances. So as one of the organising committee for LCA 2010 in Wellington I will be watching what we do, and although I don't intend to get personally involved in the video production (I've got plenty of other stuff on *my* plate :-) I do intend to provide what advice and assistance I can. I know that we hope to have some professionals involved (as volunteers), but how many volunteers, and with what levels of skill & experience, we are unlikely to know until much closer than the date. I'll also personally try and get a run-down on all of the audio equipment so that in an emergency, if I happen to be available, I can sub as a sound mixer operator. So we will try and do better in Wellington in 2010. Come to the conference, though, because we can make no guarantees, and if you do come to Wellington, and you see a single cameraman, and you know something about running a sound mixer, then perhaps you can come and volunteer to help out in that capacity, for the talks you are attending anyway. We'd really appreciate the help. And finally I must say thanks, in particular, to Holger Levsen for all the learning I have gained since joining the videoteam at DebConf5 in Helsinki in 2005. And too, to all of those past conference teams (LCA, DebConf and otherwise) who have put their best efforts into providing videos of the talks I couldn't see in person. I know it's a bloody hard job, and often a less high profile one, so:

Thank You.

I got a HP 2133. I have installed Debian in it, successfully Here, I'll show all the steps I followed in order to install Debian.
First of all, you'll need an USB stick (formatted to FAT16). We need to convert such a device, in a bootable one. For making it, we have to download two files. One of them is boot.img.gz that you can get from http://debian.org/devel/debian-installer/ in the section "other images (netboot, usb stick, floppy, etc)". The other one, is a business card or a netinst image.

When you have downloaded them, we can proceed to make the next:

$ zcat /root/boot.img.gz > /dev/sdbX

(where sdbX should be changed for the correct device for you, maybe dmesg tail when you insert the USB stick will help you).

When you have executed what I have stated above, then you have to copy either the business card or the netinst ISO image (just one of them ). Doing this, our USB stick has become in a bootable device. You cannot copy a complete CD ISO, just netinst or business ones.

[Update] Note: If your system refuses to boot, try this:

# install-mbr /dev/sdb

(where sdb should be changed for the correct device for you, maybe dmesg tail when you insert the USB stick will help you).

Now, you can proceed to boot your HP mini using the USB stick and proceed with the installation process. After installing Debian, I'd suggest you to boot again, in Rescue Mode, to change the file acpi-support which is in /etc/default directory. Look for the line number 92 and set SAVE_VBE_STATE to false. Doing this you will avoid the annoying white screen you get when the system tries to save such a state.

Now, the problem you will face is the ******* resolution. After trying some xorg.conf files, I found one that worked for Debian. You can find it here.

For the wireless card I found this post http://jomcode.com/fadhil/?p=59 which worked pretty nice.

I still have to make the 3d acceleration work, but I haven't had the time to do it. Furthermore, I'll paste this info in http://wiki.debian.org/InstallingDebianOn/HP/HP2133 so that if someone has a HP2133, will be able to contribute or add some more information.

I have been meaning to write this up for a long time now, since I vaguely made a promise to do so last Debconf. I have also been wondering about the inefficiencies in my work-flow, but I kept postponing my analysis since there were still large gaps in my packaging automation since I moved off Arch as my SCM of choice. However, recently I have taken a sabbatical from Debian, so I ve had time to complete bits and pieces of my package building framework, enough so that I could no longer justify putting off the analysis. I tried writing it up, but the result confused even me; so I instead recorded every shell command during a recent series of packaging tasks, and converted that into a nice, detailed, activity diagram that you see over here. This is as efficient a work-flow as I have been able to come up with. details here Along with a git commit hook script, that parses the commit log and adds pending tags to bugs closed in the commit, the figure above represents my complete work-flow down to the details of every cd command I executed. I think there are too many steps still. Feedback and commentary would be appreciated, as well as any suggestions to improve efficiency.

Some necessary background: George R.R. Martin is a science fiction and fantasy author who's been writing (and editing) in the field for quite a while. In 1996, he started a new epic fantasy series entitled The Song of Ice and Fire, a hugely complex and sprawling series telling the story of an entire medieval world, with four volumes published and something on the order of 19 viewpoint characters to date. The fourth and last book to date in the series was published in 2005. It contained only half the viewpoints expected (and in my opinion and that of at least some other readers, the least interesting half). There was an afterword saying basically that the book was cut somewhat artificially in half for length reasons (it was 753 hardcover pages for what was there), the next book would have the other viewpoints, and it was basically done. Three years and some later, and after a few other optimistic updates, it's not yet done. Some of Martin's fans are increasingly getting antsy and sometimes abusive about this. This has increasingly been getting to Martin, and he's responded in various ways in his personal blog, most recently February 19th. See also John Scalzi and Charlie Stross reacting to his post. Now, I'm not one of the people who is rabid about this series. I'm a little disappointed that I haven't gotten to read the next bits with the characters I really like in the series, and I didn't much care for A Feast for Crows because of how the book was split. But I have a thousand other books I want to read (literally I've read less than half the books I own) and if I don't get to see more of the series, oh well. I am, however, very interested in the fan reaction to this delay and Martin's reaction to that, because it has started reminding me of similar things in my own life. Some of the fans are just batshit insane, which is one of the things that happens to a best-selling author; I feel for Martin there but there isn't much anyone can really do about that. But among the sane people, there are a bunch who say something like "I understand why the constant nagging doesn't help, but on the other hand, when you start a big story with unresolved plots, you have an obligation to your readers to finish it." I call bullshit on that. This same effect happens in the free software world. If you write some program, you're perceived to have an obligation to support it, fix it, release new versions, and so forth. I've also had this happen in other volunteer contexts, such as Usenet. Often that obligation is based on some comments that one makes about future plans, things that will go into the next release, e-mail messages where you say that you'll look at something, and so forth. It's not entirely groundless, and it's not groundless with Martin either. However. As any software developer knows, time estimates for tasks are horribly difficult and almost always too short. This is clearly what happened to Martin, and bitching about the time estimates doesn't help at all. Some problems turn out to be so much harder than you expect that time estimates fail entirely. With creative work (including some programming) it's particularly hard to know how much work is remaining. You may know roughly how much you have left to write, but you don't know how hard each chunk will be until you start it, and sometimes until you finish it. With some projects, the only thing you can do is say "sorry, my estimates were completely off and I don't know how to estimate this" and then stop promising dates. Which Martin has already done. He was "wrong" in some sense for setting bad expectations, but estimation is insanely hard and the world usually doesn't let you get away with just refusing to estimate anything. So much for time. What about whether Martin has an obligation to write the next book at all? The equivalent question in the free software world is whether one can just walk away from a project, or away from a volunteer position, leaving a bunch of stuff undone that some people who were using the software were counting on having finished. It's a bit easier to deal with in free software, since usually just promises are at stake, whereas with Martin he's sold a commercial product and people get weird about money. There is a reasonable expectation that a series of this type will have a conclusion (although I'll point out that the SFF world is filled with unfinished series). Maybe you wouldn't have bought any of the series if you had known that it wouldn't end, so now you're out $100 for the hardcovers that you feel like you bought on false pretenses. Let's examine that. First, I have a serious problem with people who use the economic transaction as leverage in this sort of argument. This is a really piddly amount of money for each individual person, generally less than I get paid for one hour of work. Writing a new novel is way, way more than one hour of work. Martin's fans are demanding that he do work that's worth many orders of magnitude more than they're conceivably out monetarily. (And the reactions are individual reactions of anger; the level of upsetness of each individual shouldn't change based on the total size of the fan base.) Furthermore, their economic transaction was with the publisher, and they had no control and no say over how Martin got paid. From multiple different directions, they're not his employer, have no contractual control over how he spends his time, and have no legitimate economic basis for asserting any such control. They can make a decision to not buy his future work because they're disappointed, and that's it. Second, it is absolutely mandatory to give other people room to be wrong or change their mind. Human beings cannot keep every promise that they make. We fail at things that we fully intend to do, particularly around estimates, and particularly around one's dedication to decade-long major life projects. People are wrong about marriages and children, which involve far more serious consequences than a fiction series. I think it's a good reality check here to note that his fans are placing way more restrictions on what he can do with his life than would be legal for any employer. Third, when someone doesn't meet your expectations, the response should be proportional and rational. This is the one that really gets to me. Choosing not to read the next book in the series because it's been too long is entirely reasonable. Trying to make Martin feel like crap is not. I would go further: nothing that an artist could promise to their general public could warrant intentionally making them feel like crap for failing to do it. That level of emotional consequence should be reserved for things like marriage, parenting, or life-long friendship, not disappointment that you didn't get to hear the end of a story you were enjoying. I speak from personal experience here: this type of punishment by guilt is a nasty, nasty business. It burns people out faster than any other possible reaction, it makes it much less likely that Martin will continue the series at all, and it's probably poisoning his feelings about the entire world. It's burning down the bridge you're standing on. It always hurts and never helps. People already create feelings of obligation around things they've promised, implicitly or explicitly, to do, and generate plenty of their own guilt. That guilt is one of the major obstacles that one has to overcome to be productive; if you don't believe me, read any good productivity book, such as Allen's Getting Things Done, and notice how much it talks about getting past guilt. Intentionally going out of your way to contact someone you do not know personally and pile on more guilt is vicious, cruel, and tactically counterproductive. Trust me, Martin didn't fail to notice that he missed his own deadlines. I think Martin's post and the subsequent discussion is a great opportunity for all of us who create or use creative and technical works to think about how we apply the Golden Rule. There's a natural tendency to hold people tightly to promises that we'll get something that we want. There's a natural tendency for all of us to make those promises, since people are grateful for them, and then pile guilt on ourselves for not meeting them. All of the emotion wrapped up in both sides of that tension of expectation and obligation can be exhausting and poisonous. It makes relationships brittle because we don't let people renegotiate. We don't let people say they were wrong. We don't let people change their minds. And we don't let ourselves change our minds. Here's my promise: the next time someone doesn't meet an expectation I had, I will remember this discussion, give them space to be wrong, and not pile on more guilt. Like all promises, I'll try to keep it, but I might not be able to.

According to Netcraft 20 Million Chinese websites running on "QZHTTP" ( apparently serving mostly the qq.com domain ) just came out of no where, or are at least crawl-able now. What does this mean? To Me it just means more Questions, I cant seem to find any information on QZHTTP. Is it Open Source ? GPL ? Based on Apache ? Totally from scratch ? etc. etc. etc. So "Dear Lazyweb" what does it mean? Will QZHTTP overrun IIS in web server market share for 2nd place, what about even Apache in 1st ? A quick Google ( don't you like how google is a verb now ) didnt turn up much other than another blog post with just as many questions and not any answers or comments.

I wanted to record a conference call for a colleague who couldn't make it. Normally I'd cheat and run Wireshark to capture and dump an unencrypted VOIP stream, but for various reasons that wasn't an easy option and Skype was going to work better for the call. But how to record it? IRC suggested various ALSA magic options, which looked like they'd do the trick if I could only understand the fine manual. It actually turned out to be much easier than it looked. I dropped:

pcm.fileout  
	type file;
	slave  
		pcm "hw:0"
	 
	file "/home/noodles/pcmout";
	format "raw";
 

into .asoundrc, restarted Skype and told it to use the fileout device for audio out. That led to a pcmout file being created, as well as the sound going to the sound card.

sox -r 44100 -s -2 -c 2 -t raw pcmout -t wav foo.wav then converted that file into a WAV that could be played back. For some reason setting format to wav in the ALSA config resulted in an error - throwing sox at the problem was the easy answer but I suspect that step could be eliminated with some more doc reading.

Last week, I couldn't resist and bought myself an Acer Aspire One (AOA 150Ab) netbook. It has 1G RAM, 120G HDD, unfortunately needs a fan, and is the model without 3G modem. It comes with Linpus Linux pre-installed. Looks quite nice, but is obviously ultimately the wrong OS ... Besides, it's locked down quite a bit, there's not even an easy way to start a terminal :-) I still have kept it, in a dual-boot configuration, to play around or show to people. Installing Lenny went very well, and to make things more fun I'm running quite a few things from experimental: KDE 4.2, xorg 7.4 (1:7.4~5 right now) and Oo.org 3. And, to get DRI2, also the 2.6.28 kernel from the newer-than-sid repository of the kernel team (2.6.28-2~snapshot.12850, but I hear 2.6.28 has now been uploaded.) While the whole thing is fun to use and didn't make any real problems, there are a few remaining issues (yes, this is a Dear Lazyweb posting, feel free to comment. I'll try to add updates to this article as this progresses):

• Power events (power button, battery level critical) are handled by two sets of scripts. Not sure if the blame lies with acpid, acpi-support or KDE for this one. Symptom: when setting up, in KDE, that the power button should bring up the logout dialog, this results in: the power button does indeed show the logout dialog, but then immediately the system is shut down. Adding an exit 0 in /etc/acpi/powerbtn-acpi-support.sh before the final shutdown command in that file fixes this, though. Similarly, the battery critical event brings up a warning that the system will soon be forcibly suspended and then immediately suspends to RAM. (I'll have to investigate if there's already a bug about this in the bts.)
• The X server has quite a few issues. It sometimes blanks the display without any reason. Causing any of the fancy full screen effects (like present windows ) to happen sometimes fixes this, sometimes a quick suspend to RAM and wakeup cycle fixes it. Sometimes it does not and I need to reboot (and I have yet to set up a hotkey for log out without questions.) Also, the screen stays black after a switch back from a text console, and after logout. Oh, well, I guess I'll just wait a few Intel driver and perhaps kernel releases (not sure: do I already have kernel modesetting, btw?)
• KDE sometimes complains that X compositing is too slow and disables it. I immediately re-enable it, because while some of the effects do indeed demonstrate the limits of the graphics hardware, I've become used to things like present windows and, especially on the small screen, the screen magnifier.
• Also a feature of the new X server is HAL powered handling of input devices, which left me without my desired keyboard layout in X. After some hunting around at places like #447666 I found a very simple x11-input.fdi file somewhere I can't remember and installed that:

  <?xml version="1.0" encoding="UTF-8"?>
  <deviceinfo version="0.2">
    <device>
      <match key="info.capabilities" contains="input.keys">
        <merge key="input.xkb.layout" type="string">ch</merge>
        <merge key="input.xkb.variant" type="string">de</merge>
      </match>
    </device>
  </deviceinfo>
  

  I now realize that just installing hal-info from squeeze or sid might also fix the issue.
• Also related to the new input hotplugging: how do I pass options to the synaptic driver? Probably another XML file for HAL, haven't hunted for this yet. As it is, the touchpad works but tapping won't click, and there's no scrolling on the edges of the pad. Update: Mark points me to the correct HAL invocation, thanks.. Now I only need to find the right values for all the options...(at least tapping doesn't work yet when I use the same values as the Linpus installation uses.)
• The various Fn key keyboard functions situation is very inconsistent. Some of the keys just work (Num-lock, the completely useless Scroll-lock, Home, End, volume up, down; Even brings up a graphical notification, blank screen). Mute/unmute is caught by userspace but doesn't work correctly: it just displays the current volume instead of muting/unmuting audio (it also shows HalPower::slotButtonPressed: Unknown button type in .xsession-errors. Same message but no effect whatsoever for the Zz sleep button.) The deactivate touchpad key works but gets unknown key pressed/released kernel messages, as does the (off-keyboard) WiFi power switch. Switch video output only shows the unknown key pressed/released messages but doesn't do anything. Finally, some work but are also mapped to keycodes where they shouldn't be (dim screen is also mapped to ^@ , it appears, while increase screen brightness is mapped to .)
• WLAN only works with the options acer_wmi wireless=1 option, and without the LED, as described on the Debian Acer Aspire One wiki page. This is with the ath5k driver, haven't tried the MadWifi one yet.
• Powertop claims that the camera is always on, unloading all related modules () seems to solve this (at least, powertop doesn't complain anymore, and power is down by 0.5W.) Powertop also claims that USB autosuspend is off, but it's just set to 2 instead of 1 which if I read this correctly is the timeout to use for USB devices.
• KDE4 doesn't have a network manager applet frontend in Debian. I guess this is an upstream problem. (Although I note that the OpenSUSE people already have an applet ;-) Update: Sune tells me it's in NEW already, thanks.
• While network-manager (lenny version) does work properly and switches between wired and wireless as needed, it strangely keeps sending out DHCP requests on eth0 even though no cable is attached (and mii-tool correctly reports no link.)

Ok, this has become rather a long list. But at least, as you can see, it's mostly minor issues, and hopefully a few where it's just missing configuration. One other issue is battery life: I see that there should be a large battery available for this thing. If it doesn't cost me as much as the whole netbook again, I'll seriously have to think about this... The 3-cell battery does last about 2.5h (and has, right now, uncovered a little bug where the battery monitoring applet tells me No AC adaptor plugged in, battery capacity: 50%, charging . Whee! I have a perpetuum mobile! I'm gonna be RICH!)

I was very pleased to wake up this morning to the news that National has delayed the introduction of S92A via an order-in-council. It s a nice short-term victory, but I ll save the champagne until the law is fundamentally rewritten. The most pleasing aspect of the decision is simply that it was made at all. Within two weeks, a small band of protesters were able to harness the power of the Internet to direct international attention and place enough pressure on a Government, whose Prime Minister admitted to not having read the bill prior, that he then took the time to understand the issues and personally announce the delay in implementation of the law. We owe much thanks to the Creative Freedom Foundation for all the effort they put into co-ordinating the protest and ensuring that a single coherent message was presented. Just a little bit of my cynicism and belief that politicians never listen to public opinion outside of election campaigns was chipped away today. The reason I m not breaking out the champagne yet is that we ve only achieved a temporary reprieve in the commencement of the law. While those present at the press conference seem somewhat confident that John Key didn t like what he found in the law and would have repealed it if given the chance, all that has actually been done is delay it in the hopes of an agreement between the TCF and the rights holders (aka big media companies) on how to implement the still fundamentally broken law. The Government has given until late March for that to occur. To put this into a more global context. My happiness as I took the bus to work after reading about the decision to delay the law was short lived as the front page of the local paper declared that Eircom (Ireland s equivalent of Telecom) has voluntarily agreed to block sites such as The Pirate Bay upon request by the media companies (this comes a week after they also announced an agreement to, again voluntarily , implement a 3-strikes S92A style policy). Now, with the biggest ISP in their pocket (so to speak), the media companies have sent threatening letters to the remaining ISPs in the country demanding they implement the same procedure. To me, this illustrates one of the fundamental problems with S92. The concept that an ISP is liable for the conduct of its users, or for policing where on the Internet users should and shouldn t be able to connect to does not belong in our laws. Most ISPs already have provision to disconnect customers for illegal activity in their terms and conditions. If an end-user is doing something illegal, that is an issue between the rights holder and the end-user to take up in the courts just like every other sector of society must do when wronged, at which point the existing ISP terms and conditions can be invoked and access terminated. The big media companies, having decided that it is too expensive/hard/inconvenient to follow standard legal procedures to resolve their grievances are launching multi-pronged attacks to shift the playing field in their favour. In countries like New Zealand, where our politicians yearn for a Free Trade Agreement with America, they use their lobbyists to ensure that S92 style laws are part of the conditions. In other jurisdictions, like Ireland, they use strong-arm, divide and conquer style bully tactics outside of the political and legal process. I don t support copyright infringement. I rely on copyright to protect much of the work I place on the Internet, I want strong laws that protect me when my rights have been infringed. I don t believe that such laws should come at the expense of due process, our legal tradition and the basic principle of fairness! I don t believe that copyright infringement is such a heinous crime that it demands punishments stronger than those we deliver to paedophiles, stalkers or any other class of criminal who uses the Internet to enable their crimes. To me, today s (yesterday s - depending on your timezone) decision is only the first step in clawing New Zealand back from the dangerous path that the big media companies have been leading our law makers down. From here we need to press on and demonstrate to the Government over the next month that even if the TCF and rights holders are able to come up with some sort of workable code of practice, the law is still fundamentally flawed. It is based on premise that we are guilty by accusation. Even if guilt were to be proved by a competent legal body (eg. court or copyright tribunal) we don t need laws placing further liabilites onto ISPs (and remember the definition of ISP under this amendment act includes businesses who provide Internet access to staff, libraries, schools and hospitals) when their existing terms and conditions already prohibit illegal activity. Finally, and most importantly of all, we need to remember that laws exist to serve all sectors of society. Yes, copyright infringement is against the law and rights holders are reasonable in expecting the law to protect their content and allow them to make a fair profit. On the other side of the fence, average New Zealanders are not being unreasonable in their desire to have media available electronically, on demand and non-inhibited by DRM following a legal purchase. The failure of the media businesses to adequately cater to this change in market demand and usage of technology is obviously a contributing factor to the widespread copyright problems that they are facing today. Obviously, I m not condoning copyright infringement simply because the media companies are failing to address demand. Even stupid laws must be obeyed (and the concept of copyright is far from stupid). What I want to see is the Government acknowledging that the problem is not solely with consumers infringing copyright for malicious purposes, and therefore that the solutions do not lie solely in increasing the enforcement and punishments available. Copyright has always been a balancing act between the rights of content producers and consumers. S92 and the act it is contained within are taking us far too far down the road of catering to big business and their outdated business models with far too little concern for the rights of the individual consumer. Despite the many submissions made on this act last year when it was first passing through parliament, there was no comprehensive debate on what copyright means and how it should balance the rights of content producers and consumers in our digital century where copying is a zero-cost, zero-thought activity. Without such a debate we re doomed to continue wasting time arguing over the symptoms of the problem, like S92. So, I m saving my champagne for the day when we as a country address these issues and come up with a fair and workable interpretation of what copyright means today.

While working on the Debian packages of navit I stumbled upon gypsy, as the libgypsy is used by navit to listen to notifications about location changes via D-Bus. As maintainer of the gpsd package I started to wonder what the opinion of the gpsd developers about gypsy is - especially after reading that "Gypsy was designed to fix the numerous design flaws found in GPSD". Well, here is their answer, which I support fully. I'm blogging about it as I think it is important to know about this details if you plan to do something useful with a gps device, for example on mobile phones like the OpenMoko Freerunner. gpsd works very well on embedded devices, and if there's a feature missing just contact the developers. They're very responsive and like to implement useful features, if they can get a spec to do so (and even better, the hardware to test it). So I'm really wondering if it wouldn't make sense to replace the minimal NMEA/UBX implementation in the FSO Framework Daemon by gpsd, even if that means to compile code instead of writing Python code, which is much faster for rapid prototyping, of course.

Last week, Scott James Remnant posted a series of Git Sucks on his blog, starting with this one here, with follow up entries here and here. His problem? To quote Scott, I want to put a branch I have somewhere so somebody else can get it. That s the whole point of distributed revision-control, collaboration. He thought this was a mind-numbingly trivial operation, and was frustrated when it wasn t a one-line command in git. Part of the problem here is that for most git workflows, most people don t actually use git push . That s why it s not covered in the git tutorial (this was a point of frustration for Scott). In fact, in most large projects, the number of people need to use the scm push command is a very small percentage of the developer population, just as very few developers have commit privileges and are allowed to use the svn commit command in a project using Subversion. When you have a centralized repository, only the privileged few will given commit privileges, for obvious security and quality control reasons. Ah, but in a distributed SCM world, things are more democratic anyone can have their own repository, and so everyone can type the commands git commit or bzr commit . While this is true, the number of people who need to be able to publish their own branch is small. After all, the overhead in setting up your own server just so people can pull changes from you is quite large; and if you are just getting started, and only need to submit one or two patches, or even a large series of patches, e-mail is a far more convenient route. This is especially true in the early days of git s development, before web sites such as git.or.cz, github, and gitorious made it much easier for people to publish their own git repository. Even for a large series of changes, tools such as git format-patch and git send-email are very convenient for sending a patch series, and on the receiving side, the maintainer can use git am to apply a patch series sent via e-mail. It turns out that from a maintainer s point of view, reviewing patches via e-mail is often much more convenient. Especially for developers who are just starting out with submitting patches to a project, it s rare that a patch is of sufficiently high quality that it can be applied directly into the repository without needing fixups of one kind or another. The patch might not have the right coding style compared to the surrounding code, or it might be fundamentally buggy because the patch submitter didn t understand the code completely. Indeed, more often than not, when someone submits a patch to me, it is more useful for indicating the location of the bug more than anything else, and I often have to completely rewrite the patch before it enters into the e2fsprogs mainline repository. Given that, publishing a patch that will require modification in a public repository where it is ready to be pulled just doesn t make sense for many entry-level patch submitters. E-mail is in fact less work, and more appropriate for review purposes. It is only when a mid-level to senior developer is trusted to create high quality patches that do not need review that publishing their branch in a pull-ready form really makes sense. And that is fairly rare, and why it is not covered in most entry-level git documentation and tutorials. Unfortunately, many people expect to see the command scm push in a distributed SCM, and since git pull is a commonly used command for beginning git users, they expect that they should use git push as well not realizing that in a distributed SCM, push and pull are not symmetric operations. Therefore, while most git users won t need to use git push , git tutorials and other web pages which are attempting to introduce git to new users probably do need to do a better job explaining why most beginning participants in a project probably don t need their own publically accessible repository that other people can pull from, and which they can push changes for publication. There is one exception to this, of course, and this is a developer who wants to get started using git for a new project which he or she is starting and is the author/maintainer, or someone who is interested in converting their project to git. And this is where bzr has an advantage over git, in that bzr is primarily funded by Canonical, which has a strong interest in pushing an on-line web service, Launchpad. This makes it easier for bzr to have relatively simple recipes for sharing a bzr repository, since the user doesn t need to have access to a server with a public IP address, or need to set up a web or bzr server; they can simply take advantage of Launchpad. Of course, there are web sites which make it easy for people to publish their git repositories; earlier, I had mentioned git.or.cz, github, and gitorious. Currently, the git documentation and tutorials don t mention them since they aren t formally affiliated with the git project (although they are used by many git users and developers and the maintainers of these sites have contributed a large amount of code and documentation to git). This should change, I think. Scott s frustrations which kicked off his git sucks complaints would have been solved if the Git tutorial recommended that the easist ways for someone to publicly publish their repository is via one of these public web sites (although people who want to set up their own server certainly free to do so). Most of these public repositories probably won t have much reason to exist, but they don t do much harm, and who knows? While most of the repositories published at github and gitoriuous will be like the hundreds of thousands of abandoned projects on Sourceforge, one or two of the new projects which someone starts experimenting on at github or gitorious could turn out to be the next Ruby on Rails or Python or Linux. And hopefully, they will allow more developers to be able to experiment with publishing commits on their own repositories, and lessen the frustrations of people like Scott who thought they needed their own repositories; whether or not a public repository is the best way for them to do what they need to do, at least this way they won t get as frustrated about git. Related posts (automatically generated):

1. Git and hg John Goerzen recently posted about Git, Mercurial and Bzr that...
2. Batches of patched batches of patches I found the following from the Risks Digest, authored by...