4 ms·

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 devic

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 6y ago
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 6y ago
  > 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 6y ago
    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.
ryukafalz 6y ago
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.
woofie11 6y ago
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.

jeffbee 6y ago

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 6y ago
> 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 6y ago
  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.

ryukafalz 6y ago

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.

woofie11 6y ago

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.