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.
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
> 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.
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).
> 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.
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.)
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.
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?
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?
> 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.
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 wish message passing and capabilities based OS had taken off stronger in the 80s because I sometimes feel like there are design goals and approaches latent in what we do now, which we could have been advanced in before now, beyond research models.
I don't think they were as tenable then as they are now.
When I was doing performance work on the platform one of the notable things was how slow some of the message passing was, but how little that mattered because of how many active components there are computing concurrently and across parallel compute units. It'd still show up where latency mattered, but there are a ton of workloads where you also basically hide or simply aren't worried about latency increases on that scale.
A counter case though, as an example, is building the system using a traditional C-style build system that basically spams stat(2) at mhz or these days ghz speeds. That's basically a pathological case for message passing at the filesystem layer, and it's a good example of why few microkernels which aimed at self-hosting made it over the line. It's probably possible to "fix" using modern techniques, but it's much easier to fix by adjusting how the compilation process works - a change that has major efficiency advantages even on monolithic kernels. Alas, the world moves slow on these axes, no matter how much we'd rather see everything move all at once!
This is why Linux works and is good and most other kernels are slow and don't work. Linux has been optimised over the years based on how software actually works rather than fantasies about how it would work it we got to rewrite the world.
Yes. And without over stating it, iOS is an amazingly robust, very secure OS. it has high trust and low trust models, a secure zone, special purpose hardware and an operating system designed around minimum access rights models which manages to keep going, despite app authors worst intentions.
At one level, it proves the model. The shame is that Mach otherwise has kind of not taken off. Gnu the OS was going to be Mach at the core, at one point IIRC
I think the lack of public information about their future plans for the project combined with the “killed by Google” meme got smashed together here and that is actually a really common perception but also one that is completely made up out of thin air.
It has been under heavy heavy development for many years now.
The fact that they are now starting to talk about it publicly now is probably a sign that they are looking to move beyond just IoT in the future.
For example, I know it’s coming to Android (not necessarily as a replacement but as a VM) and I know there is some plans around consolidating ChromeOS and Android as well. I expect that is also going to be another place we might see it before too long.
I know they are also working on a full Linux compatibility layer called Starnix [1] as well where I believe the goal is you can just run all your Linux workloads on Fuchsia without any changes is the goal AFAIK so you can probably extrapolate from there that the end state is going to be roughly in line with anywhere Linux runs currently is a good potential fit for Fuchsia and it will come with a lot of additional security guarantees on top of it that is going to make it particularly attractive.
I think the problem is that "lack of public information about their future plans" is hard to differentiate from "no future plans exist". For a company that's in the past been known for their willingness to go for low-likelihood but high impact "moonshot" projects and seemingly open with some of their long-term plans (like everyone knowing that they were working on self-driving cars years before self-driving became a topic that people wouldn't be shocked to hear, like, their grandparents talking about), it's honestly pretty weird that the only device they've shipped with it was the Nest Hub, which apparently used to run on the same thing as a Chromcast (so which I don't even think was ChromeOS?).
If this were something that they were planning on using mainly for internal stuff, like for some sort of competitive advantage in data centers or something, I could understand the radio silence on future plans, but it's hard for me to imagine that's their main purpose when they're publicly putting it on stuff like the Nest Hub and Chromebooks (they didn't sell any with it afaik, but they published a guide for putting it on them). It really feels like they just don't know exactly what to do with it, and they're trying to figure that out as well. As for ChromeOS and Android, those already feel like a pretty good example of them not having a super clear initial product strategy for how they overlap (and more important, how they _don't_), so while having some sort of consolidation would make sense, it's not clear to me how Fuschia would help with that rather than just make things even murkier if they start pushing it more. I'd expect that consolidating them would start with the lower-level components rather than the UI, and my understanding is that Fuschia (as opposed to Zircon, which is the kernel) has quite a lot of UI-related stuff in it specifically with Flutter. I'm not saying you're wrong, since it sounds like you might have more relevant knowledge than me, but I can't help but wonder how much of this has really been planned in the long term rather than just been played by ear by those with decision-making power.
> The fact that they are now starting to talk about it publicly now is probably a sign that they are looking to move beyond just IoT in the future.
You're reading too much into a conference presentation.
The team has been allowed to make conference presentations for many years, it's just that most folks haven't wanted to put in the personal effort. A few have in the past, one I know of was Petr: https://www.youtube.com/watch?v=DYaqzEbU0Vk
There used to be patches in AOSP for Fuchsia but they all got reverted a couple years ago. I believe Starnix is the new strategy to get Android working on Fuchsia, if they are going to try for it.
This is a potpourri of stuff over 7 years, sprinkled on a base of confirmation bias re: the common wisdom has a "perception...completely made up out of thin air", and a misunderstanding that speaking publicly in this individual talk represents a step change or something new.
I would bet, very, very, many dollars it is not coming to Android in any form, Starnix isn't coming soon if ever, and they're not looking to move beyond IoT. Long story short, it shipped on the Nest Hub, didn't get a great rep, and Nest Hubs haven't been touched in years because they're not exactly a profit center.
Meanwhile, observe Pixel Tablet release in smart display factor, Chrome OS being merged with Android, and the software-minded VP who championed the need for the project, moving on, replaced by the hardware VP.
When you mash all that together, what you get is: the future is Android. Or, there is no future. Depending on how you look at it.
Fuchsia may not be outright dead, but it's definitely on life support and would've been killed a long time ago if senior people at Google weren't personally backing it.
It had great foundations but without a concrete use case or product development was constantly pulled in different directions. It seemed like every year a new niche for Fuchsia was on the horizon, 6 months of development time would be dedicated to it, an extremely hacky demo would get the public hyped up, and then the whole thing would be abandoned because it didn't make any business sense.
Starnix, for example, has been completely deprecated. There was even a newer system to replace it which also got cancelled.
* My knowledge is a couple years old at this point and I haven't kept up with recent developments so maybe the future is brighter than I think.
I think there's still significant investments into the project. Android is big enough so any sort of greenfield experiments cannot be done cheaply. Also there were so many custom variants of Linux based operating systems in Google and some of them moved onto Fuchsia. Probably it still have some values there.
It seems like Fuchsia components have less that they can assume about their environment and require the caller to be more explicit about what the component can do ("capabilities"). So for instance a docker container might just decide--without the user's say-so--that it wants to write a debug log file to /foo/bar/baz and then it would be up to the user to go find that file if they care. By contrast a Fuchsia component would not by default have the capability to write anywhere, so the user would have to pass in a handle that says "write your logs to this place" if they wanted logs to exist at all.
Linux folk are familiar with working with file descriptors--one just writes to stdout and leaves it to the caller to decide where that actually goes--so that was the example used but it seems like this sort of thing is done with other resources too.
It looks like a design that limits the ways programs can be surprising because they're not capable of doing anything that they weren't explicitly asked to do. Like, (I'm extrapolating here) they couldn't phone home all sneaky like because the only way for them to be able to do that is for the caller to hand them a phone.
It's got strong "dependency injection" vibes. I like it.
It's a lot like sandstorm; the web hosting platform that Kenon Varda created. It failed as a corporation, but is still open source. It's a shame: it was before it's time and still holds up incredibly well.
Sure, but it is allowed, at least as far as I understand, to phone home if it otherwise needs network access. In practice it’s really hard to prevent unauthorized semantic network access once you allow any network access.
The main benefit is that kernel space is drastically smaller which means that the opportunity for a kernel-level exploit is minimal vs something like the Linux kernel that a single device exploit compromises your entire machine.
Is it similar to NixOS? Recent convert, would be interested to read a comparison to fuchsia from someone in the know of both.
If it’s anywhere close Google might be sat on a huge opportunity to tread the same ground while solving the ergonomic issues that NixOS has. (I’ve never been more happy with a distro, but I’ll admit it took me months to crack)
Xoogler here. I never worked on Fuchsia (or Android) but I knew a bunch of people who did and in other ways I was kinda adjacent to them and platforms in general.
Some have suggested Fuchsia was never intended to replace Android. That's either a much later pivot (after I left Google) or it's historical revisionism. It absolutely was intended to replace Android and a bunch of ex-Android people were involved with it from the start. The basic premise was:
1. Linux's driver situation for Android is fundamentally broken and (in the opinion of the Fuchsia team) cannot be fixed. Windows, for example, spent a lot of time on this issue to isolate issues within drivers to avoid kernel panics. Also, Microsoft created a relatively stable ABI for drivers. Linux doesn't do that. The process of upstreaming drivers is tedious and (IIRC) it often doesn't happen; and
2. (Again, in the opinion of the Fuchsia team) Android needed an ecosystem reset. I think this was a little more vague and, from what I could gather, meant different things to different people. But Android has a strange architecture. Certain parts are in the AOSP but an increasing amount was in what was then called Google Play Services. IIRC, an example was an SSL library. AOSP had one. Play had one.
Fuchsia, at least at the time, pretty much moved everything (including drivers) from kernel space into user space. More broadly. Fuchsia can be viewed in a similar way to, say, Plan9 and micro-kernel architectures as a whole. Some think this can work. Some people who are way more knowledgeable and experienced on OS design seem to be pretty vocal saying it can't because of the context-switching. You can find such treatises online.
In my opinion, Fuchsia always struck me as one of those greenfield vanity projects meant to keep very senior engineers. Put another way: it was a solution in search of a problem. You can argue the flaws in Android architecture are real but remember, Google doesn't control the hardware. At that time at least, it was Samsung. It probably still is. Samsung doesn't like being beholden to Google. They've tried (and failed) to create their own OS. Why would they abandon one ecosystem they don't control for another they don't control? If you can't answer that, then you shouldn't be investing billions (quite literally) into the project.
Stepping back a bit, Eric Schmidt when he was CEO seemed to hold the view that ChromeOS and Android could coexist. They could compete with one another. There was no need to "unify" them. So often, such efforts to unify different projects just lead to billions of dollars spent, years of stagnation and a product that is the lowest common denominator of the things it "unified". I personally thought it was smart not to bother but I also suspect at some point someone would because that's always what happens. Microsoft completely missed the mobile revolution by trying to unify everything under Windows OS. Apple were smart to leave iOS and MacOS separate.
The only fruit of this investment and a decade of effort by now is Nest devices. I believe they tried (and failed) to embed themselves with Chromecast
But I imagine a whole bunch of people got promoted and isn't that the real point?
This is probably the most complete story told publicly, but there was a lot of timeline with a lot of people in it, so as with any such complicated history "it depends who you ask and how you frame the question": https://9to5google.com/2022/08/30/fuchsia-director-interview...
I remember reading the fuchsia slide deck and being absolutely flabbergasted at the levels of architecture astronautics going on in it. It kept flipping back and forth between some generic PM desire ("users should be able to see notifications on both their phone and their tablet!") to some ridiculous overcomplication ("all disk access should happen via a content-addressable filesystem that's transparently synchronized across every device the user owns").
The slide with all of the "1.0s" shipped by the Fuchsia team did not inspire confidence, as someone who was still regularly cleaning up the messes left by a few select members, a decade later.
I worked on the Nest HomeHub devices and the push to completely rewrite an already shipped product from web/HTML/Chromecast to Flutter/Fuchsia was one of the most insane pointless wastes of money and goodwill I've seen in my career. The fuchsia teams were allowed to grow to seemingly infinite headcount and make delivery promises they could not possibly satisfy -- miss them and then continue with new promises to miss --while the existing software stack was left to basically rot, and disrespected. Eventually they just killed the whole product line so what was the point?
It was exactly the model of how not to do large scale software development.
Fuchsia the actual software looks very cool. Too bad it was Google doing it.
Linux's ever evolving ABI is a feature, not a bug. It's how Linux maintains technical excellence. I'll take that over a crusty backwards compatibility layer written 30 years ago that is full of warts.
Readit News
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.
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 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.
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...
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.
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.
> 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.
(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.)
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.
https://siliconsignals.io/blog/implementing-custom-hardware-...
That's why you used to not touch vendor partition when flashing a custom ROM etc..
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?
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.
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.
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.
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?
https://android.googlesource.com/platform/bionic/ (cf. "What's in libc") / https://github.com/GrapheneOS/platform_bionic/tree/15/docs
When I was doing performance work on the platform one of the notable things was how slow some of the message passing was, but how little that mattered because of how many active components there are computing concurrently and across parallel compute units. It'd still show up where latency mattered, but there are a ton of workloads where you also basically hide or simply aren't worried about latency increases on that scale.
A counter case though, as an example, is building the system using a traditional C-style build system that basically spams stat(2) at mhz or these days ghz speeds. That's basically a pathological case for message passing at the filesystem layer, and it's a good example of why few microkernels which aimed at self-hosting made it over the line. It's probably possible to "fix" using modern techniques, but it's much easier to fix by adjusting how the compilation process works - a change that has major efficiency advantages even on monolithic kernels. Alas, the world moves slow on these axes, no matter how much we'd rather see everything move all at once!
Edit, to explain: in ios, everything revolves around mach ports, which are capabilities.
https://docs.darlinghq.org/internals/macos-specifics/mach-po...
At one level, it proves the model. The shame is that Mach otherwise has kind of not taken off. Gnu the OS was going to be Mach at the core, at one point IIRC
Also, I would be interested to see a comparison to the wasm component model as it also seems to want to do the same things docker containers do.
[0] https://www.theverge.com/2021/8/18/22630245/google-fuchsia-o...
It has been under heavy heavy development for many years now.
The fact that they are now starting to talk about it publicly now is probably a sign that they are looking to move beyond just IoT in the future.
For example, I know it’s coming to Android (not necessarily as a replacement but as a VM) and I know there is some plans around consolidating ChromeOS and Android as well. I expect that is also going to be another place we might see it before too long.
I know they are also working on a full Linux compatibility layer called Starnix [1] as well where I believe the goal is you can just run all your Linux workloads on Fuchsia without any changes is the goal AFAIK so you can probably extrapolate from there that the end state is going to be roughly in line with anywhere Linux runs currently is a good potential fit for Fuchsia and it will come with a lot of additional security guarantees on top of it that is going to make it particularly attractive.
[1] https://fuchsia.dev/fuchsia-src/concepts/components/v2/starn...
If this were something that they were planning on using mainly for internal stuff, like for some sort of competitive advantage in data centers or something, I could understand the radio silence on future plans, but it's hard for me to imagine that's their main purpose when they're publicly putting it on stuff like the Nest Hub and Chromebooks (they didn't sell any with it afaik, but they published a guide for putting it on them). It really feels like they just don't know exactly what to do with it, and they're trying to figure that out as well. As for ChromeOS and Android, those already feel like a pretty good example of them not having a super clear initial product strategy for how they overlap (and more important, how they _don't_), so while having some sort of consolidation would make sense, it's not clear to me how Fuschia would help with that rather than just make things even murkier if they start pushing it more. I'd expect that consolidating them would start with the lower-level components rather than the UI, and my understanding is that Fuschia (as opposed to Zircon, which is the kernel) has quite a lot of UI-related stuff in it specifically with Flutter. I'm not saying you're wrong, since it sounds like you might have more relevant knowledge than me, but I can't help but wonder how much of this has really been planned in the long term rather than just been played by ear by those with decision-making power.
You're reading too much into a conference presentation.
The team has been allowed to make conference presentations for many years, it's just that most folks haven't wanted to put in the personal effort. A few have in the past, one I know of was Petr: https://www.youtube.com/watch?v=DYaqzEbU0Vk
I would bet, very, very, many dollars it is not coming to Android in any form, Starnix isn't coming soon if ever, and they're not looking to move beyond IoT. Long story short, it shipped on the Nest Hub, didn't get a great rep, and Nest Hubs haven't been touched in years because they're not exactly a profit center.
Meanwhile, observe Pixel Tablet release in smart display factor, Chrome OS being merged with Android, and the software-minded VP who championed the need for the project, moving on, replaced by the hardware VP.
When you mash all that together, what you get is: the future is Android. Or, there is no future. Depending on how you look at it.
(disclaimer: former Googler on Pixel team, all derivable from open source info. I wish it wasn't the case, but it is :/ https://arstechnica.com/gadgets/2023/01/big-layoffs-at-googl... https://9to5google.com/2023/07/25/google-abandons-assistant-... https://9to5google.com/2024/11/18/chrome-os-migrating-androi..., note 7d views on starnix bugs, all 1 or 0, with the exception of a 7 and 4 https://issues.fuchsia.dev/issues?q=status:open%20componenti...)
Deleted Comment
* My knowledge is a couple years old at this point and I haven't kept up with recent developments so maybe the future is brighter than I think.
https://github.com/vsrinivas/fuchsia/blob/main/LICENSE
OpenWRT was born because companies were forced to give the source code back to users.
Linux folk are familiar with working with file descriptors--one just writes to stdout and leaves it to the caller to decide where that actually goes--so that was the example used but it seems like this sort of thing is done with other resources too.
It looks like a design that limits the ways programs can be surprising because they're not capable of doing anything that they weren't explicitly asked to do. Like, (I'm extrapolating here) they couldn't phone home all sneaky like because the only way for them to be able to do that is for the caller to hand them a phone.
It's got strong "dependency injection" vibes. I like it.
The main benefit is that kernel space is drastically smaller which means that the opportunity for a kernel-level exploit is minimal vs something like the Linux kernel that a single device exploit compromises your entire machine.
* Capability-centric design
* Single machine scope
* Tree of sandboxes
* Weaker inter-sandbox fault tolerance
* Standardized IPC system
* Model powers low-level OS features
* More detailed inputs/outputs from sandbox
* Configuration and building in separate files
* Sandboxes can encapsulate other sandboxes
If it’s anywhere close Google might be sat on a huge opportunity to tread the same ground while solving the ergonomic issues that NixOS has. (I’ve never been more happy with a distro, but I’ll admit it took me months to crack)
Some have suggested Fuchsia was never intended to replace Android. That's either a much later pivot (after I left Google) or it's historical revisionism. It absolutely was intended to replace Android and a bunch of ex-Android people were involved with it from the start. The basic premise was:
1. Linux's driver situation for Android is fundamentally broken and (in the opinion of the Fuchsia team) cannot be fixed. Windows, for example, spent a lot of time on this issue to isolate issues within drivers to avoid kernel panics. Also, Microsoft created a relatively stable ABI for drivers. Linux doesn't do that. The process of upstreaming drivers is tedious and (IIRC) it often doesn't happen; and
2. (Again, in the opinion of the Fuchsia team) Android needed an ecosystem reset. I think this was a little more vague and, from what I could gather, meant different things to different people. But Android has a strange architecture. Certain parts are in the AOSP but an increasing amount was in what was then called Google Play Services. IIRC, an example was an SSL library. AOSP had one. Play had one.
Fuchsia, at least at the time, pretty much moved everything (including drivers) from kernel space into user space. More broadly. Fuchsia can be viewed in a similar way to, say, Plan9 and micro-kernel architectures as a whole. Some think this can work. Some people who are way more knowledgeable and experienced on OS design seem to be pretty vocal saying it can't because of the context-switching. You can find such treatises online.
In my opinion, Fuchsia always struck me as one of those greenfield vanity projects meant to keep very senior engineers. Put another way: it was a solution in search of a problem. You can argue the flaws in Android architecture are real but remember, Google doesn't control the hardware. At that time at least, it was Samsung. It probably still is. Samsung doesn't like being beholden to Google. They've tried (and failed) to create their own OS. Why would they abandon one ecosystem they don't control for another they don't control? If you can't answer that, then you shouldn't be investing billions (quite literally) into the project.
Stepping back a bit, Eric Schmidt when he was CEO seemed to hold the view that ChromeOS and Android could coexist. They could compete with one another. There was no need to "unify" them. So often, such efforts to unify different projects just lead to billions of dollars spent, years of stagnation and a product that is the lowest common denominator of the things it "unified". I personally thought it was smart not to bother but I also suspect at some point someone would because that's always what happens. Microsoft completely missed the mobile revolution by trying to unify everything under Windows OS. Apple were smart to leave iOS and MacOS separate.
The only fruit of this investment and a decade of effort by now is Nest devices. I believe they tried (and failed) to embed themselves with Chromecast
But I imagine a whole bunch of people got promoted and isn't that the real point?
The slide with all of the "1.0s" shipped by the Fuchsia team did not inspire confidence, as someone who was still regularly cleaning up the messes left by a few select members, a decade later.
I worked on the Nest HomeHub devices and the push to completely rewrite an already shipped product from web/HTML/Chromecast to Flutter/Fuchsia was one of the most insane pointless wastes of money and goodwill I've seen in my career. The fuchsia teams were allowed to grow to seemingly infinite headcount and make delivery promises they could not possibly satisfy -- miss them and then continue with new promises to miss --while the existing software stack was left to basically rot, and disrespected. Eventually they just killed the whole product line so what was the point?
It was exactly the model of how not to do large scale software development.
Fuchsia the actual software looks very cool. Too bad it was Google doing it.
Deleted Comment
Deleted Comment