Microkernel, huh? At least now we will have a chance to get some empirical evidence to resolve the famous Torvalds - Tanenbaum debacle. It's going to be interesting to see how Fuchsia pans out and in what kind of environments it can be used.
Just because you don't consciously interact with them on a daily basis, does not mean they do not exist. My guess is that QNX and kernels like it are the reason you can take for granted such obvious things as your car braking correctly, your train not derailing, and your robot surgeon not crashing.
In today's world, we're so used to software breaking that if it doesn't break, we oftentimes think it must not exist. But, there is a whole world of reliable software out there that can actually be trusted. You don't hear about it often, because they work so well.
Even the parts written in straight C and C++ code have issues in performance woes on Android, as everyone that has wanted to do real time audio on Android painfully knows.
The whole architecture has been a mess.
Did they fired you?
If you had any Android developer experience, you would surely know that Google had a few failed attempts at real time audio, needed help from Samsung to implement them, and the final API was C only, with devs asking for a C++ one, wich was later dumped on github as side project and isn't part of the official NDK APIs, but alas you don't.
Would you mind to explain what happened completely? I am very curious about it.
Thank you so much ;)
Originally Android only had the Java media APIs, with a quite complex state.
https://developer.android.com/reference/android/media/MediaP...
Android 2.3 introduced OpenSL ES into the NDK and Android 4.0 got OpenMAX.
All of them weren't up to the game of realtime audio due to the Android architecture.
http://superpowered.com/androidaudiopathlatency
https://nsr.cse.buffalo.edu/wp-content/uploads/2016/10/rtdro...
https://www.androidauthority.com/android-6-0-marshmallow-aud...
There are plenty of other articles online when you search for audio issues on Android.
There was even a Google IO 2013 talk about it.
https://www.youtube.com/watch?v=d3kfEeMZ65c
Meanwhile Samsung had customized their Android versions to properly support real time audio and offered an SDK for their handsets.
http://developer.samsung.com/galaxy/professional-audio
At Google IO 2016 the problem was again discussed, with the Samsung team from Professional Audio being called on stage to discuss their collaboration.
https://www.youtube.com/watch?v=F2ZDp-eNrh4
Finally last year at Google IO 2017, the new real time audio was announced, as C only lib.
https://www.youtube.com/watch?v=C0BPXZIvG-Q
https://developer.android.com/ndk/guides/audio/index.html
The announced C++ wrapper ended up being an external project on github, detached from the NDK, that you need to integrate yourself, without any guarantees how long Google will care to maintain it.
Oh, to make things even better, it is already clear from Android P draft documentation that new audio APIs are on their way.
I'm just trying to correct all of the misinformation you like to post about Google and Android.
>If you had any Android developer experience, you would surely know that Google had a few failed attempts at real time audio, needed help from Samsung to implement them.
Unfortunately, your lack of Android development experience and your lack of exposure to development on Samsung devices has caused you to be disingenuous once again. Samsung didn't help Google nor did they contribute any of their code to AOSP. They implemented their own proprietary audio solution called SAPA. Unfortunately, it was limited to their platform and the audio latency wasn't very good in comparison to the iPhone.
>and the final API was C only with devs asking for a C++ one, wich was later dumped on github as side project and isn't part of the official NDK APIs, but alas you don't.
AAudio is indeed coded in C, but at least you can use the Oboe C++ wrapper. What were the low latency audio solutions for Windows phone again? Oh that's right, there weren't any. No wonder there were no low latency audio apps on that platform.
It's just that despite all the good arguments for 30+ years, microkernels somehow seem to have failed to reach their full potential. That's why it's going to be interesting to see how Fuchsia pans out, being written from the scratch with all the cumulated knowledge and experience. Not to mention Google's resources and talent pool.
Ultimately, kernel popularity is largely going to be a network effect. Linux is popular on servers because it is both free and popular; not really for any inherent technical merit. Windows is popular because no one loses their job for choosing Microsoft.
On the other hand, there are several microkernel operating systems with notable features and significant, dedicated fan bases. For example, AmigaOS is well-known for its responsiveness, and despite not being in production for decades, still has a dedicated fan base. QNX is used in a lot of critical, performance-oriented workflows. OS X is a partial microkernel as well.
Nevertheless, the only microkernel that has really failed is GNU/Hurd. Minix fulfilled what it set out to be (educational) and Symbian was successful enough on mobile.
If I remember right, Linus's main argument against Tanenbaum was that the overall state gets so dispersed between the various services that make up a full-fledged OS, that eventually a microkernel-based system just gets unpredictable or starts performing poorly. I think the discussion was inconclusive, although for me Linus's argument sounded intuitively convincing.
Ultimately, Linux also is not all that popular except in two niches: servers and cell phones.
Windows is also not popular except in a niche: desktop computing.
Ultimately, you have arbitrarily declared several very prevalent forms of computing to be 'niche', while declaring several equally prevalent forms to be 'popular'. One of my hypotheses above is that we tend to dismiss reliable forms of computing as 'not really computing', because we expect computers to fail. When computers work, we think of them as mechanical machines or devices (the way we might view eyeglasses for example). I feel like your subjective opinion of what is and isn't niche just further demonstrates this point.
My guess is that there are more instances of QNX (and systems like it) than we realize. There could easily be as many as Windows or OS X (almost certainly the latter, I feel).
You are totally right that microkernels have been very successful in many different areas. I am afraid to even mention, that to me it seems they are most often pretty specialized areas with targeted applications and hardware choices. Which is why I'll welcome Fuchsia, especially if it is meant to be a general purpose, open source OS for a wide area of applications running on commodity consumer-grade hardware. That's all.
Well, large parts of the Linux world ended up with systemd, and I haven't yet met a person who had NOT had his fair share of issues with it.
The BeOS demo toward the end is similar where they fire up a load of 3D apps, videos, etc with the system gradually slowing but still handling the load. That was on mid-90's hardware.
EROS was a capability-secure microkernel with persistence for saving or restoring running state of system. One thing they liked doing at demos was unplugging it during file transfers. After it restarted, the system would pick up where it left off.
In security side, there's been a few security and separation kernels to never have a reported breach in the field. They passed 2-5 years of pentesting by evaluators, too, doing many times better than monolithic kernels in defects found. Also easier to mitigate covert channels or do formal verification since they're small enough to analyze to begin with.
https://arstechnica.com/information-technology/2008/02/first...
https://news.ycombinator.com/item?id=10957020
It also had the kind of compile-time slowdowns one expects with a lot of context switches on older CPU's. So, what's your source that there's not a microkernel at the center?
Did it have nothing of the sort? A microkernel-like component in center of monolith like NT? Microkernel architecture with key stuff in kernel mode for performance like hybrids do? Did you see anything fitting the term in any BeOS release? And how would you classify its architecture?
Haiku's kernel is also monolithic, although we have a few hybrid tendencies (FUSE, but it's not widely used) and even more modularity than BeOS had, but we are still mostly source-compatible with the BeOS kernel.
I don't know why people say it's a microkernel; people say the same of Haiku, but it's just not the case. Perhaps it's because the dynamic kernel module system is built-in and virtually all kernel modules are stored as shared objects and loaded on startup, vs. Linux's more static approach, at least historically? That's not at all what's meant by the term "monolithic", but popular perception is often wrong...
Linux is in places that have higher mindshare than the places that microkernels occupy. When was the last time you thought “I wonder how the hypervisor powering AWS is designed” or “I wonder how my cellphone’s baseband is designed”. The latter being a question that I wish people would ask.
They're generally used for different purposes, but if you mean number of deployed systems, then microkernels have won hands down. Firmware in nearly every device runs a microkernel like L4. Hypervisors like VMWare and Xen are also microkernels.
Microkernels are everywhere, it's only the desktop that's still dominated by monoltihic kernels (Mac OS X's Xnu/Mach is not a microkernel).
VMWare calls their system a microkernel (and so Wiki's rules therefore repeat that without other research), but the stack trace on the ESX wiki page pretty clearly shows a network card driver being called inside kernel context, so they have to be playing fast and loose with the term. From the outside it looks like earlier Vxworks; it's somehow a microkernel despite all of the code living in the same address space with no real permissions differences because it has multiple kernel threads and loadable modules. By that definition Linux is a microkernel too.
Xen has far too much in-kernel code to be considered an exokernel. Linux on L4 had even less overhead than paravirtualized Xen. If exokernels truly efficiently multiplex the hardware in the most minimal manner possible, this wouldn't be possible.
I can't comment on VMware beyond published documents since I'm not as familiar with it.
And Linux on which L4?
Far as NOVA, here's the dissertation that goes into a lot more detail on design considerations than most of the whitepapers.
https://www.researchgate.net/publication/275031217_Improving...
Of course, the number of hardware and firmware type of attacks on mainstream platforms made NSA retire the SKPP for doing separation on them. Even a perfect hypervisor cant be trusted to maintain that when its dependencies are garbage. That was even noted in 1992-1993 papers on VAX Secure VMM. Even secure digital desigms might have analog or RF attacks.
So, the current recommendation is to build things that way just to reduce number of attacks with monitoring and recovery as usual. Those two, though, could run on simpler, verified platforms. There's a lot of precedent for such split architectures.
That is not enough emperical data?