14 ms·

Comparing Fuchsia components and Linux containers [video]

217 points by bestorworse 2y ago

thornjm 2y ago
Would appreciate anyone summarising the key differences here as I can't watch the video at the moment.
- warkdarrior 2y ago
  From the slide deck, it seems that Fuchsia components have the following characteristics, which make them different from Linux containers: * 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
  - jackpeterfletch 2y ago
    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)
    - gryn 2y ago
      NixOs is built on Linux kernel, Fushia is built on a new (micro-ish) kernel called zircon, they are not interchangable. They are working on some components/layer to run things from Linux, but you would not expect all things built to work directly or as well as thing designed from the get-go for Fushia in mind.
      - jackpeterfletch 2y ago
        Thanks - I figure its step away in terms of target platform. I meant a little more in the way that software is packaged and run. My understanding is that theres a similar mechanism for storing and linking shared libraries that means multiple versions can go exist and be independently linked depending on the requirements of the calling package.
- __MatrixMan__ 2y ago
  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.
  - vlovich123 2y ago
    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.
    - bestorworse 2y ago
      The joy of having a properly implemented capability system is that, well, you can create arbitrary capabilities. You don't need to give a process/component the “unrestricted network access capability” -- you could give it a capability to eg “have https access to this (sub)domain only” where the process wouldn't be able to change stuff like SSL certificates. EDIT: and to be clear, fuchsia implements capabilities very well. Like, apart from low-level stuff, all capabilities are created by normal processes/components. So all sorts of fine-grained accesses can be created without touching the kernel. Note that in fuchsia a process that creates/provides a capability has no control on where/to who that capability will be available -- that's up to the system configuration to decide.
sigmonsays 2y ago
What are the target use cases? like mobile, servers, desktops, tablets?
- bestorworse 2y ago
  It's technically a general-purpose OS. They had a workstation build target sometime ago which was used for the desktop use-case. They've shipped only for an IoT device so far (Google Nest Hub). Main goal would be to replace the core of AOSP considering the main work that's being done, but it seems like Google isn't convinced it's there yet.
  - dekhn 2y ago
    Hasn't this project been running for (checks notes) almost ten years now? Isn't that enough runway to determine that it's never going to replace AOSP at this rate?
    - bestorworse 2y ago
      Yep. It's anyone's guess what's been going on there. Lots of theories out there. IMO Google doesn't consider this a high priority and the cost to keep the development going on considering the engineers working on it is low enough. Also note that swapping the core of a widely used comercial OS like AOSP would be no easy feat. Imagine trying to convince OEMs, writing drivers practically from scratch for all the devices (based on a different paradigm), the bugs due to incompatibility, etc.
    - alex-mohr 2y ago
      As far as I could tell, its main goal was to have fun writing an OS. At that, it seems to have succeeded for a number of the people involved? In terms of impact or business case, I'm missing what the end goal for the company or execs involved is. It's not re-writing user-space components of AOSP, because that's all Java or Kotlin. Maybe it's a super-longterm super-expensive effort to replace Linux underlying Android with Fuchia? Or for ChromeOS? Again, seems like a weird motivation to justify such a huge investment in both the team building it and a later migration effort to use it. But what else?
bobajeff 2y ago
I'm surprised this is still being worked on I was under the impression that Google abandoned this. 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.
- mdhb 2y ago
  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. [1] https://fuchsia.dev/fuchsia-src/concepts/components/v2/starnix https://fuchsia.dev/fuchsia-src/concepts/components/v2/starn...
  - deleted 2y ago
    [deleted]
  - saghm 2y ago
    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.
ggm 2y ago
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.
- plagiarist 2y ago
  Me too. Containers are so janky compared to what we could have.
- est31 2y ago
  ios is capabilities based, no? Edit, to explain: in ios, everything revolves around mach ports, which are capabilities. https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html#ports-as-capabilities https://docs.darlinghq.org/internals/macos-specifics/mach-po...
  - ggm 2y ago
    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
    - supriyo-biswas 2y ago
      I'd have to disagree -- the lack of OS-level sandboxing primitives such as seccomp-bpf and SELinux[1] means that exploits happen rather regularly in iOS rather often ([2], among others). [1] https://source.android.com/docs/security/app-sandbox#protections https://source.android.com/docs/security/app-sandbox#protect... [2] https://www.csoonline.com/article/3811322/iphone-users-targeted-in-apples-first-zero-day-exploit-in-2025.html https://www.csoonline.com/article/3811322/iphone-users-targe...
tmp-fuchsia 2y ago
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.
- knifie_spoonie 2y ago
  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?
  - bobthecowboy 2y ago
    I'm sure there's technical reasons, but from Google's perspective, one benefit has got to be the non-copyleft license.
    - spankalee 2y ago
      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.
    - okanat 2y ago
      Google is the owner of Fuchsia's copyrights. Licensing doesn't matter for them.
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
cletus 2y ago
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?
aurelien 2y ago
AFAIK Fushia stay specific to Google HW in front of Linux that is thinked to works for all.
zoobab 2y ago
By getting rid of the GPL, users can't request the source code anymore: https://github.com/vsrinivas/fuchsia/blob/main/LICENSE https://github.com/vsrinivas/fuchsia/blob/main/LICENSE OpenWRT was born because companies were forced to give the source code back to users.
koolala 2y ago
I always hoped they would release Fushsia XR but they went with Android XR.
deleted 2y ago
[deleted]

217 points by bestorworse 2y ago

thornjm 2y ago

Would appreciate anyone summarising the key differences here as I can't watch the video at the moment.

warkdarrior 2y ago
From the slide deck, it seems that Fuchsia components have the following characteristics, which make them different from Linux containers: * 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
- jackpeterfletch 2y ago
  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)
  - gryn 2y ago
    NixOs is built on Linux kernel, Fushia is built on a new (micro-ish) kernel called zircon, they are not interchangable. They are working on some components/layer to run things from Linux, but you would not expect all things built to work directly or as well as thing designed from the get-go for Fushia in mind.
    - jackpeterfletch 2y ago
      Thanks - I figure its step away in terms of target platform. I meant a little more in the way that software is packaged and run. My understanding is that theres a similar mechanism for storing and linking shared libraries that means multiple versions can go exist and be independently linked depending on the requirements of the calling package.
__MatrixMan__ 2y ago
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.
- vlovich123 2y ago
  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.
  - bestorworse 2y ago
    The joy of having a properly implemented capability system is that, well, you can create arbitrary capabilities. You don't need to give a process/component the “unrestricted network access capability” -- you could give it a capability to eg “have https access to this (sub)domain only” where the process wouldn't be able to change stuff like SSL certificates. EDIT: and to be clear, fuchsia implements capabilities very well. Like, apart from low-level stuff, all capabilities are created by normal processes/components. So all sorts of fine-grained accesses can be created without touching the kernel. Note that in fuchsia a process that creates/provides a capability has no control on where/to who that capability will be available -- that's up to the system configuration to decide.

sigmonsays 2y ago

What are the target use cases? like mobile, servers, desktops, tablets?

bestorworse 2y ago
It's technically a general-purpose OS. They had a workstation build target sometime ago which was used for the desktop use-case. They've shipped only for an IoT device so far (Google Nest Hub). Main goal would be to replace the core of AOSP considering the main work that's being done, but it seems like Google isn't convinced it's there yet.
- dekhn 2y ago
  Hasn't this project been running for (checks notes) almost ten years now? Isn't that enough runway to determine that it's never going to replace AOSP at this rate?
  - bestorworse 2y ago
    Yep. It's anyone's guess what's been going on there. Lots of theories out there. IMO Google doesn't consider this a high priority and the cost to keep the development going on considering the engineers working on it is low enough. Also note that swapping the core of a widely used comercial OS like AOSP would be no easy feat. Imagine trying to convince OEMs, writing drivers practically from scratch for all the devices (based on a different paradigm), the bugs due to incompatibility, etc.
  - alex-mohr 2y ago
    As far as I could tell, its main goal was to have fun writing an OS. At that, it seems to have succeeded for a number of the people involved? In terms of impact or business case, I'm missing what the end goal for the company or execs involved is. It's not re-writing user-space components of AOSP, because that's all Java or Kotlin. Maybe it's a super-longterm super-expensive effort to replace Linux underlying Android with Fuchia? Or for ChromeOS? Again, seems like a weird motivation to justify such a huge investment in both the team building it and a later migration effort to use it. But what else?

bobajeff 2y ago

I'm surprised this is still being worked on I was under the impression that Google abandoned this. 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.

mdhb 2y ago
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. [1] https://fuchsia.dev/fuchsia-src/concepts/components/v2/starnix https://fuchsia.dev/fuchsia-src/concepts/components/v2/starn...
- deleted 2y ago
  [deleted]
- saghm 2y ago
  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.

ggm 2y ago

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.

plagiarist 2y ago
Me too. Containers are so janky compared to what we could have.
est31 2y ago
ios is capabilities based, no? Edit, to explain: in ios, everything revolves around mach ports, which are capabilities. https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html#ports-as-capabilities https://docs.darlinghq.org/internals/macos-specifics/mach-po...
- ggm 2y ago
  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
  - supriyo-biswas 2y ago
    I'd have to disagree -- the lack of OS-level sandboxing primitives such as seccomp-bpf and SELinux[1] means that exploits happen rather regularly in iOS rather often ([2], among others). [1] https://source.android.com/docs/security/app-sandbox#protections https://source.android.com/docs/security/app-sandbox#protect... [2] https://www.csoonline.com/article/3811322/iphone-users-targeted-in-apples-first-zero-day-exploit-in-2025.html https://www.csoonline.com/article/3811322/iphone-users-targe...

tmp-fuchsia 2y ago

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.

knifie_spoonie 2y ago
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?
- bobthecowboy 2y ago
  I'm sure there's technical reasons, but from Google's perspective, one benefit has got to be the non-copyleft license.
  - spankalee 2y ago
    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.
  - okanat 2y ago
    Google is the owner of Fuchsia's copyrights. Licensing doesn't matter for them.

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

cletus 2y ago

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?

aurelien 2y ago

AFAIK Fushia stay specific to Google HW in front of Linux that is thinked to works for all.

zoobab 2y ago

By getting rid of the GPL, users can't request the source code anymore: https://github.com/vsrinivas/fuchsia/blob/main/LICENSE https://github.com/vsrinivas/fuchsia/blob/main/LICENSE OpenWRT was born because companies were forced to give the source code back to users.

koolala 2y ago

I always hoped they would release Fushsia XR but they went with Android XR.

deleted 2y ago

[deleted]