I really wonder about this kernel IPC hype. I watched a video on React+Redux by Facebook engineers about a week ago, and the reasoning behind creating the things in the first place. Feelings about React+Redux and how they are overused aside:
Redux came first and it happened because the "interaction graph" between various components on the website became virtually impossible to resolve cognitively. The engineers (especially on-boarding engineers) faced troubles understanding how everything worked in concert and, especially, the side-effects of a single change. The nail in the coffin for the engineer was Facebook chat and she was forced to use numbers, instead of lines, to depict interactions because the graph was too dense. Redux forced interaction in one direction, with "back interaction" happening one frame/tick later. Web developers have praised and embraced this architecture.
If you look at the very first image in the article, it moves from a very straightforward application -> VFS -> ext2 -> driver -> disk graph to a [potential] rats nest. It runs counter to the hard lessons that Facebook have learned with complex distributed systems.
Is this why nothing has really come from Mach/Hurd? Up until putting 1 and 1 together a few minutes ago, micro-kernels sounded so clean and elegant. They now seem unwieldy. Perhaps there is exists another layer of architecture that can tame the dependency/interaction graph; isolation really does sound like a good idea, but we need a better way of doing it.
> Is this why nothing has really come from Mach/Hurd?
Mach 3.0 was the kernel used in NeXT and the original Mac OS X release. It was quite a bit later replaced with a rewritten kernel XNU, that’s basically a hybrid. The reason as I understand it, message passing in the kernel is expensive when crossing user space so often.
I wouldn’t call that nothing coming of Mach, it did really well!
Also, I’d say that micro-kernels are closer to the paradigm of react/redux (redux the message bus, react the user space servers) than to a monolith design like Linux.
I think instead of comparing this to a front end web framework, you should consider how Fuschia is designed using capabilities (similar to the concept of a system call, and how a system call handler works) around a fundamental restructuring of a kernel: originally named Magenta, now called Zircon, to fundamentally optimize for the evolving modular architecture of advanced mobile computing. Understanding how the OS design flows from the original kernel design is key to understanding Fuschia OS as a whole. This article from two years ago does a pretty job of justifying its' existence (in this article, Zicron is referred to as Magenta as it had not been renamed yet): https://lwn.net/Articles/718267/ but I would actually love to hear feedback/constructive criticism of the kernel architecture itself.
I remember where I was and what I was supposed to be doing when I was instead reading the HN article that posted this lwn article (above) about Magenta 2 yrs ago, after finding Eric Love's Guide to Linux Kernel Development, and found this a fascinating read to compare to, given my learnings in kernel dev at the time.
Oh wow, I remember watching that, it's crazy to revisit that talk after so many years.
Redux and Flow are somehow branded as alternatives to MVC, when they are precisely MVC (store=model, dispatcher/reducer=controller, etc). It seems that Facebook (and many others) implemented MVC very poorly and pretended to abandon it instead of admitting they just did it better on the next attempt.
If anything, the success of redux simply reinforces the fact that MVC is a very useful pattern for UI applications. But, it bothers me that newer developers might be persuaded by the anti-MVC branding.
Flux dispatcher are not really like controllers. They don't allow for any business logic. The stores are like combined controller/models, though.
A key design feature of Flux is that many unrelated (or related) stores can respond an event, and that there is a defined lifecycle for handling events. I don't believe those really map to MVC.
Of course, the whole idea of, in-theory, re-creating the UI at every refresh cycle is not part of MVC, so that is new and interesting. Considering all the work that has to be done to undo that abstraction (as it doesn't really match reality), I am not sure how useful it actually is.
I guess Google engineers has some experience with those hard earned lessons before Facebook even existed. The diagram you mentioned is very typical of microkernels and subject of research for decades.
Redux came first and it happened because the "interaction graph" between various components on the website became virtually impossible to resolve cognitively. The engineers (especially on-boarding engineers) faced troubles understanding how everything worked in concert and, especially, the side-effects of a single change. The nail in the coffin for the engineer was Facebook chat and she was forced to use numbers, instead of lines, to depict interactions because the graph was too dense. Redux forced interaction in one direction, with "back interaction" happening one frame/tick later. Web developers have praised and embraced this architecture.
If you look at the very first image in the article, it moves from a very straightforward application -> VFS -> ext2 -> driver -> disk graph to a [potential] rats nest. It runs counter to the hard lessons that Facebook have learned with complex distributed systems.
Is this why nothing has really come from Mach/Hurd? Up until putting 1 and 1 together a few minutes ago, micro-kernels sounded so clean and elegant. They now seem unwieldy. Perhaps there is exists another layer of architecture that can tame the dependency/interaction graph; isolation really does sound like a good idea, but we need a better way of doing it.