7 ms·

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.

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.