Not a remake or remaster or rerelease of something old, but something inspired or influenced by something either popular or a cult classic. Also this could extend to hardware/tech too, not only media.
Not a remake or remaster or rerelease of something old, but something inspired or influenced by something either popular or a cult classic. Also this could extend to hardware/tech too, not only media.
Those are not really the same thing. You can still run something as a microkernel and maintain it as code bases completely under your control and developed in lockstep or even in one giant repository if you really want to.
But at that point, why? Microkernels and microservices etc are best served when there is organisational separation so that teams can work in isolation of one another and for systems that are independently deployable. Device drivers depend on the kernel and to be compatible; orchestrating that as independent efforts would be painfully slow and inconsistent (not something you want for something as critical as a kernel).
The Linux kernel only has drivers in the source tree but at runtime they are separate modules loaded on demand. Given an overwhelming amount of what people see as the monolithic nature of the Linux kernel is the millions of lines of device driver code, their modular nature somewhat negates the argument for separation and ultimately I don’t see the benefit. Especially given Linux’s simpler API without the abstraction of countless user-space servers, and portability this simplicity provides.
I think the parallel of services that were architected as microservices now being refactored to be more monolithic is an interesting lens.
Not to say I’m right on this matter, just that I’m not convinced.
Microservices and microkernels are not really that similar. The great advantage of a microkernel is not so much the separation of concerns but the fact that less code needs to run unsandboxed in kernel space where every bug can potentially corrupt other parts of the kernel or lead to security holes.