[jrockway]

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.

[jeffbee]

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.

[ocdtrekkie]

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

[jeffbee]

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.

[woofie11]

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.

[jrockway]

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.

[ocdtrekkie]

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

[UncleMeat]

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.

[ryukafalz]

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.