'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

[datavirtue]

" It should be interesting if they can get around the latency for process switching and message passing."

You mean the laws of physics? Did you come here trying to be smart?

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

[Anonymous Coward]

Uh...iOS and macOS?

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

[Anonymous Coward]

Yes, it is why most microkernels suffer from poor performance. As the message goes through 3 different process spaces it causes latency. It is the context switch and copy that causes the jitter. With the speed of most CPUs these days it is not as noticeable. But a proc that uses a lot of syscalls into other things can cause significant overhead in just message passing. Linux/windows/AppleOSX uses a shortcut of putting part of the kernel (or all of it) in the same memory space as the process and treat it as a function call instead of a message. They then lock it away from the process by using CPU flags and rings.

The successful microkernels typically have had to cheat out the messaging bit in some way. Usually with in process memory or security shortcuts (ie none).

Like I said it should be interesting with a company like google studying the idea. They have hovered up any worth hiring already...

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

[Anonymous Coward]

As I understand it, Apple was compelled to violate the basics of microkernels at many points, precisely due to the cost of message passing., not merely for the latency but for the power cunsumption. Micro kernels have many benefits, but they also have some fundamental performance costs.

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

[Anonymous Coward]

Hes talking about Blackberry 10

It was an extremely modern OS doofus

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

[Anonymous Coward]

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.

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

[Anonymous Coward]

I think fushia is open source.

Re:interesting

[Anonymous Coward]

Uhh what? Android is already far, far away from Linux already, it's difficult to get further in the Android userland - right from the custom libc, through the limited process sandboxes on up until you hit Dalvik. The kernel is largely irrelevant for user processes and isn't accessible, by design.

Re: interesting

[Anonymous Coward]

And QNX, Minix, L4...

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

[Anonymous Coward]

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.

Creating a new open source OS is "abandoning open source sotware"?

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

[Anonymous Coward]

Just stop talking. You are clearly a fool.

Re:interesting

[Anonymous Coward]

ukernels also take the same hit, on top of spectre/meltdown.

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

[Anonymous Coward]

Why would Google do that? The system is designed for suit spying and data harvesting, nothing else matters.

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

[Anonymous Coward]

C++14 and later, if used correctly, undermines many of your C++ criticisms.

Re:interesting

[Anonymous Coward]

True. Also microkernels end up in 'design hell'. Message passing sounds great... but in the real world, you end up with either a system that rarely changes (could be good, depends on the situation) or constantly redesigning large chunks of it just to make small improvements.

See GNU HURD.

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

[Anonymous Coward]

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

Not saying that they're not currently "evil", but it was actually originally "Don't be evil".

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

[Anonymous Coward]

"If used correctly"

Right..

Re:interesting

[Anonymous Coward]

Most C++ coders improperly use delete when they should use delete [] and they don't even know why it makes a difference.

Don't modern C++ coders use smart pointers so you never call either?

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

[Anonymous Coward]

Or resist the temptation to reinstall the Google Advertising kernel module every fortnight and doubly so when the moon is to it's fullest.

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

[Anonymous Coward]

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.

And predictably enough, the hardware makers and many (most) open source developers started the move away from the GPL so now few new open source projects choose the GPL.

It's truly ironic that the ability to make a non-GPL open source OS will be thanks to Stallman as his actions resulted in projects like LLVM being successful, eliminating one of the biggest GPL software requirements.

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]

> The kernel is the biggest single source of security problems in Android.

2018-02-01
        Media framework
                Critical, High, High, High, Critical, High, High
        System
                Moderate
2018-02-05
        HTC components
                High, Moderate
        Kernel components
                High, High, High
        NVIDIA components
                High, High
        Qualcomm components
                Critical, High, High, High, High, High, High, High, High, High
        Qualcomm closed-source components
                High

2018-01-01
        Android runtime
                High
        Media framework
                Critical, Critical, Critical, High, High, High, High, High, High, High, High, High, High, High, High
        System
                Critical, High, High, High
2018-01-05
        HTC components
                High
        Kernel components
                High, High, High, High
        LG components
                High
        Media framework
                High
        NVIDIA components
                High
        Qualcomm components
                High, High
        Qualcomm closed-source components
                Critical, High, High, High, High, High, High

Re: interesting

[Anonymous Coward]

The only part that works... is the part that reports everything back to Googles HQ

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

[Anonymous Coward]

Or maybe you do not know the first thing about operating systems and are just blindly defending ios like the blind isheep you are

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

[angel'o'sphere]

Mac OS X aka macOS is based on MACH, a microkernel implementation.
There plenty of industrial micro kernels used in production, just google.
For reference: https://en.wikipedia.org/wiki/...

Re:interesting

[Anonymous Coward]

It sounds like BeOS.

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

[Anonymous Coward]

All languages if used corectly have little to no security holes. C and C++ are no diffrent. And even the best language can have major security holes if used wrong. This is nothing new. This is just another I don't like language x for y reason post. Next we will hear that we shouldn't use ASM or byte code because of security holes. I mean really.

The simple truth of the matter is. A program/app/os will never be better than the weakest link in the development team. Architecture isn't the problem either, I have seen code that was thrown together over night beat a full team of pros who took 6 months to basically do the same thing. Even heard the chairman apologize for sending the project over when the test code worked so much better.

The best language in the world can't make up for a shirt programmer, but a good programmer can make an great program with a shirt language.

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

[Anonymous Coward]

You're an idiot. Don't forget that. Also, the kernel is called Zircon, chico.

Re:interesting

[Anonymous Coward]

He lives in a basement. His social service checks barely cover expenses.

Re: interesting

[Anonymous Coward]

Android doesn't use a JVM. It uses ART.

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

[Anonymous Coward]

Can't even spell a word that's in the title. Must be a


Q out Q `MKS . SWART in SWART . HAWKISH `SEPSES .
BF in Q . Q . Q out Q `Q out Q `Q we bes Q out Q `
Q Q . Q . Q . Q we bes Q we bes Q we bes Q out Q `
Q `Q `Q . Q . Q `AMOK `Q `AMOK `SWART in SEPSES .
Q . Q Q . Q . Q out Q `Q out Q `Q we bes Q . Q in
Q in BF . Q . Q out Q `Q out Q `Q we bes Q in Q .
Q out Q `MKS . SWART in SWART . HAWKISH `Q out Q `

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

[Anonymous Coward]

"The Android security team badly wants to replace Linux."

But whatever they replace it with will be equally prone to breaches.

Re:interesting

[Anonymous Coward]

Modern C++ programmers also have things like std::future and std::promise for asynchronous programming, yet he wrote "Add to that that almost all modern development paradigms are asynchronous programming... unless you're stuck with some shitty language like C or C++"

So yes. There is very little content in his post. Not quite sure why he's getting so much attention.

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.

Good riddance

[Anonymous Coward]

Good riddance to the failed Linux kernel.

Re:Good riddance

[Jerry]

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

Re: Good riddance

[Anonymous Coward]

How is the most deployed kernel in existence a failure?

Joey Buttafucko?

[Anonymous Coward]

Who dat? Dis a dup too?

So basically it's Linux without the Linux kernel

[Anonymous Coward]

Fushsia, if you look at the google code site, clearly shows that Zircon is the kernel, but the vast majority of the thirdparty stuff is the same stuff you'd see in Linux or FreeBSD.

Linux is, and has only ever been "linux kernel" that made it Linux, you could swap it out with FreeBSD's kernel and essentially have a version of FreeBSD that ran all linux software for which it had hardware drivers for. Same in the other direction, if you swap the linux kernel in to the FreeBSD OS, you could run all linux and freebsd software for which drivers are available.

The catch is that this only works because you can recompile the software that makes up the OS. Hence this is why you can eject the kernel and replace it and come up with another OS.

Meanwhile I stick to iOS and Mac OS.

[Anonymous Coward]

I use real UNIX, not pretend versions.

Re:Meanwhile I stick to iOS and Mac OS.

[Anonymous Coward]

I use real UNIX, not pretend versions.

Actually you do, iOS (and tvOS and watchOS) are not UNIX, they are based off macOS but lack many key elements necessary for UNIX certification hence the reason they are not UNIX certified operating systems.

Re:Meanwhile I stick to iOS and Mac OS.

[Anonymous Coward]

Mac OS is certified UNIX dumbass.

Re:Meanwhile I stick to iOS and Mac OS.

[Anonymous Coward]

Did you not bother to read his post, or are you just incapable of doing so?

Re: Meanwhile I stick to iOS and Mac OS.

[Anonymous Coward]

Mac OS is a true UNIX.

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:Meanwhile I stick to iOS and Mac OS.

[Anonymous Coward]

Mac OS is certified UNIX dumbass.

Yes and iOS is not. I didnt think it could be quite so hard for you to understand my post.

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.

Re: Meanwhile I stick to iOS and Mac OS.

[q_e_t]

Based on, not based off.

Re: Meanwhile I stick to iOS and Mac OS.

[Anonymous Coward]

Could have been worse; 'based off of'

Re: Meanwhile I stick to iOS and Mac OS.

[Anonymous Coward]

From the post you are replying to: Actually you do, iOS (and tvOS and watchOS) are not UNIX

Reading comprehension fail?

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?

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!

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?

[Anonymous Coward]

Is this really pronounced Fuck-See-Uh?

If you are Spanish, apparently yes. (Source - used to work with a Spanish project lead who pronounced it that way.)

Re:Fuchsia?

[sd4f]

If you say it fast enough, probably can be called 'fucks-ya', which is quite fitting for a company like google.

Re:Fuchsia?

[Anonymous Coward]

Is this really pronounced Fuck-See-Uh?

Only if you're ignorant or trying to be funny.

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?

[Anonymous Coward]

When you say "read slashdot" do you mean the articles, summaries or comments? Because it's a fairly well established meme to not read the articles here. And it's not terribly uncommon for people to not bother reading the summary. And I'm talking about the regulars here, not just the ACs like myself.

Re: Fuchsia?

[Anonymous Coward]

The amount of bitching over a company that doesn't even have paid products to speak of is astounding.

"Omg their open source OS will be moving to a different open source OS! Eeeeeeeevil!"

Re:Fuchsia?

[Anonymous Coward]

Yeah, as in Fuck See Ya, Linux.

Re:Fuchsia?

[Anonymous Coward]

not by anyone fluent in English

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

[Anonymous Coward]

Except, Fuscia's kernel is based off another embedded kernel called "lk" which was MIT-licensed... not Linux, and not GPL.

Re:Translation

[Anonymous Coward]

From a practical view, microkernels fail when there are shitty drivers driven by clumsy inefficient iterfaces. The screen, and the wifi are the main hogs. Crypto will be another biggie going forward. Uses Java-like interpreter and JIT - another hog. Now if this is all human optimised assembler code, fine. If they run binary blobs like mobile telephone chips - it is game over. DRM crap - another rule breaker. Microkernel is a very poor choice unless the hardware is extremely stable, not 2 year and throw it away stuff like Apple.

Google should talk to IBM and Z/OS or I say the very good Digital (DEC) operating system which featured their own selectable schedulers and control blocks.

I wonder if Google is coding anti trace and sabotaging single step/dump diagnostic features. That is the feature of microkernels . Otherwise crapware will start spawning
vampire tasks like bitcoin mining, yet nobody can see where that latency is coming from.

 

Re:Translation

[Anonymous Coward]

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.

Read the docs. The APIs look nothing like any UNIX. This is not Linux.

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

Re:Translation

[Anonymous Coward]

LOL, Fuchsia is based on the Little Kernel microkernel. Also Project Treble doesn't move device drivers from the kernel. Project Treble just separates the kernel from the userspace so that you can update the Android OS without touching the kernel.

This is stupid

[mohsel]

on so many levels

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

[Anonymous Coward]

So it is GNU/Fuchsia?

Who cares what it is?

[Anonymous Coward]

What are the licensing terms?? You coulda put that in the headline, you know... but then it wouldn't be click bait anymore, would it?

Anyway, if it's open source great. If not, the upgrade treadmill will fuck you up every couple of years. That is the Google way.

Re:Who cares what it is?

[Anonymous Coward]

According to Wikipedia,

It is distributed as free and open-source software under a mix of software licenses, including BSD 3 clause, MIT, and Apache 2.0.

In other words, there'll be a "free and open" version of it, just like Android, but the version that people actually use on their smartphones will not be free software.

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

[Anonymous Coward]

That f*cking stupid manuscript is that much holy because you believe that ghost mentioned in that manuscript?

Re: Google is just asking for it

[Anonymous Coward]

> Confucionists

Yeah there's a lot of Confucion surrounding Asian religions.

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.

Will it (finally) prioritise the user ?

[Anonymous Coward]

We are living in the 21st Century, yet it appears to be beyond the ability of computer engineers to bring us an operating system that never, ever lets the system have priority over the user.
For example, I, as a user must ALWAYS be able to stop tasks ( that I started ) IMMEDIATELY, without any perceptible delay.
That is surely not too much to ask ?
It seems beyond the creators of Windows / Linux / Android / Mac / etc.

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.

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

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

[Anonymous Coward]

Again Bruce it was mentioned to you in a previous story with Ruby that threading takes care of all of this if you have a proper OS. Promises and state machines are hacks for shitty code.

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.

Re:Will it (finally) prioritise the user ?

[BuckBundy]

No, making money is the most important part of commercial computing.

Re:Will it (finally) prioritise the user ?

[Anonymous Coward]

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.

It goes without saying that I agree with the parent poster on this...

To add to this, it is my understanding that some of this IO is likely to be handled via DMA writes or reads. Interrupting something that is not actually costing you CPU time is something I'd think twice about. Of course with USB devices, I suspect the CPU has more involvement almost all the time, but I agree, better hardware could fix that.

I haven't studied this OS, but I do wonder if perhaps we need a more hybrid approach. What I'm talking about is having a system with these cores,memory,etc set aside for hard real time tasks and resources that are not.

A thread running on those cores would have to be deterministic, in that we know every iteration of the thread will complete in a bounded time and we know the total schedule of threads will not exceed the time allotted for threads.

The problem, is once any task gets beyond a certain degree of complexity it becomes really hard to get that assurance. You can do it for some dedicated tasks with C or C++. I could poll a mouse or keyboard all day with dedicated resources and a hard real time OS and capture every keystroke or mouse movement without ever glitching. It would be trivial.

What is not trivial, is taking that information, feeding it to the possibly managed rendering engine, allocating during runtime any new resources needed to render the updates, redraw anything affected, scale it if needed, plus keep the rest of the stuff running. (We are ignoring the fun that is the modern paranoid anti malware stuff.)

I've played a lot of games with threading and affinity on windows. It does help, but only if you do it just right and only around the edges. Get it even slightly wrong and it can easily be worse than not setting anything at all. For instance if you have 2 physically separated cpu's, you can probably reduce jitter a bit if you keep real time tasks on one, and non real time on the other, assuming that load works out. Why does such stuff matter? Well it usually doesn't, when it does matter is because your preventing the process from moving around and loosing some of the benefits of cpu cache.

Again, unless your trying to somehow capture uninterrupted data streams by polling or some other task you wish you weren't given, it is usually a fools errand, and probably is even then. Of course if I had that mythical system that was basically half RTOS, I could put the polling in there, where it is deterministic, then shovel up big buckets full for the non RTOS, which usually works better. (Good data acquisition cards do this for you, as does well most other good hardware..)

Most of the time trying to second guess the scheduler is easier said than done, and, as mentioned it is easy to get it wrong. You could, for instance give your program so many resources that you indirectly starve resources from some other system task your program needs, or even worse some task set to a higher priority sits there spinning waiting for some lower level task to complete that will never run.

Overall, I'm not sure the underlying OS is the biggest thing android needs, but again I'm not remotely an expert there. My guess is you have a fair chunk of not particularly efficient applications, combined with limited resources, combined with the crazy crap that is the modern web page.

Seriously, we went from pages with barely any graphics, and all served from one server (usually), to the mess that is countless graphics, bad scripting, ad providers, tracking crap, databases, etc, etc just to load well weather.com. That however is another story, though one that certainly could be solved.

Re:Will it (finally) prioritise the user ?

[Anonymous Coward]

Yay: Bruce Perens replied to my comment !!!
Boo: His reply is scored 5 and my comment 0. Hmm.

I made the make of writing "operating system" and then using "system" to mean the whole shebang.
I do accept that the operating system must have priority over user input at the low level. But the user should not need to be aware of this in the GUI ( or should be informed why their input is not being acted on ) and MOST importantly, the GUI should ALWAYS continue to function well, no matter what.

I also meant things like a user starting a processor-consuming task using a GUI, then not being able to stop that task via the GUI because the task is consuming all the processor and prevents the GUI from processing the stop request. So the computer carries on doing a pointless task.

Re:Will it (finally) prioritise the user ?

[Anonymous Coward]

OP here.

"Y U argue with Bruce Perens?"
Because this is science, not religion.

Re: Will it (finally) prioritise the user ?

[Anonymous Coward]

iOS is a POS, lots of other mobile OS can do that: Android, Windows Phone (when it was a thing), Jolla, etc...

My pretty

[Anonymous Coward]

what better way to suck up your data, my pretty

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.

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

[Anonymous Coward]

Fushsia, if you look at the google code site, clearly shows that Zircon is the kernel, but the vast majority of the thirdparty stuff is the same stuff you'd see in Linux or FreeBSD.

So, you say its Linux because it has the same "thirdparty stuff" as seen in FreeBSD? How does that make sense?

Unless you're saying macOS is Linux without the Linux kernel because I have all that same "thirdparty stuff" via Mac Ports and Homebrew? And Solaris is also Linux without the Linux kernel because it also contains a lot of that "thirdparty stuff"? I guess FreeBSD is also Linux without the Linux kernel?

No. Linux is the kernel. An operating system that uses the Linux kernel can be called a Linux Distribution (also can be called GNU/Linux assuming its based around stuff from the GNU project). An operating system that uses a non-Linux kernel is not Linux, nor is it a Linux Distribution.

By the way, that "thirdparty stuff" is "opensource software".

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: So basically it's Linux without the Linux ker

[Anonymous Coward]

we can only hope he was stirring to take a shower

if That's the case...

[Anonymous Coward]

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

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.

Open source or nay?

[Anonymous Coward]

That's the real question. Will it be open source like the Android Open Source Project? I have no problem with Google's work IF they open source it. Most of Android's security problems come from the crap that vendors tack onto Android, and users not getting patches in a timely manner.

Re:Open source or nay?

[viperidaenz]

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

It's an MIT based open source license

Re:Open source or nay?

[DeVilla]

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

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.

Linux is deprecated

[Anonymous Coward]

I'm upgrading to Fuchsia as soon as I can!

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

[Anonymous Coward]

You mean the Windows NT kernel, not Windows the operating system. And in that case, you mean the VMS influence, since David Cutler got caught stealing DEC owned source code and his old development team from DEC operating system projects based on VMS to write the NT kernel This write-up about it is pretty accurate.

http://neilrieck.net/docs/dave_cutler-prism-mica-emerald-etc.html

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

[Anonymous Coward]

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

That depends on if you include the file system in the kernel. Windows is still really slow at managing files and this is something Linux excels at (from my personal experience as a software developer, a Linux machine with a mechanical disk is faster than a Windows system with an SSD).

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

Portable c

[Anonymous Coward]

Wow, projects written in "portable c" are actually portable. Don't tell the Java devs.

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.

Client-Server Future

[Anonymous Coward]

Interesting read on how filesystems are handled and the implications toward a future where the cloud (presumably starting with google online storage) will be indistinguishable from local storage. On the one hand, I'd like to see how Fuschia developes. On the other... the concerns of (even more) surveillance, tracking, data-mining looms even greater on the horizon.

Pink or Purple

[Anonymous Coward]

Thatâ(TM)s all good....

But IS Fuchsia PINK or PURPLE?

Patent minefield

[Stan92057]

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

Re:Patent minefield

[Anonymous Coward]

Most everything anybody writes is copyrighted. Your post is copyrighted. My post is copyrighted. Linux is copyrighted. It's a rather useless label.

Re:Patent minefield

[Anonymous Coward]

Most everything anybody writes is copyrighted. Your post is copyrighted. My post is copyrighted.

Nope. Small snippets of ordinary text like your post typically don't contain enough creativity to be copyrightable (for varying definitions of 'small', 'ordinary' and 'enough'). You could *try* asserting copyright on your post but the court would probably take a very dim view of it.

Sounds like...

[Anonymous Coward]

Pronounced "Fucks Ya".

You insensijtive clod!

[Anonymous Coward]

would like 7o

It's OK To Be White

[Anonymous Coward]

The actual people who run Joogle are Joos, numbnuts. Your hasbara isn't fooling us.

The Goyim Know.

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

[Anonymous Coward]

Or to brush his teeth.

The should have called is FINL

[goombah99]

FINL is not Linux.

Even better FINAL.

FINAL is not a Linux

Riiight...

[Anonymous Coward]

Google, I don't care how good you are at Search-and-Replace ... "Fuchsia is not Linux!" is about as convincing as "Dalvik is not Java!"

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

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.

interesting-licensing.

[Anonymous Coward]

Not really. BSD has been available as a license as long as the GPL. As far as riding on the backs of "familiarity breeds an app store", this new OS will have the same chicken/egg problem as a license choice would have.

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?

interesting-sentient licenses.

[Anonymous Coward]

Programmers write code. Licenses don't write code. If your scenario comes about it because that's what developer's want. Not what the license wants.

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

[Anonymous Coward]

More likely Busybox/Fuchsia

So many possible puns

[cyber-vandal]

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

Let Google have complete control over my device?

[Hallux-F-Sinister]

Fuch that sia.

This is pretty bad

[Anonymous Coward]

If Fuchsia takes over that would be pretty bad I think.
For Linux there is an existing path to get your patches into the main tree. Fuchsia is controlled by google completely and so will only support whatever Google wants, and will only be patched by Google.
Of course forking will be possible, but then you will be stuck forever porting patches onto Googles version.

No systemd?

[Anonymous Coward]

Then count me in!

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.

Wait states

[Anonymous Coward]

Except for the workload of handling interrupts from communication networks and producing sound and video in real time, mobile devices are in a wait state most of the time. You can't compare the task switching in a mobile device to the work load of a server, supercomputer, or tpu training itself for deep learning. If the microkernel limits itself to mobile devices and the internet of things, then it doesn't appear to present an insurmountable performance challenges.

If the microkernel architecture is dedicated to protecting the privacy and security of its users on mobile devices and IOT, then the performance hit should be worth the sacrifice.

On the other hand, if Google plans to use Fuchsia in autonomous vehicles, then lives are at stake, and every nanosecond in the operating system counts to protect human lives and avoid unnecessary accidents.

FNL - GNU ?

[Anonymous Coward]

So, of GNU is Gnu is Not Unix, a recursive acronym ... then Fuschia is not Linux is pretty much the same thing, no?

Start over from scratch!

[Anonymous Coward]

Said no one in the industry, ever, who is still around.

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:Secured By Ex-BlackBerry ?

[Anonymous Coward]

I could be wrong, but it might be Android with a QNX kernel. BlackBerry's Android phones run on the QNX kernel.

Making the FINL Acronym

[Anonymous Coward]

...is the only acceptable Unix greybeard course of action!

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

[Anonymous Coward]

So, you say its Linux..

Did you actually *read* the post you quoted?

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

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.

Google Updates

[razibraj]

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