Hacker News Reader

Comment by tmp-fuchsia | Hacker News Reader

I haven’t watched this talk, but I worked on Fuchsia from the start (I’m no longer at Google) and want to clear up some common questions and misconceptions:

1. Fuchsia is a general-purpose operating system built to support Google’s consumer hardware.

2. It’s not designed to compete with or replace Android. Its goal is to replace Linux, which Android is built on. One big challenge it addresses is Linux’s driver problem. If Fuchsia succeeds, Android apps could run on it.

Fuchsia isn’t trying to replace Android. Its survival for over a decade—through layoffs and with hundreds still working on it—says a lot.

I can’t predict Fuchsia’s future, but it’s already running on millions of devices. The git logs show big strides in running Linux programs on Fuchsia without recompilation, as well as progress on the Android runtime. The best way to predict Fuchsia’s future is to look at its hardware architecture support and which runtime is getting attention.

Fuchsia’s success will likely depend more on market forces than on technical innovation. Linux is “good enough” for most needs, and its issues may not justify switching. The choice between sticking with Linux or moving to Fuchsia often favors Linux.

Still, I hope Fuchsia succeeds.

View on HN

I was never that close to the Fuchsia project, but knew quite a few people who worked on it.

My understanding from them was, as much as I can remember it now, something like:

1. That yes, Fuchsia was originally intended, by at least some in senior leadership on the team, to replace both Android and ChromeOS. This is why Fuchsia had a mobile shell (or two?) at one point.

2. The Android team wasn't necessarily on board with this. They took a lot of ideas from Fuchsia and incorporated them into Android instead.

3. When Platforms were consolidated under Hiroshi it brought the Android and Fuchsia teams closer together in a way that didn't look great for Fuchsia. Hiroshi had already been in charge of Android and was presumed to favor it. People were worried that Hiroshi was going to kill Fuchsia.

4. Fuchsia pivoted to Nest devices, and a story of replacing just the kernel of Android, to reduce the conflict with the Android team.

4a. The Android team was correct on point (2) because it's either completely infeasible or completely dumb for Google to launch a separate competitor to Android, with a new ecosystem, starting from scratch.

To work around the ecosystem problem, originally Android apps were going to be run in a Linux VM, but that was bad for battery and performance. Starnix was started to show that Fuchsia could run Linux binaries in a Fuchsia component.

5. Android and ChromeOS are finally merging, and this _might_ mean that Android gets some of the auto-update ability of ChromeOS? Does that make the lower layer more suitable for Nest devices and push Fuchsia out there too?

Again, I was a pretty removed from the project, but it seemed too simplifying to say that Fuchsia either was never intended to replace Android, or always intended to replace Android. It changed over time and management structures.

I worked on Fuchsia engprod for a while. I am still employed at Google and can't talk about anything that isn't publicly available already (which really means anything gleaned from commits to the Git repo).

I think the best way to look at it is like any software: there's Fuchsia The Artifact (thing that is made) and Fuchsia The Product (how thing is used, and how widely). I don't know anything about operating systems, but my understanding is that the engineers are very happy with Fuchsia The Artifact. Fuchsia The Product has had some wandering in the wilderness years.

You got the high drama stories with the timelines re-arranged to fit the narrative :D

Fuchsias underlying goals are to be a great platform for computing. This is distilled in its current incantation into a short tagline on fuchsia.dev: simple, secure, updatable, performant.

The details of how when and where Fuchsia might fit / gets exercised are nuanced and far more often about other factors than those which make great stories. Maybe there will be some of the good stories told one day, but that'll need someone from the team to finish a book and take it through the Google process to publish :D

In the meantime, here's Chris interview: https://9to5google.com/2022/08/30/fuchsia-director-interview...

Look I understand the context here but if you're going to go around saying "a great platform for computing" it's not really telling me much about the project.

It is a OS. Intended to run on mainstream devices.

Main difference to Linux: stable driver API. So vendors could make their blobs and support them easier, without open sourcing, like linux demands.

Stable driver API and open source/GPL'ed drivers are orthogonal.

They are both significant for some companies in deciding whether to support Linux, but they are independent from each other. If Linux ever had a stable driver API, the GPL requirement would still cause some vendors to not provide drivers for Linux. If Linux dropped the GPL requirement (such as it is), but did not promise a stable driver API, some vendors would still choose not to provide drivers for Linux.

fuchsia.dev has literally hundreds of pages of detailed content, I’m not going to rewrite it all in an HN comment

Yes, but clearly there is some middle ground between dumping all of Fuchsia's public documentation and providing the marketing slogan?

Secure: fuchsias kernel is a “practically sized kernel” - many call it a microkernel but it doesn’t take that too far. The kernel retains control over memory allocation, facilitates and enforces IPC and maintains an enumerable set of processes and threads. The kernel does not implement any high level drivers, it contains very few parsers. It has a consistent set of interfaces to userspace that are relatively few. The component system design carves out the “root resource” very early in the boot process and moving pieces down to dedicated delegates with limited access scopes and limited responsibilities. The component system is loosely coupled to, but leans on the package system which along with the content addressed filesystem ensures that code which is executed is _exactly_ what was originally built and specified - if that is violated it does not run. The verified boot path combines these features providing an end to end cryptographic path from signed bootloader images to the fully booted operating system. Builds done by the team apply many modern security practices, with hardened toolchain features, about half the code (as of a few years ago, probably more now) in rust, most of the other half in professionally reviewed c++. Some of the early third party researchers who attacked the system found that while they could identify some bugs (that we fixed promptly), lateral movement through the system was extremely difficult.

Updatable: as mentioned above the package system maintains a content-hard guarantee. It reduces cost of isolation and versioning using artifact sharing (as a result of content addressing) between versions where unchanged. Isolation properties of the design completely eradicate DLL hell. IPC interfaces in the core system provide stable APIs and are designed and reviewed with care to manage the evolution story and enable component interchange due to no invasive unmanaged coupling between components. Many components have been replaced with v2+ over the years with little to no fuss. The preferred deployment design follows an a/b update strategy making updates extremely safe.

Performant: most components in the system are medium sized in terms of responsibility as compared to common alternatives or common extremes. This optimizes for low latency for related task data locality and computation while maintaining a lot of separation between major components. While IPC has a latency cost, a lot of user facing performance amortizes well due to the implicit multiprocessing thah can result. All core components are written in fast systems languages. There’s always more to do on performance with a nascent system, but the architecture is setup in a generally good place for modern computing topologies and some of the implementations are decently strong for their age.

Simple: as it is a whole operating system and it has its own flavors of things, there may seem like a lot to learn which sounds complex, but many of the independent components and/or layers have simple interface boundaries with often fairly clear constraints and boundaries, which simplifies many aspects of understanding as a whole. Similarly the appropriately medium sizing of the kernel, of components, of interfaces with a generally “good taste” of sizing manages the numeracy complexity to a good level also. It’s quite easy to build associative memory for the system architecture and the components. Years on from when I worked on it I still have good recall for a ton of the system - hell I have a better memory for parts of fuchsia than the code bases I work on every day since I left.

> Fuchsia pivoted to Nest devices, and a story of replacing just the kernel of Android, to reduce the conflict with the Android team

This is like a textbook example of weak leadership of an executive team.

The power jockeying of a fiefdom’s chieftain (power reduction mitigation in this case) is allowed to drive the organizational structure and product strategy.

"Google force replace Android kernel with Fuchsia and hit some teething troubles".

This is example of technically incompetent clueless leadership. That's why MBAs should not be in control in technical companies. They have ruined a product running on billion devices by replacing rock solid kernel with immature experimental project. And so on...

Why do you think fuchsia is immature and/or experimental? It's been iterated on for nearly a decade and is deployed on millions of devices. Also why do you believe there are any MBAs involved in any decision making? Your understanding of how Google works seems to rely on faulty assumptions. It's also not clear why you seem to wish for Fuchsia to fail - having a Linux monoculture has all the same issues many folks argue against with other monocultures. Fuchsia succeeding will lead to improvements in all OS as they learn from each others advantages.

Yeah the "was never meant to replace" here sounds exactly like the placation we got with wasm - "it's not meant to replace JavaScript" (it totally is).

Is it? I don’t think those statements are incompatible in either example. In both scenarios we are looking at very meaningful leaps forward in terms of the underlying architecture and what that enables that simply aren’t possible within the boundaries of what is out there currently. I don’t think that’s the same thing as “meant to replace” at all though.

> "it's not meant to replace JavaScript"

The word meant is doing a lot of heavy lifting here. Meant - by who? The technology itself doesn’t want anything.

Do some people want to use wasm instead of JavaScript for websites? Yes. Will JS ever be removed from web browsers? Probably not, no. Wasm isn’t a grand design with a destiny it’s “meant to” reach. It’s actually just some code written by a bunch of people trying to solve a bunch of disparate problems. How well wasm solves any particular problem depends on the desires and skills of the people in the room, pushing the technology forward.

It’s kind of like that for everything. Rust was never meant to be a high performance systems language by its original creator. But the people in the room pushed it in that direction. Fuscia could replace Linux in Android. I’m sure some people want that to happen, and some people don’t. There’s no manifest destiny. What actually happens depends on a lot of arguing in meeting rooms somewhere. How that turns out is anyone’s guess!

> Meant - by who? The technology itself doesn’t want anything.

The people who created the project and who are writing the code, obviously. This is clear from the context; you don't need to nitpick stuff like this.

> Wasm isn’t a grand design with a destiny it’s “meant to” reach.

Yes it is. The destiny is being able to create dynamic websites with languages other than Javascript. The first step was Asm.js which allowed compiling other languages to Javascript. Then we got WASM which compiles them to a binary format instead. But you still need some Javascript glue to interact with the DOM APIs. And now there are extensions in progress that will remove that requirement (GC, reference types etc).

> Rust was never meant to be a high performance systems language by its original creator.

Yeah citation needed. The very first compiler release already described it as "a strongly-typed systems programming language with a focus on memory safety and concurrency."

https://web.archive.org/web/20130728230358/https://mail.mozi...

Even before that the website described it as "a programming language for low-level, safe code."

https://web.archive.org/web/20110924054534/http://www.rust-l...

>> Meant - by who? The technology itself doesn’t want anything.

> The people who created the project and who are writing the code, obviously. This is clear from the context; you don't need to nitpick stuff like this.

This isn't a nitpick, it's an important point.

Even on a small project, but especially at a huge company, there will be different ambitions and motivations for doing things.

ie, one person wants Fuchsia to eventually take over all of Google's OSes, another wants a secure IoT OS, another just wants a cool research project to pursue ideas about OSes they've had since grad school, etc...

Ah, but you’ve moved the goalposts! The original claim was that wasm would replace JavaScript. Now you’re just talking about wasm being another option from JavaScript for web development.

This distinction really seems to matter to some people. I suppose there’s something tribal about it. Is rust here to destroy C++? Rust gets a lot of irrational hate in the C++ community, and I think this perception is the reason. Is Fuscia here to destroy Android? To some, this will be a very emotionally important question.

> Yeah citation needed. The very first compiler release already described it as "a strongly-typed systems programming language (…)”

This is the article I’m thinking about, titled “The rust I wanted had no future”. Well worth a read: https://graydon2.dreamwidth.org/307291.html

> Performance: A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good.

There might have been a time when Fuchsia included some UI/UX elements to it, but that was long ago. For the last half decade there has been basically no overlap in what Android offers vs what fuchsia offers. They don't really compete and there is no one who wants fuchsia to supercede Android. The only people who want this don't understand what fuchsia is and simply want some drama. Comparing it to rust vs c++ is not really a good comparison as those languages overlap a great deal in terms of use cases and features.

I sincerely hope to see some kind of Fuchsia desktop experience someday.

Even in the form of fuchsia -> Android -> ChromeOS which publicly at least seems those layers are actually converging somewhat.

The first step was browser plugins, followed by NaCL, followed by PNaCL, followed by Mozilla's refusal to adopt PNaCL and push asm.js instead.

Active State had plugins to run Python, Tcl and Perl on the browser for example.

As we always joke in Germany nowadays when clearly there is intention even if public denied, we remind ourselves there was never an intention to build a wall, until there was actually one standing there.

That’s a narrative I’ve heard before, and there’s probably some truth to it.

There’s the product side, and there’s the technical side. I’m not sure what qualifies as “senior leadership,” but when a VP finally stepped into the org, all the ambitious product ideas were cut, and we landed on Nest as a product. Until then, I believe it was mostly courtship and sales pitches (I wasn’t in the room).

Apologies if this comes across as harsh, but Fuchsia always seemed to suffer from poor product judgment. I think it’s only healthy to acknowledge that. That said, it’s not entirely surprising—good product people don’t tend to stay very long at Google.

Yes, there was a mobile shell briefly. There was also a desktop shell. I think the narrative you’re describing could be better framed as a series of attempts and experiments to see if Fuchsia could find a use case and client. That doesn’t necessarily mean there was a concrete plan that was seriously contended or scrutinized.

Just to clarify, these are my personal opinions and observations. I don’t actually know what went on behind closed doors, but I’m not sure it’s all that useful to know either, for the reasons I mentioned above.

Thanks for the info. For those of us not familiar with it, what were the main motivations for building Fuchsia instead of just using Linux?

I'm sure there's technical reasons, but from Google's perspective, one benefit has got to be the non-copyleft license.

Google is the owner of Fuchsia's copyrights. Licensing doesn't matter for them.

It might not matter to Google, but it would definitely matter to the hardware vendors who'd write drivers and ship devices with Fuchsia.

So many GPL violations in the Android world currently

IMO the fact there are so many GPL violations just goes to show they don't care about the GPL.

I don't think this was ever really a concern. Google and device manufacturers already have ways of publishing non-GPL portions of a complete Android distribution.

I think the reasons have probably changed over time, but my recollection is mostly to have a stable Windows-style driver API so that kernel and drivers can be maintained separately. Making such an API on top of Linux was prototyped, but was unsuccessful.

(Historically, that's one big reason that there's lots of Android phones that get a fork of whatever release was current some months before they shipped, and never get substantial updates.)

They did say:

> One big challenge it addresses is Linux’s driver problem

Android devices have been plagued with vendors having out-of-tree device drivers that compile for linux 3.x, but not 4.x or 5.x, and so the phone is unable to update to a new major android version wit ha new linux kernel.

A micro-kernel with a clearly defined device driver API would mean that Google could update the kernel and android version, while continuing to let old device drivers work without update.

That's consistently been one of the motivating factors cited, and linux's monolithic design, where the internal driver API has never been anything close to stable, will not solve that problem.

> A micro-kernel with a clearly defined device driver API would mean that Google could update the kernel and android version, while continuing to let old device drivers work without update.

A monolithic kernel with a clearly defined device driver API would do the same thing. Linux is explicitly not that, of course. Maintaining backwards-compatibility in an API is a non-trivial amount of work regardless of whether the boundary is a network connection, IPC, or function call.

I would love to have an open source microkernel OS that works as well as Linux on modern hardware even if the API wasn't stable. I am making assumptions that you could have ZFS and secure boot at the same time without jumping through hoops, containerization without needing fictitious UIDs for every user, and other things of that nature. The monolithic kernel is very frustrating with some things.

Why does a monolithic kernel make those features have "hoops to jump through" compared with how a micro-kernel would handle those features?

The hoops that ZFS has to go through are twofold: licensing and unstable internal API. I don't see how a microkernel (on its own) fixes either of those things.

> A monolithic kernel with a clearly defined device driver API would do the same thing.

Maybe, but I doubt it. History has shown pretty clearly that driver authors will write code that takes advantage of its privilege state in a monolithic kernel to bypass the constraints of the driver API. Companies will do this to kludge around the GPL, to make their Linux driver look more like the Windows driver, because they were lazy and it was easier than doing it right, and for any number of other reasons. The results include the drivers failing if you look at the rest of the system funny and making the entire system wildly insecure.

If you want to a driver not subject to competent code review abide by the terms of the box in which it lives, then the system needs to strictly enforce the box. Relying on a header file with limited contents will not do the job.

It's still possible that drivers might be so buggy that a newer OS version might interact with them in a slightly different way which is still legal by the API definition but it still makes them crash or stop working.

That can be treated as an OS bug that’s fixed by updating the kernel to the latest version that fixes compat with that driver, which you can do because the driver remains unchanged. With Linux, even with DKMS, you’d need to backport your fixes to that old kernel in addition to maintaining the latest kernel version. And on mobile DKMS is not a thing.

I believe you might be limited by your imagination just how bad out of tree third party drivers can be. We're talking about hardware with DMA access here. It's trivial to create a situation that can not be fixed in the kernel (without breaking other things).

If you are running some generic PC hardware to write this comment, chances are that at least one tiny part somewhere which is dependent on some specific obscure timing to come up properly which just happens to work because someone inserted a small delay somewhere.

I don't disagree with that and yet somehow Windows manages to largely maintain HW compat across major OS upgrades with the same crappy third party driver ecosystem.

Windows drivers are absolutely version specific. Try to install a driver for an old Windows version sometime.

They generally tend to work for a very long time, like for 5 years at least. That’s literally the reason Windows has a stable ABI. Linux generally breaks drivers every 6 months or so.

It doesn't? Try loading a driver written for an old version of Windows. Third party drivers generally won't work for the next version of Windows. I have a printer that had a Windows 7 driver. It won't load on any more recent version than that.

The same printer works with Linux the same it has always done. But that's not Windows' fault or to Linux's credit. It's just the result of a really crappy vendor. However the Linux API is generally more stable than people give it credit for, it's just that it's the C headers only. Anything compiled for a kernel generally won't work anywhere else, and that's not what the crappy vendors wants.

In the embedded space, including most mobile phone vendors which seemed to be an important use case for Fuchsia, even reputable vendors will generally give you an image of an operating system heavily modified to work with their hardware. That's their "driver". Imagine buying a new PC and receiving a DVD with a Windows modified to work on that hardware only. Of course you can't upgrade or even patch security issues beyond what the vendor will give you! You're supposed to buy new hardware. Sure, you could extract the drivers and try to install them on a vanilla Windows, and that's exactly what projects like LineageOS do, but most users won't bother.

That's the situation with phones. It's not at all clear why Fuchsia thinks they could solve this. It's a cultural and an economical problem and can't be fixed with software alone. Why would phone manufacturer care about your microkernel architecture? They will just patch the whole operating system, binaries and everything, until it boots enough to start the GUI and ship that. Just like they always have.

The only thing that could improve this situation is by enforcing the GPL, or have similar contractual stipulations like only being allowed to ship a reference implementation unmodified, but Google shows no interest in doing that. They care about getting Android on as many devices as possible with no regard to their respective quality or product longevity.

So far Windows has kept driver APIs stable across multiple version.

https://en.wikipedia.org/wiki/Windows_Driver_Model

https://en.wikipedia.org/wiki/Windows_Display_Driver_Model

Naturally, as you point out, it can do nothing against forced obsolence if the the OEM expliciltly tied the driver to check the Windows version.

Microsoft is exactly the kind of vendor that will be inserting those small delays in weird places to keep a popular-but-broken device working better. Their focus on backwards compatibility has historically been very strong, and at the same time that has often lead them to not even attempt to clean up their platform. NT came to be largely because the legacy mess got too hard to deal with.

> driver authors will write code that takes advantage of its privilege state in a monolithic kernel to bypass the constraints of the driver API.

Well, your job is shipping the driver. If the API is limited and/or your existing drivers in Windows or other OSs do something and the linux driver doesn't then you have a problem

Linux kernel pros: it evolves organically

Linux kernel cons: it evolves organically

You do have a valid point that sufficiently boxing off the drivers can force them to use an API of your choosing. Even the smallest of hurdles against doing it the "wrong way" can help because many drivers are written by inexperienced teams with a tight schedule.

However, if you discover that the box was insufficient at any point, you have to choose between changing the box (and breaking some perfectly good drivers), or leaving the insufficient box in place. API versioning can let you delay this decision to reduce pain, but it will happen at some point.

FWIW, I'm hugely in favor of microkernels, but they are a lead bullet (which we need lots of), not a silver bullet for these sorts of problems.

The point of linux is to upstream drivers so that devices just work.

The problem is the release cadence, especially around mobile devices. Driver packages for them tend to be worked on right up to shipping, because they are developed in parallel with the hardware.

Android using the absolutely most head or tip version of the Linux kernel sounds like a QA nightmare of its own.

Mobile SOC has to have everything to start up the phone, as there is no bios like system that the driver is kind work through. Maybe this is a problem that could be solved, but it hasn't been yet.

In PC land linux driver support is not always day one as they are working on the drivers up to and sometimes after the release. Somehow the mobile vendors aren't capable of this.

OEMs would rather sell new devices that do updates for free.

The same happens in PC land with laptops, you seldom get drivers from Microsoft for laptop specific components, those come from the OEM, and get you what you get.

For example, https://download.lenovo.com/eol/index.html

On the PC a lot more is handled by the UEFI firmware so you need a lot less device specific drivers.

The problem, especially around mobile devices, is that the vendors only care about a single-time sale. They just fork a specific kernel release, take a chainsaw to it until it stops crashing on their device, and try to never touch the source again. Very few hardware vendors put money into having maintainable drivers, because the next gadget they ship might have different chips in it, and the chips come from a subcontractor anyway.

It’s also a totally different security architecture that is considered actually defendable rather than the cat and mouse game we have going on today. It’s actually well designed for modern threats.

> Android devices have been plagued with vendors having out-of-tree device drivers that compile for linux 3.x, but not 4.x or 5.x

What's preventing adding a driver compatibility layer over the unstable API? I would accept a some performance cost and NOPs for new features using a shim for existing legacy binary drivers compared to being forced to junk functioning hardware.

It's worth mentioning that fuchsia doesn't currently actually offer a stable driver abi. Or at least not one that is stable for more than a few months.

The reasons are pretty obvious IMO:

1. Control. It's pretty awkward if your main product depends on an open source community who might say "no" (or "fuck off you worthless imbecile") to half the things you want. You'll end up with a fork (they did!) which has serious downsides.

2. Stable driver ABI.

3. Modern security design. A microkernel, and Rust is used extensively.

The goal is to make devices more controlled by google and less FOSS. The many GPL violations happening around drivers are telling.

Shipping toybox instead of busybox is even more telling of that exact mindset.

Instead of a moonshot micro kernel, why didn't Google just build and maintain a new Linux driver API/ABI layer with backwards compatibility and security? Not an easy endeavor, but is it harder than Fuchsia?

Yes. If you want a nice, secure driver model, a greenfield project is much easier.

Maybe one could run a Fuchsia-like thing inside Linux and use Linux to provide the Linux userland ABI, but that might be challenging to maintain.

It is more moonshot to design an API while Linux devs are constantly pulling the rug under.

Microkernels provide nice secure API boundaries and optimizations to reduce performance impact when crossing them on modern CPUs.

The monolithic design forces you to stay in either user or kernel mode as much as possible to not lose performance. Adding the API and ABI incompatibility makes it near impossible to maintain.

It will require a hard fork of Linux, which won't be Linux anymore. Monolithic design is the artifact of low-register-count CPUs of the past. If you are going to create a hard fork of a kernel, why not use a more modern design anyway?

You have to wonder why the Linux devs are "pulling the rug under"

They want to keep control. Same reason RMS opposed exposing GCC internals for non-free use.

If you get your driver into the mainline kernel, it gets maintained. If your driver is not in mainline, then you have to deal yourself with kernel internals changing.

Hell, a while back one of the kernel devs was actively screaming for hardware manufacturers to reach out to them so folks could work with the manufacturer to get drivers for their products into mainline. There was even a website and nice instructions on what to do and who to contact... but I'll be fucked if I can find it anymore.

There's nothing nefarious going on... it's explicitly stated (and well-known) that the stable interface to Linux is the userspace interface. Inside the kernel, things are subject to change at any time. Don't want to have to work to keep up? Get your driver into mainline!

Google kind of does this with Android. Most of the magic sauce for a lot of hardware is in user space -

https://siliconsignals.io/blog/implementing-custom-hardware-...

That's why you used to not touch vendor partition when flashing a custom ROM etc..

Was it what project treble was about? https://android-developers.googleblog.com/2017/05/here-comes...

Because they get the bonus of no GPL and owning the copyright as a bonus with Fuchsia.

> Fuchsia isn’t trying to replace Android. Its survival for over a decade—through layoffs and with hundreds still working on it—says a lot.

Says a lot about managing to cling onto another product as a dependency to save the team from cancelation. Gotta thank the Directors for playing politics well. (Dart also played that game.)

Does not say much about necessity. Won't be surprised if it gets DOGE'd away at some point.

The best way to predict Fuchsia’s future is to look at its hardware architecture support and which runtime is getting attention.

Having tea leaves instead of a public strategy and roadmap is what's causing the FUD in the first place. Google probably has good reasons for not making any promises but that hedging comes with a cost.

FUD for who?

Feels like a quirk that some of its originators are open source hackers that ended up with Fuchsia being published externally at all. Google definitely doesn't want to attract more killedbygoogle headlines for its experimental projects, and I haven't seen any public Fuchsia evangelization.

If your target platforms are your own smart displays and maybe replacing the Linux kernel in a stack that already doesn't use the Linux userspace, why would you want to spend effort supporting third parties while you're still working on fundamentals?

I think if google collaborated with NetBSD it would be successful than creating new OS from scratch

Coincidentally, Android ABI is a scaffolding on *BSD by the way of bionic.

https://android.googlesource.com/platform/bionic/ (cf. "What's in libc") / https://github.com/GrapheneOS/platform_bionic/tree/15/docs

How would that help? Someone still has to write drivers for devices.

Reply on news.ycombinator.com