As Debian has been released my "unstable" box recently upgraded to glibc 2.9.
This caused DNS resolving to mysteriously fail in some applications.

Turns out that only IPv6 enabled applications suffer.

Apparently libc now fires both an IPv4 and IPv6 DNS resolving request in parallel. It looks like some DNS servers don't handle that correctly and answer an error on the IPv6 request before the IPv4 request even has time to resolve further in the internet.

In my case it was my local NSLU2 running Debian lenny causing the trouble, more specific the maradns local DNS server and DNS proxy running on it.

I manually upgraded maradns to the latest version (> 1.3.10) and things are "back" to normal.

Another solution is to disable IPv6 systemwide but I prefer not to do that as I use IPv6 occationally for testing.

I fear that this will cause more trouble for alot of people with routers doing DNS proxying.

I have uploaded dosfstools version 3.0.2 that contains another few fixes. Source tarballs can be downloaded as usual from its homepage. The aim for 3.0 was to unify all the patches out there that have been accumulated over the years. As this is mostly completed now, I will soon start doing real work which will lead to dosfstools 3.1 eventually.

I have no idea how such a great open-source game as Teeworlds has been able to exist without me hearing about it until recently. Teeworlds is a fast-paced realtime multiplayer shooter. You control a small "Tee" which can hold various weapons (hammer, gun, shotgun, laser-rifle, rocket launcher, ninja-sword) while running and jumping around frantically on the map, trying to frag as many other Tees as you can before you're killed by some other guy. Easy, eh? There's are many game servers to choose from, as well as various game modes (death match, team death match, capfure the flag and some unofficial "mods"). You can join servers on the Internet, or create your own server, be it a public one or a LAN server. Installation Usually I would suggest apt-get install teeworlds, but for now the packages in unstable are an older 0.4.x version, whereas upstream released a much-improved 0.5.1 version. I have already filed a bug and I'm optimistic there'll be a new version in unstable soon. In the mean-time however, you can manually build the game from source via:

 $ apt-get install zlib-dev libsdl1.2-dev
   (maybe also libgl, libglu, and python, if not already installed)
 $ wget 'http://teeworlds.com/trac/bam/browser/releases/bam-0.2.0.zip?format=raw' -O bam-0.2.0.zip
 $ wget http://teeworlds.com/files/teeworlds-0.5.1-src.zip
 $ unzip bam-0.2.0.zip
 $ unzip teeworlds-0.5.1-src.zip
 $ cd bam-0.2.0
 $ ./make_unix.sh
 $ cd ../teeworlds-0.5.1-src
 $ ../bam-0.2.0/src/bam release

Running the game

 $ ./teeworlds

You'll obviously need a working OpenGL/DRI setup (check if "glxinfo grep direct" says "Yes"), otherwise the game will be way too slow. In case you experience graphics glitches and distortions, first exit the game, then:

 $ vi ~/.teeworlds/settings.cfg

Change the "gfx_noclip 0" option there to "gfx_noclip 1" and restart the game. Firewalls If you use a local firewall as I do, you need to open at least ports 8300-8303 (UDP), even better 8300-8310 for more choice in game servers:

 $ iptables -A OUTPUT -m state --state NEW -p udp --dport 8300:8310 -j ACCEPT

Further resources

• Official website
• Forums (yuck)
• For developers: trac, bugs, wiki, mailing list
• Code repository: svn co svn://svn.teeworlds.com/teeworlds/trunk
• Unofficial "Teewiki"
• Lots more useful links

Have fun!

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/

natura.oskuro.net, the home server which still serves this blog, has been suffering hardware problems for some weeks. Apparently the hard drive is failing intermittently, so every now the kernel starts spewing out noisy errors about its main disk dying. If I notice this quickly, it can be rebooted and that normally fixes it for a few more days. But if I don't, it'll end up giving nasty bus errors which will make remote logins a challenge. Most processes still work, but the filesystem appears to be gone. It's easy to know what's going on if you visit the blog's url and get some 404, and in that case I can only phone my father and tell him to press the reset button (I've tried sysrqd, but I need to open the port in the router and haven't had chance to do that yet). So it was time to do something about it, and the other day I installed a dirty 40GB drive on the second IDE controller, in case I could find the time to do somethng about it. Being with an endless pharyngitis that doesn't seem to get cured entirely, I've had some time today to look at it. This evening, I was about to transfer all the system to the new disk (it's half the size as the broken one, and probably slower, but it hopefully has no bad sectors), but I decided to upgrade the system first. natura was first installed in late 1997 or at the beginning of 1998, using the Debian bo install media on a Pentium 150MHz, and has gone through seven dist-upgrades which, as far as I can remember, have always worked out without major problems. The upgrade to lenny hasn't been an exception. The server has gradually lost many of the services it once hosted, so there aren't too many services to take care of anymore. All the mail services I setup for my father ended up being deprecated as they started to get used to Hotmail, GMail and so on, and the frequent hardware crashes made me switch them to the Linksys based DHCP server. In the end, the problems I saw after the upgrade were very similar to what I faced when I upgraded to etch:

• apache2 restored the 000-default symlink in the sites-enabled dir, which resulted in my website showing the classic It works message for a while.
• Apache's suexec support had moved to its own package, and was very well documented in the NEWS file, but I somehow failed to notice for some time and kept wondering what was going on.
• The Python upgrade again affected my Pyblosxom install. Fortunately it was a minor problem; I just had to add a coding=utf-8 line to the beginning of my config.py to get it working.
• dhcp3-server apparently restored its init scripts and got started again. This time, it got removed.

Such an ancient install will clearly have old, obsolete packages. I installed apt-show-versions to find out what didn't match my package sources. I found I had every single version of cpp, gcc and g++ from 2.95 to 4.3, and a myriad of obsolete libs. But there were also real gems:

defrag 0.73pjm1-7 installed: No available version in archive
figlet 2.2.1-3 installed: No available version in archive
ipmasqadm 0.4.2-2 installed: No available version in archive
isapnptools 1.26-5 installed: No available version in archive
ms-sys 2.1.0-1 installed: No available version in archive
queso 0.980922b-3 installed: No available version in archive
update 2.11-4 installed: No available version in archive

Spaniards will remember queso because it was written by Jordi Murg and became a classic tool to find out what OS was running on a remote host. update was apparently needed to flush your filesystems prior to Linux 2.2.8, and defrag is obvious, although leaves me wondering why it was needed at the time. With the upgrade done successfully, next step is trying to get the system transfered to the spare hard drive. For this, I first partitioned it creating a primary partition using up more or less half of the available space, and setup a LVM volume, leaving some free PE's in the volume group just in case I want to do snapshots in the future, and formatted it using ext3. I then transfered the system to the new disk and now face the boot challenge. I haven't created a boot partition and that should be a double problem: the BIOS is buggy and will only boot from the first 1024 cylinders, and my root is on LVM and GRUB legacy might not like it (but I'm not sure). However, I've become a big fan of GRUB2, and know I will be able to boot no matter what my BIOS thinks of my disks and regardless the complex root partition setup I throw at it. The plan is to install GRUB onto the new drive's MBR, and set it up using the ata module, which should allow to ignore what the BIOS says, and read beyond cylinder 1024 or even boot from CD-ROM. However, this isn't a setup I haven't tried before, and a single failure will result in me taking a train to fix it on-site. So, GRUB experts out there, any suggestions? Of course, for now I guess I can install GRUB in the current drive's MBR and make it boot the old kernel using the new system as root, but that's dirty and would just postpone the problem.

This is my first entry from my Acer Aspire1 since installing the latest Emdebian Grip and the 2.6.28 kernel that now provides free wireless support. A few tweaks still needed to get a few packages sorted out so I've got a Debian source on this box too. Still, with my usual packages (iceweasel, sylpheed, grisbi, geany), all my email cached data, liferea data, a few documents and a few Debian packages and I'm still at only 753Mb used.

Using wicd from squeeze, I've got wireless working - there's no led lit but I'm sure that's fixable.

Copying a few files around from ~/.gnome2/ on my other laptop and suddenly I have drivel, sylpheed and liferea all pre-configured.

I'll be blitzing this install again numerous times in the next few days but by keeping the ~/.gnome2/ files on a USB stick, it will be simple to restore the system, especially as I'm using IMAP email.

(If you're wondering, the drivel upload is delayed by the churn in Debian Sid - waiting for the libmtp7 8 transition to make rhythmbox available in a clean chroot.)

I've not had that many problems with network-manager, until now. The new version in unstable is just completely broken on my machine. Sadly, I can't report why it failed as I inadvertently closed the terminal with the relevant output.

Suffice to say, nm repeatedly got the wrong IP address, an invalid route and failed to set a usable nameserver. I've had those problems before with wireless but when this started happening with a wired connection (which had always previously worked), it was time to move on.

I've noticed people using wicd instead and decided I didn't have time to debug nm, I have a worksession starting in Cambridge on Sunday and a shed load of work to do before that, all of which requires a stable network connection.

Installing wicd replaced network-manager which was nice, (nm has always had problems working with any other network config so this allowed me to skip the removal of nm myself). wicd initially had a few issues - which I managed to pin down to the remnants of the broken nm config and steps that I'd taken to try to fix it.

Turns out that I may have some unresolved issues with my router - even with wicd I had problems getting a route over wireless. However, wicd allows suitable configuration that both works and is easy to keep discrete from other configs. Nice work. I have to set a static IP over wireless in order to set a valid route (and netmask). Looks like the DHCP implementation on the router is borked.

I'm sticking with wicd though - the interface is better for what I need, the icon has a useful traffic indication as well as signal strength and it's worth pursuing to see if the previous intermittent nm errors affect wicd.

As some people may have noticed (especially people in #debian-xfce and other Xfce fans), Xfce 4.6.0 has just been released. Packages are already prepared, since the packaging is done in parallel with the release cycle. I don't really plan to upload anything to my repository, now that Lenny is released and we can break unstable. That being said, I won't upload to unstable directly, as we have some packages which need to go through NEW. NEW is quite huge this days, so those packages won't leave it soon, and for consistency I'd prefer not breaking unstable completely, with a mix of 4.4 and 4.6. So first uploads targeted at experimental, and then when all packages are out of NEW, unstable. In the meantime, I already uploaded a new desktop-base version with config files useful for the new configuration system in 4.6. One of theses files will conflict with one in xfce4-session. Yeah, I shipped that file in xfce4-session when it was private, now it's time to go official. So yes, this morning you may have a conflict with desktop-base. It's not a problem in desktop-base (you don't need to report a bug). Just an inconsistency with an un-official, un-supported repository package, and an official package from main. Just force the overwrite or something like that. Or hold the upgrade until xfce4-session is available. As I already said, no special dependencies informations will be used in packages uploaded to Debian, so it may break your system at upgrade. The best solution would be to clean the packages from my repository before trying to upgrade to the ones in Debian (but it should not be too broken, in the end). For the record, besides the desktop-base / xfce4-session conflict, I didn't have any problem upgrading to the packages I should upload to experimental. More on this when things have settle down and we start uploading to unstable.

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.

An interesting extract from the latest IA32 SDM (18.20.5)

The TSC, IA32_MPERF, and IA32_FIXED_CTR2 operate at the same, maximum-resolved frequency of the platform, which is equal to the product of scalable bus frequency and maximum resolved bus ratio.

For processors based on Intel Core microarchitecture, the scalable bus frequency is encoded in the bit field MSR_FSB_FREQ[2:0] at (0CDH), see Appendix B, "Model-Specific Registers (MSRs)". The maximum resolved bus ratio can be read from the following bit field:

• If XE operation is disabled, the maximum resolved bus ratio can be read in MSR_PLATFORM_ID[12:8]. It corresponds to the maximum qualified frequency.
• IF XE operation is enabled, the maximum resolved bus ratio is given in MSR_PERF_STAT[44:40], it corresponds to the maximum XE operation frequency configured by BIOS.

In summary, TSC increment = (scalable bus frequency) * (maximum resolved bus ratio). This implies the TSC is incrementing based on some external bus source (any hardware engineers explain what happened for Core here?), and is a departure from simply assuming that the TSC increments once for each CPU cycle. The interesting bit is that if XE operation is disabled, the bus ratio is assumed to be the maximum qualified frequency. This seems to mean that if you overclock your CPU and your processor is running at higher than the qualified frequency, attempts to measure the CPU speed by counting TSC ticks over a given time may yeild the wrong results (well, will yield the rated result; i.e. the speed of the processor you bought out of the box). While interesting, this divergence is probably has little practical implications because using the TSC for benchmarking is already fraught with danger. You have to be super careful to make sure the compiler and processor don't reschedule things around you and handle other architectural nuances. If you need this level of information, you're much better using the right tools to get it (my favourite is perfmon2).

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

So, DebConf 10 will be held in New York City! Congratulations to the NYC bid team, now DC10 local team, which managed to provide a sound proposal for 2010. As time allows it, I ll be happy to help out and be there! I d also like to congratulate Boston s bid, who provided an outstanding proposal, and also the rest of Quito s team, whose bid I led: I think we provided an extraordinary bid to host an important event as DebConf in an amazing city as Quito, and as long as we can keep guaranteeing extraordinary quality, we ll be glad to present the bid for future DebConfs. Finally, the decision was taken after a long meeting, where we as a Project learnt useful things for future decision meetings. So, DC11 bidders, keep up the good work and enjoy the ride!

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.

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.