Comparing Fuchsia components and Linux containers [video]
1–10 of 191 posts
Re: Comparing Fuchsia components and Linux containers [video]
#2Would appreciate anyone summarising the key differences here as I can't watch the video at the moment.
Re: Comparing Fuchsia components and Linux containers [video]
#3Would appreciate anyone summarising the key differences here as I can't watch the video at the moment.
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
Re: Comparing Fuchsia components and Linux containers [video]
#4What are the target use cases?
like mobile, servers, desktops, tablets?
Re: Comparing Fuchsia components and Linux containers [video]
#5I'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.
Re: Comparing Fuchsia components and Linux containers [video]
#6What are the target use cases? like mobile, servers, desktops, tablets?
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.
Re: Comparing Fuchsia components and Linux containers [video]
#7Would appreciate anyone summarising the key differences here as I can't watch the video at the moment.
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.
Re: Comparing Fuchsia components and Linux containers [video]
#8What are the target use cases? like mobile, servers, desktops, tablets?
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.
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?
Re: Comparing Fuchsia components and Linux containers [video]
#9I'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.
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/starn...
Re: Comparing Fuchsia components and Linux containers [video]
#10Would appreciate anyone summarising the key differences here as I can't watch the video at the moment.
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 e…
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)