jonjenk

Right. But this requires cooling to liquid helium temperatures. That's a separate level of hard and cost compared to liquid nitrogen.

Why not? Because the single greatest threat to Amazon's business continuity is a major quake in Seattle. Vancouver sits on some of the same tectonic plates.

It's likely that this move is, in part, an attempt to address the business continuity risk.

This is a joke. The latest MacBook Pro redesign is an affront to pro users.

At our hardware/software startup the new MacBooks are unusable due to the limitations of the USB-C ports. Our engineers refuse to engage in the dongle shenanigans necessary to get these computers to work with the displays and the other peripherals necessary to do their jobs.

We just purchased several of the old MacBook Pros to make sure we have enough for new hires and interns arriving this summer.

Apple cares about Pros? Heh.

Sure, but they aren't Web Scale!

I've created a lot of 3D printed gears over the last few years and one of the best tools I've found is from Rainer Hessmer.

http://hessmer.org/gears/InvoluteSpurGearBuilder.html

It allows you to specify additional parameters like backlash, clearance, and profile shift. It also allows you to output in DXF which tends to be more of a standard in the engineering world.

Former head of engineering at Pinterest here. Marty was one of the first three engineers at the company. He is an amazing guy -- smart, personable, fun to work with.

This is a boon for Reddit and as a Reddit user I'm very excited. Fortunately Pinterest has a strong bench and can afford to share the wealth of their amazing engineering team.

Former Amazon person here.

This is totally wrong. Amazon retail has been running on AWS for years.

What you are describing is called "backdriving" the gearbox. Generally speaking, gear trains with high reduction ratios don't like to be backdriven. Small steel gear trains with ratios in the 1000:1 range can destroy themselves when back driven.

This is a pretty shitty apology. The key problem is that ekjp isn't owning the failures directly. Just look at the language in the post...

"We screwed up." "We haven’t communicated well..." "we acknowledge this long history of mistakes..."

This type of language shows a lack of ownership and accountability of the author. It's a huge red flag. If one of my employees wrote something like this I would never have accepted it.

A good apology would have started with something like, "I am sorry." Everything that happens at a company is ultimately the CEO's responsibility. The language used in ekjp's apology does little to reassure me that she actually feels like she owns the failures.

I know some of the people who have signed up for this and I can say with confidence that I'd happily take them at any salary.

The fact that some of the best and brightest in our industry have decided to do this work because it's important rather than because it's the most financially rewarding option is encouraging.

That level of accuracy would be hard to achieve. Most radio signals (eg. BTLE) don't travel well through water (eg. snow).

Additionally, if you've ever dug someone out in the field (or practiced doing so) it takes a lot of effort to move snow. Being within three meters isn't good enough.

"When I ride alone I can maybe go top to bottom in slightly under 20m but I'm flying and really pushing it the whole time, I wonder if the drone could even keep up in that situation (speed would be over 25mph almost the entire time)."

Where do you ski? 20 min at 25 mph implies an 8.3 mile long run.

I'm an engineer so when people ask if something is possible my honest answer has to be that anything is possible.

Would you allow me to rephrase your question? I'd rather answer the question, "What is the likelihood that the knob can be installed incorrectly or that the mechanical interlock will fail in a way that would allow the knob to unexpectedly turn the burner on when not intended?"

My answer to this question is that it would be EXTREMELY improbable that this would happen. I say this for the following reasons. 1) The part of the knob that allows the user to push the shaft inward to override the safety interlock is a completely separate piece from the part that turns the knob; 2) Both of these pieces are made of smooth, lubricious plastic such that it should be very difficult to install the knob in a way that they would bind; 3) assuming the user did install the knob in a way that made this possible it would be very obvious to the user that things are not right; 4) the knob software is written in a way that the knob will refuse to move from the off position without physical intervention from the user.

What I've described is generally called a defense in depth approach. You put a bunch of safety mechanisms in place such that all of which have to simultaneously for a bad event to occur.

Hopefully that helps.

I totally understand your concern. That's why we NEVER turn on the stove for you. All modern stoves require you to push the knob in to move it from the off position. The Meld Knob is mechanically incapable of defeating this safety interlock.

I'm one of the founders of Meld and I'm happy to answer any questions you might have about our product or precision cooking and temperature control in general.

We were as surprised as you that this doesn't exist already. A traditional stove is an amazingly capable and flexible device. By adding some simple smarts to the burner control it's possible to do amazing things.

Induction stoves are good, but you might be surprised to learn that gas is even more precise. With gas you basically have infinitely fine control over the flow of energy to the pan since a gas valve is a linear analog control. Honestly, though, whether you have a gas or electric stove we can generally keep temps to within one degree (F) of a given target.

I wish every flight I was on would deplane this way.

I agree that we don't have a controlled study in this case. However, it will be interesting to look at this data at the end of next season. If the Patriots fumble stats revert to pre 2007 levels it will certainly raise some interesting questions.

Analyzing outlying statistics across all the available variables would be an interesting technique to try to predict other potential rules violations. This could apply to many different types of sporting events.

I wonder if anyone is working on this problem?

Despite a few nit picky issues I have with this particular analysis of the Patriots fumble data it's probably the strongest evidence I've seen so far that there has likely been a persistent rules violation.

I don't think so. I can almost hear Jeff's voice...

"Don't make your problem the customer's problem!"

There are often many technical solutions to create a particular customer experience. Jeff never accepts false dichotomies. If the particular technical solution being considered fails to produce a delightful customer experience then you better start thinking about other solutions. Many of the projects on which I worked turned out much better when Jeff challenged us break out of our little technical boxes and consider alternate solutions that preserved the customer experience.

I can sense that my answer will be frustrating to some who don't like being told that they aren't thinking big enough / creatively enough / bold enough / outside the box enough. Believe me, I felt that way too when working on Jeff projects. I left his office in frustration many times only to realize several hours or days later that I would have been better served by focusing on creative problem solving instead of trying to convince Jeff that X was not possible.

I have immense respect for Jeff. I also have increased respect for Sergy because he appears to be asking the right types of questions at Google.

Former Amazonian here. If anyone wants to understand the key difference between Amazon and Google culture there's a great quote in the article.

"In all the testing, Roy had never seen one of his drones deliver a package. He was always at the takeoff point, watching debugging information scroll up the screen, and anxiously waiting to see what would happen. “Sergey [Brin] has been bugging me, asking, ‘What is it like? Is it actually a nice experience to get this?’ and I’m like, ‘Dude, I don’t know. I’m looking at the screen,’” Roy told me."

Google and Amazon are both great companies. But at Amazon the drone program would start with a description of what the customer experience is when they receive a drone delivery and you'd work backwards to the technology solution. At Google the technology precedes the customer experience.

It's interesting that they delay the Twitter by an hour. You can get real time 911 info for Seattle here.

http://www2.seattle.gov/fire/realtime911/getRecsForDatePub.a...

Would someone please start a religion that denies the authority of the TSA so we can opt out of this security theater on religious grounds?

If you're interested in this general topic check out this Wikibook from John Rauser. He's a data scientist at Pinterest.

http://en.wikibooks.org/wiki/Ad_Hoc_Data_Analysis_From_The_U...

There is a great wiki book on this subject.

http://en.wikibooks.org/wiki/Ad_Hoc_Data_Analysis_From_The_U...

Setting aside whether dollar cost averaging into a low cost index mutual fund is a good or bad strategy, the author falls prey to a common investing fallacy. It is most evident in this sentence, "Over the long haul, you won’t lose."

Experienced investors will immediately recognize that there is always some probability you will lose money regardless of the perceived safety of the investment. An investment provides return in exchange for risk -- there is always risk -- understanding this fundamental truth about investing is the the most important thing an average investor can do regardless of what the market is doing.

While the proposed strategy will provide a rate of return slightly below the broad market over long time horizons it's no sure thing. This observation is especially poignant on a day when the Tokyo market index is at a 28 year low.

http://www.cnbc.com/id/47668274

I tend to think we use it quite a lot internally. For instance every amazon.com web server has been running on AWS for quite a while now. You'll find more info here.

http://psav.mediasite.com/mediasite/Viewer/?peid=7ab95f6a5d4...

We're also building Amazon Silk on AWS. As you might guess I think it's pretty cool too.

http://amazonsilk.wordpress.com/

This presentation contains some fairly detailed information about the amazon.com migration to AWS.

tl;dr The organic migration to AWS started in 2006 and continues to this day.

http://psav.mediasite.com/mediasite/Viewer/?peid=7ab95f6a5d4...

Here are two other great talks by one of my friends at Amazon.

http://www.youtube.com/watch?v=UL2WDcNu_3A

http://www.youtube.com/watch?v=coNDCIMH8bk

I think the most impressive stat is a little later in the presentation. Only ~0.001% of deployments actually cause an outage.

Anyone can create a system that generates a lot of deployments, but what really matters is that you can complete all of those deployments safely. Of course, that is still ~0.001% too many outages due to deployments and we are working hard to make that number zero.

Wow. Look at me on the front page of Hacker News!

Our systems are extremely modular. We've previously disclosed that in excess of a hundred discrete services may be called to generate a single page on our web site. You can find more info about that at the following link.

http://highscalability.com/amazon-architecture

When we refer to a deployment at Amazon it means a single code push to one or more servers. For example, if you deploy a new piece of code to a thousand hosts that counts as one deployment. In other words a distinct update is pushed every 11.6 seconds.

Hopefully that makes sense.