> stable hw/driver api (this is a huge mistake in linux, agreed)
Not to get into a flamewar over this, but there are real benefits to Linux's rolling driver ABI (the "API", however, is mostly stable, contrary to what you say). It encourages mainline collaboration, and greatly improves the quality and compactness of the drivers.
On Windows (and to some extent macOS), you'll find whole classes of driver where each driver has its own proprietary internal implementation of something that should have been in the API and ABI, but is not (or just was not when the driver was written). Linux has great, up to date drivers for the vast majority of devices you'd want to use†, and all of the best ones are built (compactly!) right in to the kernel, so it is more or less moot at this point whether a stable ABI is a good thing (at worst, it didn't matter in the long run; at best, it made the system better).
The level of integration and standardization in the Linux kernel is spectacular, and absolutely would not have been achieved if vendors were empowered to link ABI-compatible binary blobs into end user kernels. There is tremendous value in the fact that I can manage, consistently, every LED, every DVFS controller, every fan controller, every GPIO pin, etc. on each supported system in a consistent fashion. Left to their own devices, each vendor would use their pet interface (as seen with NVIDIA putting their foot down and demanding EGL surfaces be used with their driver on Wayland, despite the fact that no standard software supports it); NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no.
† Outside of the Android ecosystem, which, through what could maybe be called poor stewardship on the part of Google, inexplicably refuses to develop against the mainline kernel, so is constantly fighting to maintain literally thousands of vendor-, OEM-, model-, SKU-, country-, and carrier-specific kernel trees for absolutely no recognizable benefit, and against the clearest and most consistent advice of the highest experts on the subject.
The Linux model definitely encourages mainline collaboration. It just happens that the Android vendors are fighing against this encouragement, and Google has caved in to their demands.
> Compared to what?
Compared to what happens on Windows and Android, where individual drivers have to reimplement common functionality, often in inconsistent ways.
> Which no user has ever cared about.
Users care that their drivers work and that they continue to be supported in the future. Less compact code is larger, and therefore buggier. Drivers which are provided as proprietary userspace blobs are invariably unmaintained and stop working with future kernel versions.
> Third-party firmware like CyanogenMod exists only because in-kernel GPL parts can be ported to new OS versions.
With Fuchisa there won't be anything like CyanogenMod anymore.
I think you're confused. If the interface for the drivers stays stable, then you can just carry over the same exact binary blob and it will keep working perfectly, which is exactly what Microsoft does. Windows 7 drivers still work just fine in Windows 10.
Android devices not running mainline kernels is a direct result of the Linux development process.
If an Android device launches with a new CPU or device, the OEM has to go through the process of up-streaming the changes to mainline before they can launch their phone? not going to happen.
> Device vendors don't update already sold devices because they don't care (and because average consumer also does not care).
You should consider why the hardware vendors are in the critical path for OS updates in the first place. Dell doesn't get to decide whether you can apply Windows updates.
Turning that notion on its head, Pinephone could be one to watch.
They more or less intend to supply the hardware only. This avoids the pretence of vendor updates entirely, by both the company (Pine64) and the ARM licensee (Allwinner).
The software stack is up to you, with mainline Linux support courtesy of the A64 [0] powering a number of 'RPi-killer' boards. Device updates will be supplied by the likes of Ubuntu Touch, LineageOS, postMarketOS et alia mobile distributions.
> Turning that notion on its head, Pinephone could be one to watch.
Maybe. Except that for me (and I know I'm not alone) the second most important part of my pocket computer after web searching is the camera, and they're unlikely to have anything great in there.
i think in the end, this whole divide boils down to a divide in philosophy between free software and corporations that support “open source” but don’t want it free (as in gpl)
thereby we get the constant tension between google and hardware makers that want to keep their jewels secret, and the linux/foss community that wants to keep their freedom to install their (open) software on any device... by keeping the drivers in with the kernel, linux can foster that end, but it causes no end of frustration to google et al...
i think that’s probably the reason we get fuchsia: google can be open source, and with the hw makers, keep the proprietary parts proprietary... the result being, we have open kernel and os bits but no guarantee (or much hope at least) we could ever run it on our devices...
i think that’s the biggest cultural divide: freedom to change and replace the software vs freedom to look at the code (and maybe run it in an emulator...
There's a whole class of devices that will never be in linux mainline kernel - experimental filesystems(remember those years wher FUSE was a patch?), propietary hardware(embedded devices), kernel bypass hardware(onload), security hardening mechanisms(remember PaX?), commercial software who basically sell the driver(intel studio profiler).
All this breaks every time linux releases a major rewrite. If the vendor is out of business or no longer interested in a product - you are left with the drivers that do not work.
Moreover - in a case of major api breakage - its kernel contrubutors who are left with re-writing every driver for a new api, delaying the kernel releases.
Windows doesn't even have a standard driver-ABI anyway - if it did, we wouldn't have hardware losing driver support when switching the system to a different Windows version (XP/Vista/7/8+/10).
> Windows doesn't even have a standard driver-ABI anyway
It does to a very significant degree. Windows 7 drivers from 10 years ago still work today with Windows 10. Windows 95 user software from 23 years ago will still work today in Windows 10. Microsoft cares strongly about maintaining compatibility and only removes functionality when necessary.
Not to get into a flamewar over this, but there are real benefits to Linux's rolling driver ABI (the "API", however, is mostly stable, contrary to what you say). It encourages mainline collaboration, and greatly improves the quality and compactness of the drivers.
On Windows (and to some extent macOS), you'll find whole classes of driver where each driver has its own proprietary internal implementation of something that should have been in the API and ABI, but is not (or just was not when the driver was written). Linux has great, up to date drivers for the vast majority of devices you'd want to use†, and all of the best ones are built (compactly!) right in to the kernel, so it is more or less moot at this point whether a stable ABI is a good thing (at worst, it didn't matter in the long run; at best, it made the system better).
The level of integration and standardization in the Linux kernel is spectacular, and absolutely would not have been achieved if vendors were empowered to link ABI-compatible binary blobs into end user kernels. There is tremendous value in the fact that I can manage, consistently, every LED, every DVFS controller, every fan controller, every GPIO pin, etc. on each supported system in a consistent fashion. Left to their own devices, each vendor would use their pet interface (as seen with NVIDIA putting their foot down and demanding EGL surfaces be used with their driver on Wayland, despite the fact that no standard software supports it); NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no.
† Outside of the Android ecosystem, which, through what could maybe be called poor stewardship on the part of Google, inexplicably refuses to develop against the mainline kernel, so is constantly fighting to maintain literally thousands of vendor-, OEM-, model-, SKU-, country-, and carrier-specific kernel trees for absolutely no recognizable benefit, and against the clearest and most consistent advice of the highest experts on the subject.