fuchsia-flower-with-boot

Computers are like cars, we are used to just starting them up and using them. We often forget the complexities and intricacies of what is happening under the hood. Android, Windows, OS X, and Linux are all complex operating systems, but what we use today is the mature product that has been in development for years. Fuchsia isn’t like that. It is new, it is in its infancy, it is a work in progress, it is incomplete and it is a mystery.

When I wrote about Fuchsia a few days ago, I included a link to the build instructions, how to take the source code and build it to make a bootable version of the OS. Having written about it, the next logical step was to follow the instructions and see what pops out the other end.

Compiling Fuchsia OS

The easiest way to build Fuchsia is to use a 64-bit Intel Ubuntu Linux machine. Apparently it will also build on OS X and it might work on other Linux flavors like Debian etc. If you aren’t familiar with Linux or you don’t have command-line ninja skills then this isn’t a task for you, but don’t worry I have done all the hard work for you!

At the moment Fuchsia is made up of two big parts. Magenta, which is the kernel, and the various tools, libraries and programs which take the raw Magenta kernel make it Fuchsia. At the heart of Magenta is the Little Kernel (LK), a small OS suited to small embedded devices and bootloaders. LK is tiny and has limited functionality beyond those needed for embedded systems. Magenta builds on top of LK to make an OS that is designed for systems which have more memory and which have peripherals (meaning it understands device drivers). For example, Magenta has the concept of a process whereas LK does not, Magenta has a user mode (where user programs run) whereas LK does not, and so on.

So to build Fuchsia you need to do two things. First is to build the tools and libraries which will run in user space, including a simple shell program called “mxsh”. The second is to build LK/Magenta. Once that is all done you can boot Magenta using a filesystem that has the Fuchsia user space executables.

Running Fuchsia OS

The simplest way to run Fuchsia is using qemu, the popular open source machine emulator. In fact, the Fuchsia source tree contains its own copy of qemu which is compiled as part of the overall build process.

fuchsia-boot

When you boot Fuchsia you get lots of kernel level debug messages telling you about the system as it boots. The initial message says “welcome to lk/MP” and then the kernel goes on to initialise various subsystems like threads and timers. After that comes the CPU detection, the scheduler, the device manager and networking. Once booted you get access to a simple shell called mxsh.

mxsh has a few built in commands including cd, cp, echo, ls, and rm. If you type in a word that isn’t a built-in command then the shell will try to run a program of that name found in /boot/bin/. The /boot/bin directory has lots of different executables, most of which are to do with the testing and further development of Fuchsia. For example one program is called “thread-depth-test” which tests the thread creation abilities of Fuchsia. There are also some simple executables like fortune and cowsay.

fuchsia-cowsay

Most importantly is the support for Dart, Google’s scripting language which was originally earmarked as a replacement for Javascript. However Dart has grown since then and is now a fully fledged interpreted language which Google uses for its own in-house systems including AdWords. In general Dart can be run in one of two ways, by compiling it to Javascript (and then running it through a Javascript interpreter) or by interpreting it directly via the stand-alone Dart VM. The latter approach is used by Fuchsia.

To test Dart on Fuchsia there is a simple Dart script in /boot/apps called hello_fuchsia.dart which just prints “Hello, Fuchsia!” to the console. To run it type: dart /boot/apps/hello_fuchsia.dart

fuchsia-dart

Seeing “Hello, Fuchsia!” on the console might not seem much, but actually that is quite impressive. It means that Fuchsia is advanced enough to run a complex interpreter environment, and run the script. This implies process management, thread management, memory management, file I/O and much more. It reminds me of Linux when it was first released, pre v1.0.

What does it all mean?

The first thing we can glean about Fuchsia OS is that Dart will play an important role. The current distribution doesn’t include and C compilers or other high level languages like Java, however Dart is there and working. Since Google has invested heavily in Dart this could mean that Google is working on a device that runs Fuchsia and will be programmed via Dart. A VR device maybe?  A home automation product? An intelligent device for accessing Google’s huge AI infrastructure? We also know that the Flutter project now works on Fuchsia. Flutter is a way to build high-performance, cross-platform mobile apps using Dart.

We also know that Fuchsia isn’t aimed at embedded systems (with just a few K of memory), it is for larger devices, from smartphone sized upwards. The idea that Fuchsia is some kind of desktop OS to compete with Windows or OS X, is in my opinion absurd. As are the notions that it is a replacement for Android or Chrome OS. For any OS to succeed commercially it needs to have a thriving and dynamic developer community. Google has invested millions in building up a developer community around Android and it isn’t about to jeopardize that.

fuchsia-boot-apps

Lastly it is worth repeating that Fuchsia is in its infancy. There is currently no graphical user interface (and it isn’t guaranteed that there will be one in the end). There is no consumer level distribution or installer, everything needs to be built from source. The number of commands and libraries is limited and so on. Having said that for those who understand the complexities of OS design, Fuchsia is progressing nicely.

The purposes and goals of Fuchsia are still a mystery, however it is a serious undertaking. Dart is certainly key, as is Flutter. It will be interesting to see where this goes. Any thoughts? Please let me know in the comments below.

Gary Sims
Gary has been a tech writer for over a decade. Prior to that, he had over 10 years of experience as a software engineer.