Conversation

Notices

1. Sun Microdevil Pte Ltd (koakuma@uwu.social)'s status on Tuesday, 28-Jan-2025 22:11:42 JST Sun Microdevil Pte Ltd

   From http://tunes.org/wiki/microkernel_20debate.html

   > The only possible justification for a microkernel is not technical. It's political: a microkernel is the only way to allow with any robustness the existence of black-box proprietary third-party binary modules that access and provide deep system resources without anyone having to disclose source code. Microkernels are technically the worst possible organization for system code of same functionality, and the fact that the proprietary closed-source development model encourages such horrors accounts for the deep evil behind that model. It has been suggested that a psychological reason behind the abstraction inversion is that, by a misled tradition, the "Operating System" community stubbornly refuses to mess with language issues (they claim "language independence"), and stick to designing system interfaces for bit-level languages; but we can also track this want of language "independence" to the political issue of proprietary software, since it is what induces the eager clustering of computing into hermetic fields where no one can modify or adapt (proprietary) code from other fields forces people into the paranoid "trust no one, never cooperate: even if you want to, you can't" behavior.

   > Latest developments in microkernels (L4, Xok) amount to reducing as much as possible the semantics and overhead of the kernel, and putting everything in either servers or system libraries. The logical next step beyond these developments would be to reduce the microkernels to zero, naught, nada, and have everything in "modules" that constitute the system, and are high-level concepts without forcibly any obvious, one-to-one direct correspondence between the high-level compile-time modules limits and low-level run-time code barriers. Depending on the point of view, this leaves us either with "monolithic" systems, or with systems without a privileged kernel at all (such as systems built atop the Flux OSKit). Such is the right way, in our opinion: to provide high-level modular design, but without any kernel at all.

   :cirnothinking:

   • xianc78 repeated this.
   • Sun Microdevil Pte Ltd (koakuma@uwu.social)'s status on Tuesday, 28-Jan-2025 22:11:45 JST Sun Microdevil Pte Ltd

     in reply to

     From http://tunes.org/wiki/no-kernel.html

     > A term describing a system without a kernel. The idea looks like it is original as far as operating systems are concerned, but it is so natural that for any other kind of software (and one of our points is that there should be no such privileged notion as that of an "Operating System" well-separated from "Applications") where there isn't such a stubbornly overwhelming tradition, it is the very idea of a kernel that looks odd.

     > Software in a no-kernel system works just like most any software: various objects interact, each doing its part of the work. The difference compared to software in kernel-based systems? No-kernel software is not limited to a single centralizing entry point like the Unix syscall() or DOS interrupts, whose overhead, limitations, bugs and misdesign you must cope with or work around. Instead, objects can directly interact one with the other, and you can upgrade/extend/modify any unlocked part of the system anytime.

     :cirnothinking:

     xianc78 likes this.