ephemeralgomi

Says right in the article that you can recharge it with ice instead of electricity.

From the article: "The worst of the harbingers? Repeat customers, those with a tendency to purchase a product like Diet Crystal Pepsi not just once, but over and over again. These customers really, really like the products that end up failing. Harbingers with a history of making four or more repeat purchases of a failed product are nearly twice as likely as other customers to buy another product that fails."

So no, it doesn't seem like it's as simple as early adopters or novelty-seekers.

Partially because McDonalds/PHP lets you eat/deploy by cramming/uploading the food/file directly into your mouth/server. No utensils/tools required.

If it's Showdown (which, given your description, it must be) then I love you. /dex was incredibly helpful when wending my way through Battle Maison.

Same here (although my living dex has since been deposited in Bank). I was super psyched to take this quiz and then was immediately disappointed by the first question. Too bad, coulda been funny.

I get a _lot_ of mileage out of being able to chain promises like that. If I really need to resolve a promise to a promise, I can resolve to an object wrapping the promise and then unwrap it on the receiving side.

async.js has 'waterfall' and 'parallel', both of which take an array of functions, and it's (imo) much clearer to declare them as anonymous functions inline than make named functions and then pass an array of names to it. I would say that that makes me someone who regularly declares a bunch of anonymous functions in an array.

If it's a pattern you haven't used, I can certainly understand being wary of it at first. But being wary is different than being prescriptive. There is always more to learn.

This is awful. Shell commands are not guaranteed to be idempotent, people! These should all be of the form exec($_POST, not exec($_GET.

No, you're totally right here. I think matdes skimmed over the critical "without having everyone in on it" part of your post.

Yup.

I know you're trolling, but some people might not, so I thought it might be helpful to point out that they are actually discovering and fixing vulnerabilities. For example, CVE-2010-5298:

http://www.tedunangst.com/flak/post/analysis-of-openssl-free...

"the investigator did find evidence of mistakes and errors of judgment."

Link to where the XKCD comic was debunked or shown obsolete? Most of the responses I've seen to it were of the form "well, yeah, but you're not gonna remember a hundred different passphrases, it's much better to use a password manager."

I mean this in the nicest way: I'd just like to point out that before Kickstarter, pretty much your only option would have been to scrounge up the money yourselves, invest it along with your sweat, blood, tears, and time into making the game, and then release it only to find out that it doesn't resonate with your target audience. With Kickstarter, you're able to discover up front if what you're making isn't what people actually want, and save yourself the wasted effort.

There's only one bit of tangible advice I have for you - and I haven't ever run a successful Kickstarter, so take it with a grain of salt. I've worked in games, and I know that they always take way more time and effort than you expect, even with aggressive cutting/scoping. Whenever I see a game Kickstarter with a target this low, my estimation of its failure probability (even if it's overfunded!) is around 80-90%. It tells me that the people involved don't really know what they're getting into. The lowest game Kickstarter I ever backed was Radio the Universe with a target of $12k (but ended up bringing in $80k), and I fully expected it to fail.

Heartbleed doesn't give you access to storage - it gives you access to the raw heap of the process that's linked to OpenSSL. Passwords are typically transmitted unhashed, albeit encrypted by TLS, and the application decrypts the TLS stream to heap, which means an unhashed version of the password is in process memory for some amount of time. An attacker using Heartbleed has a chance to see that memory, and could therefore see hashes OR unhashed passwords.

I do now! Thanks for makin me feel better =)

I'm kind of sad that this is a throwaway account because you're posting good responses, that are technically competent and are actually specific to the bug discussed in the article, to people who are either less informed or are talking about their vague general understanding of vulnerabilities rather than reading the article and actually discussing its contents.

Your posts are exactly the kind of thing I _want_ to read on HN. Is there a particular reason why you feel you can't post this under a general-use account?

These aren't "tricks" or "abuse". They're design patterns.

The ideal resolution for Tesla is for the guy to drop the suit. This is what they're trying to accomplish by laying their cards on the table. IANAL either, but I'm not sure what risk you're talking about - do you suspect this suit will go to a jury trial, and it will become difficult to find jurors that haven't read this press release?

My main objection to it is that since the OP is almost certainly going to accept their own answer before other people can post, there may be other, better answers that arrive late and don't get as much attention.

This was exactly my thought, too. Upon investigating Project Spark, it seems like something more akin to a pumped-up LittleBigPlanet than an actual game development framework. I'm sure folks will have fun playing around with it, but not much more than that.

> Otherwise this "stand up your own email/cloud" trend would have started last summer.

It did! Understandably, since it's not absolutely-zero-effort, there hasn't been 100% uptake, but Alex Payne started up a project that lets you run you own private cloud with surprisingly little configuration:

https://github.com/al3x/sovereign

I've been using it for a few months now and have been quite happy with it. I'm in agreement with you, though, that it won't scale to the entire world, but I don't think that it needs to.

> painfulness to read (not debug with an IDE, which is easy, but to actually read Java code)

This is incredibly important and I never see any Java advocate addressing it. I _do_ see tons of people pointing out how easy it is to automate refactoring, and then they leave dozens of ugly, poorly-thought-out methods lying around...

They didn't punish anyone yet.

If anything, "I would like to personally apologize to Julie" would mean that defunkt personally wronged her, not the company.

Maybe he's just sorry because she's obviously hurt and things didn't work out for the best?

> Pretty much a full admission that everything that Julie said is true.

It reads more like an admission that at least some of what Julie said is not immediately known to be untrue and that they have to check it out. Hence the, y'know, investigation.

No, you're absolutely wrong.

Promises are great for replacing callbacks in the sense of "Here is a function I want you to call once and only once". You can't convert the callback parameter of http.Server.listen() to a promise.

I don't really get the confusion. First-class functions let you do all kinds of great things - I can do things like map across a list to generate a list of functions which I then pass to somewhere else that can left-fold them, which I have trouble visualizing how I would do in a pseudo-synchronous language.

I understand that people have strong preferences for how they like to write code and that's why it's great that there are tons of programming languages out there. Javascript is one of them.

There is always room for misinterpretation. You will never be able to defend yourself 100% against people with poor reading comprehension.

For future reference, the bad API/app design is worse.