neura

"Content is king!" Have you never heard that before?

You say Mozilla should figure out what will draw users from other browsers, but you've outlined what will draw users from Mozilla to other browsers. In the end, people want content. The content providers have more control. If 70-80% of the browsers already support the DRM they want to use, the other 20-30% will follow or be left out. Which is exactly what happened here.

Maybe the old saying "give them an inch, they'll take a mile" is apropos here?

So, you're saying, we should trust the business that's currently trying to milk more money from any tit they can find, to lower their prices because they're bringing in a new revenue stream elsewhere? The same business that has no incentive to do so because they probably only have one competitor in a given geographical area?

The internet itself was basically built on equality. Look at any of the articles and blog posts being written by the actual internet backbone providers. They've been keeping the equality stable through the years with their peering agreements.

We would basically be giving the rights to providers like Comcast to say "We've decided that Wikipedia should pay extra if they want consumers of their information to continue to receive it in a timely manner." "Oh, we're also starting up a new service called Xfinipedia that provides a similar service, but one where we moderate the content."

Call it paranoid, but this is exactly what they're intending to do with video streaming services. They want to provide on demand video streaming to their online customers, while making it more expensive for competitive services to operate. What prevents them (or other providers) from doing the same with any service?

I think you may still be missing the main point, which is that network access providers already have a tight hold on your business. For a given geographic area, you usually only have access to either phone lines or cable, with some exceptions, which usually are higher cost and lower quality.

While you may be able to obtain DSL service from multiple "providers", they're almost always using the same resources. Kind of in the same way that there are many mobile providers, but they all rely on the major networks.

Companies like Stripe on the other hand, are equivalent to the front end of that system. Nearly anybody can provide the same service that Stripe does. Which makes it a competition to see who can provide the best service vs price (or whatever choices you're basing your decision on).

If you only have access to the internet through your cable lines or phone lines, having the entities that control those finite resources legally able to charge more for different types of content over their lines or content from different locations, etc. is a pretty huge deal.

Even when you use some "local ISP", if the company that controls the end point at which your phone lines are connected to the internet decides to start filtering, rate limiting, etc. the data you're receiving, there's not much you can do about it.

Heck, even wireless internet providers are working with finite resources. You can't just decide one day that you want to start a business doing wireless networking over large distances without getting the FCC involved. It's to the point that you could basically consider wireless networks with enough broadcast strength to cover a city to have virtual hard lines. They essentially own those frequencies, so they may as well be considered the same type of finite resource.

I think you're taking only half of a comment and changing the context. "We often think that people use social networks the same way that we use social networks. This is intended as a live demo that most people on twitter are not like you."

I understand that you're using "not like you" in the context of what language they speak, but it seems pretty clear that the author is referring to "the way that we use social networks".

Is this even news? What's the ratio of software developers in general or at least at similar companies?

This is mostly how i feel about it. With the addition that, there's a big difference between a friend asking to read your diary (who, we'll note, was not in the diary, as he pointed out) and a friend (or anybody) asking to distribute your diary to the public. I think that's the main thing most other people are commenting on as well. There are many levels of private and making something public is not the same as making it publicly accessible.

I love the use of "should" in "you should not host any type of server using your Google Fiber connection".

For a legal document, that's a pretty muddy word. It could be just a suggestion or it could be interpreted as "shall", basically making it a demand.

"Netflix seems to be the only one that realizes this, and has started producing their own content (e.g. House of Cards and Arrested Development), and I think this is the only true catalyst that will change the industry for the better."

There's a big difference between a company like Netflix producing their own content, making it available for watching uninterrupted, whenever you like -vs- any of the content providers that charge cable companies for their content streams that include commercials and are generally not available "on demand", packaged together through a single company that won't give you just the content you want, when you want it, but charges you for some combination of provider's streams in a package.

Hence the argument of "the alternative is having to pay $100/month for a cable subscription to watch garbage you don't want to see". 5x7.99 is not the cost of cable. The only cable packages you can get for that price are extremely limited. Also, they will require another $4.99 a month for on-demand, on top of your regular cable fee, unless you're paying more than $100 a month, in which case, it's included. ¬.¬

The original point was that a "netflix" provides better content than cable to start with.

The argument against it was that the company providing the content would be exclusively providing that content.

The rebuttal is that it would be better to pay 5 companies that all produce exclusive content than to pay for cable, which "provides" mostly stuff you don't want to see (and frequently don't have the option to not watch, if you're viewing any of their content, ie: commercials).

TL;DR - They've said repeatedly that they would rather work on their product/projects than have to deal with all of the details themselves.

The crazy amount they're spending should give you an idea of how much throughput they have and what would be required for their own setup. That means a lot of design, additional time implementing, more time updating to new tech (including on the software side, in gems, etc), then in the end, ongoing maintenance.

There's probably a lot more that I'm not mentioning as hey, like them, I'm not interested in spending my time developing, purchasing and administrating my own hosting systems, either. I have apps to write.

> If they had been using New Relic correctly (note that I don't work for or speak for New Relic, I'm just a former employee), they'd have seen on the javascript-enabled monitoring that requests were taking a long time. The server-side time is only a portion of that, but it's clearly delineated.

Note that they were using New Relic as part of an expensive add-on package from Heroku. It gave them a queue time value in it's reports, but it was extremely misleading, since the only value it showed was for the router queue time, which should have always been extremely low (and was displayed as such). It didn't say "router queue time" or "dyno queue time shown elsewhere".

Since New Relic is supposed to be showing them everything that happens with their request on Heroku's servers, it seems logical that it would include dyno queue times.

Javascript-enabled monitoring would only show you that the request times are much longer than what Heroku says they are, then you still have to troubleshoot down to figuring out why.

> Unfortunately they picked a number (queue time) that doesn't have much functional basis on Heroku's stack at the moment, which weakens their argument.

I don't think it weakens their argument as it clearly shows that the biggest problem they have is not only out of their control (even with very short run-times, the higher the number of requests you have per minute, the more this problem is going to affect you) but that even buying very expensive tools integrated into Heroku's "stack" will not help you to see where the problem is. The tools were basically hiding the one problem that was solely Heroku's responsibility.

Do not forget that even while there were a lot of statistics about how long running requests can cause other, much shorter requests to take just as long and even timeout, the heart of the matter is that even with a high number of extremely short requests, the router can end up sending many requests to a single dyno while other dynos remain idle. There were plenty of graphs, even animated to show you the effect over time for this random dyno routing.