51–60 of 191 posts
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.
What do you think the answers to those are?
Earlier quoted context omitted.
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…
I think the problem is that "lack of public information about their future plans" is hard to differentiate from "no future plans exist". For a company that's in the past been known for their willingness to go for low-likelihood but high impact "moonshot" projects and seemingly open with some of their long-term plans (like everyone knowing that they were working on self-driving cars years before self-driving became a…
Fuchsia is not itself a consumer product, it's an open source project meant to be used to build a product. There is no application runtime for app developers to care about or UI for an end user to see. It would be strange to talk about things like mesa or the Linux kernel the way you are talking about fuchsia. There are software layers it does need to integrate with, but unless you work on those things, it's not really interesting to you.
Companies don't really discuss products they build using these open source building blocks while contributing to those projects until after the product launches either. It shouldn't really matter where and how it gets used to the end consumer, only that when it is used there are tangible benefits (more stable, less security problems, etc). I don't really understand why folks are so keen to understand what internal plans for using it may or may not be.
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…
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…
> 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…
Earlier quoted context omitted.
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...
> wearables, IoT, AR/VR, Auto, etc... Why would Android be a poor fit for those?
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.
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?
I'm sure there's technical reasons, but from Google's perspective, one benefit has got to be the non-copyleft license.
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…
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…
> 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…
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 lazy and it was easier than doing it right, and for any number of other reasons. The results include the drivers failing if you look at the rest of the system funny and making the entire system wildly insecure.
If you want to a driver not subject to competent code review abide by the terms of the box in which it lives, then the system needs to strictly enforce the box. Relying on a header file with limited contents will not do the job.
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?
Maybe one could run a Fuchsia-like thing inside Linux and use Linux to provide the Linux userland ABI, but that might be challenging to maintain.