Hacker News Reader

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.

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.

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

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

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.

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.

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.

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.