Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Jury Is In: Monolithic OS Design Is Flawed [pdf]

ts.data61.csiro.au

Post reply on HN
Print view View original

141–150 of 199 posts

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#141

Post by jacquesm »

iamcreasy wrote: post #140
jacquesm wrote: post #133

The jury was in in the mid 1990's, but Linus Torvalds doesn't know when he's wrong and to listen to his betters. Linux succeeded because of its community, not because of its architecture. QnX has shown the strength of microkernels for decades, they are far more stable and much easier to work on than monoliths. The (small) speed penalty should be well worth the price of admission.

> QnX has shown the strength of microkernels for decades Could you elaborate on this one please?

QnX is so common that if you removed it from the industrial world the world would literally grind to a halt. Machinery and vehicles would stop moving, factories would stop producing, chemical plants would (hopefully!) shut down and airplanes would no longer take off (or would have a much harder time trying to land without the usual guidance systems), boats would drift and messages would stop being sent through many systems that you probably would never have heard of.

For one example of such a system: A computerized way to communicate the availability of cargo and space to brokers all over the world, on a good Monday morning several million such messages are sent with a guaranteed maximum time between the first and the last such message sent (to ensure a fair market).

QnX is extremely pervasive and it - and other OS's like it - are so reliable that people tend to forget the systems it powers.

Blackberry made a pretty smart move with their acquisition of QnX, pity that it did not end with QnX being open sourced, that would have been very nice.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#142

Post by snaky »

pjmlp wrote: post #59
KMag wrote: post #45

Earlier quoted context omitted.

The dirty secret is that we take a microkernel, rename the syscalls as "upcalls", throw in some hardware emulation code as a less efficient and uglier API for software that can't be bothered to be ported, and call it a hypervisor. Also, your phone's baseband processor almost certainly runs a microkernel, and likely so does your car.

And what many seem to be unaware, is that project Treble made Android Linux into a microkernel where drivers use Android IPC to talk with the kernel. https://source.android.com/devices/architecture/kernel/modul... https://source.android.com/devices/architecture/hidl/ So everyone running Android Oreo or newer on their phones, not only has a microkernel on their basebase radio, they also have a Linux tamed into a micro…

Recently committed Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel framework is going even further in that direction.

https://lwn.net/Articles/758745/

> Could allow for APK installable kernel drivers, allowing modules to be upgraded (even live)

https://twitter.com/MishaalRahman/status/1029064974805688320

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#143

Post by thsowers »

enitihas wrote: post #77

Reminds me of the famous Torvalds Tanenbaum debate. https://groups.google.com/forum/m/#!topic/comp.os.minix/wlhw...

Thanks so much for the share, great gems in here, I still found myself surprised at this:

> True, linux is monolithic, and I agree that microkernels are nicer.

It's hard to believe that he was only 23 when he wrote this

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#144

Post by justicezyx »

nostrademons wrote: post #135
justicezyx wrote: post #134

Now it's a good time to revive microkernel for prime as server less offers the abstraction for making transition transparent to users and application developers. Anyone tried that?

Much of the cloud/virtualization industry is actually built on exokernels; a hypervisor is basically the commercially-viable version of an exokernel. The unikernel movement is an attempt to revive the LibOS and use exokernels as they were originally designed (i.e. move OS abstractions into user-space and not have a whole OS running on top of an OS), but there've been several pragmatic barriers that've kept them from…

I think I am mostly want to say to the advocate of a certain on machine first-level software infrastructure above hardware to feel more free to try to prove their technology is the best.

I am not too much about particular alternatives.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#145

Post by travbrack »

enitihas wrote: post #77

Reminds me of the famous Torvalds Tanenbaum debate. https://groups.google.com/forum/m/#!topic/comp.os.minix/wlhw...

>I also agree that linux takes the non-portability to an extreme: I got my 386 last January, and linux was partly a project to teach me about it.

Times sure have changed

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#146

Post by Sporktacular »

pweissbrod wrote: post #8

I wonder if there exists a parallel dimension where linux is microkernel design and folks are pushing for monolothic citing the driver friendliness and performance

And in that dimension there would be debate about whether we should cut corners by reducing security and reliability to slightly improve speed and mollify lazy programmers.

That debate would be short and the answer would be "nope, we shouldn't because that would be stupid".

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#147

Post by Sporktacular »

acd wrote: post #70

There is a reason why kernel code run in privileged mode, speed! If you run more kernel code in privileged mode then you do not need to copy as much data between the kernel and user space. Vs a micro kernel you will have to copy more data up to user space. Copying data to user space causes context switches and gives less performance. Larger mono kernels: Speed Micro kernels have advantages such as: smaller privileged…

In a world of constant security threats and 2 GHz CPUs dedicated to cat videos - needing speed can no longer be the excuse for poor design.

And "embedded CPUs need every precious cycle" is not an argument either. As the paper says modern microkernals have a negligible speed penalty while IoT/networked industrial controllers are a security backwater.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#148

Post by Sporktacular »

nine_k wrote: post #53

I'd hazard to say that every design is "flawed" in some regards: there's no way to achieve all desirable qualities and none of undesirable qualities. For one, some desirable qualities contradict each other. So "${thing} is flawed" is not precise enough; an interesting statement would be "${thing} is not the best choice for ${conditions}". A monolithic OS is not the best choice for a high-reliability system on unrelia…

If we can't make reasonably secure controllers with only 4KB of RAM, perhaps we shouldn't be making controllers with only 4KB of RAM.

Tech and market pressure will make more capable processors affordable if security is prioritised.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#149

Post by etatoby »

agumonkey wrote: post #57
KMag wrote: post #45

Earlier quoted context omitted.

The dirty secret is that we take a microkernel, rename the syscalls as "upcalls", throw in some hardware emulation code as a less efficient and uglier API for software that can't be bothered to be ported, and call it a hypervisor. Also, your phone's baseband processor almost certainly runs a microkernel, and likely so does your car.

and according to someone, your Nintendo console too It's quite crazy to count all the layers cpu microcode cpu isa hypervisor os kernel userspace api browser runtime js vm application your mouse I want my 386 back

Soon it will be:

    ...
    webassembly vm
    (insert variable height custom stack)
    application
    ...
Sad times.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#150

Post by pjmlp »

snaky wrote: post #142
pjmlp wrote: post #59

Earlier quoted context omitted.

And what many seem to be unaware, is that project Treble made Android Linux into a microkernel where drivers use Android IPC to talk with the kernel. https://source.android.com/devices/architecture/kernel/modul... https://source.android.com/devices/architecture/hidl/ So everyone running Android Oreo or newer on their phones, not only has a microkernel on their basebase radio, they also have a Linux tamed into a micro…

Recently committed Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel framework is going even further in that direction. https://lwn.net/Articles/758745/ > Could allow for APK installable kernel drivers, allowing modules to be upgraded (even live) https://twitter.com/MishaalRahman/status/1029064974805688320

Interesting thanks for sharing. Looking forward for when it pops up on AOSP.
Post reply on HN