|
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. |
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.