Linus Torvalds (torvalds.delete@this.linux-foundation.org) on March 16, 2021 7:25 pm wrote:
> anon2 (anon.delete@this.anon.com) on March 16, 2021 5:53 pm wrote:
> >
> > I see. So at least it tries to get away from the RPC proxying as much as possible.
>
> This whole thread has been inane.
>
> Absolutely nobody sane disputes that the IPC overhead is a big and very real deal.
> Even the people who seem to be arguing for microkernels seem to be admitting it.
>
> It's something to generally be avoided, but sometimes you can't (or you don't care
> about the downsides, and have a load where it works for you). So if your sandboxing
> capabilities can't do it any other way, you fall back to some kind of IPC model.
>
> Which just brings us back to the original issue: designing your whole
> kernel around something that people know is bad is a bad idea.
>
> That sounds pretty simple, doesn't it?
>
> And it really is that simple.

Nope, it is not that simple. Lets stick in a couple of changes

Absolutely nobody sane disputes that the IPC overhead is currently a big and very real deal.
...
Which just brings us back to the original issue: designing your whole kernel around something that people know will be bad is a bad idea.

So the question becomes - can the performance of IPC be dramatically improved? If not then I'd agree that microkernels don't have a future for general use, and if they aren't used generally they probably shouldn't even be used in general for secure projects as there is an awful lot to be said for the security gained by having the code looked at and used by large numbers of people.

A problem is very often an opportunity and I certainly don't see this as an 'insuperable opportunity' ;-) As to whether it is worth it - well basically I see current operating systems as like the personal computers of 40 years ago able to overwrite anything and doing cooperative multitasking to get a decent interface. The security was fine for the time as the machines weren't shared and there was no internet. And they passed around data easily just like a current OS does internally. Nowadays the OS provides a virtual machine to the user level, the OS still has the flexibility but denies it to the user level. The business of sending data between tasks has been made more difficult and expensive. And for good reason. There probably isn't a way to do it well with the current hardware architecture. And meanwhile the operating system grows larger and larger and people stick in things like a system manager or trusted compute to avoid the very real possibility of dangers from problems in it.

We are currently at the start of computing and becoming dependant on it. In the future it will be ubiquitous, and there will still be trolls and other psycho nutters who aren't satisfied to just steal money but want to cause destruction and misery. With all of them spending countless hours doing that we should be trying to have better security so access to one part of the system doesn't 'root' it.

As I say in another bit of this thread I think capabilities have the potential to drastically improve the speed of IPC type transfers and so enable a microkernel type operating system to become competitive for general use. And provide a way to support things like sandboxes better. The idea of capabilities has ben around for a while but we're only now able to easily afford the extra hardware and need the facilities they promise. In the past one couldn't even afford an on chip MMU.