Hacker News new | ask | show | jobs
by jeffbee 2117 days ago
> Planned obsolescence for most Google devices (Chromebooks

Google has only EOLd two Chromebooks ever, the Cr-48 that was supported from 2010-2015 and the Pixel, from 2013-2018. The current model is guaranteed to get updates through 2026. What's wrong with this?

3 comments

The main issue is that it's a huge step backwards from PCs to treat laptops like phones that require model-specific updates. There are tons of Chromebook models that Google has abandoned, just not ones they themselves manufactured. The list is here: https://support.google.com/chrome/a/answer/6220366?hl=en

And yes, it's Google's choice to kill these, not OEMs: Chromebooks are built according to certain platform specifications Google hands down, upon which they then support for a given amount of time. So claiming Google has only dropped updates for two Chromebooks ever, ignoring all of the third party manufactured ones, is dishonest.

Meanwhile, Windows, Linux, and macOS machines generally can run the latest version long past when the manufacturer supports it heavily. (Less true with Apple, but Apple's lifecycle is insanely long anyways.) You can actually take machines built to run Windows XP and install the latest release of Windows 10 on many of them. (It sometimes even runs decently too, if you use an SSD!)

Ironically, you can run the latest version of Chrome, via Windows 10, on PCs built for XP, but plenty of Chromebooks sold since then can't.

Additionally, Google has, like phones, positioned Chromebooks as disposable computing devices. $200-300 price point devices that you'll end up replacing in two or three years. Which is a massive e-waste problem, particularly given Google's push to get schools to force every student to buy/use them. For a supposedly green company, the entire Chromebook initiative should be seen as an embarrassing gap in good stewardship.

Note that this entire subthread is pretty off-topic to the original article though.

The underlying problem is Linux's driver model. To support new features, you have to support a new kernel. To support a new kernel, you have to port the device drivers to that kernel. Vendors don't like to maintain their code and changes in the kernel often break drivers, so vendors often just give up. That is basically the end of life for anyone that chooses hardware with bad drivers, which I guess some OEM Chromebook manufacturers did.

I did a 20% project on Chrome OS when I worked at Google. At the time, I happened to use a Wacom tablet as a mouse and Chrome OS as my primary OS, and so I backported all the upstream Wacom drivers to the various kernels used by the variety of Chrome OS devices. It was a ton of work, and I really only did it because I needed it myself and there was one really nice person on the bug tracker who supported the tablets at his school. But it doesn't scale -- this was the easiest and most trivial porting job imaginable, and it took me several hours each patch; not because applying the patch was hard, but because validating that it worked as expected took a long time. It was a 15 minute build per device, then I had to reflash, then I had to try all the Wacom devices I had laying around. Now imagine doing that with WiFi -- where your laptop has to work with hundreds of craptastic access points. It's a multi-week effort for every (device, patch) combination.

I don't work there anymore so I have no idea what the official policy is... but understand that it's, to some extent, the OEM's problem. They choose a WiFi chipset that breaks every kernel upgrade, and only they use it -- that's their validation to do. If they don't want to do it anymore they say "hey we saved three cents on the WiFi chipset, now throw away your laptop."

As to why this doesn't affect Windows... Microsoft has spent years building in compatibility for binary blob drivers. On my fresh install of Windows 10 I have drivers from 2008 that are running (for my USB webcam, sadly). The code hasn't changed, so they don't have to revalidate it. It just works, forever. But with Linux there is no such option; you have to make your code compile against the latest kernel, or your device stops working. Hardware vendors (and OEMs) are very lazy, and you can see that in action -- Android and Chrome OS devices stop getting updates because nobody will maintain the code. This, I suppose, is the cost of building atop a GPL-based operating system. Hardware is "design once and forget". Linux is "evolve and grow forever". The impedance mismatch between hardware vendors and software engineers leads to a bad user experience.

I don't think the Windows model is all that great either. Windows 10 flat out refuses to install on an Intel NUC, which is about the most bog-standard "WinTel" machine you could imagine. Windows appears to work because vendors are motivated to integrate their drivers properly, and because running privileged driver installers from fly-by-night software vendors is socially acceptable in the Windows community.
> Windows 10 flat out refuses to install on an Intel NUC

I am really curious about this claim, because I've installed Windows 10 on multiple Intel NUCs without any sort of issues. They've very well supported.

The only particular peeve I know of is that you can't install Windows Server 2016/2019 on an Intel NUC and use it's built-in Ethernet port, because Intel decided to disable allowing drivers for "consumer" Ethernet chips (like the one in most NUCs) to install on a server OS.

On mine it just whines that there's no mass storage device. The stack overflow responses to this problem indicate that the trick it to pull out the usb install media at just the right moment, and then return it to a different port at just the right moment. I think this advice perfectly clarifies the claim the Windows "just works" on any randomly selected PC of the last fifteen years.
I guess I've never had that problem on my Linux desktop. I've had it for around a quarter-century now. There's a philosophical question whether it's the same desktop, since it has none of the original parts. I guess I've reinstalled the OS too, probably twice in the time.

I'm sorry, but the problem here is Google. You're looking at this at a 10 foot engineer's view. I'm looking at this at a 10,000 foot view. Google has all the power in the world in this ecosystem. If it requires you to use one particular type of hardware... it can do that. If it requires you to open source all drivers... it can do that too. If it requires 20 years of support... that's within it's power.

And if it was a Linux problem, you couldn't get around it by installing Linux on some of the now-deprecated devices; I've seen people do that too. So Google doesn't just break the devices that are no longer supported. It's 100% planned.

Remember that Google has to convince OEMs to get behind their experimental free OS instead of Windows. They can't say "hey, you can have the OS for free, but now you need to keep specialty embedded engineers on staff until we say it's okay to stop maintaining drivers, which will be never" when Microsoft will probably happily negotiate down the cost of a Windows license to near $0 and pick up the driver maintenance as well.

The question then is, why bother with OEMs? But it's necessary to drive adoption: nobody wants to get fired over their choice of laptop vendor, and nobody ever got fired for picking Dell / HP / Samsung. But if you pick the weird upstart OS and anything goes wrong, you'll be blamed. So the OEMs exist to attach their credentials to the transaction -- "we'll be happy to sell you whatever laptops you want; you can have our Windows laptops for $2000 each or Chromebooks for $200 each". Now you at least have some excuse if things go bad -- "HP misled me! But we saved $1800 per student" or whatever.

When taking on a huge established incumbent, price and technical merits are not enough, and you can't go it alone. I don't think I'm looking at things from a "10 foot engineer's view" when I say that it will be very difficult to take on a company with 80% market share and 40 years of industry experience with your new Linux thingie. The OEMs are crucial there -- they have sales contacts, they have a brand that people trust, and people need to gradually warm up to the fact that there's a new OS in town that might save them some money. The cost there is that OEMs don't always do everything you want -- they have their own business to run and don't really need you to stay alive.

> Remember that Google has to convince OEMs to get behind their experimental free OS instead of Windows.

I think this argument held for the first year or two of Android, where they were a small player in the market.

...It simply doesn't hold today, where Google is a monopoly in mobile and one of the largest platforms in the education laptop space. OEMs live or die on Google working with them. Sales reps from major PC OEMs try to convince me to buy Chromebooks when I call them about Windows machines I need to buy.

There's no realistic claim today that Google doesn't have the clout or leverage to ensure their OS is supported properly. It's a choice.

People complain when google does what you are proposing too. Just look at how many people are aggravated about updating their apps to new android sdk versions, for example.
This isn't a problem if you get your drivers upstreamed into mainline Linux, right? My understanding is the kernel community keeps in-tree drivers up to date as the kernel APIs change, and that's why I can install a modern version of Linux on just about any of the x86 machines I have lying around and expect (most of) the hardware to just work.
Go to Google's store:

https://eduproducts.withgoogle.com/products/category/chromeb...

Every Chromebook has a nicely listed expiration date. Past that date, security updates stop. At least in contrast to Android, they let you know.

I have old expired Chromebooks. They're insecure.

Most shops won't post the expiration date, and plenty of people buy Chromebooks with just a few months life left.

I guess you're only counting Google-branded Chromebooks, because there are plenty of obsolete models listed. https://support.google.com/chrome/a/answer/6220366?hl=en