6 ms·

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.

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 problem. If Fuchsia succeeds, Android apps could run on it. Fuchsia isn’t trying to replace Android. Its survival for over a decade—through layoffs and with hundreds still working on it—says a lot. I can’t predict Fuchsia’s future, but it’s already running on millions of devices. The git logs show big strides in running Linux programs on Fuchsia without recompilation, as well as progress on the Android runtime. The best way to predict Fuchsia’s future is to look at its hardware architecture support and which runtime is getting attention. Fuchsia’s success will likely depend more on market forces than on technical innovation. Linux is “good enough” for most needs, and its issues may not justify switching. The choice between sticking with Linux or moving to Fuchsia often favors Linux. Still, I hope Fuchsia succeeds.

knifie_spoonie 2y ago
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?
- bobthecowboy 2y ago
  I'm sure there's technical reasons, but from Google's perspective, one benefit has got to be the non-copyleft license.
  - spankalee 2y ago
    I don't think this was ever really a concern. Google and device manufacturers already have ways of publishing non-GPL portions of a complete Android distribution.
  - okanat 2y ago
    Google is the owner of Fuchsia's copyrights. Licensing doesn't matter for them.
    - saidinesh5 2y ago
      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
      - SkiFire13 2y ago
        IMO the fact there are so many GPL violations just goes to show they don't care about the GPL.
- s3graham 2y ago
  I think the reasons have probably changed over time, but my recollection is mostly to have a stable Windows-style driver API so that kernel and drivers can be maintained separately. Making such an API on top of Linux was prototyped, but was unsuccessful. (Historically, that's one big reason that there's lots of Android phones that get a fork of whatever release was current some months before they shipped, and never get substantial updates.)
- TheDong 2y ago
  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, while continuing to let old device drivers work without update. That's consistently been one of the motivating factors cited, and linux's monolithic design, where the internal driver API has never been anything close to stable, will not solve that problem.
  - aidenn0 2y ago
    > 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 boundary is a network connection, IPC, or function call.
    - plagiarist 2y ago
      I would love to have an open source microkernel OS that works as well as Linux on modern hardware even if the API wasn't stable. I am making assumptions that you could have ZFS and secure boot at the same time without jumping through hoops, containerization without needing fictitious UIDs for every user, and other things of that nature. The monolithic kernel is very frustrating with some things.
      - wilsonjholmes 2y ago
        Why does a monolithic kernel make those features have "hoops to jump through" compared with how a micro-kernel would handle those features?
      - aidenn0 2y ago
        The hoops that ZFS has to go through are twofold: licensing and unstable internal API. I don't see how a microkernel (on its own) fixes either of those things.
- IshKebab 2y ago
  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.
  - deleted 2y ago
    [deleted]
- goodpoint 2y ago
  The goal is to make devices more controlled by google and less FOSS. The many GPL violations happening around drivers are telling.
  - kees99 2y ago
    Shipping toybox instead of busybox is even more telling of that exact mindset.
wmf 2y ago
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.
- bsimpson 2y ago
  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?
ckocagil 2y ago
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?
- amluto 2y ago
  Yes. If you want a nice, secure driver model, a greenfield project is much easier. 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.
- okanat 2y ago
  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?
  - ranguna 2y ago
    You have to wonder why the Linux devs are "pulling the rug under"
    - kevin_thibedeau 2y ago
      They want to keep control. Same reason RMS opposed exposing GCC internals for non-free use.
    - simoncion 2y ago
      If you get your driver into the mainline kernel, it gets maintained. If your driver is not in mainline, then you have to deal yourself with kernel internals changing. Hell, a while back one of the kernel devs was actively screaming for hardware manufacturers to reach out to them so folks could work with the manufacturer to get drivers for their products into mainline. There was even a website and nice instructions on what to do and who to contact... but I'll be fucked if I can find it anymore. There's nothing nefarious going on... it's explicitly stated (and well-known) that the stable interface to Linux is the userspace interface. Inside the kernel, things are subject to change at any time. Don't want to have to work to keep up? Get your driver into mainline!
spankalee 2y ago
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.
- cflewis 2y ago
  I worked on Fuchsia engprod for a while. I am still employed at Google and can't talk about anything that isn't publicly available already (which really means anything gleaned from commits to the Git repo). I think the best way to look at it is like any software: there's Fuchsia The Artifact (thing that is made) and Fuchsia The Product (how thing is used, and how widely). I don't know anything about operating systems, but my understanding is that the engineers are very happy with Fuchsia The Artifact. Fuchsia The Product has had some wandering in the wilderness years.
- raggi 2y ago
  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 great stories. Maybe there will be some of the good stories told one day, but that'll need someone from the team to finish a book and take it through the Google process to publish :D In the meantime, here's Chris interview: https://9to5google.com/2022/08/30/fuchsia-director-interview-chris-mckillop/ https://9to5google.com/2022/08/30/fuchsia-director-interview...
jaypatelani 2y ago
I think if google collaborated with NetBSD it would be successful than creating new OS from scratch
- ignoramous 2y ago
  Coincidentally, Android ABI is a scaffolding on *BSD by the way of bionic. https://android.googlesource.com/platform/bionic/ https://android.googlesource.com/platform/bionic/ (cf. "What's in libc") / https://github.com/GrapheneOS/platform_bionic/tree/15/docs https://github.com/GrapheneOS/platform_bionic/tree/15/docs
- rjsw 2y ago
  How would that help? Someone still has to write drivers for devices.
tgma 2y ago
> Fuchsia isn’t trying to replace Android. Its survival for over a decade—through layoffs and with hundreds still working on it—says a lot. Says a lot about managing to cling onto another product as a dependency to save the team from cancelation. Gotta thank the Directors for playing politics well. (Dart also played that game.) Does not say much about necessity. Won't be surprised if it gets DOGE'd away at some point.

knifie_spoonie 2y ago

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?

bobthecowboy 2y ago
I'm sure there's technical reasons, but from Google's perspective, one benefit has got to be the non-copyleft license.
- spankalee 2y ago
  I don't think this was ever really a concern. Google and device manufacturers already have ways of publishing non-GPL portions of a complete Android distribution.
- okanat 2y ago
  Google is the owner of Fuchsia's copyrights. Licensing doesn't matter for them.
  - saidinesh5 2y ago
    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
    - SkiFire13 2y ago
      IMO the fact there are so many GPL violations just goes to show they don't care about the GPL.
s3graham 2y ago
I think the reasons have probably changed over time, but my recollection is mostly to have a stable Windows-style driver API so that kernel and drivers can be maintained separately. Making such an API on top of Linux was prototyped, but was unsuccessful. (Historically, that's one big reason that there's lots of Android phones that get a fork of whatever release was current some months before they shipped, and never get substantial updates.)
TheDong 2y ago
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, while continuing to let old device drivers work without update. That's consistently been one of the motivating factors cited, and linux's monolithic design, where the internal driver API has never been anything close to stable, will not solve that problem.
- aidenn0 2y ago
  > 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 boundary is a network connection, IPC, or function call.
  - plagiarist 2y ago
    I would love to have an open source microkernel OS that works as well as Linux on modern hardware even if the API wasn't stable. I am making assumptions that you could have ZFS and secure boot at the same time without jumping through hoops, containerization without needing fictitious UIDs for every user, and other things of that nature. The monolithic kernel is very frustrating with some things.
    - wilsonjholmes 2y ago
      Why does a monolithic kernel make those features have "hoops to jump through" compared with how a micro-kernel would handle those features?
    - aidenn0 2y ago
      The hoops that ZFS has to go through are twofold: licensing and unstable internal API. I don't see how a microkernel (on its own) fixes either of those things.
IshKebab 2y ago
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.
- deleted 2y ago
  [deleted]
goodpoint 2y ago
The goal is to make devices more controlled by google and less FOSS. The many GPL violations happening around drivers are telling.
- kees99 2y ago
  Shipping toybox instead of busybox is even more telling of that exact mindset.

wmf 2y ago

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.

bsimpson 2y ago
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?

ckocagil 2y ago

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?

amluto 2y ago
Yes. If you want a nice, secure driver model, a greenfield project is much easier. 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.
okanat 2y ago
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?
- ranguna 2y ago
  You have to wonder why the Linux devs are "pulling the rug under"
  - kevin_thibedeau 2y ago
    They want to keep control. Same reason RMS opposed exposing GCC internals for non-free use.
  - simoncion 2y ago
    If you get your driver into the mainline kernel, it gets maintained. If your driver is not in mainline, then you have to deal yourself with kernel internals changing. Hell, a while back one of the kernel devs was actively screaming for hardware manufacturers to reach out to them so folks could work with the manufacturer to get drivers for their products into mainline. There was even a website and nice instructions on what to do and who to contact... but I'll be fucked if I can find it anymore. There's nothing nefarious going on... it's explicitly stated (and well-known) that the stable interface to Linux is the userspace interface. Inside the kernel, things are subject to change at any time. Don't want to have to work to keep up? Get your driver into mainline!

spankalee 2y ago

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.

cflewis 2y ago
I worked on Fuchsia engprod for a while. I am still employed at Google and can't talk about anything that isn't publicly available already (which really means anything gleaned from commits to the Git repo). I think the best way to look at it is like any software: there's Fuchsia The Artifact (thing that is made) and Fuchsia The Product (how thing is used, and how widely). I don't know anything about operating systems, but my understanding is that the engineers are very happy with Fuchsia The Artifact. Fuchsia The Product has had some wandering in the wilderness years.
raggi 2y ago
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 great stories. Maybe there will be some of the good stories told one day, but that'll need someone from the team to finish a book and take it through the Google process to publish :D In the meantime, here's Chris interview: https://9to5google.com/2022/08/30/fuchsia-director-interview-chris-mckillop/ https://9to5google.com/2022/08/30/fuchsia-director-interview...

jaypatelani 2y ago

I think if google collaborated with NetBSD it would be successful than creating new OS from scratch

ignoramous 2y ago
Coincidentally, Android ABI is a scaffolding on *BSD by the way of bionic. https://android.googlesource.com/platform/bionic/ https://android.googlesource.com/platform/bionic/ (cf. "What's in libc") / https://github.com/GrapheneOS/platform_bionic/tree/15/docs https://github.com/GrapheneOS/platform_bionic/tree/15/docs
rjsw 2y ago
How would that help? Someone still has to write drivers for devices.

tgma 2y ago

> Fuchsia isn’t trying to replace Android. Its survival for over a decade—through layoffs and with hundreds still working on it—says a lot. Says a lot about managing to cling onto another product as a dependency to save the team from cancelation. Gotta thank the Directors for playing politics well. (Dart also played that game.) Does not say much about necessity. Won't be surprised if it gets DOGE'd away at some point.