Slashdot Mirror
'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.
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.
Is this really pronounced Fuck-See-Uh?
I object to power without constructive purpose. --Spock
Naming their manuscript "The Book". I mean God is merciful but taking the same name as His manuscript just might be smiteworthy.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
...and that's FINL!
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
Blackberry used QNX, a microkernel based OS used in lots of real-time applications.
Yeah, the device failed, but not because of the microkernel.
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.
Bruce Perens.
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.
A Pirate and a Puritan look the same on a balance sheet.
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:
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
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.
Your ad here. Ask me how!
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.
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