Hacker News Reader

Comment by dare944 | Hacker News Reader

As an early Nest employee who worked on the first-gen thermostat I can tell you definitively that you're way off base here. That doesn't mean that Google shouldn't have done more to keep these units alive (and indeed that's one of the reasons I left Google). But these devices were designed in 2010-11. Even keeping the Linux kernel up to date with the latest version is a major undertaking. Adding major functionality like Matter compatibility, or even a simple (but secure!) local API, would take a seasoned engineering team a considerable amount of time.

That said, investing in devices that are local first is certainly good advice, provided the APIs are open and well supported.

View on HN

Recent extreme frustration with Google products in mind, I'm tempted to read the crux of this post as, "Google engineers/designers are incompetent." It might be unfair, but on a day when Google Search, Youtube History Search, and (whaddya know) my Nest Thermostat have all failed me, the temptation is strong.

I think the reality is that the engineers are competent but this was just not a priority they were given and they were not going to spend nights making this happen instead of hanging out with their kids.

They might even have gotten in trouble if they had rolled out an update that product management didn't ask for and is perceived to reduce incentive to upgrade to a new device

> Recent extreme frustration with Google products in mind, I'm tempted to read the crux of this post as, "Google engineers/designers are incompetent."

Engineers don’t make business decisions on when to end support, that’s a management decision; engineers ideally ought to be consulted on what it would take to continue support, but even that isn’t guaranteed. If planned obsolescence has been a business strategy, literally having an obsolescence switch and pulling the trigger on it has to be tempting to certain decision-makers even when support would be practical.

I am bit confused by this post.

Let me turn it around. Imagine that you are a Google engineer who worked on Search, YouTube, or Nest. How would you feel reading your own post? You would probably vehemently disagree! I'm not sure your sentiment is relative in 2025. Everyone on HN knows that any "web scale" public product (with billions of users) 100s of engineers behind it. And, it takes very good ones to keep them running and continuously improve them.

Thus, in response to:

    > It might be unfair

I say: Yes, it is unfair and unnecessary to post. It adds very little to the wider discussion.

If I’m a Google engineer, what motivation do I have to make decisions that keep a device running for a decade?

Even more pertinent, when it gets time to go through the promo process and when I need to prove “impact” and make sure what I’m doing is aligned with the department wide OKRs, why would I want to be on a project supporting old legacy tech that I can’t spin to show how it helped the company’s revenue?

I’ve never worked for Google. But incentives based on the promo culture is endemic to all of BigTech.

And even worse, every company is focused on “AI” these days. If you aren’t part of an initiative that can be said to be AI adjacent, if you care about your career and comp, you shouldn’t touch it with a 10 foot pole.

https://www.warp.dev/blog/problems-with-promotion-oriented-c...

https://news.ycombinator.com/item?id=31261488

I would expect a thermostat to last 15+ years across multiple home owners - it should be an improvement over a mechanical one, after all. If that's not adding to Google's bottom line, they shouldn't have "disrupted" that market in the first place.

https://killedbygoogle.com/

> If I’m a Google engineer, what motivation do I have to make decisions that keep a device running for a decade?

Empathy and being a good human being in relation to society. Making devices that look good at first and cause pain later, when it's too late to do anything about it... is bad.

> I need to prove “impact” and make sure what I’m doing is aligned with the department wide OKRs

Fair, and that's a reason to _not_ put in the effort to make longer lasting devices.

> But incentives based on the promo culture is endemic to all of BigTech

And we should be calling them out for it. It's bad in the same way that forced ranking systems are bad; they promote the wrong things.

Say the employee did want to work on the product in spite of it not being in their best interest. How are they going to get the buy in and the team to make the change and the support to get it pushed to devices in the field?

And no one works for a privacy invading ad tech company because they want to make the world a better place. It’s purely about making a shit ton of money.

> And we should be calling them out for it. It's bad in the same way that forced ranking systems are bad; they promote the wrong things.

Despite the newest LP about being the best employer, Amazon has been the shittiest of the BigTech employer as long as I can remember. Their reputation hasn’t changed anything about their profitability or stock price.

Before you ask if I knew that, why did I work there. I was 46 at the time, it was my 8th job out of 10 and it was purely remote and a “field by design role” that was remote until a year after I left. It was purely a money and resume play.

Security is always the excuse, but it's a local device connected to Wifi. Add a setting to the existing menus that is opt in to turn on the new API.

Beyond that, there's what, like 4 or 5 parameters that are useful to set, and a few that can be read. It wouldn't be necessary to over engineer the API, even a few simple, fixed TCP packets to query state and set the basic parameters like mode, fan, room and set temp would be all that is needed. It can be ugly and basic, just release the info and other devs would run with it.

For example, the older TPLink Kasa line of smart devices have a simple TCP packet protocol for local control. The 'security' was easily reverse engineered (simple key autokey cipher), but there wasn't any outrage. Their simple scheme that wasn't meant to be widely known meant it was possible for others to build the integrations.

https://www.softscheck.com/en/blog/tp-link-reverse-engineeri...

"Even keeping the Linux kernel up to date with the latest version is a major undertaking."

To me this sounds always backward. We make a choice of tools, and now we can't support you longer, and blame it on the tools. It's like "I need a car because I've moved out of the city center." Yes, of course you need a car, but because of your choices and actions.

If you prioritize easier development over long term support when choosing tools, then this is what you get.

Of course it's ok and valid to make that tradeoff, but then don't blame it on the tools, but on your choices.

Nest made an implicit choice of tools back around 2010 when it selected the particular SoC that powers the early thermostat. Options were more limited then, and vendors often provides kernel tools and libraries that included proprietary closed-source components. Over the years most of these tools have been abandoned or EOLed by their providers (as companies will do). Keeping these tools working and building new releases of software in the context of a modern build environment is a full time jobs itself, especially in the context of Google with its highly idiosyncratic internal processes.

While I was at Google I complained bitterly about the repeated killing Nest products. But there was no way I had the bandwidth (or the permission) to serve as the sole lifesaver for any of them.

> a simple (but secure!) local API

A bit of an unusual idea, but: if the users of such a thing are folks who're already playing with HA and are tech savvy, why not just expose the API and tell users that they're "only allowed to use the "hacker's update in good faith" if they put the devices on a separate network without internet access?

Your team doesn't need to spend a ton of time on making it super secure, and DIYers can continue to use the hardware for as long as it physically works, me thinks

Liability.

Isn't this exactly what the mountain of liability waivers already included in the ToS are for?

Not a lawyer, but liability waivers may not apply if there is determined to be gross negligence or recklessness.

Making a reasonably-designed API available, only if connected to an inaccessible network, doesn't sound dangerous, but the goodwill gained might be hard to weigh against a miniscule chance of malware, which would revise everyone's opinion of the degree of negligence or recklessness.

First, thank you for posting. Insiders can provide unique persepectives.

    > Even keeping the Linux kernel up to date with the latest version is a major undertaking.

Dumb question: Why does an old Nest need an updated Linux kernel?

    > investing in devices that are local first is certainly good advice, provided the APIs are open and well supported.

Do you have any examples that could sufficiently replace old Nests?

"Why does an old Nest need an updated Linux kernel?"

Old versions that no longer receive security updates is a major issue

For general purpose computing - yes.

For a thermostat, with presumably an attack surface that could be made arbitrarily small (albeit by removing non essential features) -why?

Surely this means all embedded devices are a serious liability?

I'd be worried about any internet-connected IOT device in my home. It the very least it can snoop on traffic. The Nest in particular could a) use it's motion detector to report if you are home b) harass you through temperature changes (and maybe even gaslight you by not showing them) c) maybe overload something (itself?) and cause fire?

That's just what I can come up with sitting here and having no in-depth knowledge. I am sure actual security experts could come up with more scenarios.

Absolutely nothing is stopping Google from keeping all the integrations working until the thermostats physically break. No one asked for a new kernel and whatnot.

Is keeping alive the infrastructure that servers the 1st and 2nd generation devices online and just proxy the communication between the old features and new features available in HomeKit and other smart home hub apps such as big undertaking that Google balked at it?

Okay, but isn’t this really about, why should Google spend money making things work better for iPhone users? It doesn’t like doing that. That’s what Matter support is really about. It’s always been about Apple Home.

And before you accuse me of being “way off base” lemme ask you: why doesn’t Gmail support push for iOS Mail anymore?

Reply on news.ycombinator.com