12 posts • joined Saturday 5th January 2008 11:05 GMT
It doesn’t seem particularly likely that a single paper is going to shift the views of large numbers of linguists on this point!
(If anyone’s interested in more detail) a good recent presentation of the kurgan hypothesis is David Anthony’s _The Horse, The Wheel And Language_ (ISBN 0691058873); a (compressed) summary of the argument against the anatolian hypothesis is that the relationships between wheel-related words in IE languages indicate that PIE speakers had the wheel, and that this is inconsistent with the timeline of the anatolian hypothesis on archaeological grounds. The argument in favour of the steppe origin in particular is based on (according to my notes l-) farming-related vocabulary and relationships with other eurasian language groups.
Colin Renfrew has a decent book holding the opposing view, though it’s getting on a bit now - I don’t know if there’s anything more recent.
I've long been curious why the MPAA (etc) don't go after the NSPs directly, rather than wasting their time on indexing sites. As far as I know there aren't even that many of them (that actually carry binaries groups).
What would be nice would be a -Wdeleted-null-pointer-checks (and similarly for any other optimization options that infer that certain bits of code can be deleted). Then it would be possible to have the optimization without also the risk of bugs.
If I'm reading this and the associated blog post right, it's saying that if you mess with the system's Perl outside its knowledge then things will break on update. Which seems less than surprising.
"no download limits"
http://allyours.virginmedia.com/websales/service.do?id=2 currently claims "no download limits". While it may be true that there's no limit after which you're cut off or have to pay more, a limit after which your bandwidth is reduced is a limit nonetheless.
register comment form insists on a title
Ironically, the diff posted above (with #ifdef PURIFY) is the harmless half of change 141. It was the change to ssleay_rand_add() that was a disaster, not the change to ssleay_rand_bytes(), which is harmless.
The bug report reference is correct, but the patch in it is not the problematic change (read the patch in the context of the code it changes if you're unsure about this). The Debian maintainer ignored it and made their own change elsewhere.
It's also not in fact true that OpenSSL upstream were not consulted about it; indeed it seems Kurt got a go-ahead (http://marc.info/?l=openssl-dev&m=114652287210110&w=2) in a response from a member of the OpenSSL development team.
- Product Round-up Smartwatch face off: Pebble, MetaWatch and new hi-tech timepieces
- Geek's Guide to Britain The bunker at the end of the world - in Essex
- FLABBER-JASTED: It's 'jif', NOT '.gif', says man who should know
- If you've bought DRM'd film files from Acetrax, here's the bad news
- Microsoft reveals Xbox One, the console that can read your heartbeat