RFC-0082: Runnning unmodified Linux programs on Fuchsia
There is a lot of negativity here, but for once I&#x27;m going to defend Google.<p>I&#x27;ve been using Linux on all my (non-mobile) devices for a long time, but I&#x27;m excited about the potential of Fuchsia as a general purpose (including desktop) operating system.<p>## Capability Based Kernel<p>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 &quot;RPC&quot;.<p>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.<p>In short: it&#x27;s kind of a mess.<p>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.<p>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.<p>A new open source OS with sandboxing as it&#x27;s core design element can open the door to actually secure ecosystem.<p>## Sandboxed Drivers<p>In Fuchsia drivers are regular processes and only get access to what they need via capabilities.<p>A big part of the Linux kernel is drivers. Many of them are buggy and have potential vulnerabilities. I&#x27;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)<p>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.<p>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.<p>## Library and Application Model<p>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&#x27;s own set of libs.<p>As a NixOS user myself, this is exactly what I want.<p>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.<p>This opens a few interesting doors to application design. EG: you don&#x27;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).<p>This also has some interesting benefits for development.<p>---<p>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.<p>Do I trust Google to be a good steward of an open source OS and work with the community, rather than running a mostly &quot;source available&quot; project? Probably not. Do I have concerns about the effects on open drivers? Definitely.<p>But it&#x27;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.