There is a lot of negativity here, but for once I'm going to defend Google.
I've been using Linux on all my (non-mobile) devices for a long time, but I'm excited about the potential of Fuchsia as a general purpose (including desktop) operating system.
## Capability Based Kernel
Each process gets its own custom environment and only has access to capabilities that it receives, either ambient ones provided at startup, or passed down from other process via "RPC".
Linux has a hodgepodge of isolation solutions with different levels of abstraction, ranging from namespaces or seccomp over Docker and other container solutions to selinux, AppArmor, Firejail, Snap and Flatpak.
In short: it's kind of a mess.
The low level functionality has been steadily evolving, driven by containers, but very little of the ecosystem was built with sandboxing in mind. Most of the end-user solutions are either a leaky sieve, fringe and barely used, or a pain to use. Often all three of them.
I have a really hard time seeing the Linux (desktop) ecosystem evolve into something that can be reasonably secure. Not because of lack of technical foundations, but because of ecosystem cruft and lack of motivation.
A new open source OS with sandboxing as it's core design element can open the door to actually secure ecosystem.
## Sandboxed Drivers
In Fuchsia drivers are regular processes and only get access to what they need via capabilities.
A big part of the Linux kernel is drivers. Many of them are buggy and have potential vulnerabilities. I'd much rather have my drivers running in an isolated environment. Especially with huge drivers that no one can audit anyway (eg graphics cards - the AMD graphics drivers alone take up a large percentage of the kernel)
YES, this does allow hardware manufacturers to not open source their drivers and keep their shoddy, badly written code private instead of polishing it somewhat and upstreaming it to the Linux kernel, denying any chance of auditing or customizing them short of reverse engineering.
This definitely is a problem and a step in the wrong direction, which is my biggest concern about Fuchsia.
But it is my understanding that this is already the reality on mobile devices - most of them are based on a private kernel tree with a whole bunch of closed source drivers added.
## Library and Application Model
Fuchsia apps actually work a lot like Nix(OS). Apps are retrieved from a package registry and stored in an (immutable) blob store bashed on content hashes. Libraries are also shared between applications based on those hashes, which means different versions of libraries can be present and each application can have it's own set of libs.
As a NixOS user myself, this is exactly what I want.
In addition, system facilities like drivers and even higher level ones like an HTTP client use a standardized interface (via a FIDL schema and RPC) and can be swapped and plugged per application.
This opens a few interesting doors to application design. EG: you don't need to bake in an http client, you can just have bindings to the system interface, and let the OS provide the http client for you. (or let the user chose the implementation that they want).
This also has some interesting benefits for development.
---
In general, Fuchsia with its hybrid Kernel has made some really cool design decisions that would make it a great desktop and mobile OS, even for me as a big Linux supporter.
Do I trust Google to be a good steward of an open source OS and work with the community, rather than running a mostly "source available" project? Probably not. Do I have concerns about the effects on open drivers? Definitely.
But it's still a really cool effort, and a company like Google is one of the few players with the resources to actually make a new OS happen.
> But it is my understanding that this is already the reality on mobile devices - most of them are based on a private kernel tree with a whole bunch of closed source drivers added.
On mobile devices, the proprietary drivers are in user space. The kernel can be recompiled (because providers are forced to provide the source for their modified kernel), with necessary patches, which helps create alternative ROMs. This probably won't be a possibility anymore with a kernel for which you don't need to provide the source code. The drivers will probably be back in the kernel and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space.
> On mobile devices, the proprietary drivers are in user space.
So, the situation would stay the same regarding that.
> The drivers will probably be back in the kernel
Manufacturers putting drivers back into the kernel would be a step back for them since it would be more work than just using them in user space given there is a stable driver API.
> and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space
I think people forget that Fuchsia is more than the kernel. It comprises more things than Linux. Being based on a microkernel design, the kernel part represent just a small surface of the whole 'system interface'. All the rest is in the user space. The Android (platform) part of the system will be layered on top of this 'system interface', and will not define all the user space per se alone. This 'system interface' is well defined and documented [0] and, similarly to the Android (platform), they also have a CTS that tries to ensure that [1]. For example, the software layer implementing the product representing the Nest Hub is outside the Fuchsia platform, as will be with the Android (platform). So, a manufacturer implementing a particular feature inside the kernel, or in other component like drivers, will still result in its device having a 'system interface' at least compatible with the oficial Fuchsia one; if it's not, but offers something more, we all would be in the same situation where the provider bundles that features in closed blobs anyway.
I think Fuchsia's decoupled system architecture will make using an alternative user space not a big problem, if not even easier that it is with Android based systems.
The danger I see is that we get the bad mobile environments on other systems like desktop. I am an embedded dev and Fuchsia could be interesting. But it isn't really something I am waiting for. I like OSS much more than I like Google. And the lack of trust is deserved in my opinion.
The advantages seem very theoretical, the lack of tooling will be a problem at first. So there needs to be more compelling reasons to use it.
I've been using Linux on all my (non-mobile) devices for a long time, but I'm excited about the potential of Fuchsia as a general purpose (including desktop) operating system.
## Capability Based Kernel
Each process gets its own custom environment and only has access to capabilities that it receives, either ambient ones provided at startup, or passed down from other process via "RPC".
Linux has a hodgepodge of isolation solutions with different levels of abstraction, ranging from namespaces or seccomp over Docker and other container solutions to selinux, AppArmor, Firejail, Snap and Flatpak.
In short: it's kind of a mess.
The low level functionality has been steadily evolving, driven by containers, but very little of the ecosystem was built with sandboxing in mind. Most of the end-user solutions are either a leaky sieve, fringe and barely used, or a pain to use. Often all three of them.
I have a really hard time seeing the Linux (desktop) ecosystem evolve into something that can be reasonably secure. Not because of lack of technical foundations, but because of ecosystem cruft and lack of motivation.
A new open source OS with sandboxing as it's core design element can open the door to actually secure ecosystem.
## Sandboxed Drivers
In Fuchsia drivers are regular processes and only get access to what they need via capabilities.
A big part of the Linux kernel is drivers. Many of them are buggy and have potential vulnerabilities. I'd much rather have my drivers running in an isolated environment. Especially with huge drivers that no one can audit anyway (eg graphics cards - the AMD graphics drivers alone take up a large percentage of the kernel)
YES, this does allow hardware manufacturers to not open source their drivers and keep their shoddy, badly written code private instead of polishing it somewhat and upstreaming it to the Linux kernel, denying any chance of auditing or customizing them short of reverse engineering. This definitely is a problem and a step in the wrong direction, which is my biggest concern about Fuchsia.
But it is my understanding that this is already the reality on mobile devices - most of them are based on a private kernel tree with a whole bunch of closed source drivers added.
## Library and Application Model
Fuchsia apps actually work a lot like Nix(OS). Apps are retrieved from a package registry and stored in an (immutable) blob store bashed on content hashes. Libraries are also shared between applications based on those hashes, which means different versions of libraries can be present and each application can have it's own set of libs.
As a NixOS user myself, this is exactly what I want.
In addition, system facilities like drivers and even higher level ones like an HTTP client use a standardized interface (via a FIDL schema and RPC) and can be swapped and plugged per application.
This opens a few interesting doors to application design. EG: you don't need to bake in an http client, you can just have bindings to the system interface, and let the OS provide the http client for you. (or let the user chose the implementation that they want).
This also has some interesting benefits for development.
---
In general, Fuchsia with its hybrid Kernel has made some really cool design decisions that would make it a great desktop and mobile OS, even for me as a big Linux supporter.
Do I trust Google to be a good steward of an open source OS and work with the community, rather than running a mostly "source available" project? Probably not. Do I have concerns about the effects on open drivers? Definitely.
But it's still a really cool effort, and a company like Google is one of the few players with the resources to actually make a new OS happen.