Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Fuchsia components and Linux containers [video]

fosdem.org

Post reply on HN
Print view View original

121–130 of 191 posts

Re: Comparing Fuchsia components and Linux containers [video]

#121

Post by mdhb »

IshKebab wrote: post #108
spankalee wrote: post #70

Earlier quoted context omitted.

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

Is it? I don’t think those statements are incompatible in either example. In both scenarios we are looking at very meaningful leaps forward in terms of the underlying architecture and what that enables that simply aren’t possible within the boundaries of what is out there currently. I don’t think that’s the same thing as “meant to replace” at all though.

Re: Comparing Fuchsia components and Linux containers [video]

#122

Post by mdhb »

TheDong wrote: post #46
knifie_spoonie wrote: post #40

Earlier quoted context omitted.

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?

They did say: > 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, w…

It’s also a totally different security architecture that is considered actually defendable rather than the cat and mouse game we have going on today. It’s actually well designed for modern threats.

Re: Comparing Fuchsia components and Linux containers [video]

#123

Post by vlovich123 »

stouset wrote: post #113
vlovich123 wrote: post #106

Earlier quoted context omitted.

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…

Your editor doesn’t do it because handling, delegating, and slicing up capabilities isn’t a core part of the OS.

Firstly, VSCode runs on 3 major OSes that don’t have this capability and such software results the way it is partially because of targeting the lowest common denominator. Only a Fuscia first editor would do this.

Secondly, the editor also does it this way this because of reasons other than support within the OS because even with components it would need to design a capabilities model for extensions and a sandbox process to maintain the permissions - it’s much easier to just do the extensions in-process and not think about it.

Re: Comparing Fuchsia components and Linux containers [video]

#124

Post by mdhb »

ggm wrote: post #74
est31 wrote: post #67

Earlier quoted context omitted.

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

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…

iOS is without question one of the most secure OS out there today with any amount of real world use but the gap between what it is and what state of the art looks like is also insane. Fuchsia is actually quite well aligned with something that’s actually defendable in the real world and across time.

Re: Comparing Fuchsia components and Linux containers [video]

#125

Post by mdhb »

intexpress wrote: post #23
bobajeff wrote: 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.

Fuchsia has been on life support for a few years now, but not completely dead yet

This is completely made up bullshit masquerading as a fact.

Re: Comparing Fuchsia components and Linux containers [video]

#126

Post by ranguna »

okanat wrote: post #61
ckocagil wrote: post #53

Earlier quoted context omitted.

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

You have to wonder why the Linux devs are "pulling the rug under"

Re: Comparing Fuchsia components and Linux containers [video]

#128

Post by lukan »

saagarjha wrote: post #117
raggi wrote: post #99

Earlier quoted context omitted.

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

Look I understand the context here but if you're going to go around saying "a great platform for computing" it's not really telling me much about the project.

It is a OS. Intended to run on mainstream devices.

Main difference to Linux: stable driver API. So vendors could make their blobs and support them easier, without open sourcing, like linux demands.

Re: Comparing Fuchsia components and Linux containers [video]

#129

Post by rjsw »

jaypatelani wrote: post #115
tmp-fuchsia wrote: post #36

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 think if google collaborated with NetBSD it would be successful than creating new OS from scratch

How would that help? Someone still has to write drivers for devices.

Re: Comparing Fuchsia components and Linux containers [video]

#130

Post by josephg »

IshKebab wrote: post #108
spankalee wrote: post #70

Earlier quoted context omitted.

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

> "it's not meant to replace JavaScript"

The word meant is doing a lot of heavy lifting here. Meant - by who? The technology itself doesn’t want anything.

Do some people want to use wasm instead of JavaScript for websites? Yes. Will JS ever be removed from web browsers? Probably not, no. Wasm isn’t a grand design with a destiny it’s “meant to” reach. It’s actually just some code written by a bunch of people trying to solve a bunch of disparate problems. How well wasm solves any particular problem depends on the desires and skills of the people in the room, pushing the technology forward.

It’s kind of like that for everything. Rust was never meant to be a high performance systems language by its original creator. But the people in the room pushed it in that direction. Fuscia could replace Linux in Android. I’m sure some people want that to happen, and some people don’t. There’s no manifest destiny. What actually happens depends on a lot of arguing in meeting rooms somewhere. How that turns out is anyone’s guess!

Post reply on HN