I recall a story, probably from here in Canada, that a utility had to replace wind generators on remote sites with much more expensive solar panels, because "hunters" found the moving blades an irresistible target. (yes there are yahoos here too - you can find informal rifle ranges up logging roads. They're just a bit quieter and more polite :-)

I have to wonder at the brains of someone who would try to shoot down a high-voltage transmission line, considering what might happen if they succeeded and the line landed anywhere near them, their truck or friends.

The figure for 25 purchases refers to "25 orders delivered at the same time" This is from Plepy's paper "the grey side of ict" http://www.graduateinstitute.ch/aspd/wsis/DOC/200EN.PDF, which quotes a 1999 paper by G. Jönson, F. Orremo, C. Wallin and K. Ringsberg. Which I could not find .. time to go home and eat ..:-7

http://www.theiet.org/factfiles/transport/unintended-page.cfm

Looks like it's a meta-study; it seems to quote this: http://is4ie.net/images/Matthews.pdf, quoted by someone else, which is a 2001 study from the US. Also this: http://onlinelibrary.wiley.com/doi/10.1162/108819802763471816/pdf - a study of online book retailing in Japan in 2001.

I may have got this all wrong, and there may be some new UK research I didn't find.

A rootkit as I understand is a software package run after one has got root. The intent of the rootkit is to hide the nefarious activity (IRC server, warez stash etc.) from the user or admin. LKM rootkits tell the kernel to ignore certain process id's, ip addresses etc. while old-style rootkits overwrite programs like ps, top, ls with modified ones.
A rootkit might contain a backdoor as part of the kit.

The situation appears to be exactly as described by Ksplice.
CVE-2010-3081 has been discussed on RedHat forums and elsewhere.
The Ac1db1tch3z exploit published on the full disclosure list http://seclists.org/fulldisclosure/2010/Sep/268
does indeed appear to contain a backdoor (0p3n1ng th3 m4giq p0rt4l).
From the comments, the vulnerability was found in 2008 and the exploit has been used by the author for some time, and may have been circulating in the underground. When the vulnerability was found and disclosed by Ben Hawkes, the exploit was published to a wider audience.
A number of sysadmins may well have run the exploit on their systems to prove to themselves that this was a real threat. In doing so they may unknowingly have left a backdoor.
More commonly, proof-of-concept exploits posted on full-disclosure lists are crafted by security researchers, do not contain backdoors, and are relatively easy to read. In this case, the disclosed exploit is crafted by a hacker, may well contain a backdoor, and is written with leetspeak runtime messages and obfuscated code.

I admit I do not fully understand the code in the exploit or in the detection tool, or indeed the nature of the backdoor. However, on a Fedora 9 system, running the detector says there is no backdoor. After the exploit is run, the detector says there is a backdoor, so
the exploit must have changed the state of the system in some way. The detector looks for 3 separate backdoors; the one on my
test system disappears after reboot. As I thought the fix was to update the kernel to a patched version, which requires a reboot, I'm not sure how the backdoor could survive. I do not see how having the backdoor is riskier than having an unpatched system.

I can say, though, that the vulnerability exists in stock kernels 2.6.25 - 2.6.36, and was back-ported by RedHat into 2.6.18 used
in RHEL 5 (hence CENTOS 5). As stated by others, an unprivileged user account is required in order to exploit the vulnerability, which exists only on 64-bit x86 systems which also can run 32-bit code. One published mitigation step, which does not require a reboot, is to disable 32-bit compatibility mode by writing into /proc.

Give up passwords, move to certificates, SSH keys, biometrics etc. It doesn't matter how good your password is, it's toast if someone grabs it off a hacked server/client/WiFi (BTW there's some Brazilian hackers busy installing trojan sshd everywhere they can get to).
Re. stupid website passwords, I've started generating random 20-char passwords and using FireFox to remember them (with a master password, of course). A bit of a pain moving between computers, I really need to get some secure sync scheme sorted out (they do exist)

There have been suggestions that if this leak had happened in the Arctic, it could have an environmental impact for centuries, quite apart from being a lot more difficult to fix. I was wondering how the environmental impact compares with nuclear accidents. As a child, I remember reading of the Windscale leak poisoning pastures with radioactive iodine, so that a month's milk was thrown away. The Deepwater Horizon leak has already closed down shrimping and other fisheries for an extended period, with no end in sight.
Chernobyl, as I recall, has turned into a kind of wildlife refuge (disappointing legions of Farside fans with an absence of 3-eyed deer and size-legged wolves)

The practice of using a single privileged account for everything - banking, reading slashdot, downloading porn - may be doomed, and about time too. But I still think there's hope for using a single piece of hardware and a single network. Even if it comes down to using not just separate accounts, but separate cores, for play and work. Last time I looked (a while back) some CPU manufacturers were adding features for process separation but the OS had not yet implemented support. End-to-end encryption should protect your data in transit, if not your usage pattern, though there a a few things to fix in SSL implementations to prevent MITM.

I saw a documentary a while ago about a plane flying through an ash cloud at night over the Andes - all 4 engines quit. There was also abrasion of
the windshield as I recall, plus electrical discharges around the plane that probably affected radio communications.
Several media articles have explained the effects of ash on jet engines, and it seemed prudent not to fly following the volcano eruption. There were initially no standards on safe levels from the engine manufacturers, so zero tolerance as a first response was sensible. Later, some testing was done, and measurements of ash density determined that some airspace could be opened. The last report I read said that planes were flying but engines were being inspected before and after every flight. One might argue that the tests should have been done sooner.

Adobe Acrobat will do some of this, if not all. It does not require a central document repository and works across platforms - at least, as I recall, documents can be signed and verified on Linux though must at present be created in Distiller on Windows. As PDF is a somewhat open standard there is at least the possibility of other tools supporting the digital signatures.
A document may have multiple signatures placed in the document body in a natural way - i.e. where you might have an ink signature box. You need a certificate authority of your own to issue certificates to signers - after all, anyone can get a Verisign certificate, and who's to say that Joe Bloggs, even he is the real Joe with passport to prove it, can sign off on your reactor design ?
There are some options to set when the document is created that control whether it can be signed by the free cross-platform reader or only by the paid-for Distiller.
Drawbacks vs. GPG digital signatures - only works on PDF files, must be created on Windows.
Advantages - natural signing/verification mechanism built into the reader.

what's this "You failed to confirm you are a human. Please start from the beginning and try again. If you are a human, we apologize for the inconvenience" thing ?

So, reading this backwards, I presume we need new cable modems for native IPv6 support ?
And if Comcast's doing a trial, I guess they are in production somewhere.