Google has actually started extending its security update policy for its hardware to 5 years. I don't know what "enough" is, but as someone who has to do these updates (ironically, for Fitbit devices, yes we are owned by Google now) I will say that continuing to ship updates for products you shipped 5 years ago is far from trivial. It forces you to develop in ways that are not natural for people that work with hardware (the natural thing is to branch per product, but good luck managing that if you need to land a security fix on the 15 or so products we shipped in the last 5 years). This is manageable now that we're owned by Google, but prior to the acquisition it was a serious drain on my team. And folks on my team would tell you that they don't love it even today -- having to support 5-yr old MCUs when you're trying to keep your BOM down can be very challenging, especially managing available memory.
Yeah, a pure service model would be lovely in many ways. If I ever start a company that makes HW (fat chance) my experience at Fitbit means it will certainly be service-based.
Thanks for contributing first-hand experience. Your story highlights how dysfunctional historical hardware dev practices are for the connected age. Forking for each product absolutely does not scale in an era of continual updates, and manufacturers that don't figure this out are not gonna make it. People don't forget having to discard working hardware because of some stupid software EOL.
The memory limits of old devices is a real problem, and I don't know the solution besides doing the hard work to fight the the bloat, and produce a modular solution. Apple pretends to support the Apple Watch 3, but you can not upgrade the os without a hard-reset every time because the local flash can't hold the update and user config at the same time. But I can't help wonder if they _really_ need multiple GB for the core OS in a watch.
Heh. Not going to comment on Apple Watch for obvious reasons, but I will say that we measure free memory in 10s or 100s of bytes on most of our older products. Even a single GB would be amazing, but also amazingly expensive.
Google has generally supported Chromebooks for about 6 years and just recently seem to have started extending that duration to about 8 years. Some recent Chromebook launches have support through 2029.
If Google can do this for Chromebooks, most of which aren't even designed by Google (although usually based off reference designs), clearly they can also do this for the actual phones they make and sell under the Pixel brand. And Chromebooks span quite a wide variety of hardware capabilities, from school-targeted low cost models with eMMC and <4GB RAM all the way up to devices with NVMe and gobs of RAM on cutting edge CPUs from a variety of manufacturers, both ARM and x86.
Chrome OS is proprietary (Chromium OS is not) and it also cannot be modified by any manufacturer. Every chromebook manufactured also is developed with Google being aware so that the chipset and underlying hardware can be supported. It's quite a different licensing model than Android and that's most likely why giving eight years of updates was much easier.
Sure, but Google has all the source code and all the design files for their Pixel phones. I'm not saying Google needs to support ALL Android devices, just Pixel devices. It is definitely possible for them to support Pixel phones for more than 5 years if they wanted to. It's just an economics question of if it's worth it to Google to do so and clearly it hasn't been.
Even 5 year support for Pixel phones is new with the Pixel 6 line. Previously it had been 3 years max.
But they really don't have all the sources. Up until Pixel 6, they've all used Qualcomm chipsets.
Qualcomm is such a ridiculously horrible company to deal with. They're in the business of selling new SoC designs every 6 months and trying to support a device for more than a few years is considered a massive opportunity cost for them.
It's the same concept as Apple mulching old MacBooks so they don't enter the used market except killing them by lack of software support instead.
They have an absolute stranglehold over the SoC market in the US. Samsung made a stupid deal back in the 90's to license CDMA patents in exchange for not selling SoCs (eventually Exynos) in the US or to any other manufacturer for that matter. At the time it probably made sense because Qualcomm agreed to use Samsung to manufacture their chips, but the deal is so hilarious lopsided these days. 30 years on and Qualcomm still won't renegotiate. It might've drawn regulatory ire if Samsung wasn't a foreign company.
I imagine there's a major attitude difference in the support model for SoCs made for Chromebooks and laptops compared to the ones for smartphones. Smartphones on average are kept for barely over two years in the US, whereas people hang onto a laptop for nearly 5 years.
People are used to desktops and laptops chugging along until they get tired of them being slow, rather than their device or OS vendor cutting them off.
> It forces you to develop in ways that are not natural for people that work with hardware (the natural thing is to branch per product...)
The problem rather seems to be that close-to-hardware developers are unwilling to adapt to modern software development practices: modularity (i.e. drivers and sane HAL), automated (regression) testing and, at least for some cases, even using version control.
Since the market hasn't managed to achieve that, the government needs to step in and mandate stuff like repairability, longevity and update support - then there won't be any other choice than to drag the industry by its ears into the 21st century.
> having to support 5-yr old MCUs when you're trying to keep your BOM down can be very challenging, especially managing available memory.
And again, the answer is government regulation: when the tradeoff between extra cost on the BOM vs ability to update shifts towards extra cost for an actual Linux-capable CPU, you won't have that problem any more.
You seem to saying a lot of things here rather declaratively. I will speak to my experience only, but we have used version control, drivers, various HALs, and automated testing (plus some manual, this is HW after all and some end to end tests are simply not worth automating) throughout my time here. So those things have not been holding us back.
With respect to government regulation, every dollar on the BOM is $2-3 to the customer. Many of our competitors are not based in the US. When buying memory you’re probably competing for supply against large car companies who have longer contracts with more committed volume. These are just facts, but they affect what the solution space here looks like.
Not your responsibility I know but given that Google can't seem to be able to notify everyone who is impacted by their GSuite changes I do worry about the path they seem to be going down. To me it seems that very simple things are falling by the wayside more and more these days which doesn't bode well for the future.
I don't know much about Fuschia. I'd be surprised, though, if updatability wasn't a major concern. Part of why I don't know much about it, though, is that AFAIK it's 64-bit only, and the MCUs we run are 32-bit affairs.
Unfortunately not with such a broad statement. Our CS team is usually abreast of issues with products that are in market and keeps me and others in the loop when there’s something we need to fix from an engineering side.
Within the last couple of weeks, people have been having issues with syncing, time being accurate, and sleep tracking. Seems like it is tied to a forced update of some sort.
I haven’t heard about that. I’ll reach out to CS and see what’s up. We haven’t made any forced updates that I know of (and I should know). That said phone updates do sometimes break or lower the reliability of our Bluetooth connection, and radio updates are sadly forced on people’s phones all the time.
