Sign the "Thank you, Poland!" letter.

Apparently, the Americans on Slashdot cannot understand why European policy is largely made by the agriculture departments. It's because the EU is really an organisation to subsidise French farmers - but I would agree that it doesn't really made much sense.

Which OS are You?

Dead right; although to be so easily seen through I am afraid is pitiful. Now, the real question — does the quiz really use your answers, or does it cheat and look at the User-Agent: string?

Another minor update. This improves the behaviour of the HTTP code; it should help with some unusual servers and proxies. As usual see the download page.

zsync-0.1.4 is out, to fix some compilation problems with gcc 3.4. (Note to self: never use fancy compiler directives without fully understanding them!)

So I moved ntpdate to the multiuser part of startup, and hacked /etc/init.d/hwclockfirst.sh so it didn't query the timer to work out if setting the time had freakily failed (never happens on any machine I know!) (see previous post). Startup time is now 10s (graph). Zippy. (But of course, this is without starting XFree86.)

Someone pointed out this. Looks like the kernel will in future contain this hack to filter out UDP packets with broken checksum at select time for blocking sockets. So the various select-with-blocking-socket UDP vulnerabilities have returned to minor niggles now — although the software in question is still broken, of course, but the status quo ante is restored, so it will once again be hard to trigger.

So it is not of much interest now, but in case you want it, here is my patch to detect select(2)s on blocking sockets.

I came across the cool bootchart program today. This creates an extremely nice Gannt-chart-like graph of the processes running during bootup, CPU and disk utilisation and so on. So I set it up on my machine, to see how my parallel patch for file-rc fared.

Here's the chart. It looks like my parallel file-rc is doing quite well, with 21s bootup times and excellent CPU and disk utilisation in the main startup period. I should probably ditch ntpdate or background it, and look into why hwclock is so slow - without these 15s or better is easily within reach. Nor is my machine that lightly loaded, with squid, cups and apache in the startup list.

I finally got around to investigating the problems with proxies that someone reported. I was planning to add support for HTTP proxies anyway, so it seemed sensible to do that at the same time. I have only tried with Squid so far, but it seems to work now. There were some problems with the HTTP header parsing — I have just put out v0.1.3 which fixes these. See the download page as usual.

I was installing cups yesterday, as I found a rare occasion where I actually needed to use the printer. It immediately fell foul of my kernel patch to detected select(2) on blocking sockets. For the background to this, see this linux-kernel thread, where Linux's behaviour is discussed in depth: to cut a long story short, Linux doesn't guarantee that a read(2) or recvmsg(2) on a socket won't block even if select says there is data on that socket. This is because UDP, for instance, is a datagram protocol, and is allowed to discard packets at any time, even after they have been "seen" by a select(2).

So I filed Debian bug 284501 yesterday. I have already been responsible for the fixes for this issue to inetd and syslog. The list of applications bitten by this behaviour change just gets longer. I should put my kernel patch up here soon — it's an even more gross hack than my /tmp race detector, but it does the job well enough. But perhaps I should modify it to only report UDP sockets; while TCP sockets are theoretically vulnerable, in practice it's UDP which is easily DoSed using hping2.

Don't get me wrong: I, for one, welcome our new insect overlords... erm, that is, I like the new behaviour. If a program wants not to block on a socket, it should make it non-blocking. But surely introducing this change, which breaks so many applications, when the benefits are essentially a small micro-optimisation for VoIP and realmedia users — surely we are insane to make this tradeoff? How about fixing the applications first, next time? Surely the people who needed the speedup should have been responsible for doing the background work, so other users were not negatively affected by it?

Ever wished that Linux would boot faster? Ever been frustrated that Linux, so good at multitasking, should be forced to start up all the system daemons one after another?

filerc-parallel.diff — a patch to Debian's file-rc package, which makes the system rc script start several daemons in parallel. It parallelises the startup of any daemons which are at the same "level" in the runlevel.conf file (so utilising the existing knowledge about startup order as far as possible — although by hand-tuning the levels you can get further speedups). I have been using this on my home computer for 6 months, and it seems good enough. No warranty, though!

I have updated the Empirical Results section of the technical paper. It now includes results for the greatly improved gzip file support in zsync 0.1.1+. These figures dramatically alter the earlier results of comparison with rsync: as I suspected, the --rsync option is comprehensively beaten by the look-inside approach now it is has been properly tuned.

Nothing new in this release. I have merged a few portability improvements, and fixed a problem with the hash functions on Solaris/sparc (the functions were compiling for little-endian and giving wrong answers). I would be interested in positive reports from Solaris users now.

So, ebay offer limited insurance for unhappy buyers and duped sellers now? How do the economics of this work? The social success of Ebay has always relied on the principle that the number of honest users will outweigh the fraudsters, so users can use the site without having much recourse if the goods fail to show up (since it would be so hard to trace a dishonest seller). However, the user of Ebay was still necessarily running a risk — even if it pays off on average, the uncertainty itself is undesirable. It's a classic case for insurance, you could say — pooling the risk among all users would remove the uncertainty and crystallise the risk as a fixed cost.

So have Ebay decided the risks are really that small that they can pool the risk themselves, with just the listing and Paypal charges to cover the costs? Listing fee is, what, 10% of the initial list or reserve price, and Paypal is only 5% or something like that, but this has to provide for their normal business costs and profit. So it's a small percentage. They have strictly capped their liability per claim and the number of claims per user too. Are they going to be tight about paying out; do they think few people will claim, or few will meet the standard of proof; or is it a bet on society's predominant honest? Clearly most Ebay users at the moment rely on that general honesty; but the old moral hazard problem could bite Ebay, not to mention people gaming the system.