Google is “quietly” developing a brand new operating system called “Fuchsia”. Google introduces Fuchsia on its GitHub page: “Pink + Purple == Fuchsia (a new Operating System)”.
All operating systems developed by Google are based on the Linux Kernel: Chrome OS, Android, and Chromecasts. However, the Linux Kernel does not perform well in all scenarios (affecting performance or causing other issues), especially in embedded devices, such as car dashboards and GPS units.
The information available on the Fuchsia homepage is limited, but it completely fails to satisfy our curiosity.
| Is it better than the Linux Kernel?
From the projects and documents included in Fuchsia, it is found that the kernel of Fuchsia is the Magenta kernel, a project based on “Little Kernel”. The relationship between Magenta and Fuchsia is similar to that of Linux and Android, with the Magenta kernel driving the powerful Fuchsia operating system. Magenta is designed as a commercial embedded operating system, similar to FreeRTOS and ThreadX.
However, Magenta is significantly more powerful than Little Kernel, specifically prepared for modern, high-processor devices, supporting embedded devices, smartphones, and desktop computers. Hereafter, Little Kernel will be referred to as LK.
The internal architecture of Magenta is based on LK, but the above layers are entirely new. Magenta has the concept of processes, while LK does not. Magenta processes are composed of LK-level architecture, such as threads and memory.
Other differences:
Magenta has first-class user mode support, while LK does not.
Magenta has an object handling system, which LK also lacks.
Magenta has a capability-based security model (similar to Android 6.0 permissions), while all code in LK is trusted.
Here, magenta/mg_and_lk.md at master · fuchsia-mirror/magenta · GitHub mentions:
LK is a Kernel designed for small systems typically used in embedded applications. It is a good alternative to commercial offerings like FreeRTOS or ThreadX. Such systems often have a very limited amount of RAM, a fixed set of peripherals, and a bounded set of tasks.
It seems to be an embedded real-time system, somewhat related to VR/AR/cars and even robots;
But later it states:
On the other hand, Magenta targets modern phones and modern personal computers with fast processors, non-trivial amounts of RAM with arbitrary peripherals doing open-ended computation.
So it doesn’t seem to be a system dedicated solely to embedded devices, but rather a general-purpose system.
The developers of Fuchsia have provided some hints:
Purple – A system with high-performance graphics, low-latency input, and a beautiful UI.
Pink – An incredibly modular system for developers and users.
Looking at what is outside its kernel:
Google uses Flutter as the user interface for Fuchsia, with Dart as the primary programming language, and from the colors and presentation effects, it adopts the Material Design UI concept.
Fuchsia supports 32-bit and 64-bit ARM CPUs, as well as 64-bit PCs, and should later support Raspberry Pi 3.
The UI layer uses Flutter (a mobile application framework implemented in Dart, supporting Android/iOS, capable of writing Native Apps); the underlying rendering is Physically Based Renderer, codenamed Escher, supporting Vulkan as the underlying Graphics API; so will it begin to support Material Design from the system level (Flutter currently adopts MD, of course, this framework also supports third-party design styles)? This means taking MD a step further.
There is also a Mojo framework (this seems closely related to Chrome and is key to the future support of multiple programming languages in this system), which has already bound some languages, such as: Go, Java, JavaScript, Python, Rust. Using Dart to write the GUI part, these languages can be used to write backend code.
The contributors to the project include Travis Geiselbrecht and Brian Swetland, both of whom are key developers of the Android system, have previously developed WebOS, were once developers of BeOS, and have also participated in developing NewOS, Danger, and iOS. And Dart, Flutter, Mojo come from the Chrome team, and recalling the previous rumors that “Google plans to unify Android and Chrome OS in 2017”, could this be it?
Google repeatedly emphasizes that it will not support (at the SDK level) languages other than Java to develop Android Apps, and recently Chromebooks can seamlessly run Android Apps (by adopting container-like technology), so this new system is likely to support existing Android Apps in this way. Just a thought: unlike Android, this system seems to currently not have things like VMs, and in the future, it can avoid the entanglement with Oracle.
Google currently has two systems:
Android – performs poorly on tablets and large screens; the fragmentation issue of Android seems unsolvable, only alleviated but not cured;
ChromeOS – has no presence on phones, but performs quite well in the education sector, though it does not support Native Apps (recently just seamlessly supported Android Apps), Web Apps can be greatly useful, but replacing Native Apps (is it really necessary?) is still far away.
In the future, there is a huge potential opportunity in emerging fields like IoT, VR/AR, but currently, there is no system that was optimized and built for this from the start.
So: developing a new platform from scratch to integrate these three should be its ultimate goal (of course, it is also possible that it is just an RTOS, an embedded system developed specifically for VR/AR, perhaps I am overthinking).
However, Android is currently the most widely used system in the world, with a vast ecosystem; ChromeOS has just begun to show good performance, and Google is unlikely to abandon these two systems, nor can it afford to abandon them; for example, how can it abandon Android?
I think it is more like a: evolution, integration. If you look at its source code, many of its technology stacks are actually interconnected with Android and ChromeOS, bringing together many projects that were previously scattered within Google (such as Skia, Mojo).
Therefore: the system’s underlying architecture will be completely renewed, the Android app ecosystem will be preserved and continued, Java will no longer be the only language to write apps, and ChromeOS may be absorbed, further supported by the system level for VR/AR.
This strategy aligns with the style of Alphabet’s CFO Ruth Porat since her appointment: streamlining the product line and avoiding reckless spending.
If at this time a system dedicated to the Internet of Things were developed, there was already Brillo, is it to play Mahjong with Android and ChromeOS?
| What is Google’s purpose?
Having learned so much about Fuchsia, why is Google developing a brand new OS and Kernel? Is it to build the Material Design concept on smartphones and PCs? The most likely reason is that Google hopes Fuchsia can one day replace Chrome OS and Android, but perhaps Google will treat Fuchsia like Samsung treats Tizen OS. But it may also just be an experiment by Google.
Is Fuchsia just a project development codename? What will this system be called in the future?
Maybe it will still be called Fuchsia, perhaps Android 8.0 (9.0), maybe ChromeOS 2.0, or perhaps a completely new name.
When will this new system be able to replace (I think the term replace is not very accurate) Android and ChromeOS?
I think it can integrate well with the existing ecosystems of the first two, and the transition process to the new system will not bring a significant sense of difference to users and third-party vendors (for example, many apps not being usable, many drivers being incompatible, and many things needing to be re-adapted, leading to reluctance from users and vendors to switch to the new system, which would result in failure), meaning it will be transparent to users and third-party vendors, and it will succeed in replacing the latter two.
In fact, the first to propose the concept of “Convergence” was Ubuntu, and Ubuntu initially did that, but progress was not smooth; in terms of strength and financial resources, Canonical still lacked enough, such as Mir being repeatedly delayed.
(Let’s leave it at that for now, as there is currently very little relevant information released, just speculation)
Note from Lei Feng Network: The main author of this article is Ye Xiulan, and it is published on the WeChat public account Open Source Pie with authorization from Lei Feng Network. Please contact for authorization and retain the source and author, and do not delete content.