This is an important point because it conflicts the doom and gloom claim that something like Fuchsia is just a temporary transition technology that will then dump the compatibility.
You can't just dump the compatibility and remain relevant.
If Google deploys Fuchsia on mobile devices, and then morphs it into something that isn't Linux compatible, it just won't be relevant; it's basically a step of retreating into a niche.
Various pieces of middleware won't work on it; I don't think Google wants that.
> It's the kernelspace drivers that will entrench Linux for a long while
You might think, but it is 100% clear? Drivers can be ported to a different system. There are out of tree drivers out there that use #ifdefs to be compatible across kernel versions due to upstream changes. Drivers can be separated into the payload parts, and the Linux glue, and then that glue can be retargetted.
Nobody wants to do that though if they can just use Linux right?
However, the arguments of Linux accumulating code and becoming less and less maintainable could precipitate into situations where alternatives spring up which take what they want or need out of Linux, without all the other crud.
> Kinda surprised he didn't mention WSL
I was thinking the exact same thing when he brought up Fuchsia, but I think he had a point there. Not a lot of us have heard of Fuchsia. WSL is not a threat to anything because it already runs under Windows. It's not poised to take a huge number of devices famously based on the Linux kernel, and take Linux out of the picture. WSL isn't a transition off Linux and could never be; nobody is looking to transition to Windows via WSL. WSL has little room to break Linux compatibility.
Imagine that, say, ten years from now, no Android, Chrome OS or Google TV or whatever device is built on Linux any more. The kernel is Fuchsia or whatever; there is a C library that is the same old Bionic or a derivative. That will be a blow to Linux.
> If Google deploys Fuchsia on mobile devices, and then morphs it into something that isn't Linux compatible, it just won't be relevant; it's basically a step of retreating into a niche.
Android developers don't care about Linux, it isn't part of the official APIs, unless you are an OEM doing your own drivers and AOSP customization.
As long as Fuchsia runs ART (which they are already porting), and the official NDK APIs, Android users will barely notice it is another OS running on their new phone.
> Nobody wants to do that though if they can just use Linux right?
That's kind of what I'm getting at, yeah. Sure, you could port a bunch of drivers to some new kernel and driver API, but even out-of-tree (let alone in-tree) drivers don't necessarily lend themselves to that, and the comprehensive collection of in-tree drivers makes that a hard sell.
> However, the arguments of Linux accumulating code and becoming less and less maintainable could precipitate into situations where alternatives spring up which take what they want or need out of Linux, without all the other crud.
Definitely seems like a possibility, though (to my knowledge at least) it doesn't seem like there are any projects going in that direction - I suspect because of the relative instability of the driver API (let alone the absolutely-not-stable-whatsoever ABI) and the more intertwined nature of kernelspace code compared to the userspace ABI/API.
This is an important point because it conflicts the doom and gloom claim that something like Fuchsia is just a temporary transition technology that will then dump the compatibility.
You can't just dump the compatibility and remain relevant.
If Google deploys Fuchsia on mobile devices, and then morphs it into something that isn't Linux compatible, it just won't be relevant; it's basically a step of retreating into a niche.
Various pieces of middleware won't work on it; I don't think Google wants that.
> It's the kernelspace drivers that will entrench Linux for a long while
You might think, but it is 100% clear? Drivers can be ported to a different system. There are out of tree drivers out there that use #ifdefs to be compatible across kernel versions due to upstream changes. Drivers can be separated into the payload parts, and the Linux glue, and then that glue can be retargetted.
Nobody wants to do that though if they can just use Linux right?
However, the arguments of Linux accumulating code and becoming less and less maintainable could precipitate into situations where alternatives spring up which take what they want or need out of Linux, without all the other crud.
> Kinda surprised he didn't mention WSL
I was thinking the exact same thing when he brought up Fuchsia, but I think he had a point there. Not a lot of us have heard of Fuchsia. WSL is not a threat to anything because it already runs under Windows. It's not poised to take a huge number of devices famously based on the Linux kernel, and take Linux out of the picture. WSL isn't a transition off Linux and could never be; nobody is looking to transition to Windows via WSL. WSL has little room to break Linux compatibility.
Imagine that, say, ten years from now, no Android, Chrome OS or Google TV or whatever device is built on Linux any more. The kernel is Fuchsia or whatever; there is a C library that is the same old Bionic or a derivative. That will be a blow to Linux.