HackerNews中文版HackerNews CN
GitHubTwitter

展示HN：一次关于操作系统设计的讨论在一周内变成了一个实际的操作系统

1 分•作者: jonathanrtuck•1 天前•原帖
上周五，我与Claude开始了一场关于操作系统的对话。这场对话演变成了一次设计会议，设计会议又转变为一个原型。从那时起，我几乎没有停下来过。 核心理念是：你的文件存在于应用程序内部。应用程序决定你如何查看内容、可以对其进行什么操作，以及你的工作保存在哪里。如果操作系统能够直接理解你的文件——渲染它们、索引它们、追踪它们的历史——而编辑器只是你在需要修改某些内容时才使用的工具呢？没有“用...打开”，也没有保存按钮。默认是查看，编辑则是有意为之。 经过一周的努力，现有的成果包括：一个用Rust从零开始开发的内核，运行在QEMU（aarch64）上，27个系统调用，具有4个对称多处理核心的EEVDF调度器，一个完整的显示管道（合成器、亚像素TrueType渲染、透明混合、PNG图像查看器），通过共享内存环形缓冲区实现的结构化进程间通信，一个编辑器进程模型，其中操作系统服务是唯一的写入者，一个文件系统原型，900多个测试，包括正式的错误审计，以及约2200行设计文档，包含13个已确定的架构决策。在上周五之前，我甚至从未见过Rust代码。 完整故事包括演示、逐日时间线、我如何与人工智能合作以及我学到了什么：<a href="https:&#x2F;&#x2F;github.com&#x2F;jonathanrtuck&#x2F;os&#x2F;discussions&#x2F;1" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jonathanrtuck&#x2F;os&#x2F;discussions&#x2F;1</a> 代码库：<a href="https:&#x2F;&#x2F;github.com&#x2F;jonathanrtuck&#x2F;os" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jonathanrtuck&#x2F;os</a> 我并不是想要构建下一个Linux。这是一次设计探索——如果从内核开始重新思考整个技术栈，OpenDoc和Xerox Star所尝试的以文档为中心的模型是否真的可行？我真心想知道这个社区的看法。
查看原文
Last Friday I started a conversation with Claude about operating systems. That conversation turned into a design session. The design session turned into a prototype. I haven’t really stopped since.<p>The core idea: your files live inside applications. The app decides how you see your content, what you can do with it, and where your work gets saved. What if the OS just understood your files directly — rendered them, indexed them, tracked their history — and editors were tools you picked up only when you needed to change something? No “open with.” No Save button. You view by default, editing is deliberate.<p>What exists after one week: a from-scratch kernel in Rust on QEMU (aarch64), 27 syscalls, EEVDF scheduler with 4 SMP cores, a full display pipeline (compositor, subpixel TrueType rendering, alpha blending, PNG image viewer), structured IPC via shared-memory ring buffers, an editor process model where the OS service is the sole writer, a filesystem prototype, 900+ tests including a formal bug audit, and ~2,200 lines of design documentation with 13 settled architectural decisions. I’d never even seen Rust code before Friday.<p>Full story with demo, day-by-day timeline, how I worked with AI, and what I learned: <a href="https:&#x2F;&#x2F;github.com&#x2F;jonathanrtuck&#x2F;os&#x2F;discussions&#x2F;1" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jonathanrtuck&#x2F;os&#x2F;discussions&#x2F;1</a><p>Repo: <a href="https:&#x2F;&#x2F;github.com&#x2F;jonathanrtuck&#x2F;os" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jonathanrtuck&#x2F;os</a><p>I’m not trying to build the next Linux. This is a design exploration — can the document-centric model that OpenDoc and Xerox Star attempted actually work if you rethink the whole stack from the kernel up? I’m genuinely curious what this community thinks.