'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

[Chris Mattern]

Microkernel? Oh, god, just bury it now. Microkernels have been the coming thing for decades now, and they never make it work.

Re:interesting

[thinkwaitfast]

latency for process switching

Has this been a problem for decades on user devices?

Re:interesting

[thinkwaitfast]

I've worked on a number of microkernel systems with no problems. They are used in many many consumer and industrial embedded systems.

Re:interesting

[iggymanz]

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

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

[thinkwaitfast]

Why? Single purpose appliance can still run hundreds of applications simultaneously (bit, logging, control, monitoring, databases access. All in real time). I did testing on hardware maybe 15 years ago with 10,000 threads showing a 1-2% context switch overhead.

Re:interesting

[iggymanz]

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

Re:interesting

[drinkypoo]

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.

Re:interesting

[Anonymous Coward]

QNX (now owed by Blackberry) is a major player in embedded systems and has been for well over a decade, and it is a very pure, solid, and commercially-successful 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

[rickb928]

'single purpose'.

I don't think you know what the hell you're writing about. A robotic vacuum cleaner might meet the definition of 'single purpose', but what that's relatively primitive. So microkernel should be considered appropriate for toasters, etc?

Tell that one to Apple. Or BlackBerry.

Re:interesting

[Pinky's Brain]

On x86, yes. That's why user space drivers suck for things with frequent calls.

Re:interesting

[thinkwaitfast]

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).

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

[PhunkySchtuff]

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

So, obviously iPhones and iPads are no good then as they run the Mach microkernel. I mean, it's clear by their marketshare that it's a dead-end system.

Re: interesting

[lordwabbit9046]

So if market share is the indicator of a good system windows is the bomb!

Re:interesting

[Bruce Perens]

Blackberry, on the other hand, is a company that once bought QNX because they though having a really good kernel would save their product. Users don't see or care about kernels. Remember this lesson. Now, there is essentially nothing but QNX left of Blackberry.

Re:interesting

[PCM2]

Yeah, but this wasn't the "really, really old" BlackBerry you may be thinking of. BlackBerry devices based on QNX didn't start shipping until 2013.

Yeah ... you've never seen one in the wild.

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

[phantomfive]

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

Re:interesting

[zennyboy]

Gosh, I remember when Commodore suggested that the next Amiga might use QNX, before they fell over and died....

Re:interesting

[thinkwaitfast]

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.

Re: interesting

[Pseudonym]

As I understand it, Apple was compelled to violate the basics of microkernels at many points, [...]

You understand wrong, but you're not alone. Apple broke the rules of 1990s microkernel fundamentalism, which are not the same as "basics of microkernels".

Re:interesting

[Pseudonym]

IIRC, this issue was pretty much fixed since the advent of PCID. Also, it was never as much of an issue on ARM.

Re: interesting

[Brockmire]

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

Re: interesting

[Brockmire]

You mean "most users". The majority of phone users are now media consumers, not productive business professionals. If the kids could get their social apps on BB10 natively, they'd have succeeded. The HTML5 app future they envisioned didn't allow them app parity like they needed.

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

[phantomfive]

Good point.

Re: interesting

[khb]

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

Re:interesting

[Tough Love]

QNX

Re:interesting

[Anonymous Coward]

isn't it the same 30% performance hit we get with the Meltdown/Spectra patches. These basically are the start of a microkernel

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

[zilym]

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."

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

[LostMyBeaver]

Pretty sure it's about making a replacement for Linux which isn't 30 years of bloat.

As for the license, I believe it's actually more open than Linux.

Re:interesting

[LostMyBeaver]

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.

Re:interesting

[Yaztromo]

Real time systems got it right (as opposed to pre-emptive).

Huh? Real time systems can still pre-empt. Time sharing RTOS' do exactly this. Depending on wether the RTOS is hard of soft; so long as you can deterministically meet a deadline, you can pre-empt and still be a hard RTOS.

Yaz

Re:interesting

[Yaztromo]

Gosh, I remember when Commodore suggested that the next Amiga might use QNX, before they fell over and died....

Look up the Unisys ICON, an 80186 based computer back in the 1980's that ran QNX. They had quite the interesting architecture, and were basically early network computing environments (they had their own local memory and processing, but a centralized network disk share by all systems).

I have fond memories of those machines.

Yaz

Re:interesting

[Yaztromo]

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.

ICON?

Re: interesting

[q_e_t]

Linux is the kernel. Android is not Linux, but used it, but is not GNU/Linux.

Re: interesting

[q_e_t]

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

Re:interesting

[war4peace]

Depending on wether the RTOS is hard of soft; so long as you can deterministically meet a deadline, you can pre-empt and still be a hard RTOS.

That's EXACTLY what she said!

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

[Tough Love]

Wow, your post is an example of what makes Slashdot worth reading. I never coded for QNX myself, and appreciate your perspective, it has the ring of truth.

I just took a look at some of the internal apis for Magenta and it is clear that a kernel built around clunky glue like that can't be anything other than a dog. Will there somehow be a flash of genius to make it magically fast? Don't count on it.

Re:interesting

[SurenEnfiajyan]

So why do you care only about the kernel? Android user-space which is the _most_ of the code isn't GPL. Also how does GPLv2 prevent lockdown and the use of proprietary drivers?

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

[NorthWay]

>Microkernels work fine, they just take (up to) a 30% performance hit depending on the workload.
Yes. On your grandmothers cpu. (She has some mighty hefty cpus though.)

Which is why I am keeping an extremely keen eye on the works of Mill Computing - there should be no difference between monoliths and microliths in their architecture.
(And until Intel fixes their ghosts in the system then the performance is real close there too.)

Re:interesting

[swillden]

I will tell you the problem with Android bugs is not in the kernel.

Go look at the monthly Android security bulletins. It's a rare month that does not have a serious kernel vulnerability. The kernel is the biggest single source of security problems in Android. The Android security team badly wants to replace Linux.

Re:interesting

[swillden]

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.

Re:interesting

[Cesare Ferrari]

Nah, there's little content in what you've said. Real programming languages? I'm going to guess that your real programming languages will keep changing over time to follow the current trend. When producing something long lived like an OS, you want to use established technologies where you know the implications and shortcomings, so something like C is a good place to start.

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.

Re: interesting

[mSparks43]

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.

Re: interesting

[phantomfive]

Yeah I should go look.

Re: interesting

[SurenEnfiajyan]

all android userspace is open source

I know, it's mostly Apache and it's a permissive OSS license. My point is that does the tiny kernel's license permissive really matter when even Linux kernel's GPLv2 doesn't protect you from DRM, closed drivers/libraries and locked bootloaders?

Re:interesting

[haruchai]

"I saw a qnx demo of a bouncing cube and realtime video playing on the different sides of the cube"

I think that was BeOS unless QNX also had a similar demo

Re:interesting

[Faw]

Are you sure it was a QNX demo or the Amiga DE SDK based on TAO intent OS? I still have the Amiga SDK manual for that OS and probably the DVD is hidden somewhere around my house. I actually liked that OS.

Re:interesting

[hairyfeet]

Sooo...its Embrace, extend, and extinguish all over again? Hmmm...and so many here ran to defend Google for being so " GPL friendly" while many of us pointed out they were just as nasty as any other megacorp.

Re:interesting

[rwise2112]

This isn't about advancing computer science. This is them abandoning open source sotware. They're pulling old Microsoft. Embrace, Make slight variations so it only runs on your Linux/java platform, and then destroy.

It's open source. The summary even says 'all of the information thus far has come as a result of people digging into the source code'.

Re:interesting

[Curupira]

No, its a severe case of GPL**3**, where Stallman decided the software being free and open source wasn't enough and instead he also wanted to dictate the hardware.

What? The Linux kernel is licensed as GPL 2 *only*. Is is NOT licensed as GPL 3.

Re: interesting

[Anonymous Coward]

That's an absolutely absurd statement.

Considering how much Google software many of us use daily end-to-end, you'd have to tailor your criteria incredibly narrowly for that to be remotely true, to the point that you're not saying anything meaningful.

Re:interesting

[swillden]

Two months, seven serious kernel vulnerabilities. In these particular months the media and Qualomm components were worse, but those come and go. The kernel vulns are there every month.

Re:interesting

[Anonymous Coward]

>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.

This is how Google developed Golang. It's basically the web backend equivalent of COBOL, but the syntax makes it look like a modern language on the surface.

Re: interesting

[angel'o'sphere]

None of those apps runs on a JVM, they run on a Dalvik VM.
And you keep mixing up what an OS is (Android is an OS) and what an App or a VM is.
E.g. how/on what OS would a C++ App run on an 'Android Device', when Android only would be a VM and not the OS?

Re: interesting

[mSparks43]

What exactly do you think the difference between a JVM and Dalvik VM is?
->how/on what OS would a C++ App run on an 'Android Device',
In exactly the same way you run native C/C++ code on a JVM, via a native code API (in androids case the "NDK")

Which makes sense, because Dalvik is googles "clean room" copy and paste of JVM.

Re: interesting

[angel'o'sphere]

In exactly the same way you run native C/C++ code on a JVM, via a native code API (in androids case the "NDK")
No, C++ Apps run natively, they don't run in an VM/JVM.

Which makes sense, because Dalvik is googles "clean room" copy and paste of JVM.
No it is not.
The Dalvik VM uses completely different byte codes. Dalvik is based on a 256 registers based VM (actually several 256 registers sized register windows) and the JVM is a stack based VM.
They have completely different class file layouts.

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

A Dalvik VM has absolutely nothing in common with a JVM.

The only thing "Java" on Android is the syntax of the language and the classes/API of the core libraries. (java.lang.* and java.io.* and java.util.* etc.)

Re: interesting

[mSparks43]

from your link:
Programs for Android are commonly written in Java and compiled to bytecode for the Java virtual machine

doh.

Re: interesting

[mSparks43]

yes, because you dont have to buy any of that, you can just pick up a raspberry pi 3 for a few dollars and stick LineageOS 14.1 (Android 7.1.2) on it.

Re: interesting

[mSparks43]

the android vm uses translated jvm bytecode, android apps run on any old jvm.

Re:interesting

[Hognoxious]

I think fushia is open source.

/|\ how it's pronounced.

How it's written: fuchsia.

What it does: fucksya.

Re:interesting

[Tough Love]

The kernel formerly known as magenta, and I feel more stupid after reading your post, much less replying to it.

Re: interesting

[angel'o'sphere]

Doh, why did you not read further?
After compiling to ordinary bytecode they get packaged together into a .DEX file and translated to Dalvik bytecode, for the Android VM.
Obviously you have no clue about the topic, but I don't care :)

Re: interesting

[mSparks43]

same reason you don't keep searching for your car keys after you find them.
The answer to 'android has nothing to do with the jvm' being true or not has been found.

Re:interesting

[datavirtue]

"You do realize most microkernels suffer from those 2 issues. "

Yes...due to the laws of physics.

Re: interesting

[angel'o'sphere]

Well, which part of: "on Android runs no JVM" did you not grasp yet?

Anyway, good luck in your Android related endeavors :D

Re: interesting

[mSparks43]

you said
->A Dalvik VM has absolutely nothing in common with a JVM

Java bytecode a fairly substantial commonality in everyones world but yours it seems.

Re: interesting

[mSparks43]

where you get the idea that this https://developer.android.com/... is wrong.

Re:interesting

[KingBenny]

i'm not smart enough to flame and pretend the truth is held by decado old books but wouldnt that require a revision of hardware where the switching itself is handled by a bridge so you dont count cycles of flips or flops or mips or trips because the other components don't need to halt ...

Re: interesting

[iggymanz]

nonsense, they dropped it. can't cut what a modern smartphone does

Re:interesting

[iggymanz]

not for modern smartphone it isn't, that's why they dropped making any new QNX in 2015 with support only since then. Live in the past if you want, but the future is not that type of kernel, it's not up to the job

Re:interesting

[phantomfive]

It's rare that an operating system succeeds (or fails) on technical merits, and you know it.

DOA

[datavirtue]

Stupid name. Dead on arrival.

Re:DOA

[guacamole]

Google is young enough not to remember the demise of the Yggdrasil Linux.

Re:DOA

[Kryptonut]

Really? Microsoft disagrees....their platform, also named after a colour is thriving despite the name.

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?

Re:Fuchsia?

[squiggleslash]

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.

Re:Fuchsia?

[Anonymous Coward]

And on top of that, getting +3 Insightful, for saying nothing except that he doesn't know the subject of the article. Apparently the audience/moderators aren't much better. Maybe it's postmodernism or some other infectuous brain disease, take warning.

Re:Fuchsia?

[TiberiusKirk]

LMAO!!! No, it's insightful in that the subject is so obscure, but Google think that it will be widely adopted. Sorry, but it's Android.

Translation

[sexconker]

Fuchsia is not Linux

Translation: Fuchsia is Linux. We took Linux and hacked away at it to make Fuchsia. Because Oracle won in court recently, we're being a bit more careful at covering our tracks this time.

Re:Translation

[thinkwaitfast]

I've gotten to play with many operating systems..vx, minix, psos, linux, nt, 5 or 6 home grown varieties. They all more or less provide the same primitives - processing, object and temporal and sometimes spacial separation. From the Zircon Kernel Concepts section it looks like the same stuff and concepts as posix...but it did have wait_for_many() from nt land. Don't think posix had that. Maybe borrowed some object ideas from Plan9?

Re:Translation

[TheRaven64]

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.

Re:Translation

[sexconker]

Nope. Fuchsia is the OS. Their kernel is called Zircon.
If they ever ship the thing, come back and remind me so I can laugh at how they ended up copying everything from Linux again. (Hopefully I don't need to find and show you the GNU/Linux / Linux is not an OS copypasta?)

Boots quicker

[AHuxley]

So you are in front of the ads sooner.

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

[viperidaenz]

God shall smite thee! And thou shalt be smitten!

Re:Google is just asking for it

[Bruce Perens]

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

Re:Google is just asking for it

[williamyf]

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"? ;-)

Re:Google is just asking for it

[Anonymous Coward]

Hey now, Catholics aren't the only one who read The Orange Book religiously...

Re:Google is just asking for it

[williamyf]

I meant this:

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

Re:Google is just asking for it

[AmiMoJo]

I figured it was traditional. Many Unix based operating systems have a electronic book as their primary reference guide.

Re: So basically it's Linux without the Linux kern

[MightyMartian]

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.

Fuchsia Is Not Linux

[Pfhorrest]

...and that's FINL!

Re:Fuchsia Is Not Linux

[Anonymous Coward]

But if you install it, it Fuchs ya.

Re:Will it (finally) prioritise the user ?

[murph]

I recall the Amiga working that way. input.device was the highest priority task in the system. I may, however, recall incorrectly, it was a long time ago.

Fuchsia kernel (Zircon) is a lot like Windows

[Anonymous Coward]

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.

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.

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

[Pseudonym]

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.

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

[Pseudonym]

That depends on if you include the file system in the kernel.

NTFS is a driver that happens to be compiled in (because it makes it easier to boot the damn thing if nothing else), so you could go either way on that one

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.

Re:Open source or nay?

[viperidaenz]

https://github.com/fuchsia-mir...

It's an MIT based open source license

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:Will it (finally) prioritise the user ?

[Wrath0fb0b]

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.

If only it was so simple, but in fact it's far worse than this. Not only does the OP want the interactive task to have priority to all possible resources over everything else, but that this priority inherits from this task to every task that is blocking it, including those access over all possible inter-task-communication methods. At the very minimum, it means that all of those IPC mechanisms need to be 'priority aware' and the kernel needs to arbitrate this correctly. It also means that all tasks must migrate away from any IPC mechanisms that don't have the structure to encapsulate the concept of a 'blocking request' -- shmem probably has to go.

In other words, it's not enough to give my topmost process the highest priority to the disk, but if that process reaches to any other process, say a system service, then that process must, for the lifetime when it is services the request from the topmost process, also (temporarily) be granted highest disk priority. In a POSIXy world where processes often connect via (local, not AF) sockets, this means that the socket mechanism itself needs to somehow figure out if the request is blocking or if it is 'background priority'.

Re:Will it (finally) prioritise the user ?

[110010001000]

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.

Re:Will it (finally) prioritise the user ?

[Bruce Perens]

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.

Patent minefield

[Stan92057]

Bet the only thing not patented already or copyrighted is the name of the OS lol

Re:Good riddance

[Jerry]

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

Re:Will it (finally) prioritise the user ?

[zennyboy]

Funny, as an ex Amigan, how often it comes up when Future, Faster, Better is mentioned, the Amiga comes up.

Re:Will it (finally) prioritise the user ?

[Anonymous Coward]

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,

Re:Meanwhile I stick to iOS and Mac OS.

[jedidiah]

> 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.

Re:if That's the case...

[jedidiah]

> ...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.

Sounds like...

[Anonymous Coward]

Pronounced "Fucks Ya".

Re:Meanwhile I stick to iOS and Mac OS.

[i.r.id10t]

Not sure about Real Unix (I've only played with the BSDs a little as CLI-only vms) but the differences between OS X and Linux when you hit the command line are pretty interesting - and annoying. Things like "user preference directories for Firefox and VirtualBox and ... are possibly in 3 different places, with no consistency". My Linux workstation died last December, I grabbed a nice older iMac (mid-2011) with 16gb ram and tried using OS X for 2 weeks, using my normal applications since they are all cross platform or have drop in near identical replacements. Wiped the drive,installed Debian, restored my ~/ and haven't looked back. Nice hardware. LOVE the monitor, and I'm afraid to look at the new ones the graphics guys down the hall have (I can't afford to go buy one....). The OS though is just Too Different for me to deal with when I'm busy with trying to get back to being productive at work.

The should have called is FINL

[goombah99]

FINL is not Linux.

Even better FINAL.

FINAL is not a Linux

Re: Will it (finally) prioritise the user ?

[Brockmire]

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.

Re:Will it (finally) prioritise the user ?

[IMightB]

Y U argue with Bruce Perens?

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

Re:Will it (finally) prioritise the user ?

[Aighearach]

kill -9 pid

Simple.

Or if it was really you that started it,
kill -9 %1

Get you's' a *nix!

Re:Now there are 3 capability systems, in the work

[Aighearach]

If you read the white papers on HURD architecture, they're quite clear that we don't need it, and everybody knows it already. ;)

Re:Will it (finally) prioritise the user ?

[jdschulteis]

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.

Re: Good riddance

[Anonymous Coward]

How is the most deployed kernel in existence a failure?

When asked, Richard Stallman had this to say:

[douglips]

"I really must insist you call it GNUschia."

Re:When asked, Richard Stallman had this to say:

[helpfulcorn]

This was after he had originally insisted it was FuchGNUsia, but changed it after so many complaints at how "awkward" the term was.

Re:Open source or nay?

[DeVilla]

So it'll be about as open source as iOS?

Re: Meanwhile I stick to iOS and Mac OS.

[q_e_t]

Based on, not based off.

Re:interesting-licensing.

[Anne Thwacks]

BSD has been available as a license as long as the GPL.

Wasn't the BSD licence there 20 years earlier?

So many possible puns

[cyber-vandal]

I think I'll go with microkernels are the fuchsia.

Re: Will it (finally) prioritise the user ?

[q_e_t]

No, they are a naturally expressive programming paradigm to and in expressing the problem, which acknowledges the cost of programming effort.

Let Google have complete control over my device?

[Hallux-F-Sinister]

Fuch that sia.

Licensing

[gotan]

The question is: why make such an effort when Linux is already there and can be modified to your needs.

One reason may be, that there is something you want to do fundamentally different, so it's easier to start a new project than change the old one to your needs.

Another thing may be that they want to get rid of (L)GPL-Licensed parts in their OS, and that may well be the more important motive here.

See here how the android website argues for other licenses than LGPL for User space apps:
https://source.android.com/set...

It could even be a move to prepare for a proprietary branch (the sources for which they have complete copyrights, i.e. that didn't incorporate patches from outside, can always be licensed under an additional license) and in the long run have a completely closed source OS.

This is just wild speculations since IANAL, but it might be be interesting what lawyers make of the change in licensing.

Re:Licensing

[iampiti]

Ever since I first learnt of Fuchsia I thought Google wanted control about the Android kernel. I still think the same.

Ma GNUschia

[kackle]

So if I embrace it, it would be "my GNUschia"?

Secured By Ex-BlackBerry ?

[Sweettoother]

A couple of years ago, a BlackBerry fan posted a comment saying that Google and BlackBerry were working on a new OS that would replace Android and BB10. It now looks to me like he may have been right. And that may have been why David Kleidermacher, BlackBerry's former director of security, left BlackBerry to work for Google. I imagine he's in charge of the securing the new OS. When I read that BB fan's post, I imagined that the data-mining code would be put into modules that would be loaded by Google for their devices, and unloaded by BlackBerry for their devices. I'm looking forward to seeing how it turns out.

Re:Meanwhile I stick to iOS and Mac OS.

[angel'o'sphere]

I use linux at work and Mac OS X privately, never stumbled into issues with bash or other tools.
I wonder what problems/differencces do you encounter?

Lots of OSes out there

[OrangeTide]

Every year a good percentage of computer science and computer engineering undergrads write a small kernel for their coursework. It's not hard to write a kernel that solves a narrow set of requirements. When you have an every expanding scope, like in the Linux world, it gets hard. Linux has to run kiosks, mobile phones, desktops and supercomputers. And it's probably not the best possible kernel for any one of those problems, and certainly more complex than a kernel designed for a single specific purpose.

Why do we need Google Fuchsia? We don't really. But a whole lot of people leverage Little Kernel for their projects (my own company is using LK in 3 totally different ways). I blame LK for projects like Fuschia as it has turned into sort of a DIY Operating System kit.

If Linux and the BSDs are too complicated or you're just looking for some kernel you can hack up to meet your own special needs:
* NewOS
* Xv6 - a teaching OS. but people have patches for virtual memory and other goodies
* LK (little kernel) and for an example of a fork TLK (Trusted Little Kernel). LK is quite a good starting place for an aspiring osdev'r
* basekernel - rough starting place for making your own kernel
* FUZIX - a UNIX-like kernel geared toward 8-bit CPUs. but can be ported to bigger CPUs (there is a 68K port for example)
* TinyOS
* Femto OS - a kernel suitable for multitasking on small microcontrollers
* PonyOS - a graphical OS for people who love ponies (OMG Ponies). If you're looking for a more serious version see Toaruos.

There are hundreds of these hobby and learning OSes and several more complete and better established ones (like FreeRTOS).

Re:Open source or nay?

[viperidaenz]

If the entire source code for iOS is freely available to anyone and you're free to do pretty much anything you want with it, sure.

Just what we need

[simpz]

A so called open source OS, that is really just a thrown over the wall every so often OS. That I can't contribute to. Great !

If you want OS innovation maybe rust OS is a better place to look.

Re:Meanwhile I stick to iOS and Mac OS.

[i.r.id10t]

Mostly with restoring settings/profile data from my Linux system for the same apps under OS X - like Firefox, Thunderbird, Geany, Netbeans, etc

Re:Meanwhile I stick to iOS and Mac OS.

[angel'o'sphere]

Yeah, that is understandable.
I tried to find where Thunderbird saves its settings, because I need to delete an SMTP/IMAP configuration, but failed so far (on Linux).
Netbeans might have an "export settings" and "import settings" option. Most IDEs have that.
Good luck!

Google Updates

[razibraj]

waiting for the next google updates............