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