Here's a summary of the key themes discussed in the Hacker News thread, along with supporting quotes:
Microkernels vs. Monolithic Kernels: The Debate Continues
The discussion revisits the long-standing debate between microkernel and monolithic kernel architectures. There are clashing opinions on their respective merits in the context of modern operating systems. Some believe microkernels are the future, citing security benefits, while others argue that monolithic kernels remain practical and offer comparable performance.
- Pro-Microkernel Arguments: Some users argue that microkernels are superior for security and modularity. "Designing a modern and secure kernel in 2025 as a monolith is a laughable proposition. Microkernels are the way to go." - uncircle
- Anti-Microkernel Arguments: Others suggest microkernels have minimal practical benefit in modern times due to cheap hardware and virtualization. "In modern times, the practical benefit from a microkernel is minimal. Hardware is cheap, disposable, and virtual machines exist. The use case for "tolerate a chunk of the kernel misbehaving" are minimal." - dale_glass. Some also point out the potential performance overhead of IPC in microkernels. As hardwaresofton stated, "This IPC often has a performance impact, which is a big part of why microkernels have remained relatively unpopular."
- Historical Context and Relevancy: Some users dismiss microkernels based on historical arguments. "There are hordes of developers completely dismissing the idea of microkernels with no serious argument other than 'lmao didn't Linus destroy Tanenbaum that one time?'" - uncircle. There's also a counter-argument that simply because Linux succeeded, it doesn't invalidate microkernel architectures. "I've seen this exact opinion before, only the year in it was '1992'. And yet Linux was still made and written regardless of it." - Joker_vD.
Performance of Microkernels: Optimizations and Trade-offs
The performance implications of Inter-Process Communication (IPC) in microkernels are discussed, with some arguing that modern microkernels have significantly reduced this overhead.
- Optimized IPC in Modern Microkernels: Some mention that modern microkernels, like seL4, have aggressively optimized IPC. "Sending a message via sel4 ipc is apparently an order of magnitude or two faster than syscalls under Linux." - josephg
- Techniques for Optimizing IPC: Some users explain techniques to achieve optimized IPC, such as using CPU registers for arguments and minimizing context switching. "The trick with L4 is they treat IPC basically like syscalls. Arguments are left on CPU registers instead of serializing them to a message buffer." - winternewt
- Monolithic Kernels Implementing Microkernel Functionality "A monolithic kernel can always clone microkernel functionality wherever it wants, without paying the price elsewhere"- dale_glass.
Rust and Kernel Development: Safety and Security
The discussion highlights the use of Rust in kernel development, particularly in the context of the Asterinas project, and the trade-offs between safe and unsafe Rust code.
- Safe vs. Unsafe Rust in Asterinas: The Asterinas project's approach of separating privileged (unsafe Rust) and de-privileged (safe Rust) code within the kernel sparks discussion. "Only the privileged Framework is allowed to use unsafe features of Rust, while the unprivileged Services must be written exclusively in safe Rust." - Quote from project website.
- Rationale Behind the Privilege Separation: Some explain the rationale for this separation, emphasizing that the privileged part encapsulates low-level, hardware-oriented unsafe operations behind safe APIs. "So the privileged part is privileged because it does unsafe stuff." - magicalhippo
- Terminology Confusion: Recognizing that the naming privileged and unprivileged is easily misinterpreted, ronjakoi, the author of the article stated: "Perhaps I, as the author of this article, could have also been more careful with the terminology."
- Advantages of using safe Rust in the kernel As Tatetian16 describes, Asterinas will have "clear advantages over Linux thanks to its memory safety guarantee and small TCB."
The Practical Challenges of New Operating Systems
The thread touches on the difficulties of creating a new, usable operating system, particularly in abstracting away hardware complexities and the importance of device drivers.
- Driver Development as a Bottleneck: The challenge of writing device drivers is highlighted as a major obstacle for new operating systems, referencing Linus Torvalds' observation about the importance of a stable (or unstable from the driver writer's perspective) driver interface. As weinzierl puts it, "keeping the driver interface unstable is his moat."
- Hardware Quirks and Lack of Standardization: The discussion acknowledges that hardware often deviates from standards, requiring significant effort to handle quirks and errata. leeter states that "the realities of hardware are that it never behaves nominally."
- Potential Solutions for Driver Development: The reuse of existing Linux drivers, either through translation to Rust or by running a Linux kernel in isolation, is discussed as a potential solution. According to Tatetian16 "Maybe we will have young and hungry AI-for-system researchers who would like to take on the job of developing AI agents that translate Linux drivers in C to Asterinas ones in (safe) Rust."
- Confidential VMs Tatetian16 states, "Our initial focus is to use Asterinas as the guest OS inside Confidential VMs. This use case prioritizes security, where Asterinas has clear advantages over Linux thanks to its memory safety guarantee and small TCB."
Kernel Security and Trust in Modern Designs
The evolving landscape of kernel security is examined, stressing the challenges of maintaining trust within monolithic kernels and the potential advantages of capability-based systems in microkernels.
- Implicit Trust in Monolithic Kernels: The concept of implicit trust between kernel components in monolithic kernels is questioned, highlighting potential vulnerabilities. "In a monolithic kernel, you can have implicit trust that things will happen" - dale_glass
- Capabilities as a Solution: Capabilities are presented as a more secure and scalable alternative to implicit trust, offering better security guarantees in microkernel architectures. "Capabilities have solved this problem in a much better and scalable way than the implicit trust model you have in a monolithic kernel." - uncircle
- Security Concerns with Loadable Modules: Concerns are raised about the security implications of loading third-party modules into monolithic kernels, emphasizing the risk of running untrusted code in kernel mode. "how do you deal with implicit trust when you can load third-party modules at run-time?" - uncircle
Adoption and Socio-Political Factors
The thread briefly acknowledges that technical merits alone don't determine the adoption of projects. Social, political, and marketing factors play an important role in the success or failure of an OS.
- Socio-Political Influences on Adoption: immibis states that projects are mostly adopted based "on socio-political processes such as marketing, and only rarely on the actual merits of the project such as performance."