Live data from Hacker News

Comparing Fuchsia components and Linux containers [video]

fosdem.org

101–110 of 191 posts

Re: Comparing Fuchsia components and Linux containers [video]

#101

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

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…

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

Re: Comparing Fuchsia components and Linux containers [video]

#102
post #75

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

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

Re: Comparing Fuchsia components and Linux containers [video]

#103
post #97

Earlier quoted context omitted.

Ok, give me access to a subdomain I control and I’m phoning home and there’s no way you can restrict mysubdomain.foo.com/phonehome vs mysubdomain.foo.com/normal - and even if you tried to do path restrictions, I can arbitrarily side-channel phoning home with normal access (which by the way you can’t unless you’re sniffing the encrypted HTTP session somehow). Also imagine you are trying to run a browser. It’s implicit…

> there’s no way you can restrict mysubdomain.foo.com/phonehome vs mysubdomain.foo.com/normal Of course you can! With capabilities you can tell a program: "if you want to communicate with the external world here's the only function you can use : `void postToMySubDomainSlashWhatever(char* payload, size_t size)`

Ok great. Now I put the phone home stuff within payload. It’s a game of whackamole you’re bound to lose. Like I said - if I control both endpoints, it’s going to be very hard for you to simultaneously give me a pipe connecting them while controlling the set of messages I’m allowed to send.

Re: Comparing Fuchsia components and Linux containers [video]

#104
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…

> 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

Re: Comparing Fuchsia components and Linux containers [video]

#105
post #57

Earlier quoted context omitted.

Google is the owner of Fuchsia's copyrights. Licensing doesn't matter for them.

It might not matter to Google, but it would definitely matter to the hardware vendors who'd write drivers and ship devices with Fuchsia. So many GPL violations in the Android world currently

IMO the fact there are so many GPL violations just goes to show they don't care about the GPL.

Re: Comparing Fuchsia components and Linux containers [video]

#106
post #95

Earlier quoted context omitted.

All I said is that in the general case you’re not going to be able to rely on capabilities to do things like prevent phoning home or otherwise doing things you semantically define as harmful. This isn’t a UX issue - this is a technical issue. Capabilities, outside from very rare circumstances, can’t enforce it no matter how you structure this. The only rare circumstances is if you can restrict access to servers that…

Your perspective is coming from a very rigid all-or-nothing mentality and I don’t think it’s wise to see things that way. Sure, a web browser that needs to open arbitrary network connections can be built to phone home. But nearly none of the components it’s built out of can. The image decoding and rendering libraries can’t touch the network, the rendering engine can’t touch the network, and nor can the dozens of othe…

But your editor extensions can’t phone home only if your editor sandboxes them into a separate process. Hint: VSCode doesn’t do such sandboxing and neither do most editors that I can think of.

Anyway, you’ve just proven my point with “install extensions out of band” - you’ve ceded that it’s a losing position technically and are arguing for alternative UX solutions. I’m not pretending it has to be perfect. Like I said, capabilities are great for creating a secure OS and writing more secure software more generally. But the threat model it’s protecting against is not software that phones home but against the size of the exploit opened up from a compromise.

Think about it this way, Android apps and iOS apps are largely sandboxed through a primitive capabilities system already, not super fine-grained capabilities but still the same concept. Would you care to claim that privacy and malware isn’t a problem on these systems or that the permissions model has meaningfully curtailed anything but the most egregious of problems?

Re: Comparing Fuchsia components and Linux containers [video]

#107
post #66

Earlier quoted context omitted.

The problem is the release cadence, especially around mobile devices. Driver packages for them tend to be worked on right up to shipping, because they are developed in parallel with the hardware. Android using the absolutely most head or tip version of the Linux kernel sounds like a QA nightmare of its own. Mobile SOC has to have everything to start up the phone, as there is no bios like system that the driver is kin…

In PC land linux driver support is not always day one as they are working on the drivers up to and sometimes after the release. Somehow the mobile vendors aren't capable of this.

OEMs would rather sell new devices that do updates for free.

The same happens in PC land with laptops, you seldom get drivers from Microsoft for laptop specific components, those come from the OEM, and get you what you get.

For example, https://download.lenovo.com/eol/index.html

Re: Comparing Fuchsia components and Linux containers [video]

#108

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

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…

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

Re: Comparing Fuchsia components and Linux containers [video]

#109

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

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?

The reasons are pretty obvious IMO:

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.

Re: Comparing Fuchsia components and Linux containers [video]

#110
post #21
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?

How long does it take to develop a general purpose, fully capable OS, from scratch? Not a *NIX / POSIX variant, but brand new? (IIUC, it's brand new?)

It really depends. If you have a good, small enough team, and a clear design, with a well defined and limited scope, it shouldn't take that long.

If your team is too large, and especially if you don't know what the use case is, it can take a very long time. You asked for general purpose and fully capable, so you're probably in this case, but I think the desired use cases for Fuchsia could be scoped to way less than general purpose and fully capable: a ChromeOS replacement needs only to run Chrome (which isn't easy, but...), and an Android replacement needs only to run Android apps (again, not easy), and the embedded devices only run applications authored by Google with probably a much smaller scope.

But it also depends on what 'from scratch' means. Will you lean on existing development tools, hosted on an existing OS? Will you borrow libraries where the scope and license are appropriate? Are you going to build your own bootloader or use an existing one?

Post reply on HN