系统与数据库2021citeseerx.ist.psu.edu
操作系统：是否应该只有一个？
The operating system: should there be one? (2013)
进阶 · 约 45 分钟读完前置知识：操作系统原理、编程语言运行时、系统编程基础
导读
这篇 2013 年的论文探讨操作系统是否应该存在这一根本性问题，其核心观点是“操作系统就是一堆放不进语言里的东西的集合，因此本不该有操作系统”。文章质疑传统 OS 的必要性，引发对语言运行时能否取代 OS 的思考。
HN 关注点：HN 读者长期关注“去 OS 化”这一话题，讨论焦点在于 OS 应该更精简还是被更高层抽象（如 Web 技术、语言运行时）取代，以及图形 API 的演进是否预示了这一趋势。
HN 评论精选
这几条评论里：支持 2 补充 2
支持现代 OS 处于既不够底层又不够高层的尴尬中间地带，Electron/Qt 正在充当事实上的 OS，OS 应该更精简
我不禁想到图形 API 的演变——老 API（DX9、OpenGL）更照顾用户，新 API 则极其贴近裸机、不适合胆小者。但多数人认为这是进步：应用开发者可以用更高层的库，引擎开发者则获得更多控制权。老 API 处于既不好用又不够底层的尴尬中间地带，没人满意。现代 OS 栈（至少 Windows 和 macOS）处境类似：真正的底层控制很痛苦，但 OS 库又不够高层好用。于是 Electron 或 Qt 在不同程度上充当了事实上的 OS，代价是不可否认的资源浪费。我在想，既然现代语言和工具链已经足够先进，OS 是否应该变得更原始、更精简。某种程度上我们正在朝这个方向走——Web 技术正成为事实上的用户空间和工具集。这没问题，但如果没有那 50 层的历史包袱，我们的机器本可以快得多。Smalltalk 在很多方面确实像自己的 OS，堪称程序员的 OS，虽然不太适合普通用户。
overgard查看英文原文
I can't help but think about what happened with graphics APIs - the older ones (DX9, OpenGL) held your hand more, and the new ones are super bare metal and not written for the faint of heart. I think most would agree this is better though; for an application developer you can simply use a much higher level library built on top, and for the library/engine developer you have a lot more power and control. The old APIs were in an awkward middle ground of not being particularly easy to use, but also not being nearly low level enough. Nobody was happy. I think modern OS stacks are in a similar boat, at least Windows and macOS. True low level control is kind of a pain, but the OS libraries are not particularly pleasant or high level enough either. So largely things like Electron or Qt are acting as the defacto OS anyway to varying degrees of success but undeniable levels of resource waste. I wonder if modern languages and tooling and such are advanced enough that the OS should become more primitive and minimal. In a way it feels like we're moving there anyway with web tech becoming the defacto user space and toolkit. That's fine, but god if it wasnt all built on 50 layer of cruft our machines would be screaming fast. Smalltalk, if you get a chance to use it, really does act like its own OS in so many ways. It's great as a programmers OS really, although it doesn't really hit the right notes for average use. Still though, if someone had the urge to build it I could easily see a smalltalk based userland built on like a linux kernel (with no gnu user space) being a totally viable thing.
补充主张 OS 之间通过标准接口分层协作，设备驱动和文件系统应由 UEFI 等标准层统一提供
我希望操作系统之间有更多协作，应该有更多带标准接口的层次。比如当年的 BIOS 曾是驱动层，向底层 OS 提供简单 API，这个概念应该扩展。没理由每个 OS 都反复重写驱动。应该为磁盘、键盘、鼠标、GPU 等常见设备制定标准 API——我买一块 Nvidia GPU，装一个 UEFI 驱动，它就应该能为任何底层 OS（Windows、Linux、OpenBSD、ReactOS）提供 Vulkan API。文件系统也一样：各大 OS 从用户视角看非常相似，应该能抽象掉差异。Windows 可以把它的 NTFS 驱动装进 UEFI，Linux 直接用它安全访问 NTFS，而不用费尽心思逆向工程、从头重新实现。我曾想过虚拟化是满足这些需求的答案：如今可以写一个完全虚拟化的 OS，只需实现 virtio 系列驱动，就能在任何宿主 OS 上运行并获得厂商的完美驱动支持。GPU 还不行，但我认为并非不可能。
vbezhenar查看英文原文
I would love more collaboration between operating systems. There should be more layers with standard interfaces. For example BIOS used to be a driver layer back in the day, providing simple API to underlying OS. This concept should be expanded. I don't see no reason for every OS to rewrite those drivers again and again. There should be some standard for common device APIs, like disks, keyboards, mouses, GPU and so on. I should be able to buy an Nvidia GPU, download and install UEFI driver and it should provide Vulkan API for any underlying operating system, Windows, Linux, OpenBSD, ReactOS. Another example is file systems. All major operating systems are very similar when it comes to file systems, at least from the user PoV. Yes, there are Windows ACLs, Linux permissions, but it should be possible to abstract those away enough. So Windows could install its latest Windows 11 NTFS driver into UEFI and Linux should be able to just use it to access NTFS safely, without any gigantic efforts to reverse-engineer and reimplement everything from scratch. At one point I thought about virtualization being an answer to those demands. These days you can write completely virtualized operating system which needs to implement virtblk, virtfs, virtio-* drivers and run it on any host operating system with perfect driver support from manufacturer. GPU is not there, but I don't think that it's impossible to implement. Of course running a full-blown ad-ridden Windows 11 just as a hypervisor seems like not the most elegant solution. Unification will not play nicely with new progressive features like BTRFS, though. That's something to think about as well.
支持OS 应定义为精简的调度器+IPC 核心，把更多功能留给用户态，以获得确定性、可靠性和安全性
先得定义什么是操作系统，因为划线位置不同，结论会大不相同。暂且不谈大型机，只从个人电脑的角度看：如果你把 OS 看作任务调度器 + IPC 交换中心，那系统就是简单、定义清晰的，可以期望它以确定性的、可验证正确的方式运行（假设硬件正常）。如果你把 OS 定义为“什么都塞进来”——媒体播放器、浏览器等等——那就无法做出任何保证，确定性也不可能实现。我个人偏爱更精简的 OS，在其上构建更大的用户态软件圈，让运行最终用户应用的核心尽可能小。这类系统往往能在可靠性、速度和安全性之间找到好的平衡，因为每层暴露的攻击面都最小。Windows 在这个尺度的一端，macOS 居中，Linux 其实可以裁剪得比默认发行版精简得多。
jacquesm查看英文原文
Let's start off with defining what an Operating System really is because depending on where you draw that line the outcome will be substantially different. Ignoring mainframes and other large installations for the moment, strictly from a 'personal computer' point of view: If you see the operating system as the task-schedular + IPC clearinghouse then the system is simple, well defined and it can be expected to perform in a deterministic and verifiably correct way (assuming working hardware). If you define the operating system as 'everything and the kitchen sink' including media players, browsers and so on then there is no way to make any guarantees and determinism is going to be impossible to achieve. Personally I prefer the leaner-and-meaner operating systems that have a larger ring of userland software built on top of them to create as small as possible a core on which the actual end-user applications are run. Those systems tend to find good middle ground between reliability, speed and security because the amount of surface area exposed is going to be the minimum at every level. Something like Windows is on one end of that scale, something like MacOS is somewhere in the middle. Linux can be stripped (or more accurately: it could be stripped) to something a lot slimmer than the default distros, and something like IRIX (no longer used in production as far as I know) was roughly where MacOS sat (custom hardware, custom OS tied closely to that hardware). An ideal OS that limits itself to scheduling and IPC is currently not on the market for desktop usage, and the arrival of the mobile device market has blurred many of the lines that we thought were drawn pretty clearly in the past. The 'lets move everything into the kernel' philosophy is as far as I'm concerned fatally broken and likely things will have to get a lot worse before they will finally get better, and it would not surprise me if everything that we do today will be discarded once that happens.
补充类比提出：文件/文件夹隐喻已过时，可以尝试以数据库为核心来构建操作系统
“操作系统是一堆放不进语言里的东西的集合，所以不该有操作系统”——我对数据库也有同样的疑问。和 OS 一样，数据库也要管理磁盘上的数据并决定何时缓存。文件和文件夹的隐喻可以说是前计算机时代的遗物——与其在文件夹里翻找，不如按特定属性搜索和排序，这正是数据库擅长的。我觉得从数据库出发、围绕它构建一个 OS 会很有意思，看看能走多远。
qPM9l3XJrF查看英文原文
"an operating system is a collection of things that don’t fit inside a language; there shouldn’t be one" I've wondered the same thing about databases. Just like an OS, a database has to manage data on disk and figure out when to cache it. The files & folders metaphor is arguably a relic of pre-computer times--instead of searching through folders, it is easier to search and sort based on particular attributes, something that databases are well-suited to. I think it'd be interesting to start with a database and try to build an OS around it, see how far you could go.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2021Hacker News 讨论帖168 分 · 199 评
同领域还值得读
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 分钟编辑精选