Security on Android is a joke for 80%+ of users. They can't run on the latest version of Android, because various vendors' drivers are in out-of-tree kernel patches that are un-upstreamable for non-technical reasons.
(By comparison, Chrome OS is also Linux-based, but, IIRC, it requires all shipping devices to have drivers upstreamed.)
Owning an OS with a stable device driver ABI would allow Google to fix the Android fragmentation problem, and make sure all devices stay up-to-date ala Chrome OS.
But it's not just control, is it? Reading this sub-thread I'm not convinced some commenters have actually taken much of a technical look at Fuchsia. I'm not associated with the project but from what I understand there are plenty of technical merits:
1. Zircon, the kernel, is entirely capabilities based. No users, no groups. Those are higher abstractions built on the capabilities system. This is all around a win for security from executing 3rd party drivers to building a sandboxed multi-user system, not to mention is just generally more flexible and less error prone at the kernel boundaries and internally.
2. The WM is scene based. Applications draw to a scene which the WM composites and renders. This means a single draw list is sent to the GPU for each pass instead of many apps spamming their own updates. Also you can do cool things like have objects from one app cast shadows on another app.
3. The kernel API is not a bloated mess and will not become one. Keeping the number of syscalls on the order of 10s not 100s is a design goal. You can see the commitment to this in the way the project is structured. Which brings up:
4. Testability. The project was designed with testability in mind. Not Enterprise Java mock and verify the world shit. Just good practice separation of responsibility between the different layers and enforcement of a sane unidirectional dependency relationship from lower to higher layers. Good luck testing the Linux kernel.
5. The system will update from a single image rather than relying on N parties to pull new patches into their distro and update and test everything N times before releasing to people. Again layers.
This isn't all new by any means, but it's a pretty practical approach to an OS in 2017. This isn't an "academic microkernel", and also decidedly not *nix.
Enough evangelism. Point is, the project is not solely designed to give the big G more control over a platform. Not saying that is not one goal, but technically this thing checks out.
This particular line struck me more than the rest of your (very good) post. For those of us unfamiliar, can you recommend/reference critical resources on the testability of the Linux kernel?
It was my understanding that it was almost completely technical reason, i.e., vendors write drivers that mostly work but are completely terrible from a quality perspective.
Quality problems with code at this magnitude aren't really a technical problem (i.e. not something you can fix by asking the same programmers who created the problems to fix them.) It's rare that good programmers could write code as badly as these patches demonstrate. Even actively-harmful coding standards directed from the top down wouldn't cause this kind of code.
Instead, the kind of code that ends up in these driver blobs is caused by, in essence, a political problem: they simply hired bad programmers. The only way to fix that, is to demand that the driver vendors' management teams adopt higher standards for their software hires: that they fire many of the programmers they have, and hire new ones in a much more stringent process. And probably also pay them more, because that stringent process will likely choke their existing funnel out of existence.
It's much the same as, say, finding that a company is using a low-quality outsourcing firm. Would you say that there's a technical problem inside the outsourcing firm? No, you'd say that there's a management problem in the choice of outsourcing firm.
I don't know if this applies so much at the phone / laptop level, but for embedded devices, the example code / reference drivers are often terrible, but it's not entirely fair to blame the devs. This issue is usually not so much that they're bad programmers and more that they're good electronics engineers who, once the hardware is done, are the only people with the knowledge required to implement the drivers.
I haven't read this yet, but they have docs outlining driver development. Note that it is called a "driver development kit" which may imply it's more stable.
Treble attempts to fix fragmentation by re-standardizing and more loosely coupling between the driver layer and system APIs. We won't know if this is a solution until later and this XKCD[0] kind of explains why.
This is a real time OS from the ground up. Some have SPECULATED it might be run in a VM/container rather than directly on hardware, effectively further standardizing in a similar way to Treble but via a virtual machine's interface instead of a series of system APIs.
That would allow Google to ship Fuchsia VM/container images that could run in every single handset no matter the hardware, and therefore every Android device could be updated directly by Google at the same time.
Meaning Fuchsia may not replace Linux, it might run above Linux and therefore above Treble. That's why the two aren't mutually exclusive.
PS - This is how Microsoft's XBox One platform is engineered currently.
Security on Android is a joke for 80%+ of users. They can't run on the latest version of Android, because various vendors' drivers are in out-of-tree kernel patches that are un-upstreamable for non-technical reasons.
(By comparison, Chrome OS is also Linux-based, but, IIRC, it requires all shipping devices to have drivers upstreamed.)
Owning an OS with a stable device driver ABI would allow Google to fix the Android fragmentation problem, and make sure all devices stay up-to-date ala Chrome OS.