The username/password in question supposedly were "admin". And it sounds like it was probably overheard because the sharing was routine and the authentication a farce. So perhaps they didn't have a technical problem, but they certainly don't sound blameless.

I think these kind of issues are harmful to everyone because they encourage black-hat hacking (which is trivial), and they discourage whistleblowing. It's perhaps not honorable, but obviously many whistleblowers like the attention. But if that's the currency that needs to be payed for better security, it sounds like a pretty reasonable tradeoff. In short: typically the hackee should be fined and shamed, not the hacker, even if the hacker's a jerk. It's not about the hacker after all - he's probably not the person you've entrusted your data to - it's about the resposible party taking responsibilty.

Having used default parameters in a medium sized team on a large codebase for quite a while now (basically since day 1), I can assure you that the default argument argument feature is a wolf in sheeps clothing.

They seem sort-of handy and thus get used when you just need to toggle this small thing. However, that encourages methods to do more than one thing; or to work subtly different in different scenarios. The reliability of your codebase suffers. Furthermore, they break programming 101: encapsulation. You can't encapsulate a function with a default parameter. If you wrap that call in something else and need to pass along the default parameter, you need to add the default argument to that second function now too. If the default changes... oh boy. In essence, they encourage misdesign by allowing API's with terrible method signatures and then making it cumbersome to abstract those APIs - so you're being hurt on both ends.

Another small problem is that they're entirely static. I find the binary compatibility argument to be largely irrelevant (seriously, what tiny percentage of your API is outward facing anyhow, and how many people even have customers that buy libraries but don't recompile dependencies?). A much more serious problem is that they thus encourage placeholder values (null, -1, etc) that mean something entirely different. This makes reasoning about functions much harder (irregularities are bad), and can cause surprising bugs when you manage to accidentally pass one of those placeholders. Secondly, they somewhat undermine an actually useful part of C#, namely expression-tree lambdas, which don't support this feature (so APIs with default paramaters tend to be unworkable in expression trees).

I wish they'd never released the feature, or at least made it very annoying to write APIs for so that its usage would be limited to there where absolutely necessary (e.g. interop with APIs designed with it in mind).

var newarr = []; for(var i=0;iarr.length;i++) newarr[i]=arr[arr.length-1-i];

or

for(var i=0;iarr.length/2;i++) { var tmp = arr[i], j= arr.length-1-i; arr[i] = arr[j]; arr[j]= tmp;}

if you really want it in place...

That's not a reasonable position for Apple to take; not at all. They could have simply left the old gmaps app since their license had not *yet* expired, and at least avoided this debacle. Furthermore, you present "plastering" google's logo all over the app as if its certain this was something truly terrible - when that's not sure at all; it's not unreasonable to claim credit for an app you made so a logo might be reasonable.

All in all - if both parties had wanted this to work out they would have made it work. It's certain apple wasn't being reasonable, and quite believable Google wasn't either (but we really only have Apple's word for that). In any case - it's Apple's device; they're Apple customers, and that makes it Apple's responsibility to come up with a solution that doesn't suck - whether that solution involves using an old-fashioned app for another year, or a different provider, or kowtowing to Google isn't really important.

Regardless of who else is involved, Apple chose to harm their customers, probably intentionally, because that fit their strategic aims better. Given apple's dealings with samsung (and others), Apple doesn't come across as a very open-minded company: does it really surprise anyone they played hardball even if doing so cost them something?

Put it this way: if you blame some third party for a seller's failure to provide quality goods, that's not exactly a great incentive for said seller to be fair with you the next time - why bother? Defending Apple for their abuse of their customers reminds me a little too much of the stockholm syndrome for comfort.

I don't think these power-fights are good for customers.

Some small percentage of people, however, have abnormal natural clocks that are much more sensitive to change.

Dude... that's just priceless :-D

While P/NP is indeed pretty way offtopic here, P vs. NP doesn't necessarily apply solely to decision problems. Furthermore, many problems can be rephrased as decision problems; e.g. Does the cannonball need more than 10 second to complete its flight?

For a traditional P/NP example: the traveling salesman problem is about finding the shortest path, which is also not a decision problem.

Possibly relevant here (in some minor way) is that thinking in a foreign language allows people to be more rational.

Seriously, RTFM: https://bugzilla.mozilla.org/show_bug.cgi?id=744193

I don't think anyone's bothered to read the bugzilla case. Possibly including the idiot @ internetnews.com - seriously, I don't understand how you could possibly come to those conclusions based on that bugzilla case.

It's also a fictional summary designed to grab your attention rather than represent the truth.

In other shocking news, different platforms requiring different implementations of this rather non-critical feature don't get the feature exactly simultaneously. And here I was hoping they'd have quantum entangled programmers whose coding is either both done or not done.

This isn't a story.

According to KPN, the hacked website was not part of the CA's issuing system. Assuming they're being wholly truthful, this article is pure sensationalism: A company has a non-critical website that's hacked: whooptie.

Of course it's bad PR: it doesn't inspire confidence in their other security matters. However, its just as likely that they're concentrating on their actual business (managing certificates), and the site was an afterthought. In any case (maybe I'm just cynical) it doesn't surprise me that a very low traffic, low volume site is negligently secured.

Totally misleading headline.

The hacked machine seems unrelated to the actual CA business, though - it's just a website, not a CA management tool or whatever. Source: http://forum.kpn.com/t5/News-stream/UPDATE-11-30-KPN-sluit-tijdelijk-website-Gemnet/ba-p/8477

Yeah; people seem to have this idea that because FF will change versions several times a year that this mean they'll see the same amount of change and the same amount of plugin breakage several times a year they used to see just once every year or two.

Of course, that's nonsense - development speed won't go up by an order of magnitude; it's just a different (and better) way of packaging essentially the same changes.

I kinda hope they adopt something like chrome's auto-updater for an even less intrusive experience.