Google’s Fuchsia OS runs on a little bit of Magenta

Both of Google's extant operating systems, the Android OS for mobile devices and Chrome OS for chromebooks, are based on the Linux kernel. In case you haven't heard, though, Google has another operating system under development—and it isn't based on Linux. Google says the so-called Fuchsia OS is meant for "modern phones and personal computers with fast processors [and] non-trivial amounts of RAM."

Fuchsia is built upon a new microkernel called Magenta that is loosely based on the "littlekernel" embedded kernel. Using a microkernel means that Fuchsia can neatly sidestep some of the issues that have plagued Android devices, like slow updates for device drivers. The new kernel is also a huge flying leap into the unknown: unless hardware vendors pile on their support, the devices which can run Fuchsia will be limited. So far, Fuchsia supports x86 PCs as well as Qualcomm's Snapdragon 835 SoC.

Applications written for Fuchsia should have no such problems, at least. The OS is tightly integrated with Google's Flutter SDK, which produces cross-platform code for Android and iOS. Flutter apps themselves are written in the Dart programming language. While Dart began life as a replacement for Javascript, it has grown to become a highly-capable interpreted language. Google purportedly even uses it for some of its in-house systems, like AdWords.

Google has likely been working on the new OS since early last year, but the first public release of Fuchsia was this past August. At that time, the OS was little more than a command line and a few test applications. Recently, Kyle Bradshaw over at Hotfix IT wrote up some instructions for how to build a copy of Fuchsia and its new demo interface called Armadillo. You can check his video above showing off the UI for the operating system, or hit up Ars Technica for a full preview of what Fuchsia could look like on smartphones.

Image: Ars Technica

It's not yet completely clear what Google intends to use Fuchsia for. The OS could be a replacement for Android, Chrome OS, or both. It also could feasibly be intended as a competitor for Microsoft's Windows, although any such aspirations are likely far down the road for the fledgling system. We could speculate for days on Google's intentions, but at this early stage it seems more prudent to simply wait and see where Fuchsia ends up.

Comments closed
    • VincentHanna
    • 5 years ago

    You asked for an explanation in layman’s terms, and received one. A pretty good one.

    Now you are arguing.

    • bhtooefr
    • 5 years ago

    Microkernel isn’t necessary to have a stable ABI for drivers, and it isn’t a modular kernel (Linux can take kernel modules, but it’s a monolithic kernel – but it doesn’t have a stable ABI, so modules have to be compiled for your kernel, not just Linux in general).

    Microkernel means that (simplifying a bit) traditional kernel components (like drivers) run as normal (but privileged) processes, and aren’t part of the kernel at all.

    • Laykun
    • 5 years ago

    Apps for the new OS are built on an SDK that supports Android and iOS, this SDK however is not the defacto standard of Android development, with a lot of developers still having their code exist in a Java or C++ codebase specifically for Android (ART). I doubt there are many apps at all that exist on the aforementioned Flutter SDK since it mostly seems to be Google that uses it and compared to Android it’s relatively new (it also currently ONLY supports iOS and Android).

    Creating a container for Legacy Android apps to run on Fuchsia would only re-introduce the Oracle problem, as you still need the ART which uses Java APIs to run the apps, I don’t think you’ll see Android apps coming over to this new OS without being re-implemented in Flutter/Dart.

    • frenchy2k1
    • 5 years ago

    Micro kernel allows to load “modules” on the fly.
    A monolithic kernel requires every desired module to be compiled in.

    On desktop, most distribution just compile most modules (and drivers) in. This is not much of a problem as resources abound, but in embedded, being able to choose your configuration easily instead of fixing it at compilation is a big plus.

    Micro kernel was always the design goal for GNU (with their hurd kernel), but linux came before.
    The problem of micro kernel is that all infos need to be exchanged through messages, whereas a monolithic kernel will just pass memory pointers, so it can add processing time to cross all those boundaries.

    Some well known embedded systems (like QNX) use micro kernel.

    • willmore
    • 5 years ago

    Good point, I should have worded it as ‘the two main’ rather than making it as exclusive sounding. Sorry about that. There’s plenty of blame to go around on this issue.

    • Turd-Monkey
    • 5 years ago

    I believe microkernels use syscalls / IPC interfaces which are simpler and less likely to change compared to the (global) functions and structs invoked/used directly in monolithic kernel driver code.

    It will be interesting to see how it plays out if/when Android moves to it.

    • LostCat
    • 5 years ago

    Chrome OS seems reasonably supported at least. I won’t know what to think of this other than ‘at least it should be better than Android’ until it’s released.

    • WasabiVengeance
    • 5 years ago

    I can absolutely understand that, but there’s nothing about Fuschia so far that implies that it will be better supported than Android.

    • LostCat
    • 5 years ago

    At this point I’m all about anything but Android, so could be cool.

    • tay
    • 5 years ago

    The transformation to iOS continues.

    • slowriot
    • 5 years ago

    Right… which comes from them creating the driver interface for the microkernel and intentionally maintaining the compatibility. It’s not something inherent to the design of microkernels (as far as I can tell).

    • DancinJack
    • 5 years ago

    You’re missing at least one more major reason (and probably more we don’t necessarily know about), but I don’t think anyone would disagree with the two you listed.

    • willmore
    • 5 years ago

    The reason it’s so hard to update Android system software comes from two main things:
    1) crappy vendor or carrier customizations and software ‘pack in’.
    2) older devices not having the resources to run newer versions of Android–missing codec support, insufficient RAM, etc.

    The first one is the fault of the carriers and the vendors and they rightly deserve a lot of blame for their role in this mess. But, the latter one is completely due to the feature creap that Google has introduced in new versions of Android. As much as I’d like to fault them for it, they are no different in what they’re doing than Khronos or Microsoft are for requiring certain hardware features in a GPU for it to be compliant with newer OpenGL or DX versions. Though, some of the requirements for certain features seem gratuitous–Google claims they’re actually to make development of apps easier by guarantying a higher baseline of required features.

    • TheRazorsEdge
    • 5 years ago

    If Google maintains their own kernel, they can specify a standard driver interface (like Windows does). Anyone who wants to write a driver can do so more easily.

    In addition, as long as they keep the driver interface the same, an existing driver should work perfectly fine with a newer OS.

    Traditionally, Linux drivers are open source and included in the kernel, so the Linux driver interface can change frequently. This is useful for the kernel developers, but it makes more work for developers of 3rd-party drivers (aka, proprietary drivers).

    Most phone/tablet SoCs do not have fully-functional open source drivers. Thus, it requires a significant commitment from the SoC vendors, device manufacturers, and/or Google to support a new version of Android on older SoCs—and the manufacturers of SoCs and devices have no financial incentive to contribute.

    If Google establishes standardized driver interfaces, they accomplish two goals: (1) It is easier for 3rd parties to develop drivers, and (2) It is easier to update devices to newer kernels.

    Of those two considerations, I’m sure they are banking on #2. Better support and the ability to roll out new features will allow them to compete against Apple and keep ahead of upstart competitors. That first benefit will primarily help niche hardware, as mainstream SoC vendors will only save a small amount.

    • TheRazorsEdge
    • 5 years ago

    Except there doesn’t seem to be a compatibility break.

    Apps for the new OS are built in the same SDK that supports Android and iOS. At most, your apps should only need a rebuild.

    On top of that, all Android apps run in a virtual container. So Google could reimplement this container on the new OS if they wanted 100% compatibility. If they do so, then existing APKs could just be copied right over.

    It’s hard to say for sure what will be supported on an unfinished OS, but it is certainly feasible to maintain application compatibility.

    • slowriot
    • 5 years ago

    I’m just not sure how moving to a microkernel bypasses that on consumer devices.

    • bthylafh
    • 5 years ago

    Basically with Linux if you have a proprietary driver (as most Android devices do) then you’ll have to recompile and retest your driver for a new kernel point release*, and pretty much no OEM bothers. For example my Nexus 5 is still on kernel v3.4.

    Slow Android updates in general is a separate problem with different causes.

    * why is a long and contentious story; basically Linus doesn’t want to bother with maintaining a stable binary driver interface like Windows has, and the official solution is for OEMs to open-source their drivers so they can be included in the kernel tree. OEMs tend to not want to because of perceived competitive advantage.

    • tipoo
    • 5 years ago

    I wonder how much of this was motivated by dumping GPL for Linux, and the Oracle headaches for Java.

    It’ll have a long road ahead of it, being a clean break from Android compatibility though.

    • DPete27
    • 5 years ago

    [quote<]Using a microkernel means that Fuchsia can neatly sidestep some of the issues that have plagued Android devices, like slow updates for device drivers.[/quote<] Can someone explain this in layman terms? I thought the biggest disadvantage of Android is that everyone likes to skin their own version, which prevents one entity [Google] from pushing updates to all devices. Come to think of it, that's kindof the problem with Linux desktop OS in general, no one unified platform. Having a hard time understanding the what niche Fuchsia fills, both now and in the future. Is this a replacement for Android altogether?

Pin It on Pinterest

Share This

Share this post with your friends!