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

61–70 of 191 posts

Re: Comparing Fuchsia components and Linux containers [video]

#61

Post by okanat »

ckocagil wrote: post #53
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…

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 will require a hard fork of Linux, which won't be Linux anymore. Monolithic design is the artifact of low-register-count CPUs of the past. If you are going to create a hard fork of a kernel, why not use a more modern design anyway?

Re: Comparing Fuchsia components and Linux containers [video]

#62

Post by est31 »

amluto wrote: post #59
aidenn0 wrote: post #48

Earlier quoted context omitted.

> A micro-kernel with a clearly defined device driver API would mean that Google could update the kernel and android version, while continuing to let old device drivers work without update. A monolithic kernel with a clearly defined device driver API would do the same thing. Linux is explicitly not that, of course. Maintaining backwards-compatibility in an API is a non-trivial amount of work regardless of whether the…

> A monolithic kernel with a clearly defined device driver API would do the same thing. Maybe, but I doubt it. History has shown pretty clearly that driver authors will write code that takes advantage of its privilege state in a monolithic kernel to bypass the constraints of the driver API. Companies will do this to kludge around the GPL, to make their Linux driver look more like the Windows driver, because they were…

It's still possible that drivers might be so buggy that a newer OS version might interact with them in a slightly different way which is still legal by the API definition but it still makes them crash or stop working.

Re: Comparing Fuchsia components and Linux containers [video]

#64

Post by bsimpson »

wmf wrote: post #44
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…

The best way to predict Fuchsia’s future is to look at its hardware architecture support and which runtime is getting attention. Having tea leaves instead of a public strategy and roadmap is what's causing the FUD in the first place. Google probably has good reasons for not making any promises but that hedging comes with a cost.

FUD for who?

Feels like a quirk that some of its originators are open source hackers that ended up with Fuchsia being published externally at all. Google definitely doesn't want to attract more killedbygoogle headlines for its experimental projects, and I haven't seen any public Fuchsia evangelization.

If your target platforms are your own smart displays and maybe replacing the Linux kernel in a stack that already doesn't use the Linux userspace, why would you want to spend effort supporting third parties while you're still working on fundamentals?

Re: Comparing Fuchsia components and Linux containers [video]

#66

Post by kyrra »

throwaway48476 wrote: post #58
TheDong wrote: post #46

Earlier quoted context omitted.

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…

The point of linux is to upstream drivers so that devices just work.

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 kind work through. Maybe this is a problem that could be solved, but it hasn't been yet.

Re: Comparing Fuchsia components and Linux containers [video]

#67

Post by est31 »

ggm wrote: post #32

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.

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

Re: Comparing Fuchsia components and Linux containers [video]

#68

Post by bee_rider »

jeffbee wrote: post #37
intexpress wrote: post #23

Earlier quoted context omitted.

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

There were 25 changes updated on the Fuchsia Gerrit in the last 15 minutes. It is much less dead than 99% of open source software projects.

Are those 15 minutes representative? That seems pretty high if so.

Re: Comparing Fuchsia components and Linux containers [video]

#69

Post by saidinesh5 »

okanat wrote: post #57
bobthecowboy wrote: post #43

Earlier quoted context omitted.

I'm sure there's technical reasons, but from Google's perspective, one benefit has got to be the non-copyleft license.

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

Re: Comparing Fuchsia components and Linux containers [video]

#70

Post by spankalee »

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 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 with this. They took a lot of ideas from Fuchsia and incorporated them into Android instead.

3. When Platforms were consolidated under Hiroshi it brought the Android and Fuchsia teams closer together in a way that didn't look great for Fuchsia. Hiroshi had already been in charge of Android and was presumed to favor it. People were worried that Hiroshi was going to kill Fuchsia.

4. Fuchsia pivoted to Nest devices, and a story of replacing just the kernel of Android, to reduce the conflict with the Android team.

4a. The Android team was correct on point (2) because it's either completely infeasible or completely dumb for Google to launch a separate competitor to Android, with a new ecosystem, starting from scratch.

To work around the ecosystem problem, originally Android apps were going to be run in a Linux VM, but that was bad for battery and performance. Starnix was started to show that Fuchsia could run Linux binaries in a Fuchsia component.

5. Android and ChromeOS are finally merging, and this _might_ mean that Android gets some of the auto-update ability of ChromeOS? Does that make the lower layer more suitable for Nest devices and push Fuchsia out there too?

Again, I was a pretty removed from the project, but it seemed too simplifying to say that Fuchsia either was never intended to replace Android, or always intended to replace Android. It changed over time and management structures.

Post reply on HN