系统与数据库2020dl.acm.org
Unikernels：Linux 主导地位的下一个阶段（2019）
Unikernels: The Next Stage of Linux’s Dominance (2019)
进阶 · 约 60 分钟读完前置知识：操作系统内核基础、虚拟化技术、Linux 系统编程
导读
这篇论文探讨 unikernel（单地址空间、与应用一起编译的专用内核）能否成为 Linux 之后的下一阶段。文中提出将 Linux 内核裁剪为 unikernel 的思路（如 rump kernel 式的 fork 并剔除不需要的组件），并声称 unikernel 在许多重要领域相比 Linux 有巨大优势。
HN 关注点：unikernel 是否真能挑战 Linux 的主导地位，讨论焦点是其宣称的优势是否只是原型验证、与容器相比能解决什么实际问题。
HN 评论精选
这几条评论里：质疑 1 补充 2 亲历 1
补充数据库最适合作为 unikernel 的首个应用场景
在我看来，第一个应用应该是 unikernel 数据库。数据库本来就会绕过内核的几乎所有功能，我一直很惊讶它们至今没有合并到一起。
neilwilson查看英文原文
Seems to me that a unikernel database should be the first application. Databases tend to bypass practically all the facilities of a kernel anyway. It’s often surprised me that they haven’t merged before now.
质疑质疑论文的宣称缺乏实际落地证据，且与容器定位重叠
“unikernel 在许多重要领域相比 Linux 展现出巨大优势”——这里的“领域”是指“实际在业界某些领域使用中”，还是“原型已证明”？“有人提出 Linux 的主导地位可能即将终结”——到底是谁提出的？除了性能之外，它到底解决了什么现实问题？我认为它与容器有重叠，要取代容器得比这好得多才行。
MrBuddyCasino查看英文原文
> Unikernels have demonstrated enormous advantages over Linux in many important domains By domains, do they mean that as "actually in use in certain sectors in the industry" or "a prototype has shown that"? > causing some to propose that the days of Linux's dominance may be coming to an end Who exactly would make that claim? So, besides performance: what actual, real-life problems does this solve? I think there is some overlap with containers, and at this point, replacing them will require something a lot better.
补充补充 rump kernels 的历史背景，指出论文描述出处有误
论文中关于 rump kernels 名称来源（影射英国内战后清洗保皇派）的描述，其实来自 rumprun 2015 年的 GitHub FAQ。Rump kernels 2009 年就在 NetBSD 中引入，当时被描述为 runnable userspace meta programs 的缩写。我没在 Linux 上用过 rumprun，但至今仍在用 NetBSD 自带的 rump 工具。
x3blah查看英文原文
"Also known as rump kernels a name inspired by the infamous purge of royalists from Parliament following the English Civil War this process involves creating a fork of an existing kernel codebase and manually purging it of the components deemed unnecessary to the target unikernel." That appears to come from the FAQ on Github for "rumprun" dated 2015. Rump kernels were introduced in NetBSD in 2009. It was an described then as an acronym for runnable userspace meta programs. https://blog.netbsd.org/tnf/entry/runnable_userspace_meta_programs_in I have not used rumprun for Linux but I still use the rump utilities included with NetBSD.
亲历作者现身答疑
我是这篇论文的作者之一，有问题尽管问。
rwmj查看英文原文
I'm one of the authors on this paper, so ask away if you have questions.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2020Hacker News 讨论帖247 分 · 180 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选