A Short introduction to Fuchsia — FuchsiaOS
Hey there.
for those who missed it, Google is working on a brand new Operating System, FuchsiaOS.
As announced in 2016, FuchsiaOS isn't an Android's successor, leastways it’s not its intention. In the officials documentation, the Fuchsia team describes that it will not focus on an “User Experience”, but rather on multiple experiences.
This implies that more than Android can be, Fuchsia will be more responsive and multi-platform, “targeting” on several platforms such as: Smartphones, TVs, HomeCasts, Speeches, Desktops, Watches, and maybe any others.
Since the last article I wrote about the system two years ago, a lot of things have changed, but we’ll see all of that in this article and some other news.
Modular
FuchsiaOS, by now just Fuchsia, was designed to be an entirely modular system, allowing its libraries and applications to be entirely removed, updated and added on it without the system get affected .
This, in addition to ensuring system integrity, allows it to be more secure, for example, security patch updates can be easily obtained with a simple package without compromising user data or others applications.
Technologies / Stack (?)
The technologies used in the development of Fuchsia are, of course C and C++, Rust, GO, and Dart. Thus, developing for Fuchsia the developer will be able to choose the language used in the backend — as being a fully modular system Fuchsia has no problem with that.
Its native frontend applications are developed in Dart/Flutter, which will greatly facilitate the migration from the Android platform to Fuchsia, and still in market adoption, since Flutter is one of the most successful technologies of the last years!
An interesting point to check is that today it is totally viable to develop apps using Dart/Flutter and low-level languages — languages that communicate directly with the operating system, such as C/C++ and Rust — through the use of the Dart:ffi library , and that I’ve been written an article about the integration of Rust with Flutter and I recommend reading it.
Architecture
Fuchsia was designed to be a secure, highly upgradable, modular, and performant system. We discussed this in the last article, but this time we have news, the system now has more architectural principles to guide its development and design.
The system is no longer an “Experiment”, as it was previously treated, but a production-level system. Like the new Google Nest Hub that already comes with a version of Fuchsia running natively.
Secure
It means that all software running on Fuchsia, including applications and components of the system itself, follow the principle of least privilege (principle of least privilege), which in short, requires that in an abstraction layer of the operating system environment, each module — such as a process, a user, or an application — is able to access only the information and resources necessary for its execution.
Updateble
Upgradable implies that Fuchsia packages are designed to be updated independently or even Instant Delivery, or Enphemery, which means that packages are designed to be decoupled, and so come and go from the device as needed, and the system is always kept up to date.
Modular/Inclusive
Modular means that the system is language independent. Since it is designed to be extensible and allow for the integration of software written in multiple languages and runtimes, you can either develop using C, C++, Rust, Go, Python, or Dart/Flutter.
Kernel
The system core is Zircon, which is the kernel with a set of libraries which manage the startup and bootstrapping of the system. All system components outside the kernel are implemented, in what we call userspaces, and totally isolated from the critical layers of the system — reinforcing the principle of least privilege, as we already talked about here — , so even Device Drivers are isolated in userspaces.
Zircon brings the architecture and many of the concepts we know through Microkernels. This architecture makes it possible for Fuchsia to minimize the amount of trust code as much as possible, limiting Memory management, Scheduling, and IPC (Inter-process communication).
So we have a possible problem: if the entire core of the system is isolated from the userspaces, how can we develop apps that need information or even “talk” with the system?
So to our code perform interactions such as: Manual memory management, system tasks or processes, IPC, device I/O etc; we can use system calls. These processes that execute the system calls are executed by the vDSO (virtual Dynamic Shared Object — libzircon.so) library which reads a generated kernel image, instead of directly reading the files in the kernel. While reading this image, the userspace code is given only the necessary privileges, — how these privileges are managed we can discuss in another article.
But why do I need to know this?
The short answer is: you don’t.
But at all, if you are a developer, the vast majority of apps that you might need to develop for Fuchsia, you will probably use Events, Streams, Channel, Socket, etc. And it’s all part of Inter-Process Communication (IPC), so if that’s your case, here’s where you should start study to develop for Fuchsia 😉.
(Fuchsia dev Road map soon)
Why Fuchsia is so interesting
Remember that Fuchsia is not a Linux-based system. Absolutely unlike Android that runs on top of Linux Kernel, Fuchsia is completely independent, the entire system and kernel is developed by Google, and fully opensource (afaik), you can submit Pull Requests for the system or even work parallel to it, creating a new system for your pleasure or need. A good example of this is dahliaOS which is a Zircon/Linux (releases are on Linux based) developed based on Fuchsia for the desktop, (I gave a two cents on it 😅) I recommend seeing the Dio Linux video (if you speak Portuguese) that talks a little about the system, it’s worth checking it out!
What I like the most interesting thing about the system is that its ecosystem is free. What I mean is, while the complete system is developed by Google, their main frontend development language, Dart, is too! This allows for greater support to developers and freedom of growth for both (System and Language). But also, it gives the freedom to develop with any language that the developer finds suitable.
Fuchsia to fix, it’s not to kill
Fuchsia is not the “Android killer” system. Many limitations that Android had, with Java or JVM, the linux kernel etc, we won’t have with Fuchsia. Another point is that Android’s niche is mobile devices, which initially is not Fuchsia’s focus, and actually there isn’t, until then, a focus, but “focals”: multiple screens, embedded devices, IOT, SmartHome etc.
Testing Fuchsia
At the time of writing this article we already have simpler ways to run the system on our machine without having so much work, such as the Fimage.
Fimage is a lightweight KVM based emulator, AEMU (Android Emulator), Android emulator that comes with Android Studio, and FEMU (Fuchsia Emulator). Developed by the dahliaOS team to allow anyone to run and test Fuchsia on their machine, without the need to download over 200 Gigas of Source Code and spend hours building the system. So if you would like to test the system neat and not go to so much trouble, this is the best option so far. Instructions, documentation and download here. If you want to have all the build experience and get your hands dirty, just follow the guide on the website fuchsia.dev.
On the other hand, if you want to experience a complete operating system with a more refined UI with a shell and Desktop Environment completely built in Flutter and with a hint of Fuchsia, you can choose to try dahliaOS. The system has both a version with the linux kernel, which allows it to be installed on almost any hardware, and a version with Zircon with very strict compatibility (by now only on FIMAGE).
All download options, instructions and where to find support are in the dahliaOS Github. Bearing in mind that the system is under development and the team works in its free time on system development, therefore it is not recommended to use the system as a daily driver.
Conclusion
If you are a developer and are interested in starting testing development on Fuchsia, there are still some issues. The standard Flutter SDK doesn’t support debugging for the Fuchsia host yet, so it’s necessary to use an SDK available in the Fuchsia Repository. As Fimage you can even debug, but it needs some adjustments, but there is no support by Fimage. Remembering that I’m already producing a guide for Fuchsia devs, like a system tears down, so just keep an eye out here 😉.
Fuchsia has been my bet since I met it in mid 2018. I believe it is a revolutionary system, not because it brings new things, as there are several Opensource systems that have similar characteristics and concepts for some time, but because it brings these concepts and for being in the hands of Google. For those who don’t remember Dart, it started as an experiment, got a web proposal and finally Flutter, and as Flutter grew, the language grew to accompany the development of the Framework.
But I’m not saying that Flutter will drag the development of Fuchsia, but that by having the entire stack of the system in hand, the possibilities are limited by Google itself. Think with me, the system targets multiple user experiences (several platforms), and Flutter is designed for Multiplatform, so we have both layers supported from the same house. (Not counting Google hardware: Nest Hubs, Google TVs, Google Home etc). Of course, everything has its good and bad side, and yes, having everything under your hands can bring several problems, which we can discuss further on the subject.
Well, I hope it was a good read, and I’m available to discuss the subject, opinions, suggestions, anyway. If you’re interested, feel free to follow us on Github and social media, both me and the Fuchsia and dahliaOS team, we have Discord and channels to exchange an idea. Thanks 😁!.
GitHub; Instagram, Twitter, XDA: @allansrc
