jspthrowaway

It's not a throttle, it's the "physical" capacity of the "interface". If you're on an instance with gigabit connectivity and you're doing 1 Gb/s of EBS I/O, other network chatter will suffer, probably fairly dramatically. That's why the high-I/O instances have 10 gigabit connectivity, as I understand it.

Happy to be proven wrong but this is based on a year or so of experience dealing with EBS. You can't see the EBS traffic in your tools (at least that I've been able to find), which complicates things.

It's all kinds of different on VPC instances, therefore I suspect the network interface model -- and possibly EBS connectivity -- is different on those. So, who knows? I'd kill for Amazon to be more forthcoming here so I could understand the infrastructure running my fleet, but, I don't and they aren't.

Ephemeral is definitely not EBS, as its I/O does not contribute to saturating an instance's network connection (I've tested that). EBS has a ceiling for throughput (the instance's network throughput) and competes with your other network traffic, which is interesting for database workloads for obvious reasons. In addition, every single benchmark I've seen run reports ephemeral behaving very differently from EBS.

As ephemeral disappears when you stop an instance (presumably, when the system is given the opportunity to relocate your instance to another machine), I've always suspected that ephemeral storage was part of local disks on the virtual host's chassis -- as opposed to a SAN or other kind of network-attached storage. As such, you probably end up with the same unpredictable performance you find in all virtualized resources, since it is very unlikely that Amazon is giving you your own storage.

Before benchmarking ephemeral storage you have to pre-warm it, which might have contributed to your findings. Ephemeral is worlds better than EBS, particularly in outage scenarios; if I could convince everybody on planet Earth to stop using EBS, it would be a noble cause.

> Well Objective C is a separate language entirely.

Not quite; Objective-C is a superset of C. You can write pure C and compile it as Objective-C all day long.

This is an important point because people think their C knowledge doesn't translate to Objective-C, mainly because people say things like "it's entirely different". At its core, it really isn't -- the superset syntax becomes straight C underneath.

Diesel, on-highway in New England, is averaging $4.205/gal[1] (probably more in the city, especially more in a disaster situation). Applying your information to the above question and assuming they can get just shy of five gallons per bucket, it's probably a fair estimate that each bucket carries more than $20 of diesel fuel and accounts for seven minutes of generator time. So, about $3 per minute or 5.1 cents every second.

Really puts things in perspective.

[1] http://www.eia.gov/petroleum/gasdiesel/

Ruling out a product and dismissing it based on projected ROI is not criticism. That would be called "making a business decision," not providing constructive feedback.

I didn't put words in his mouth, he wrote that they were lying to managers and possibly being deceptive. You also misquoted me, which is ironic given your criticism.

Your postulation is unwarranted, by the way, since my posts have been going up and down based upon their depth in the thread. The top comments have been upvoted more than the lower ones, and the lower ones have actually been muted somewhat. I would actually suggest that people are reading the thread and voting appropriately, and probably aren't making it deepest into the thread.

Your sweeping characterization of mindless Hacker News voters acting by whim is disconcerting, to say the least. That we're so fixated on the voting here when karma is absolutely worthless is equally annoying. I am, however, intrigued by the shift from very light gray back to legible that has taken place on his comments since the beginning of this meta discussion (starting with ww520's remark); there might be something to what you're saying, which is that people are acting based upon what others are saying -- that's troubling.

People who have never used software should be critical of "here's what our software can do with inexperienced hands, maybe you'll do better"? I'd much rather default to giving benefit of the doubt than assuming everything sucks before I've even touched it. Reminded of people who say they don't like exotic food but have never eaten it.

I think the lowest opinion on the totem pole is one formed by assumptions (based upon personal experience with an area) used to reflect upon something from the hip. "I'm pretty versed in game development, and what these people are doing is stupid based on my world view."

Dismissal is not constructive criticism. There's a sizable difference between "meh, nothing to see here" (which is the original comment in this thread) and "here's how this could be better".

I, like pg and hopefully other Hacker News readers, am pretty sick of every story about something cool being immediately derailed by a know-it-all in an industry dismissing the innovation as "not cool enough". pg calls it middlebrow dismissal[1]. Rather than being treated as an imperfect launching-off point for further innovation, everything has to be world-changing perfect to have a reasonably sane comments section.

I'm actually glad this thread got pushed down, so maybe some actually informative discussion can rise up rather than an analysis of how minutely the people behind this screwed up.

[1] http://news.ycombinator.com/item?id=4693920

glibc's malloc() is known to be lackluster under parallel workloads. Alternatives do perform better in certain circumstances, but profile before making the switch -- your situation might not be one of them.

It's possible to inject tcmalloc into an executable using Linux's preloader, too, without recompiling[1].

[1] http://gperftools.googlecode.com/svn/trunk/doc/heapprofile.h...

Oh, now they're lying? Care to back that one up? That's a steep accusation that you should probably reconsider attaching to your name.

They wrote a tool to find things to parallelize. They parallelize them, the code gets faster. I realize that it isn't the faster you would prefer, but they picked an accessible target that everybody could understand. It isn't as cool if they say "we made Excel render graphs 15% faster" or "we made MP3 transcoding 15% faster". They just made a code base faster using their tool, that's all.

If they had made a video editor faster and you'd worked on video editors all your life, I'm sure you'd be here shitting on the achievement as well. They're not a game development shop. They picked a game to screw around with. They made it quicker. It just happens to be your pet area, so you absolutely cannot stand that someone figured out how to do something in your little world that you wouldn't think of.

I'm impressed you've upgraded to outright calling them liars now rather than just admit, maybe, you might be wrong.

All of what you say is wise, but the engineer doesn't work for the studio and isn't on Doom 3's release timeline. He made the game's frame rate 15% faster of his own volition simply because he could. So it's wrapped in a sales pitch, oh well.

"I see something I can improve, but I had better not improve it; were I to work at id, my time would probably be more valuably spent on other things."

I wish you'd just back off and laud the improvement rather than fitting it into your model of game development and continuing to double down on a snarky, dismissive comment that basically shits on somebody else's work. I certainly appreciate that you've worked in professional game development, but come on, someone did something cool. I'm sorry that it isn't cool enough for you or doesn't use the measurements you prefer.

Attitudes like yours hurt our industry as a whole.

> Instead of spending 3 weeks wrapping data structures in mutexes for a 15% framerate increase, you could probably get an equivalent speedup by reducing shader detail, texture size, or any number of other options.

I see why we differ in opinion here: you feel that regressing backwards and sacrificing visual quality is a better approach than parallelizing the same exact engine with the same quality. I don't think we're going to see eye-to-eye on this one.

Came for the dismissive hand-waving that I fully expected to be the top comment and I wasn't disappointed.

What's the improvement factor where you'd be impressed? 50%? 60%? It's remarkable in my opinion how little work it took to improve upon an already very-optimized engine, in the constraints that they set for the developer, by a developer who's never worked with game engines in his career.

Edit: No longer the top comment; it was when I commented.

> Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

http://daringfireball.net/projects/markdown/license

Markdown is a specific implementation, a concept lost on the majority of the people in this thread.

> What both Jeff and Gruber bring to the party is profile. As the article points out, there are already variants of Markdown that fix many of the problems but it would seem none of them have gained traction.

Sounds like the market has spoken.

> Markdown is not some amazing patented invention that John Gruber is entitled to perpetual dictatorial rights to forever.

Completely wrong. Markdown is John Gruber's creation, and he is quite entitled to perpetual dictatorial rights forever (although copyright is limited, his estate is perfectly capable of renewing if he wishes). John Gruber is the copyright holder on Markdown (the idea and implementation, which most of this thread is overlooking). It says so right here:

http://daringfireball.net/projects/markdown/license

In the same license, it says:

> Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

Think about that while I repeat: You do not get to take over someone's creation and trade on its name simply because you are not satisfied with the stewardship of its creator.

That's precisely what we should assume, because it's the facts as presented. Inferring things that don't exist because they benefit the parties in question is a subtle undercurrent that drives the entirety of our fact-unfriendly blogosphere, tabloids, and so on. You sound a little like an apologetic Gawker reporter, here.

We were given the story at face value, we interpret it at face value. We don't make up what could have been nor consider it acceptable to do so.

I'd say you've discovered a hefty dose of speculation that lacks any evidence.

You've also invented a false trichotomy. Those aren't Jeff's only three choices. The fourth one you left out is "make something new without shitting all over Markdown".

Your comment reeks so strongly of entitlement that I don't even know where to begin.

We could say Twitter was instrumental in organizing human rights causes in the Middle East and is now important to the human race as a communication tool; that said, if Twitter doesn't implement a feature that you want, you don't get to redesign Twitter at your whim and call it "New Twitter". You don't have a "moral claim" to write an open letter to @jack telling him why you're moving on without him.

You instead, like all rational people, design a competing service and let your work stand on its own.

Actually, he lost credibility for not being a decent human being and e-mailing John Gruber first and StackOverflow is really irrelevant here.

"Say, so-and-so, you wrote a really nice book but there are several errors in the first edition. We think it's great and we love it, and we see the potential in your work, so we're going to rewrite a second edition by committee then sell it under your title and byline without your permission; that cool with you?"

Regardless of how much I dislike Gruber's opinions on occasion, Jeff Atwood is completely steamrolling him here and I really feel for him; it isn't an accident that Jeff blogged about it instead of asking him privately. You do that when you don't care either way what the person says, and it's a completely dick move. As another commenter pointed out, there is no winning move for John Gruber here. That's so obvious that I can't even give Jeff the benefit of the doubt that he overlooked it.

This entire experience has left me with a bad taste in my mouth about Jeff Atwood -- I sure hope he doesn't set his sights on something useful that I've created for the world. You can make whatever argument you like about Gruber not "paying enough attention" to his creation, but Markdown doesn't really need to be "fixed" or "standardized". I look forward to the, undoubtedly, dozens of vendor-specific extensions that will be necessary in the final product and we'll end up right back at square one.

Really, really presumptuous and poor judgment. Invent your own stuff and let it stand on its merits rather than trading on Markdown's well-established name by force.

> and made questionable use of the downvote button

In your opinion. I think it was right on target. Complaining about downvotes is in the guidelines as something to be avoided, and predicting their onset is a slightly differently colored shade of the same thing. It manipulates peoples' reactions to your comment, and you are not at all oblivious to that.

I'm actually glad he told you why, even though it cost him karma. I wish every downvote came with a reason.

> (which comes with great responsibility, especially if you are a YC partner like he is)

I laughed out loud at this. It's the downvote button, not a loaded gun.

I'll summarize.

The CEO of justin.tv, who you've met personally (as if that's important to the issue at hand), downvoted you and you've gone after his personal image as a result. Now you're citing his responsibility "as a YC partner" to act fairly. Can we circle back toward you just not liking being downvoted eventually?

Your comment was so devoid of insight that the downvote jab at the end just became icing on the cake, and I agree with it being called out. People upvoted the article. It's a dumb article. Commenting on the people upvoting the dumb article and characterizing them as mindless IFTTT fans is just noise, and this entire thread which has now launched off from your noise is even more noise.

> This should probably be rectified: hosting providers should be held accountable for unwarranted terminations as much as they are held accountable for hosting illegal content.

A: Hosting companies are not held accountable for hosting illegal content if they cooperate with authorities. There are specific procedures for the gamut, including child pornography. The FBI is very active in working with established hosting providers to investigate and take down illicit and illegal content.

B: Your suggestion would shutter smaller startup hosting companies, raise prices at others, and cripple the startup community that Hacker News loves so much. The fallout from your suggestion would be so colossal that the harm to innovation from software parents would look minuscule in comparison. Should we punish the telephone company for every bomb threat that traverses the line? Dreadful.

> Since you bothered to create a throwaway just to post this

It's one click to deduce that is certainly not the case.

That's a thin argument, because it really depends on what the startup does. There are plenty of turn-and-burn startups that have become mission-critical for other startups, I'm sure.

Whether that's wise, well...

Couldn't agree more with most of your points. Almost everybody defaults to assuming their broken Wordpress install is the provider's fault. I'm not sure that I agree with any company being beyond mistakes.

> The problem here seems to have been that ServerBeach didn't bother to make a phone call before shutting off the servers of a not insignificant customer.

Well, two things:

Most hosting companies don't call for anything, and most don't even take a number. I've dealt with many. Amazon, in particular, won't call you for anything. (I know because I work at an account several orders of magnitude larger than OP that hosts with Amazon.) Google won't call you before they terminate your Gmail, as has been shown before, and that's simply because the resources required to maintain a call center don't make sense for (the almost entirely automated) hosting industry. Margins are low. Calling every customer that receives a DMCA complaint would, at an average-size host, require probably a dozen employees just making calls. This is seriously busy work, and people outside the hosting industry don't see that.

The other thing is that we keep saying "pull the plug," "shut off servers," etc -- that's a pretty drastic intervention, and I'd be shocked if that was what was done. More than likely, the IP address was just dropped from the Internet, which is rather quickly reversible. The same thing will happen if someone points a DDoS botnet at you and starts disrupting service for other customers as collateral.

> for what turns out not to have been a very good reason.

ServerBeach does not have the liberty to debate whether a reason is good or not. A valid DMCA complaint is a valid DMCA complaint; to remain "carrier neutral" and preserve safe harbor for other customers, a hosting company must act as if every complaint is valid and enforceable.

Once a hosting company makes decisions about complaints and selectively enforces, safe harbor goes bye bye and the copyright holder claims ownership of the hosting company. Then many, many customers beyond the original customer are affected, which is a really big deal at a hosting company (scope).

> But if it is their policy -- and until they say otherwise, it's natural to assume that it is -- then I can see why people would have a problem with that.

I don't disagree about having a problem with a policy. I do, however, detest the directions these conversations take. Look around this thread. I don't see a lot of "that's a bum policy," I see a lot of "what horrible people" and implications that the employees are incompetent, and so on. I do take issue with that.

I've been in the hosting industry for some time, and I'm always appalled at how quickly stories like this, regarding hosting providers, escalate. It's such a contrast between startups in this community that make a mistake ("I'm sure they just made a mistake, and they'll get it cleared up"), versus a hosting company ("they're incompetent, dangerous loons and I'm never giving them my business"). This attitude prevails beyond Hacker News, and finds itself into support tickets at hosting providers. I can't tell you how much support tickets made me resent the customers; the gloves come off when there's a mistake. I've personally been called much worse than has been shown in this thread thus far after I helped people in tickets.

Honestly, I have to ask this -- why do those in the technical community here feel like their hosting company is automatically out to get them? Hosting companies are drowning in policies, and acting upon DMCA complaints is a particularly dangerous area because the DMCA is very vague, particularly in the expediency of provider action. Is the hatred for hosting companies rooted in their ability to take you offline very quickly?

I deleted out of a thread here where I asked a similar question, because this is obviously a controversial topic, based upon those comments' scores within minutes. I just wish I understood why it's never okay for a hosting company to mess up, and why it's okay to attack them personally when they do.

Of course, having been on the other side of this line, I don't actually think ServerBeach erred here but I'm also hesitant to draw a conclusion without both sides of the story. It's an unfortunate situation for both sides, and this sort of thing never makes it better.