Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by BeauHD on from the not-what-it-looks-like dept.

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.

52 of 245 comments (clear)

  1. interesting by Anonymous Coward · · Score: 3, Insightful

    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.

    1. Re:interesting by iggymanz · · Score: 2

      sure, great for a single purpose appliance. for a modern smartphone or tablet not so much

    2. Re:interesting by Anonymous Coward · · Score: 4, Informative

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

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

    3. Re:interesting by drinkypoo · · Score: 2

      old blackberry is an abacus next to modern smartphone. Note they now use Linux kernel. microkernel can't cut it.

      Don't you remember when QNX gave away a Unixlike distribution? It was totally usable as a desktop.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:interesting by Anonymous Coward · · Score: 3, Insightful

      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.

    5. Re:interesting by thinkwaitfast · · Score: 2

      And it fit on a 1.2MB floppy disk - with GUI. I forgot about QNX. It was a lot of fun to play with. Real time systems got it right (as opposed to pre-emptive).

    6. Re:interesting by Pinky's+Brain · · Score: 3, Interesting

      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.

    7. Re:interesting by phantomfive · · Score: 3, Insightful

      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.

      --
      "First they came for the slanderers and i said nothing."
    8. Re:interesting by phantomfive · · Score: 2

      The Blackberry with QNX was usable, smooth, and had a great programming paradigm. QNX is a great operating system.

      --
      "First they came for the slanderers and i said nothing."
    9. Re:interesting by thinkwaitfast · · Score: 2

      I saw a qnx demo of a bouncing cube and realtime video playing on the different sides of the cube - and it was running on low end hardware (by today's standards) and kb and mouse inputs with zero lag, no matter how heavily loaded (my favorite feature of well done realtime systems). I got a personal tour of their offices in the 90's. I'm pretty sure it could handle a cell phone without problem.

    10. Re: interesting by Brockmire · · Score: 2

      You're uninformed. The QNX one was for BB10, not BBOS4-7. It was a much better multitasker than iOS.

    11. Re:interesting by shoor · · Score: 4, Informative

      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,

      --
      In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
    12. Re:interesting by Actually,+I+do+RTFA · · Score: 5, Insightful

      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!
    13. Re: interesting by khb · · Score: 2

      Spring (https://en.m.wikipedia.org/wiki/Spring_(operating_system)?wprov=sfti1 ) beat many of the performance issues. Chorus too, but with different solutions. Linux is not the beginning nor the end of OS development. Kudos to Google management for making the investment

    14. Re:interesting by zilym · · Score: 5, Informative

      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.

    15. Re:interesting by zilym · · Score: 2

      It's one of the steps toward that goal. By eliminating the Linux kernel and using only stuff they invented at Google, they can later pull the rug out from under open source software by simply changing the licensing terms to what is now entirely THEIR software.

      At the moment, with a Linux kernel underpinning the Android ecosystem, it's impossible for them to completely close the door on open source because plenty of outside Linux developers aren't going to go for that. Get rid of the Linux kernel though and those guys will have no say on future license terms.

      "Do No Evil" becomes "Do Know Evil."

    16. Re:interesting by LostMyBeaver · · Score: 5, Interesting

      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

    17. Re:interesting by LostMyBeaver · · Score: 2

      I worked on the first major device running QNX as a kernel for an interactive device. It was the most difficult platform I ever coded for and to be honest, there were many things which were very problematic with the platform.

      I do chalk most of this up to QNX being an RTOS as opposed to it being a Microkernel.

      These days, with multi-core CPUs everywhere, I think the whole Microkernel/message passing vs everything else is basically irrelevant since the real-time stuff can be run on one core while everything else runs elsewhere. In fact, if most of the rest of the system is written as an OS within an OS... the scheduler and message dispatch mechanism should be fine.

    18. Re: interesting by q_e_t · · Score: 2

      I was saddened when it was no longer free. I was tempted to use it on the desktop.

    19. Re:interesting by religionofpeas · · Score: 3, Informative

      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.

    20. Re: interesting by mSparks43 · · Score: 3, Insightful

      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.

    21. Re:interesting by swillden · · Score: 2

      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.

      Care to make a wager on that? I've got $10K that says you're wrong.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    22. Re:interesting by AmiMoJo · · Score: 3, Interesting

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    23. Re: interesting by mSparks43 · · Score: 2

      eh, all android userspace is open source, its how we have lineageOS. They have to, its covered under the gpl. The only bits that aren't OS are google apps like the play store, gmail and google maps, which run on any old jvm.

  2. DOA by datavirtue · · Score: 2, Insightful

    Stupid name. Dead on arrival.

    --
    I object to power without constructive purpose. --Spock
  3. Fuchsia? by TiberiusKirk · · Score: 3, Insightful
    "You've probably seen mentions of the Fuchsia operating system here and there since..."

    Um, no. Never heard of it.

    1. Re:Fuchsia? by datavirtue · · Score: 4, Funny

      Is this really pronounced Fuck-See-Uh?

      --
      I object to power without constructive purpose. --Spock
    2. Re:Fuchsia? by squiggleslash · · Score: 2

      Is the new hipster thing to do to come to Slashdot, wade into the comments section, and post that you don't read Slashdot?

      Because that's just weird. Really. Bad enough when someone builds a mechanical clone of a Pentium out of Lego and squirrel spit and someone insists on posting here that this is a total waste of time and why would anyone do this, but it's a new level of laziness to just post that you don't read Slashdot at all and have no idea what this thing is that Slashdot posts regularly about.

      --
      You are not alone. This is not normal. None of this is normal.
  4. Google is just asking for it by ArhcAngel · · Score: 4, Funny

    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
    1. Re:Google is just asking for it by Bruce+Perens · · Score: 3, Funny

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

      --
      Bruce Perens.
    2. Re:Google is just asking for it by williamyf · · Score: 2

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

      Well, maybe there are a lot of hinduists, budhists and Confucionists working there that do not care to call that "the Book"...

      May I sugest calling it the Cathiloic Orange Bible, or better yet, the Catholic Fuschia Bible to avoid any posibility of "Smitening"? ;-)

      --
      *** Suerte a todos y Feliz dia!
    3. Re:Google is just asking for it by williamyf · · Score: 2

      I meant this:

      https://en.wikipedia.org/wiki/...

      --
      *** Suerte a todos y Feliz dia!
  5. Re: So basically it's Linux without the Linux kern by MightyMartian · · Score: 2, Funny

    The villagers quaked, dropped their tools and ran for the safety of the caves in the hills, for that most feared of creatures, that most fearsome and angry of bearded protean gods, Richard Stallman, was stirring.

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  6. Fuchsia Is Not Linux by Pfhorrest · · Score: 5, Funny

    ...and that's FINL!

    --
    -Forrest Cameranesi, Geek of all Trades
    "I am Sam. Sam I am. I do not like trolls, flames, or spam."
  7. Fuchsia kernel (Zircon) is a lot like Windows by Anonymous Coward · · Score: 2, Informative

    Zircon has a unified system to manage the lifetime of, and control access to, all kernel objects. It feels very much like the Windows kernel. The way Zircon uses handles, and the zx_object_wait_one() and zx_object_wait_many() functions, really show the Windows influence. I personally think this is a Good Thing -- my disagreements with Windows lie mostly in user mode -- but YMMV.

    Just to be clear... I'm not saying Zircon is a Windows clone -- just that I see clear influence from Windows.

    1. Re:Fuchsia kernel (Zircon) is a lot like Windows by jedidiah · · Score: 4, Insightful

      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.
    2. Re:Fuchsia kernel (Zircon) is a lot like Windows by Pseudonym · · Score: 2

      FWIW, I mostly agree. NTOSKRNL is very well-designed kernel by 1990 standards, and it still mostly holds up today. The lack of a unified event system, for example (e.g. wait on a socket and a condvar), is one of the outstanding issues in Linux. (For completeness, FreeBSD's kqueue almost does the job, and libevent makes things a bit less painful.)

      The main problem with Windows NT is not the kernel design, it's almost everything else.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  8. Re:Will it (finally) prioritise the user ? by Bruce+Perens · · Score: 4, Insightful

    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.
  9. Now there are 3 capability systems, in the works.. by ka9dgx · · Score: 3, Funny

    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.

  10. Re:Will it (finally) prioritise the user ? by 110010001000 · · Score: 2

    I think you just proved his point. You sound like a computer engineer and those things sound "worse" to you, because that isn't how it has been done in the past. It does make sense to prioritize the interactive task, and all resources that the interactive task uses, even down to the system level. It may not be possible with current systems, but that is computer engineer thinking. It may not be a good idea either.

  11. Re:Will it (finally) prioritise the user ? by Bruce+Perens · · Score: 2

    Actually, you're asking for the OS to break its promises in the name of interactivity uber alles. So, the system throws away its buffered I/O. What goes wrong after that? Quite a lot, actually.

    --
    Bruce Perens.
  12. Re:Good riddance by Jerry · · Score: 2

    It wasn't Linux. It was the Java code surrounding it.

    --

    Running with Linux for over 20 years!

  13. Re:Will it (finally) prioritise the user ? by Anonymous Coward · · Score: 2, Interesting

    CS 101. You are referring to deadly embraces and wait/stall times queuing depth.
    Interrupt handling is a complex thing.
    IBM has already mapped all the considerations -thats why ZOS is reliable.
    CPU Failure
    Power fail
    Memory Fail
    Quiesce hardware
    VM semaphores
    SLIP trace

    We are still waiting for toy operating systems and garden variety PC chps to catch up to DEC rabbits or VM/CMS,

  14. Re:Meanwhile I stick to iOS and Mac OS. by jedidiah · · Score: 2

    > Mac OS is certified UNIX dumbass.

    MacOS deviates from other Unixen so badly at anything but the lowest level that a MacOS user would find the differences an intolerable level of consistency.

    They annoy AIX admins too.

    --
    A Pirate and a Puritan look the same on a balance sheet.
  15. Re:if That's the case... by jedidiah · · Score: 2

    > ...what need is there ever for Linux? Just use UNIX, right?

    I tried back in the day. The commercial Unix distributions didn't support commodity hardware. I would have paid the Iron price for them too. I drew the line at rebuilding my PC with unnecessarily expensive parts.

    --
    A Pirate and a Puritan look the same on a balance sheet.
  16. Re: Will it (finally) prioritise the user ? by Brockmire · · Score: 2

    Makes sense you didn't mention BB10. I was floored when I heard YouTube video playing while not the main app didn't play on iOS but was easily done on BB10. Until low battery power save kicks in, the OS is responsive.

  17. Re:Will it (finally) prioritise the user ? by IMightB · · Score: 2

    Y U argue with Bruce Perens?

    I'm amazed that he finds time to waste on /. anymore. Thanks for chiming in Bruce!

  18. Re:Will it (finally) prioritise the user ? by jdschulteis · · Score: 2

    Don't know about the task priority but the Amiga UI was definitely amazingly responsive, and that was with a 7.16 MHz CPU (I had a RAM expansion that pushed the total to a whopping 1.5 MB). Sure, the Amiga 1000 didn't have virtual memory, or networking, but my current machine has 4 cores, each running over 300 times the clock speed, 20,000 (!) times the RAM, and software that still sometimes forgets that the person is the most important part of personal computing.

  19. When asked, Richard Stallman had this to say: by douglips · · Score: 3, Funny

    "I really must insist you call it GNUschia."

    --
    My amazing wife - Artist, Author, Philosopher - Laurie M
  20. Re:Translation by TheRaven64 · · Score: 2

    Nope, Fuchsia is a microkernel inspired by Spring, seL4 and others. The low-level APIs are very different from Linux, as is the structure of the OS. It is able to run the Android Runtime, and can support a POSIX compatibility layer (though that's not what it's designed for).

    That said, recent Android's Project Treble moves a load of device drivers out of the Linux kernel and into userspace, which would make it much easier to provide versions that work with both Linux and Fuchsia.

    --
    I am TheRaven on Soylent News
  21. Re: Meanwhile I stick to iOS and Mac OS. by q_e_t · · Score: 2

    Based on, not based off.

  22. Re:interesting-licensing. by Anne+Thwacks · · Score: 2
    BSD has been available as a license as long as the GPL.

    Wasn't the BSD licence there 20 years earlier?

    --
    Sent from my ASR33 using ASCII