Possibly I am naive, but I do broadly think this is a good idea. What does concern me however is if everyone is driving cars that automatically stop when faced with an obstacle in the road, then it suddenly becomes very easy for anyone to hijack/rob any vehicle.... so driving somewhere quiet, on a dark night, becomes a very bad idea.

Daytime in a busy area and it's great though! There *will* be less deaths as a result and this part of it is a good thing.

So does that mean that instead of affected organisations needing to fix the internal naming, now, every single piece of software that does a DNS lookup, now needs to check not only for not-found, but also 127.0.53.53 because it's magical?!

Or is this actually a good idea? It looks horrible to me.

And in other, completely unrelated news, MS has announced that it's moving it's German HQ to.... yes, you guessed it.... Munich!

I wonder... I wonder who contacted all these news outlets.... hmmmmmm.

Indeed. My feeling is that more governments are starting to question IT costs/suppliers particularly in light of NSA / US spying allegations, so "funding" must have been allocated to sway decision making. And undermining a FOSS flagship like Munich and Limux would make sense.

MS staying classy as ever!

Vista? Really? I mean, if you'd said 6.1 then that would seem more plausible!

You'd have to imagine that the reason for MS dropping support for older IE versions is to save on bug fixes for IE, and compatibility fixes for HTTP based products.

So it would probably make better sense for them to work to enable newer IE versions on older OS versions. That said, what's logical, and what MS actually do often ain't the same!

Yeah, for the most part, I prefer validation that does as little as possible. I previously had a simple check for a single @ symbol. That worked, except someone used a comma which caused the mailer to think there was more than one email address. I should have anticipated that one. Not a biggie, but there was crap in the mail.log where it was trying to use an invalid address... I don't recall the exact issue, but I believe it though it might be a local address or something.

So as a result, I thought I should make the validation a bit more robust to protect the server and at that point, I blocked UTF-8 because it seemed unlikely to work and thus was just a _potential_ vector for attack.

As a webdev who gets irritated at websites that fail badly with their email validation (e.g. not allowing + in the local part, or only allowing 2 or 3 char TLDs), I do try very hard to get this right. So I've got a solid(ish) email validation function. But, I'm a bit sketchy on what to do with UTF-8.

For the domain, I'd hope that the MTA (Postfix in my case) would allow UTF-8 and convert to punycode as required, but I'm not sure it does. So currently I don't allow for that. I _could_ convert to punycode myself, but I don't.

And as for the local-part, I'm fairly certain Postfix doesn't allow for UTF-8 at present.... at least, not the Postfix version supported on Debian 7.

So I'm just wondering what everyone else is doing? Should I improve my support, or should I just wait for support to be added to my MTA before I bother?

Slightly OT, but this article reminded me of the re-imaged Monkey Island released a year or so ago, so I just had a look on Steam and it's still only available for Windows. Why?!

This kind of treatment is itching for a useful application. Screw photographic/military/whatever - put this on a car... lets say a Lamborgini 'cos some how something very angular seems more appropriate.

it probably does that because the very first Model B rev 1 boards didn't have any holes in them.

but worth a clicky

Oh yeah - I forgot about the security code! Damn!

Is it still a scam if I pledge money using the debit card number in their video?

I think the best response to this is to switch to a domain that does not include the word "IKEA" and to include articles about hacking other furniture suppliers since clear IKEA are clueless to the benefit this site is to their business.