In terms of impact or business case, I'm missing what the end goal for the company or execs involved is. It's not re-writing user-space components of AOSP, because that's all Java or Kotlin. Maybe it's a super-longterm super-expensive effort to replace Linux underlying Android with Fuchia? Or for ChromeOS? Again, seems like a weird motivation to justify such a huge investment in both the team building it and a later migration effort to use it. But what else?
Many things that google did when I was there was simply to have a hedge, if the time/opportunity arose, against other technologies. For example they kept trying to pitch non-Intel hardware, at least partly so they could have more negotiation leverage over Intel. It's amazing how much wasted effort they have created following bad ideas.
They seemed to have unlimited headcount to go rewrite the entire world to put on display assistant devices that had already shipped and succeeded with an existing software stack that Google then refused to evolve or maintain.
Fuchsia itself and the people who started it? Pretty nifty and smart. Fuchsia the project inside Google? Fuck.
> the idea was to come up with a kernel that had a stable interface so that vendors could update their hardware more easily
maybe long-term not viable i guess...?
Also note that swapping the core of a widely used comercial OS like AOSP would be no easy feat. Imagine trying to convince OEMs, writing drivers practically from scratch for all the devices (based on a different paradigm), the bugs due to incompatibility, etc.
(IIUC, it's brand new?)
If your team is too large, and especially if you don't know what the use case is, it can take a very long time. You asked for general purpose and fully capable, so you're probably in this case, but I think the desired use cases for Fuchsia could be scoped to way less than general purpose and fully capable: a ChromeOS replacement needs only to run Chrome (which isn't easy, but...), and an Android replacement needs only to run Android apps (again, not easy), and the embedded devices only run applications authored by Google with probably a much smaller scope.
But it also depends on what 'from scratch' means. Will you lean on existing development tools, hosted on an existing OS? Will you borrow libraries where the scope and license are appropriate? Are you going to build your own bootloader or use an existing one?
The answer is not much time. The real question is how long to develop good quality drivers for a give platform (say, an x64 laptop)? How long to port/develop applications so that the OS is useful? How long to convince OEMs, app developers and such folks to start using your brand new OS? It's a bootstrap problem.
That would be surprising. Where do you get that? I don't mean toy OSes or experiments. Linux, MacOS and Windows are still in development and I can't imagine the number of hours invested.
> they use existing libraries and the like
Where can I find out about that? Thanks.