'Fuchsia Is Not Linux': Google Publishes Documentation Explaining Their New OS (xda-developers.com)

An anonymous reader quotes a report from XDA Developers: You've probably seen mentions of the Fuchsia operating system here and there since it has been in development for almost 2 years. It's Google's not-so-secretive operating system which many speculate will eventually replace Android. We've seen it grow from a barely functional mock-up UI in an app form to a version that actually boots on existing hardware. We've seen how much importance Google places on the project as veteran Android project managers are starting to work on it. But after all of this time, we've never once had either an official announcement from Google about the project or any documentation about it -- all of the information thus far has come as a result of people digging into the source code.

Now, that appears to be changing as Google has published a documentation page called "The Book." The page aims to explain what Fuchsia, the "modular, capability-based operating system" is and is not. The most prominent text on that page is a large section explaining that Fuchsia is NOT Linux, in case that wasn't clear already. Above that are several readme pages explaining Fuchsia's file systems, boot sequence, core libraries, sandboxing, and more. The rest of the page has sections explaining what the Zircon micro-kernel is and how the framework, storage, networking, graphics, media, user interface, and more are implemented.

Comments

interesting

[Anonymous Coward]

It looks like an interesting kernel using microkernel ideas. It should be interesting if they can get around the latency for process switching and message passing.

Re:interesting

[Anonymous Coward]

Blackberry used QNX, a microkernel based OS used in lots of real-time applications.

Yeah, the device failed, but not because of the microkernel.

Re:interesting

[Anonymous Coward]

Did you come here to be an ass?

You do realize most microkernels suffer from those 2 issues. It will be interesting what they do to work around it. You know maybe advance computer science forward a bit? You know by studying it. Even Apples kernel uses bits of ye-ol MACH. Which is a derivative of that. They got around it by putting parts of the user process in kernel space. So not a 'pure' implementation as it were. And yes I may know a bit more about it than you assume.

Re:interesting

[Pinky's Brain]

Intel has 4096 process ID's now, so that's a lot of stuff in kernel space which could get it's own process space. AMD has address space ID's, but those are meant for virtualization, don't know if they could be abused for microkernel isolation. ARM has 16 domain IDs.

The popular ISAs all allow more than the old kernel/user space division now. It's time to move on.

Re:interesting

[phantomfive]

Microkernels work fine, they just take (up to) a 30% performance hit depending on the workload. So you are making a tradeoff between crashing when you find a bug and speed.

I will tell you the problem with Android bugs is not in the kernel. This is a severe case of NIH. The biggest problems in Android come from Google themselves.

Re:interesting

[shoor]

The early microkernels had problems, but a 2nd generation of 'L4' kernels, pioneered by Jochen Liedtke (who died an untimely death at age 48) seems to have gotten around that. From the wikipedia article on L4 microkernel family:

The poor performance of first-generation microkernels, such as Mach, led a number of developers to re-examine the entire microkernel concept in the mid-1990s...
Detailed analysis of the Mach bottleneck indicated that, among other things, its working set is too large: the IPC code expresses poor spatial locality; that is, it results in too many cache misses, of which most are in-kernel...
Liedtke came to the conclusion that several other Mach concepts were also misplaced. By simplifying the microkernel concepts even further he developed the first L4 kernel which was primarily designed with high performance in mind. In order to wring out every bit of performance the entire kernel was written in assembly language, and its IPC was 20 times faster than Mach's.[4] Such dramatic performance increases are a rare event in operating systems, and Liedtke's work triggered new L4 implementations and work on L4-based systems at a number of universities and research institutes,

Re:interesting

[Actually, I do RTFA]

It's not a severe case a of NIH. It's a severe case of GPL. This is just so they can move all the Android devices to Fuchsia (under permissive licenses), and then slam the door shut by requiring things for new Fuchsia devices once the whole ecosystem has moved over. It's an evolution of what they started to do with GApps.

Re:interesting

[zilym]

Android is far away from Linux, but it still has the Linux kernel at its core. I recently wrote an app that uses Linux ioctls to talk to a USB device from native code in order to achieve minimal latency. Sure, I have to initially get things going from Java to obtain permissions in Android, but once I've got the file descriptor for the USB device I want to talk to, I'm off to the races.

Re:interesting

[LostMyBeaver]

Actually, Google will make Fuschia work as a smartphone/tablet platform and whatever else. From a design perspective, it's actually quite bad.

When I first started reading the code to Fuschia, I was going line by line asking myself "Haven't we already made this mistake before?". It was like one major compilation of "I took an OS course based on Tananbaum's book and decided just to copy every mistake we never learned from". And in the end we have a brand spanking new 30 year old operating system.

Ok, I'm being harsh and it's only partially fair. Let me start with your issues.

It's not necessary to sort out the issues with latency and message passing. They are making a real-time (or near real-time) operating system which in its own right already suggests that they're willing to sacrifice performance in favor of deterministic time. Telephones always benefit from real-time kernels in the sense that it allows dropping overall transistor and component count. Every telephone which ever boasted 4 day batteries ran real-time operating systems and it was generally a good idea.

Secondly, there's been a pretty huge move in Firefox and Chrome to optimize their shared memory systems to reduce or eliminate hardware locks by marshalling the memory reads and writes. Add to that that almost all modern development paradigms are asynchronous programming... unless you're stuck with some shitty language like C or C++, and most of the switch and latency issues are irrelevant. This is because you can keep multiple cores spinning more or less non-stop without much concern for kernel level inter-thread synchronization. Take it a few steps further and expose things like video hardware access directly to individual applications that would operate their own compositors based on a GPU context and apply shaders to support windowing type tasks... then it's going to be quite impressive and the locks should be a lot less relevant.

From that perspective, I don't see a good solution to the audio problem as I've never seen a sound card which would support the principle of shared resources. I don't think it would be even mildly difficult to design such a device though. The only real issue is that if mixing is moved entirely to hardware, then depending on the scenario, it would be necessary to have at least quite a few relatively long DSP pipelines with support for everything from PCM scaling to filtering. There's the other problem which is that protection faults to trigger interrupts could be an issue unless there's some other creative means of signalling user mode code of buffer states without polling. Audio is relatively unforgiving of buffer starvation.

So, let's start on my pet peeves.

Google's been working on this for some time and they still don't have a system in place for supporting proper languages. C and C++ are nifty for the microkernel itself. But even then, they should have considered Rust or rolling their own language. This world has more than enough shitty C based kernels like Linux and BSD. If you want to search the CVEs and see what percentage of them would never have been an issue if the same code was written in a real programming language, be my guest, but I'm still sitting on WAY TOO MANY unreported critical security holes in things like drivers from VMware, drivers from Cisco, OpenVPN certificate handling code, etc... I absolutely hate looking at C or C++ code because every time I do, unless it's painfully static in nature, it's generally riddled with code injection issues, etc...

And yes, I've been watching Magenta/Fuschia evolve since the first day and I follow the commit logs. It's better than TV. It's like "We have a huge number of 22 year old super hot-shot coders who really kick ass. Look at this great operating system kernel" and it looks like some bastard high school or university project written by people who have little or no concept of history.

Linux is good for many things. It's amazing for many reasons. Linus did an amazing job making it and it's a force of natur

Re:interesting

[religionofpeas]

The problem with microkernel performance is not due to latency for process switching and message passing.

The problem is the synchronization between different parts. Imagine for instance a multi-threaded filesystem. A filesystem as whole has a certain state. That state describes all the files and directories, file sizes and contents. Now imagine that one of the threads makes a change to the state. The problem is how to get that state update to all the other threads with a minimum of a delay.

In a monolithic kernel, the problem is solved by getting a lock, update the state, and releasing the lock. It's a very simple and efficient operation.

In a microkernel, you need to send messages around. You can optimize the message passing itself, but you'll still have the problem that the receiving thread is doing other things, and only handles the messages at certain points. While it is doing those other things, it's working with an outdated version of the state. Basically you're getting into the design of distributed filesystems/computing, and this is a very hairy subject. The complexity of the problem is much larger than just sticking to simple locking.

The traditional solution is to keep the filesystem (and similar parts of the OS) in a single thread. This may be a viable solution on some platforms (perhaps a phone or tablet), but it will quickly run into scalability problems on a large, general purpose computer.

Re: interesting

[mSparks43]

Android is a java vm running on a linux operating system. And works.
Fuchsia is googles attempt at writing its own operating system, but like most every bit of software i have ever seen google write, it doesn't actually work.

Re:interesting

[AmiMoJo]

This world has more than enough shitty C based kernels like Linux and BSD. If you want to search the CVEs and see what percentage of them would never have been an issue if the same code was written in a real programming language

This is a very outdated security model, one which any really secure OS has abandoned long ago. Security by eliminating all bugs is just deluding yourself into thinking that's even possible. Relying on a "safe" language to do it for you is even more foolish.

In fact that appears to be why Google is developing this OS. It's designed to be secure, in a way that building sandboxes on top of Linux or Windows can't be. The microkernel is necessary for this.

This security model is proven to work. It's how all modern operating systems try to implement security, but it's tacked on later rather than designed in from the kernel up.

Fuchsia?

[TiberiusKirk]

"You've probably seen mentions of the Fuchsia operating system here and there since..."

Um, no. Never heard of it.

Re:Fuchsia?

[datavirtue]

Is this really pronounced Fuck-See-Uh?

Google is just asking for it

[ArhcAngel]

Naming their manuscript "The Book". I mean God is merciful but taking the same name as His manuscript just might be smiteworthy.

Re:Google is just asking for it

[Bruce Perens]

Make sure to read the chapter on the Holy Hand Grenade of Antioch.

Fuchsia Is Not Linux

[Pfhorrest]

...and that's FINL!

Re:Will it (finally) prioritise the user ?

[Bruce Perens]

Well, you're not really asking that the system never have priority over the user. You're asking that your interactive task have priority over everything else. The system is responsible for reading what you type on the keyboard, for example, so in that case the system should have a very high priority so that it can service your interactive task.

I suspect that what is bothering you is a process that is blocked on I/O, or your computer is starved for resources and swapping (which means everything gets blocked on I/O).

Ultimately this comes down to the system attempting to keep all of the promises it's already made to you. Most of the time these promises are buffered writes which it has in RAM, and is pushing to your really slow USB drive or SD card as fast as it can. You interrupt it, but this does not interrupt the promises already made.

Ultimately the fix is adding more expensive hardware, like a disk that won't make you wait.

Now there are 3 capability systems, in the works..

[ka9dgx]

So, this can join GNU Hurd and Genode in the queue of things that we all need, but nobody (else) knows it yet. I look forward to running on of these, some day, so I can ditch the virus scanners, and surf the web in perfect safety... downloading and running whatever I want without worry.

Re:Fuchsia kernel (Zircon) is a lot like Windows

[jedidiah]

David Cutler likely didn't have to "steal" anything. It was already in his head. All he had to do was just spit it out again.

David Cutler stole David Cutler.

When asked, Richard Stallman had this to say:

[douglips]

"I really must insist you call it GNUschia."