6 ms·

Disclaimer: I used to work and knew a lot Fuchsia developers very well. No, Fuchsia is not a pet project. Instead, it's solving a very realistic problem: build

Disclaimer: I used to work and knew a lot Fuchsia developers very well. No, Fuchsia is not a pet project. Instead, it's solving a very realistic problem: building a clean driver interface, while keep it open and gain hardware vendor support. Anyone have shipped a Linux-based embedded system (including Android smartphone) knows the pain: there are tons of ad hoc driver source files need to be manually merged/rebased against the Linux Kernel. Want to upgrade the Linux kernel from 4.x to 5.x? Good luck redoing lots of merges and rebasing. There are tons and tons of git branches floating around, crazy examples like: "Linux-4.11-some_soc_vendor-some_oem-random_device-random_project-rev-1.3". It soon becomes unmanaged and device manufactures just gave up on keeping up with OS upgrades. Overall, the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed back or to write properly modularized driver extensions. Even when people managed to get it work, you end up something like AMD's GPU driver takes 10% of Linux kernel [1]. The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel. Is it worth it? Can Google pull it off? I don't know. But it probably worth a shot. [1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-AMDGPU-Stats https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....

xyzzy_plugh 5y ago
I half agree with you. It's not so much that Linux lacks a clean driver interface, it's really that OEMs write shitty software that doesn't belong upstream. Ideally vendors stop writing garbage drivers and distributing hacked up kernels with their "sample code" (but ends up in production) and opaque binary blobs. Android unified vendors but simultaneously made them even lazier. It's somewhat hard to get non-android code from vendors in the past 5+ years. Which makes me very sad. Will Fuchsia somehow convince vendors to produce better drivers? I don't see how Fuchsia makes this problem significantly easier. Shitty vendors will continue to be shitty vendors and take the easiest path to making money. In any case, the Kernel's super power is its community, not the software itself. The LKML is vast and full of knowledge, a strange intersection of open source, research and corporate exploits. I don't see Fuchsia replacing that anytime soon.
- londons_explore 5y ago
  I think OP's point is it doesn't matter if the drivers are crappy, as long as they only use a fixed and we'll defined interface. If drivers all had a well defined interface, the exact same driver, binary or source, can be used across any OS version, and maybe even on other OS's with the right shims. Then you don't need driver manufacturers to all collaborate to update the OS.
- pjmlp 5y ago
  The point is not to produce better drivers, rather a stable driver interface. It is no accident that Project Treble drivers follow a similar mikrokernel approach to Fuchsia. On Android, after Project Treble, classical GNU/Linux drivers are considered legacy mode drivers. https://source.android.com/devices/architecture/hal https://source.android.com/devices/architecture/hal Fuchsia is the next step.
  - cbolton 5y ago
    I wonder if a stable driver interface could also result in higher driver quality: if the same driver keeps working across many versions, even with relatively few users it could aggregate incremental improvements from various parties?
matheusmoreira 5y ago
Why can't the vendors just contribute their drivers to the kernel? Why is it so hard? Looks like Intel is doing it and their products just work on Linux as a result. Why can't these shitty mobile hardware manufacturers do the same?
- delroth 5y ago
  The sad answer is that they can't be bothered to meet the quality standards expected for upstream kernel code. Easier to just throw garbage in a tarball and ship privesc vulnerabilities to millions of users.
- 908B64B197 5y ago
  Driver supports costs money, vendors make money when they sell chips. They treat drivers and software as a cost-center, so the software quality is typically horrible. Can't be merged, won't be merged. Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.
  - fmakunbound 5y ago
    I feel this must explain why every Android device I've owned has felt janky in some way, while with an Apple phone it just seems to work.
  - zozbot234 5y ago
    > Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS. That's just not true. A lot of hardware support was stranded by OS version updates, especially pre-Vista and Win7. It's reached a point where Linux deals a lot better w/ some older hardware than any currently-supported Windows version.
    - BugsJustFindMe 5y ago
      A small handful of times over many decades when the driver model changed, not after every update.
gosukiwi 5y ago
Will we see GNU/Fucshia someday maybe then? :P
- onlyrealcuzzo 5y ago
  The Kernel is an MIT license, and the user space is BSD [1] > The Fuchsia kernel is released under the following MIT-style license: /zircon/kernel/LICENSE. > All Fuchsia user space components are released under a BSD-style license: /LICENSE or an Apache 2.0 license: https://fuchsia.googlesource.com/infra/+/main/LICENSE https://fuchsia.googlesource.com/infra/+/main/LICENSE. > All code that is BSD-licensed has an additional IP grant: /PATENTS. [1] https://fuchsia.dev/fuchsia-src/contribute/governance/policy/open-source-licensing-policies https://fuchsia.dev/fuchsia-src/contribute/governance/policy...
  - rbanffy 5y ago
    GNU/Fucsia would probably end up similar to GNU/Hurd in that case, or Apple's MkLinux.
- skybrian 5y ago
  I'm guessing that depends on how big the pile of Fuchsia-compatible device drivers grows and how badly people running open source OSes want to use that hardware. Where there's a demand for a particular class of device, maybe someone will create a shim? Then the kernel folks can have a debate. Currently though, I think Linux has a big head start.
yjftsjthsd-h 5y ago
Okay, but having a stable interface doesn't fix vendors shipping bad code, it just decouples it so you can run terrible drivers on a less-terrible kernel. Better yet, Fuchsia removes any obligation for vendors to share code (by both separating drivers from the OS and having the OS itself be permissively licensed), so third parties can't even start from vendor code and try to improve things.
- pjmlp 5y ago
  Just like Project Treble, Binderized HALs => HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only. Taken from https://source.android.com/devices/architecture/hal-types https://source.android.com/devices/architecture/hal-types
- soco 5y ago
  These are two distinct problems. Rather, one is an improvement and another is a problem. The terrible drivers can then be isolated, pinpointed if you want, and the OS can move forward - if you don't use the AMD GPU or the HP printer no need to have it bloating your kernel, so I take this as the improvement (I was always fond of microkernels, so I'm advocating here). On the second problem, I fail seeing how the blame for vendors failing to update their drivers could fall on the OS. With this approach the failing is just much more evident, not any less damaging.
dvfjsdhgfv 5y ago
> The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel. To paraphrase a popular saying, "the driver interface apparently has an abstraction problem, so Google created Fuchsia - and now we have two problems."
linuxftw 5y ago
It's a pet project. If you want to solve the kernel ABI problem, you can easily hard-fork and maintain that ABI indefinitely from any Linux kernel. And if that sounds like it's too hard, imagine how hard it is to maintain your own kernel, and all the associated user space you now have to reinvent. In fact, you don't even need to hard fork. You could have your own rolling tree with a stable "Android ABI" interface that vendors can write drivers against, optionally. In any case, no company in their right mind would use this project. Google has proven repeatedly they will enforce a monopoly on their platform one way or another.
- google234123 5y ago
  It accomplishes much more than just solving the kernel ABI problem.
  - linuxftw 5y ago
    It doesn't accomplish anything because nobody's going to use it.
    - google234123 5y ago
      May the best software win. Anyway, if they succeed in integrating it into Android then that will be a lot of users :P
      - linuxftw 5y ago
        Seeing as how this is like the 5th or 6th year there has been some sort of press coverage about "Google's new OS" I'm not going to hold my breath.
        pjmlp 5y ago
        Android already uses a similar model since Project Treble was introduced, with version 8 all drivers must use Android IPC instead of being Linux drivers. Treble driver model is quite similar to Fuchsia, so it already happened, no need to prove anything.
zozbot234 5y ago
> Overall, the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed back or to write properly modularized driver extensions. The postmarketOS folks are doing it, starting from downstream OEM Linux kernels, and the patches are being accepted on LKML. It's a lot of work because so much ARM hardware is its own weird mixture of long-supported basic IP blocks and newer stuff with its own quirks, and ARM has nothing like the plug-and-play hardware enumeration of modern x86 systems. So untangling all of this just takes a lot of time and effort. But this has nothing to do with Linux per se; it's all about the ARM system architecture itself and the SoC-based industry that has sprung up around it. And no, running a microkernel-based system won't help at all, because any hardware that's part of the SoC can read or write arbitrary memory hence your driver can (perhaps unwittingly) subvert the very same security mechanisms you're supposedly relying on. Not to mention that some of these drivers handle, e.g. voltage regulators that will happily fry your hardware irreversibly if poked the wrong way. All of this stuff is inherently part of the trusted base of your system, so you're not going to do any better than what Linux already gives you.
Steltek 5y ago
> the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed > In 2018, we got the OS running natively on a Pixelbook. After that, the Fuchsia team stopped doing its work in the open and stripped all UI work out of the public repository. Linux (AFAIK) still doesn't require the typical CLA paperwork or copyright assignment. The "strict licensing terms" of the Linux kernel ensures that kernel stays open. If openness is a goal of Fuschia, the GPL would not be a problem here. If anything, Linux needs a harder license, like GPLv3 or similar, to maintain openness in a world of locked bootloaders and not-even-half-baked clone appliances with manufacturers who aren't interested in coughing up the kernel source.
1vuio0pswjnm7 5y ago
"But Fuschia's goal is NOT to build another Android, but mainly to replace the Linux kernel." "BPF will replace the Linux kernel" - Linux kernel developer Funny that the B in BPF stands for Berkeley, as in "BSD". I bet it will be renamed at some point.
- 1vuio0pswjnm7 5y ago
  "BPF will replace the Linux kernel" is a quote from Steven Rostedt.
MayeulC 5y ago
> strict licensing terms made it hard to get code upstreamed back How come? Right now, the phone ecosystem isn't perfect. It's hard to update phones. Why is that? Because manufacturers don't care about long-term support. But at least you could ask them for kernel source, fix their drivers and eventually upstream everything, like postmarketos does. Now, with a stable driver ABI and permissive license, drivers won't get released. Hardware vendors still have no incentive to support old hardware, so bugs will remain unfixed, and hardware will decay as usual... Oh, sure, maybe you'll get one more update before reaching an edge-case in some driver? I also expect manufacturers to put all kind of ugly things in the kernel if no agreement with google prevents them to do so. Cue "branded" kernels, with drivers incompatible with each other due to some extra or removed APIs. And back to square one, but with only binaries and no source this time around.

xyzzy_plugh 5y ago

I half agree with you. It's not so much that Linux lacks a clean driver interface, it's really that OEMs write shitty software that doesn't belong upstream. Ideally vendors stop writing garbage drivers and distributing hacked up kernels with their "sample code" (but ends up in production) and opaque binary blobs. Android unified vendors but simultaneously made them even lazier. It's somewhat hard to get non-android code from vendors in the past 5+ years. Which makes me very sad. Will Fuchsia somehow convince vendors to produce better drivers? I don't see how Fuchsia makes this problem significantly easier. Shitty vendors will continue to be shitty vendors and take the easiest path to making money. In any case, the Kernel's super power is its community, not the software itself. The LKML is vast and full of knowledge, a strange intersection of open source, research and corporate exploits. I don't see Fuchsia replacing that anytime soon.

londons_explore 5y ago
I think OP's point is it doesn't matter if the drivers are crappy, as long as they only use a fixed and we'll defined interface. If drivers all had a well defined interface, the exact same driver, binary or source, can be used across any OS version, and maybe even on other OS's with the right shims. Then you don't need driver manufacturers to all collaborate to update the OS.
pjmlp 5y ago
The point is not to produce better drivers, rather a stable driver interface. It is no accident that Project Treble drivers follow a similar mikrokernel approach to Fuchsia. On Android, after Project Treble, classical GNU/Linux drivers are considered legacy mode drivers. https://source.android.com/devices/architecture/hal https://source.android.com/devices/architecture/hal Fuchsia is the next step.
- cbolton 5y ago
  I wonder if a stable driver interface could also result in higher driver quality: if the same driver keeps working across many versions, even with relatively few users it could aggregate incremental improvements from various parties?

matheusmoreira 5y ago

Why can't the vendors just contribute their drivers to the kernel? Why is it so hard? Looks like Intel is doing it and their products just work on Linux as a result. Why can't these shitty mobile hardware manufacturers do the same?

delroth 5y ago
The sad answer is that they can't be bothered to meet the quality standards expected for upstream kernel code. Easier to just throw garbage in a tarball and ship privesc vulnerabilities to millions of users.
908B64B197 5y ago
Driver supports costs money, vendors make money when they sell chips. They treat drivers and software as a cost-center, so the software quality is typically horrible. Can't be merged, won't be merged. Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.
- fmakunbound 5y ago
  I feel this must explain why every Android device I've owned has felt janky in some way, while with an Apple phone it just seems to work.
- zozbot234 5y ago
  > Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS. That's just not true. A lot of hardware support was stranded by OS version updates, especially pre-Vista and Win7. It's reached a point where Linux deals a lot better w/ some older hardware than any currently-supported Windows version.
  - BugsJustFindMe 5y ago
    A small handful of times over many decades when the driver model changed, not after every update.

gosukiwi 5y ago

Will we see GNU/Fucshia someday maybe then? :P

onlyrealcuzzo 5y ago
The Kernel is an MIT license, and the user space is BSD [1] > The Fuchsia kernel is released under the following MIT-style license: /zircon/kernel/LICENSE. > All Fuchsia user space components are released under a BSD-style license: /LICENSE or an Apache 2.0 license: https://fuchsia.googlesource.com/infra/+/main/LICENSE https://fuchsia.googlesource.com/infra/+/main/LICENSE. > All code that is BSD-licensed has an additional IP grant: /PATENTS. [1] https://fuchsia.dev/fuchsia-src/contribute/governance/policy/open-source-licensing-policies https://fuchsia.dev/fuchsia-src/contribute/governance/policy...
- rbanffy 5y ago
  GNU/Fucsia would probably end up similar to GNU/Hurd in that case, or Apple's MkLinux.
skybrian 5y ago
I'm guessing that depends on how big the pile of Fuchsia-compatible device drivers grows and how badly people running open source OSes want to use that hardware. Where there's a demand for a particular class of device, maybe someone will create a shim? Then the kernel folks can have a debate. Currently though, I think Linux has a big head start.

yjftsjthsd-h 5y ago

Okay, but having a stable interface doesn't fix vendors shipping bad code, it just decouples it so you can run terrible drivers on a less-terrible kernel. Better yet, Fuchsia removes any obligation for vendors to share code (by both separating drivers from the OS and having the OS itself be permissively licensed), so third parties can't even start from vendor code and try to improve things.

pjmlp 5y ago
Just like Project Treble, Binderized HALs => HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only. Taken from https://source.android.com/devices/architecture/hal-types https://source.android.com/devices/architecture/hal-types
soco 5y ago
These are two distinct problems. Rather, one is an improvement and another is a problem. The terrible drivers can then be isolated, pinpointed if you want, and the OS can move forward - if you don't use the AMD GPU or the HP printer no need to have it bloating your kernel, so I take this as the improvement (I was always fond of microkernels, so I'm advocating here). On the second problem, I fail seeing how the blame for vendors failing to update their drivers could fall on the OS. With this approach the failing is just much more evident, not any less damaging.

dvfjsdhgfv 5y ago

> The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel. To paraphrase a popular saying, "the driver interface apparently has an abstraction problem, so Google created Fuchsia - and now we have two problems."

linuxftw 5y ago

It's a pet project. If you want to solve the kernel ABI problem, you can easily hard-fork and maintain that ABI indefinitely from any Linux kernel. And if that sounds like it's too hard, imagine how hard it is to maintain your own kernel, and all the associated user space you now have to reinvent. In fact, you don't even need to hard fork. You could have your own rolling tree with a stable "Android ABI" interface that vendors can write drivers against, optionally. In any case, no company in their right mind would use this project. Google has proven repeatedly they will enforce a monopoly on their platform one way or another.

google234123 5y ago
It accomplishes much more than just solving the kernel ABI problem.
- linuxftw 5y ago
  It doesn't accomplish anything because nobody's going to use it.
  - google234123 5y ago
    May the best software win. Anyway, if they succeed in integrating it into Android then that will be a lot of users :P
    - linuxftw 5y ago
      Seeing as how this is like the 5th or 6th year there has been some sort of press coverage about "Google's new OS" I'm not going to hold my breath.
      - pjmlp 5y ago
        Android already uses a similar model since Project Treble was introduced, with version 8 all drivers must use Android IPC instead of being Linux drivers. Treble driver model is quite similar to Fuchsia, so it already happened, no need to prove anything.

zozbot234 5y ago

> Overall, the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed back or to write properly modularized driver extensions. The postmarketOS folks are doing it, starting from downstream OEM Linux kernels, and the patches are being accepted on LKML. It's a lot of work because so much ARM hardware is its own weird mixture of long-supported basic IP blocks and newer stuff with its own quirks, and ARM has nothing like the plug-and-play hardware enumeration of modern x86 systems. So untangling all of this just takes a lot of time and effort. But this has nothing to do with Linux per se; it's all about the ARM system architecture itself and the SoC-based industry that has sprung up around it. And no, running a microkernel-based system won't help at all, because any hardware that's part of the SoC can read or write arbitrary memory hence your driver can (perhaps unwittingly) subvert the very same security mechanisms you're supposedly relying on. Not to mention that some of these drivers handle, e.g. voltage regulators that will happily fry your hardware irreversibly if poked the wrong way. All of this stuff is inherently part of the trusted base of your system, so you're not going to do any better than what Linux already gives you.

Steltek 5y ago

> the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed > In 2018, we got the OS running natively on a Pixelbook. After that, the Fuchsia team stopped doing its work in the open and stripped all UI work out of the public repository. Linux (AFAIK) still doesn't require the typical CLA paperwork or copyright assignment. The "strict licensing terms" of the Linux kernel ensures that kernel stays open. If openness is a goal of Fuschia, the GPL would not be a problem here. If anything, Linux needs a harder license, like GPLv3 or similar, to maintain openness in a world of locked bootloaders and not-even-half-baked clone appliances with manufacturers who aren't interested in coughing up the kernel source.

1vuio0pswjnm7 5y ago

"But Fuschia's goal is NOT to build another Android, but mainly to replace the Linux kernel." "BPF will replace the Linux kernel" - Linux kernel developer Funny that the B in BPF stands for Berkeley, as in "BSD". I bet it will be renamed at some point.

1vuio0pswjnm7 5y ago
"BPF will replace the Linux kernel" is a quote from Steven Rostedt.

MayeulC 5y ago

> strict licensing terms made it hard to get code upstreamed back How come? Right now, the phone ecosystem isn't perfect. It's hard to update phones. Why is that? Because manufacturers don't care about long-term support. But at least you could ask them for kernel source, fix their drivers and eventually upstream everything, like postmarketos does. Now, with a stable driver ABI and permissive license, drivers won't get released. Hardware vendors still have no incentive to support old hardware, so bugs will remain unfixed, and hardware will decay as usual... Oh, sure, maybe you'll get one more update before reaching an edge-case in some driver? I also expect manufacturers to put all kind of ugly things in the kernel if no agreement with google prevents them to do so. Cue "branded" kernels, with drivers incompatible with each other due to some extra or removed APIs. And back to square one, but with only binaries and no source this time around.