Live data from Hacker News

Comparing Fuchsia components and Linux containers [video]

fosdem.org

11–20 of 191 posts

Re: Comparing Fuchsia components and Linux containers [video]

#11
post #2

Would 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…

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.

Re: Comparing Fuchsia components and Linux containers [video]

#12
post #8

Earlier quoted context omitted.

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?

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.

Re: Comparing Fuchsia components and Linux containers [video]

#13

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

Android is very unapologetically Linux and it's unlikely anyone seriously proposed doing anything other than use Linux.

Fuchsia more likely was for all the stuff that Google kept experimenting with using Android just because it was there rather than because it was a good fit - wearables, IoT, AR/VR, Auto, etc...

Re: Comparing Fuchsia components and Linux containers [video]

#14
post #2

Would 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…

Sounds like it has just AppArmor/Seccomp/SELinux policies built in. You usually reach the same with previous.

Re: Comparing Fuchsia components and Linux containers [video]

#15

Earlier quoted context omitted.

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…

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 co…

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.

Re: Comparing Fuchsia components and Linux containers [video]

#16
post #9
post #5

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.

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 lookin…

[deleted]

Re: Comparing Fuchsia components and Linux containers [video]

#17
post #8

Earlier quoted context omitted.

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?

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?

Re: Comparing Fuchsia components and Linux containers [video]

#18
post #8

Earlier quoted context omitted.

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?

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…

When I worked at $GOOG my manager left the team to work on Fuchsia and he described it as a "senior engineer retention project", but also the idea was to come up with a kernel that had a stable interface so that vendors could update their hardware more easily compared to linux.

Many things that google did when I was there was simply to have a hedge, if the time/opportunity arose, against other technologies. For example they kept trying to pitch non-Intel hardware, at least partly so they could have more negotiation leverage over Intel. It's amazing how much wasted effort they have created following bad ideas.

Re: Comparing Fuchsia components and Linux containers [video]

#19

Earlier quoted context omitted.

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)

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.

Re: Comparing Fuchsia components and Linux containers [video]

#20

Earlier quoted context omitted.

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…

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 co…

Most components don't need to talk to the network though and therefore do not. The ones that do can do powerful things but creating narrower capabilities to restrict what they can do is very much feasible.
Post reply on HN