It seems I have been wrong about the origins of the Seville Orange joke
Rather than Algernon Sidney It would appear to have been quipped by an 18th century Anglo-Irish actor named James Quin as recounted in "Lives of the Players" by John Galt (not that John Galt but this one) in 1831.
Quin once, in the character of Cato, received a blow in his face by an orange thrown from the upper gallery; such a circumstance would have disconcerted many an actor possessed of less presence of mind, but instead of being disturbed, he wiped his face, and taking it up, observed, "It was not a Seville orange."A proto-version of the joke does date back to Sidney's time. It was made by none less than William Shakespeare in "Much Ado About Nothing" Act II, Scene 1:
DON PEDRO: Why, how now, count! wherefore are you sad?
CLAUDIO: Not sad, my lord.
DON PEDRO: How then? Sick?
CLAUDIO: Neither, my lord.
BEATRICE: The count is neither sad, nor sick, nor merry, nor well; but civil count, civil as an orange, and something of that jealous complexion.Note Don Pedro is from Aragon which is close enough to Seville for Elizabethan comedy purposes. But while 300+ years is impressive, this joke from Sumeria c. 19th-16th centuries BC is older by far:
Something which has never occurred since time immemorial: a young woman did not fart in her husband's lap.See The world's ten oldest jokes
Ben Armstrong opened an ITP for the ATL1E NIC driver, which is found on some Asus EeePC laptops.
So, as suggested by Maximilian Attems, I provided a clean patch for this driver, made from a cherry-pick from the linux-netdev 2.6.27 tree. It has been commited into the 2.6.26-1 Debian kernel, which will be furnished with Lenny.
What's fun, is that in the mean time, I got a new computer at work. Wait, it's not fun yet. Because what I did not know is that it's made of an Asus P5Q motherboard which runs a NIC needing the ATL1E driver (and now you see it's fun).
So I've just upgraded to 2.6.26-1-amd64 and I'm glad that my own work is useful to me (and will be probably be to others as well). 
I am following closely this new DNS mess. In fact, there s nothing really new in that. DNS has been attacked lots of times over the years as a result of not being designed with security in mind from the ground up -, just this new one is a combination of known attacks against known security flaws. The quick fix is not a real fix, and just incorporate old ideas into the most used DNS software, strengthening it to face the attack. The details leaked, and there s already at least one public exploit (and who knows how many in the wild).
The new buzzword is DNSSEC.
I don t like DNSSEC. I never did. The first time I heard of it, around year 2001, it was a centralization of a decentralized database: A proposed company (called Network Solutions) would serve as a central authority, signing every root DNS entry. It was a joke! Come on! DNS is suppose to be decentralized! Having a central company anywhere is just a huge step back in decentralization (not to mention a huge step back in security).
Time passed, and the DNSSEC specs evolved to a more decentralized way of thinking. The state it is now, and the implementations we saw so far are not good. No! I am not talking about security I am talking about the KISS principle: DNSSEC turns something really simple to deploy into a full-time job, with frequent key roll-overs and re-signing everytime you change the zone a huge mess! Yes, there are automated tools, but, come on! you still have to wait for TTL to expire before publishing this part or that part of the cryptographic machinery And, if we are talking about real security, are we going to build some automated tool fire-and-forget -style and not follow it? If we are not looking at it as it goes, and it fails, we could end up with a completely wrong set-up or (even worse) a non-validating zone.
And I haven t yet mentioned the increase in payload I am not completely convinced that this alone would not lead to DoS attacks just by compromising the responsiveness of the servers (and DoS attacks are already available for quite some time maybe the DNSSEC-medicine is worse than the disease ). The root ( . ) servers are not even DNSSEC-aware, and there s a whole class of other stuff to work-around the fact that they may not be DNSSEC-aware for quite some time yet.
There has to be a simpler way!
I can imagine at least three ways to fix the problem until we can fix DNS in a KISS way And they re all KISS also:
I made a minor bugfix + minor feature release of Smux together with packages for Debian, Ubuntu and Windows. Big thanks for all the feedback I received from the users!
… this is “Do no
evil”—urchin.js isn’t.
For luck, urchin.js and friends can be easily blocked using e.g.
Firefox plugins like AdBlocker or NoScript, or with filtering proxies like Privoxy. And a line
like
address=/google-analytics.com/0.0.0.0in the dnsmasq.conf of your home router works like a charm, too.
SCNR, via Symlink
This is a pretty technical note, which I’m posting here for review and hopefully to help other people. The reinstall I mentioned last week was a MacOS X 10.5 server, so this time I installed Koha more simply and took more notes. I don’t want to put this in the distribution as INSTALL.osx, for reasons mentioned below. Also, I’d be very happy if people replaced all osx servers with debian ones, or at least some sort of tidy GNU/Linux.
The sysadmin installed XCode and fink for me and I ran
fink install apache2 apache2-dev mysql mysql15-devwithout any great event. I also re-used an old, imperfect, local finkinfo/idzebra.info to
fink install idzebra idzebra-shlibsNext, I used the extremely horrible command
fink list $(sed -n -e “/PREREQ_PM =/,/ / ;s/^[ ']*//;s/::/-/g;s/’.*\$/-pm588/;/-.*-pm588/p; ” Makefile.PL tr A-Z a-z)inside an unpacked koha-3.00.00.094 folder to find out which modules fink had packaged already. Something similar can be done for debian and ubuntu, using apt-search or dpkg instead of fink and a libperl- prefix instead of a -pm588 suffix. (I think all systems should do something like that. Then we could merge the INSTALL.*s into the main INSTALL because they lag behind.) Three of those, I copied to /sw/fink/10.5/local/main/finkinfo and edited slightly (usually to increase the version: dbd-mysql-pm, html-template-pm, xml-libxml-common-pm, xml-libxml-pm.info and xml-simple-pm.info… also in my fink-10.5 folder) and then ran
fink install dbd-mysql-pm588 text-iconv-pm588 xml-simple-pm588 data-dumper-pm588 digest-md5-pm588 file-temp-pm588 getopt-long-pm588 html-scrubber-pm588 list-util-pm588 list-moreutils-pm588 mime-base64-pm588 net-ldap-pm588 test-harness-pm588 text-wrap-pm588 time-hires-pm588 unicode-normalize-pm588 xml-dumper-pm588 xml-libxslt-pm588 xml-rss-pm588 yaml-syck-pm588to install those modules. For the remaining modules from CPAN, I set PERL5LIB to my new Koha folder (export PERL5LIB=/Library/WebServer/Koha/lib:/Library/WebServer/Koha/System/Library/Perl/5.8.8/:/Library/WebServer/Koha/lib/perl5/site_perl/:$PERL5LIB) and ran perl -MCPAN -e shell, telling the configuration screens to use PREFIX=/Library/WebServer/Koha (so install into the Koha folder instead of splattering across /System/Library). Then the command
install Bundle::KohaSupportjust worked, thanks to excellent work by Mike Mylonas and others. Finally, all that was left was to run the normal installation in the koha-3.00.00.094 folder, picking the “single” configuration and ignoring “make test” failure (because it’s a work in progress and this is RC1), edit the /Library/WebServer/Koha/etc/zebra/*cfg to point at /sw instead of /usr, symlink koha-httpd.conf into /sw/etc/apache2/sites-available and run the a2ensite commands, copy the service plist files into /Library/LaunchDaemons and load them into launchctl, browse koha and start testing it. Simple(!) It only took me a full day of work to figure that out and do the reinstall… compared to under 2 hours from scratch on debian at the moment. Maybe it’s faster if you know the OS better and/or aren’t trying so hard not to splatter stuff across the base system. Did I do anything wrong above?
The Grade-II-listed Grand Pier Weston-super-Mare has burned down. It was right in the centre of the next bay south from me, facing down the main street between the town centre and seafront, visible all the way around Weston Bay. There’s been a half-mile exclusion zone in the middle of town, but I’ve not been travelling that way today. I go past the pier four or more times a week. It will be very strange for it to be missing. Pictures by a nearby resident really capture the scale of the shock.
The pier is literally an icon, used for the WsM Forum that I help to run for the town. At least those landside towers are still standing. More reaction on WsM Forum.
So hot off the back of my successful
upgrade from Sarge to Etch, I thought I'd try the new "Etch and a Half"
2.6.24 kernel on daedalus
Let's just say that it's times like these that I'm glad I got the
serial-over-LAN thing working, and have remote power.
I spent many hours today rebooting, trying to get to the bottom of why it
wouldn't work.
At first, I thought it was hanging, but then I realised it was dropping to a
shell in the initramfs, and just not making that very obvious because the
serial over LAN console is a bit crappy.
Once I realised what was going on, I did some poking around.
It seemed like udev wasn't getting started properly, so when it
went to assemble the mirrors, that failed, because the component devices
couldn't be found, then it freaked out because it couldn't mount the root
filesystem.
If I ran the relevant bits of /scripts/init-premount/udev by hand,
the SCSI devices appeared, and I could manually assemble the mirror, and
mount the root filesystem, which was handy, because I also discovered that
you can boot with debug on the kernel command line, and it logs the
initramfs run to /tmp/initramfs.debug. So that was a convenient way
of preserving the log, because there seemed to be some characters in it that
made inspecting it over the serial console difficult, and there was no way
to get it off the machine from the initramfs environment.
As far as I can determine, it's telling udev to start, but it certainly
isn't still running when it bombs out to a shell after failing to mount the
root filesystem. It's not immediately clear if there's something later on
that is stopping it again. I've put the log here in
case anyone's interested in looking at it. This was with the addition of "x"
to the options of the shebang line of
/usr/share/initramfs-tools/scripts/init-premount/udev so that I
could see what was happening when /scripts/init-premount/udev ran.
So I don't think the kernel itself is at fault, it's some sort of weird
udev/initramfs interaction.
Rather than further rebooting the tripe out of daedalus, I'll have
to see if I can reproduce the problem on a less important machine locally to
do further debugging. In the meantime, I'll have to stick with 2.6.18.
Ryan kindly sent me a copy of the ACPI tables for his motherboard, so I've had the opportunity to look at them in a little more detail. There's nothing especially surprising. The first method of interest is OSFL, which I've annotated below:
Method (OSFL, 0, NotSerialized)
If (LNotEqual (OSVR, Ones))
Return (OSVR)
This block simply skips the checks if they've already been evaluated and returns the cached value
If (LEqual (PICM, Zero))
Store (0xAC, DBG8)
If the programmable interrupt controller has been set up in PIC mode rather than APIC mode, 0xAC is written to i/o port 0x80. This would then show up on a plug-in card if one were attached. Simply debug code
Store (One, OSVR)
Set OSVR to 1, which in this case clearly means "Unknown OS"
If (CondRefOf (_OSI, Local1))
This checks whether the OS supports the _OSI method. If it does, the following block is executed. If not, the older _OS method is used to detect the OS
If (_OSI ("Windows 2000"))
Store (0x04, OSVR)
Newer versions of Windows will also claim to support the interfaces defined in older versions, so this set of checks is done in release order
If (_OSI ("Windows 2001"))
Store (Zero, OSVR)
If (_OSI ("Windows 2001 SP1"))
Store (Zero, OSVR)
If (_OSI ("Windows 2001 SP2"))
Store (Zero, OSVR)
If (_OSI ("Windows 2001.1"))
Store (Zero, OSVR)
If (_OSI ("Windows 2001.1 SP1"))
Store (Zero, OSVR)
If (_OSI ("Windows 2006"))
Store (Zero, OSVR)
If we've got this far, OSVR is now set to 0. Linux will claim to support all of these interfaces, and so OSVR should be 0 on Linux systems. Note that there is no _OSI check for Linux - the 2.6.24 change to remove Linux from the set of claimed interfaces is therefore irrelevant
Else
Linux supports _OSI, so we should never be here. But if we somehow are...
If (MCTH (_OS, "Microsoft Windows NT"))
Store (0x04, OSVR)
Linux has responded to _OS with "Microsoft Windows NT" since 2.6.9. MCTH is simply a string matching routine defined elsewhere in the DSDT. So, worst case here is that OSVR is 4
Else
If (MCTH (_OS, "Microsoft WindowsME: Millennium Edition"))
Store (0x02, OSVR)
If (MCTH (_OS, "Linux"))
Store (0x03, OSVR)
..because this could never be true unless you're running 2.6.8.1 or earlier. But even so, getting here would still indicate failure - we've supported _OSI since before then, and so should never come anywhere near this code block.
Return (OSVR)
In summary, we end up with the following values:| Value | OS |
| 0 | Windows XP, 2003 or Vista. Linux (assuming absence of bugs) |
| 1 | Unknown OS |
| 2 | Windows ME |
| 3 | A version of Linux that doesn't implement _OSI and is from before 2.6.9 |
| 4 | Windows NT 4 and 2000. A version of Linux that doesn't implement _OSI and is 2.6.9 or later (I don't believe any such version exists |
If (LEqual (OSFL (), Zero))
Store (0x59, SMIC)
Else
If (LEqual (OSFL (), 0x04))
Store (0x5A, SMIC)
Else
Store (0x58, SMIC)
This writes different values to SMIC (which turns out to be i/o port 0xb2) depending on the OS. 0xb2 is the standard(ish) way to trigger a system management interrupt, which causes the CPU to execute some code from a memory region that can't be accessed by the OS. This isn't that unusual, but it's a little weird. In any case, note that there's no check for whether OSFL is 3 here (which would be true if the _OS call returned Linux), and so Linux is being treated identically to Windows ME and any unknown OS. In reality, Linux will be treated identically to either Vista or 2000. This block provides no evidence of conspiracy. Finally, the OS version flag is written to a region of memory before suspend and read back afterwards. Nothing appears to be done with this information - it's conceivable that the low-level resume code in the BIOS has conditionals based on this, but I suspect that it's just boilerplate code that's ignored.
I’ve used the TLA EOM occasionally, but never considered the full scope of its utility. Lifehacker just made me a full convert:
EOM means much more than End of Message. It means “good use of time.” It means “concise.” It means “clarity.” But GUOTCC doesn’t have the same ring as EOM, so let’s stick with it. Here are eight great reasons for you to adopt EOM while crafting your email messages. (1) EOM saves your recipient’s time. Don’t you value your time? Isn’t it nice when others value your time too? By keeping your subject line short and using EOM you are showing the people you send to you value their time. They’ll thank you for it (when they know what it means). … (8) EOM guarantees 100% readership We’ve all had the frustrating experience of waiting on someone to read our important email and respond. Sometimes we wait a long time and follow up to find out they haven’t even read the message at all. Perhaps the most powerful advantage of EOM is 100% readership. Why? Because your entire message is in the subject line. Your message becomes impossible to ignore because it comes in front and center no need to double click.In a job where I receive between 300-1000 emails on most weekdays, every little bit helps. The main drawback of excessive EOM’ing may be that it breaks threading for some mail readers, and may be incompatible with other email conventions. Technorati Tags: Email, EOM, Lifehacker, Productivity
KVM Utility
Gunnar Wolf made an interesting post about KVM today which is timely. He points to a simple shell script for managing running instances of KVM which was a big improvement on mine - and so is worth a look if you're doing that stuff yourself. Once I find time I will document my reasons for changing from Xen to KVM, but barring a few irritations I'm liking it a lot.Chronicle Theme Update
I made a new release of the chronicle blog compiler yesterday, mostly to update one of the themes. That was for purely selfish reasons as I've taken the time to update the antispam protection site I'm maintaining. There have been some nice changes to make it scale more and now it is time for me to make it look prettier. (A common theme - I'm very bad at doing website design.) So now the site blog matches the real site.ObQuote: Resident Evil
Several weeks ago, the people in charge of maintaining the Windows machines in my institute were desperate because of a series of virus outbreaks - Specially, as expected, in the public lab - but the whole network smell virulent. After seeing their desperation, I asked Rolman to help me come up with a solution. He suggested me to try replacing the Windows workstations by substituting local installations by a server having several virtual machines, all regenerated from a clean image every day, and exporting rdesktop sessions. He suggested using Xen for this, as it is the virtualization/paravirtualization solution until now best offered and supported by most Linux distributions (including, of course, RedHat, towards which he is biased, and Debian, towards I am... more than biased, even bent). So far, no hassle, right?Next.