Fuchsia's driver handling is superior to what you get with linux. Because pretty much everything is pushed into userspace it makes it dead simple to keep a driver going forever.

Were I to guess, the prime motivation for Fuchsia would be to have a phone or IoT device which could regularly receive kernel updates without needing hardware vendor interaction. That's the biggest sore spot for linux. (not that I think Fuchsia's kernel would require a bunch of updates due to how simple it is).

This is an outsider's perspective. Definitely a big expensive project that reminds me of other big expensive google projects which seem DoA.

> Fuchsia's driver handling is superior to what you get with linux. Because pretty much everything is pushed into userspace it makes it dead simple to keep a driver going forever.

How does the lack of hardware vendor cooperation get improved by moving the problem into userspace?

You still need/want the hardware vendors to create drivers and update them, which they frequently don't.

I guess it's better because you're just going to be content with binary blobs?

Yes, that's exactly the point: unlike Linux, and like Windows, Fuchsia defines binary interface for drivers. As long as new releases of Fuchsia keep supporting the old interface, old driver blobs will keep working.

It's common to conflate the idea of source availability with problems encountered by lack of binary stable interfaces. One of the problems with the status quo on Linux isn't that drivers aren't released as source, but that they aren't upstreamed. This causes the drivers to no longer be valid very quickly. If you solve the validity problem, folks can continue to release drivers, alongside their source and they will continue to be valid even as the rest of the operating system evolves. Just because Windows drivers tend to not have source available doesn't mean that it's a given the same will be true for fuchsia drivers. It is ultimately product makers who use fuchsia as a platform who drive the incentives for what driver authors do with their drivers.

I don't think it will DoA. They shipped it on Nest Hub, and I'm sure they'll find other places to put it now.

And yeah I think you're pretty on about the driver/vendor comment.

>Security model is better.

From the outside looking in I thought the security model could really help Google lower splash radius from zero days? The feature-set certainly sounds appealing just reading the marketing blurb. [1]

With any luck in the next iteration Google will create a Fuschia ISO or VMDK so people who want to give it a spin without building it can quickly get a taste of the environment. The fact you can at least run it in an emulator is definitely a step up from requiring dedicated hardware, which was the previous process. [2]

[1] https://fuchsia.dev/fuchsia-src/concepts/principles/secure [2] https://fuchsia.dev/fuchsia-src/development/hardware/paving

I believe Google can make a system that is secure from outside adversaries, but I'm less trusting that they would make an OS that isn't riddled with hooks for Google surveillance.

Certainly. Sad thing is how many won't make the switch. I'm not judging, I'd do the same prolly due to pressures(ease of use, bandwagon, specific pain point fixes vs Linux)

> The drivers situation for embedded Linux SoCs is awful. Fuchsia aims to fix that.

How can they solve that with software? It's an incentive/economic problem. Hardware vendors don't want to play nice, there's no incentive for them. It's better if they're jerks and never release their stuff or do it years after their hardware stops being relevant.