Well, DateTimeOffset isn't a class to start with - it's a struct. But it's still not the panacea some people seem to think it is. There are plenty of situations where what you want *isn't* a DateTImeOffset. Its inclusion was definitely an *improvement* on the state of the date/time API in .NET (as was TimeZoneInfo, for sure) - but that doesn't mean it brings it up to a decent state, IMO.

"It either works or it doesn't" - or it works for all but one or two hours of the year, around a time zone transition. Or it works so long as you're in a time zone which doesn't skip 00:00 when it transitions forward by an hour. Or it works so long as you're not in time zone which skipped a whole day once. How sure are you that all your code works in all of those conditions? How *clear* is your code in terms of which values are meant to be local, which are meant to be in UTC, and which are meant to be local in some other time zone?

You say that date manipulation in .NET is really not hard - but I've seen an *awful* lot of subtly-broken code using DateTime, and even correct code isn't always *obviously* correct, mainly because `DateTime` doesn't represent one single concept.

I looked at the .NET DateTime functionality *very* hard before deciding to write Noda TIme - and now, 5 years later, I'm still convinced that it was the right thing to do.

Glad you've liked Noda Time - but if you could drop a line to the mailing list or raise an issue for any "Java-isms" you've found, I'd be grateful. I've tried to make it as idiomatic to .NET as I can, other than where doing so would be harmful.

I'd say the debate about the consequences is fairly scientific, as in there is a debate to be had. I don't think there's much of a debate about the existence.

Alternatively we need a legal precedent that a false claim of ownership of Copyright in a work is tort (e.g. trespass to chattels) as the real owner is deprived of the use/benefits of the work; moreover if the claim was made dishonestly (the claimant knew it to be false) then the claim should be tantamount to theft. Such a precedent could potentially be established in any common law jurisdiction.

A lot of work on the C# compiler, while he was still working for Microsoft.

I thought I'd get that in before too many other people do. I have better justification than most, as I *am* Jon Skeet. I saw the list yesterday, and we've been gently laughing about it at work.

Somewhere, the difference between fame and accomplishments has been lost. Don't get me wrong, I'm not a bad coder. I'm pretty knowledgeable about C# as a language, although details of writing *applications* in C# is a different matter. I'm pretty good at expressing technical concepts, and that's really useful in various contexts (Stack Overflow, books, screencasts, and of course work). But none of these are a patch on what some of the others on the list have accomplished.

As a Googler, I know a *bit* about what Jeff Dean and Sanjay Ghemawat have done - and it's obvious I'm not in the same league. The code I'm probably proudest of is Noda Time (my .NET date/time library) which has a few thousand users, if that. I hope I've had an impact everywhere I've worked, but it just isn't on the same scale as many of the other members of the list (let alone the many thousands of other notable programmers).

It's pretty clear I'm not actually on the list because of my coding skills - it's just due to Stack Overflow reputation. That indicates *something*, but it's definitely not the kind of measure you'd sensibly use to compare two programmers. Just as I'm proud of Noda Time, I'm proud of being able to help a lot of people on Stack Overflow - but I'm not under the delusion that even that's on the same level of impact as an awful lot of other coders.

For what it's worth, if I could substitute one other name for mine, it would be Eric Lippert. I'm not sure he's really be in the "top 14" or even whether that's meaningful - but I'd say he's at least *more* worthy of being there than I am.

That is you choosing your service provider and access level (dialup, dsl, cable, etc.), which is not a net neutrality issue. At a push it could be interpreted as protocol-specific traffic priority which is a grey area (some people consider it a net neutrality issue, others don't).

Non-neutral behaviour can only occur when two service providers interact, like so: you want to ship a parcel to Bob, but there is no courier that does door-to-door service in both your area and Bob's area. So you ship the parcel with your courier, and pay for a particular service level (overnight door-to-door). Your courier delivers the parcel to Bob's courier (and pays Bob's courier according to some inter-courier agreement), who delivers the parcel to Bob's door. Neutral behaviour occurs when Bob's courier delivers the parcel like any other they handle, even if they can't meet the service level you asked for from your courier. Non-neutral behaviour occurs when Bob's courier delays the parcel delivery because they received it from another courier rather than directly from the sender.

Notice that both Bob and you are screwed by the behaviour of Bob's courier.

The Wired article misses this by focusing on how - if you are a large company - you can send through more than one courier, selecting the one most convenient for the intended recipient. This obviously makes delivery faster because it cuts out one leg of the parcel's journey; and it would make delivery faster with or without neutrality requirements. The article ignores the actual problem of non-neutral behaviour where the parcel is actively delayed (over and above the natural journey time) by one of the couriers in order to force the sender to deal directly with them rather than having the option of sending via another courier (and accepting the naturally longer journey time).

The big weakness of this analogy is that in the real world you can readily choose between one of several courier on a per-parcel basis, but few individuals or small companies can choose between ISPs on a per-connection basis.

This. Wikipedia has a Comparison of consumer brain–computer interfaces that covers devices from Emotiv, Neurosky and others.

Searching for Emotiv, Neurosky or "BCI" (brain-computer interface) plus keywords like "disabled" or "ALS" or "locked" produces a couple of results on improving communication with limited physical control, e.g. this and this. I'm sure there are plenty of others.

Another approach is software like Dasher, which turns gestures from various sources (including eye tracking) into text. There appears to have been some work to integrate Dasher and BCI.

But to get there we need to move from crowdfunding-as-advance-purchase (which is how most Kickstarter campaigns are set up) to crowdfunding-as-investing.

* (we Australians do have a small film industry)

I don't think this is / will be specifically aimed at Hollywood (we Australian's do have a small film industry).. I think that was just a rabble-rousing association made by someone who wants to whip up opposition.

That you're a content creator who wants his work protected and you oppose it because of an implication it's for Hollywood shows how effective this tactic is.


FYI I am also a content creator (software dev), but since I write business software that isn't distributed and my personal software is open-source, I do appreciate the benefits of the status-quot (though the proposal isn't particularly hard-line anyway), I don't have strong views on this. I just wouldn't get too foamy at the mouth about an implied association.

findstr has POSIX basic regular expression support (almost) and has been available since Windows 2000.

You'd need to exploit the browser in such a way that you can POST to the modem with a custom user agent set, that'd be a pretty serious exploit, and I'd be more worried about that. You could then use the modem to try and trick around with DNS to get on other machines, but it'd be hard to do transparently. It would all have to be pretty well tailored.

Anyway I'm not saying this isn't a security hole that needs to be fixed, but that the idea that this shows the need for increased regulation is nonsense.

How about this one from a month ago?

You can also compare Apple's 2095 vulnerabilities for 97 products to D-Link's 43 vulnerabilities for 40 products.