最新

上周五，我与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所尝试的以文档为中心的模型是否真的可行？我真心想知道这个社区的看法。

嘿，HN，我很高兴与大家分享 PNANA——一款轻量级、现代化的终端文本编辑器，使用 C++17 和 FTXUI 构建，旨在为习惯在终端中工作的开发者提供简单与强大之间的桥梁。 PNANA 有什么不同之处？ 零学习曲线：摒弃 Vim/Neovim 的模式复杂性，采用与图形界面编辑器相似的 Ctrl+S/Ctrl+Z 快捷键。 美观的终端 UI：开箱即用的主题（Monokai、Dracula、Nord 等）、三列布局和智能状态栏——无需配置即可呈现出色的外观。 内置 LSP 支持：为所有主要编程语言（C/C++、Go、Rust、Python、JS/TS 等）提供原生代码补全、实时诊断、跳转到定义和符号搜索功能。 轻量且快速：终端原生，资源占用低，启动瞬间——非常适合远程服务器和本地开发。 可扩展的未来：计划中的 Lua 插件系统（受 Neovim 启发）将允许用户通过自定义脚本扩展功能。 我很想听听你的想法、反馈或功能请求！查看一下这个仓库，如果你喜欢，请给它加星，让我们一起打造更好的终端编辑器。 英文 README: [https://github.com/Cyxuan0311/PNANA/blob/master/README_EN.md](https://github.com/Cyxuan0311/PNANA/blob/master/README_EN.md)