2026-11-08 Hacker News Top Stories

SuperTechFans · 科技资讯

2026-11-08 Hacker News Top Stories #

  1. Mitchell Hashimoto 发布 MIT 许可的 libghostty-vt 1.0，稳定 C ABI 并完善离线构建与发行版打包；它提供终端模拟核心，不替应用实现界面。
  2. 粉丝项目将 2004 年《极品飞车：地下狂飙 2》的 x86 程序静态重编译为 WebAssembly，以 WebGPU 绘图，支持在线自由漫游；仓库构建要求自备指定版本游戏。
  3. Hightouch 用 Jev 按置信度转交 Opus 审查合成身份数据：简单集准确率 98.8%、每千项 0.88 美元；困难集为 95.3%、2.94 美元，降本幅度随难度变化。
  4. Eighth Rank 研究发现 macOS 本地知识库用两组 XGBoost 模型和 144 项特征推断家庭关系；数据受全盘访问权限保护，部分类型是否实际使用仍未查明。
  5. Ajeya Cotra 根据 METR 对 Anthropic 的评估讨论递归加速；“一年内超级智能”依赖持续复利且无新瓶颈的假设，大量关键证据仍被删节。
  6. 彭博报道称 Anthropic 潜在 IPO 买家正讨论 1.2—1.3 万亿美元估值，个别人低至 1.1 万亿美元；仍在磋商，尚非发行定价或已实现市值。
  7. Asahi 宣布 M3 无需实验标志安装，雷电先支持 USB3 与网络、尚无 PCIe/DP 隧道；M3 GPU 刚画出三角形，项目同时启动 GPLv2+ 许可转换。
  8. pwn.ai 展示利用已有宿主内存访问能力接管 Firecracker 线程并输出标记；测试进程以 root 运行且没有 jailer，不能直接推广成所有生产 microVM 均可同样逃逸。
  9. Upload Your RAM 用 2GB、4GB、16GB“捐赠”档位讽刺算力集中，页面实际在浏览器本地申请内存；没有把闲置 RAM 传给云端的实现。
  10. Kevin Boone 的五篇教程用 Linux、C 与 gnu-efi 讲解 x86-64 UEFI 程序、启动介质和文件协议；没有操作系统，但仍依赖固件服务，实验应使用独立磁盘或虚拟机。

1. libghostty-vt 1.0 发布：终端模拟核心与 C ABI 稳定 (Libghostty 1.0) #

https://mitchellh.com/writing/libghostty-1-0

Mitchell Hashimoto 宣布 libghostty-vt 1.0 发布。这是从 Ghostty 核心提取的可移植终端模拟库，提供 C 接口；“1.0”意味着库及 C ABI 进入稳定阶段，而非 Ghostty 图形终端推出另一个同名版本。作者列举 JetBrains IDE、Emacs 的 Ghostel、Turborepo 等采用案例，并指出 Neovim 的替换补丁已获认可，仍待正式版本为发行版打包创造条件。

接口通过不透明句柄、枚举键访问器、携带大小信息的结构体等方式兼容未来扩展，CI 检查 ABI 基线，ELF 符号也做版本管理。独立发布周期、签名源码包、完整依赖包、SONAME、pkg-config 和 CMake 配置，让发行版能离线构建并按标准方式安装。

库及依赖采用宽松许可，默认运行时依赖 libc，可在关闭相应功能后做无 libc 的独立构建。作者报告曾在 4 核、8GB 服务器上运行一万个带活跃 shell 的终端，但为控制内存使用采用 dash 而非 bash。这是特定测试，不是所有嵌入场景的容量保证。文章最后还限定，其性能比较指解析吞吐与内存，界面、绘制和窗口管理仍需由使用库的应用提供。

HN 热度 1016 points | 评论 176 comments | 投稿者：mfiguiere | 发布时间：2026-11-07 07:30:52 +08:00 #

https://news.ycombinator.com/item?id=50399933

  • 已有嵌入者认为复用成熟终端核心省去大量协议与兼容性工作，比再从零实现一个模拟器更有价值。
  • libghostty 不附带界面，libvte 则带 GTK 组件，这一区别决定了可嵌入范围与应用需要承担的工作。
  • 不透明句柄、可扩展结构与自动 ABI 检查为设计长期维护的 C 接口提供了具体范例。
  • 也有人质疑在代理擅长机械迁移的时代是否仍需如此强调兼容，但认可发行版分发涉及长期的人类信任与维护。
  • 内联图片、OSC-8 链接和快速滚动对新一代 TUI 代理是可感知的功能收益，而不只是基准数字。
  • Emacs 用户分享用 Ghostel 同时运行多组编码代理的体验，说明终端核心复用也能改善现有编辑器工作流。
  • 独立终端的选择仍取决于渲染观感和个人功能需求，库成功不意味着所有用户都应更换现有终端。

2. 《极品飞车：地下狂飙 2》进入浏览器，加入在线自由漫游 (Need for Speed Underground 2 online in the browser) #

https://nfsu2.xyz/

nfsu2.xyz 展示了在浏览器中运行《Need for Speed: Underground 2》的粉丝移植，支持宽屏、在线竞速和自由漫游，以及键盘、手柄、方向盘与触控。作者说，最初只是想和兄弟重新玩二十年前的游戏；页面宣称最高可到 120fps，但这不是对所有浏览器与设备的实测保证。支持者可捐助托管费用，页面表示没有付费特权或微交易。

相关 README 解释了技术路线：以 NFSU2Recomp 的静态重编译为基础，把 x86 代码先转为 C，再编译为 WebAssembly；Direct3D 9 对应 WebGPU，声音使用 Web Audio，游戏线程通过共享内存上的 workers 运行，Rust 服务连接多人游戏。它不是简单把 PC 画面串流到网页。

仓库声明与 Electronic Arts 无关联、未获其背书，也不包含原游戏代码或素材；自行构建要求拥有指定北美 1.2 版 PC 游戏。代码的 MIT 许可不能自动等同于游戏素材获得授权。可玩性还取决于浏览器的 WebGPU 支持，README 主要面向最新 Chrome 及支持 WebGPU 的 Firefox；并不能由此认定所有手机、Safari 或 Linux 配置都能直接运行。

HN 热度 761 points | 评论 217 comments | 投稿者：fluxusars | 发布时间：2026-11-07 17:36:36 +08:00 #

https://news.ycombinator.com/item?id=50403052

  • 音乐、夜间赛道和与亲友轮流玩的记忆，是这次移植带来强烈怀旧感的重要部分。
  • 许多玩家同时涌入自由漫游制造出鸣笛、烧胎和乱跑的混乱场景，多人互动本身成了新乐趣。
  • 担忧版权的一方认为，重编译工具开源与公开托管商业游戏素材是两回事，收取捐助也不能消除争议。
  • 另一方从文化保存角度支持可访问的老游戏版本，认为停止销售的作品不应只因权利长期封存而消失。
  • 浏览器的 WebGPU 兼容性与平台标记仍有落差，用户也对启用标为不安全的实验选项提出疑问。
  • 素材加载卡顿和触控下手动换挡不够直观，说明能启动游戏与舒适游玩之间仍有差距。
  • 部分玩家更希望把多人和现代兼容性改进带到本地版本，浏览器的便捷并不适合所有使用场景。

3. Jev 遇到难题再问 Opus：身份合并审查中的成本与准确率取舍 (A Jev that can ask Opus for help gives Opus accuracy at 4x lower cost) #

https://hightouch.com/blog/llm-judges-identity-resolution

Hightouch 研究如何用模型检查身份解析系统是否把不同的人错误合并。团队借助 pseudopeople 生成虚构小镇资料，构建一千个身份，其中一半含单人噪声记录、一半人为过度合并，再另造更困难的近似姓名、亲属和日期错误案例。它评估的是合并结果审查，不是已经证明能普遍改善所有编码代理任务。

在简单集上，单用 Opus 5.5 的准确率为 99.0%，每千项成本 3.86 美元；Jev 先判断、把置信度处于 30%—90% 的案例送给 Opus 后，准确率 98.8%，成本 0.88 美元，约节省到原来的四分之一。困难集则为混合 Jev 95.3%、2.94 美元，对比 Opus 95.1%、5.39 美元，优势约为 1.8 倍成本差，而非仍然四倍。

作者认为关键在于知道何时不确定：Luna 单独判断在简单集更准，但在困难集中过于自信，难以有效转交复核。混合方案可随难度自动增加强模型调用。不过这些是特定提示词、阈值、模型版本及合成分布上的结果，测试中过度合并占一半，也不同于健康真实数据中低发生率的情况；成本和时延由作者环境测得，原文明确表示会随配置变化。

HN 热度 570 points | 评论 144 comments | 投稿者：theanomaly | 发布时间：2026-11-07 03:48:51 +08:00 #

https://news.ycombinator.com/item?id=50397429

  • 这项结果针对身份合并审查，标题不能被理解为小模型在任意任务都能复制 Opus 的能力。
  • 只画各置信区间的错误数量不足以比较校准，读者希望看到正确率分母、可靠性曲线或 ECE 等更合适指标。
  • 分流是否划算高度依赖模型版本、任务和调用链延迟，新的低价模型可能很快改变原有成本优势。
  • 如果每个判断都必须给出完整解释，单独的决策模型层可能只增加步骤，未必继续节省成本和时间。
  • 真实身份匹配还要考虑错误合并与漏合并的不同代价，以及信息不足时允许弃权，而不能只最大化总准确率。
  • 更便宜的身份关联也引发隐私担忧，技术上减少过度合并并不自动回答哪些个人数据应被关联。
  • 使用者分享了以决策模型分流安全检查或代理会话的经验，说明按任务选择强模型的思路已有实际探索。
  • 取得足够可靠的校准数据本身就是成本，不能把用强模型标注再训练或校准便宜模型当作免费前提。

4. 研究者拆解 macOS 个人知识图谱及家庭关系分类器 (Every Mac comes with an (undocumented) family member classifier) #

https://8rank.ai/game/apple-intelligence-personal-knowledge-graph

Eighth Rank 研究者分析 macOS 的 knowledgeconstructiond 与 intelligenceplatformd，描述它们如何将联系人、照片、日历、通信元数据等整理为本地个人知识图谱。研究主要基于 macOS 26.6.2，称相关组件自 macOS 13 起已存在；目录内有 51 个 SQLite 数据库，主图使用 181 类实体与 278 种谓词，记录来源、置信度和时间。

其中两组 XGBoost 分类器使用 144 项特征，包括姓氏、住址、家庭共享，以及照片和通信出现的时间模式。家庭评分另存在 entityTagging.db，含十七个关系列，但作者只为其中两列追踪到随系统分发的模型，其他列如何产生尚不清楚。声明了某种类型，也不等于该类型一定会被采集或填值。

作者担忧聚合后的关系信息可能成为隐私单点风险，还发现过期表与推断可能比原始联系人保留更久，但无法确定统一清理期限。数据库本身为明文 SQLite，目录受 TCC 全盘访问权限保护；文章没有证明这些信息被任意网站读取或自动外传。配套 iKnow 是本机只读仪表盘，示例图部分使用虚构数据，macOS 27 的适配也不完整，不能把展示中的全部关系评分当成真实观测。

HN 热度 560 points | 评论 327 comments | 投稿者：infwhispers | 发布时间：2026-11-07 17:46:03 +08:00 #

https://news.ycombinator.com/item?id=50403097

  • 支持者认为本地关系图有助于 Siri 理解“联系老板”等请求，关键是透明告知、可选择启用及明确的数据保护。
  • 即使不上传云端，持续记忆和关系推断也可能改变人际交流中允许遗忘与保留模糊性的社会预期。
  • 将分散资料聚成一张关系图，会放大设备失窃、被调查或账号遭入侵后的潜在损害，本地存储并非没有风险。
  • 部分用户在很少使用的 Mac 上看到来自手机的资料，认为“本地”还需要交代跨设备同步和来源范围。
  • 用户后来更正了“自己不能读数据”的抱怨，终端缺少 TCC 全盘访问权限不能直接等同于系统禁止本人查看。
  • 有用户报告关闭 Siri 或相关智能功能后仍看到数据，因而要求说明各开关究竟停止了哪些收集和推断。
  • 错误关系推断与 Siri 实际找错联系人的体验，让用户质疑这些额外数据是否兑现了足够可靠的功能收益。
  • 把受保护数据库显示到浏览器中也会引入新的暴露面，审视工具本身的权限与扩展访问风险同样重要。

5. AI 加速 AI 研究了吗？Cotra 的短时间线推演与证据限制 (AI is dramatically accelerating AI research) #

https://www.planned-obsolescence.org/p/ai-is-dramatically-accelerating-ai

Ajeya Cotra 解读 METR 对 Anthropic 研发加速的公开评估，认为 AI 对研究工作的帮助可能已接近“整体能力进步速度翻倍”的重要门槛。她明确表示未参与该项目，也未看过未删节报告，文章代表个人判断。其推算区分能力进步、算法效率和研究劳动：若整体速度因软件研究而翻倍，劳动端的有效加速可能需要远高于两倍，她用简化模型估到约 4—9 倍，乃至不确定的十倍量级。

进一步的“一年内极端超级智能”是有条件外推：假设更强 AI 持续加速研发、加速平滑复利，且没有新的实验算力、数据或其他瓶颈，进步速度翻倍的时间可能不断缩短。它不是已经测量到的结果，也不是可以从一次斜率变化直接证明的未来时间表。

另读 METR 原报告，其 AECI 基准趋势估计加速 1.9 倍，95% 区间 1.5—2.8 倍；约八成当前加速归因于 AI 是带显著不确定性的主观判断。大量最有信息量的材料被 Anthropic 删节，评估也承认基准分布、非 AI 因素及较早低增长基线可能影响结论。Cotra 据此主张加强安全与治理，但读者仍应把观察、归因、建模与风险预测分开。

HN 热度 361 points | 评论 336 comments | 投稿者：yurivish | 发布时间：2026-11-07 04:27:23 +08:00 #

https://news.ycombinator.com/item?id=50397994

  • 从事机器学习的读者承认软件实验可能大幅提速，但认为这不足以直接推出武器研发或物理世界也同速加快。
  • 可验证基准的进步未必覆盖难以量化的智能能力，基准分数加速与全面超级智能之间仍有推理距离。
  • 关键归因证据被删节，使外部研究者难以复核最重要结论，信任评估团队不能完全替代公开材料。
  • 资本、人才和并行实验投入也可能改变研究速度，需要将这些因素与模型本身能力提升分别识别。
  • 训练吞吐、实验硬件及算法收益递减可能成为瓶颈，尚未遇到极限不能证明复利能够无限持续。
  • 另有实践者认为 AI 在性能优化、工具衔接和小模型实验中已带来明显帮助，平凡工程改进也能累积成研究收益。
  • 个人任务做得更快，可能部分来自同时创造了更多围绕 AI 的新任务，因此还需检查最终研究产出而非只看忙碌程度。
  • 支持 AI 发展的读者也质疑主动追求失控式加速，认为提高能力和保持人类控制应同时成为目标。

6. Anthropic IPO 估值预期承压，部分买家看低至 1.1 万亿美元 (Anthropic IPO buyers see valuation as low as $1.1T) #

https://www.bloomberg.com/news/articles/2026-11-06/anthropic-ipo-valuation-expectations-pressured-after-ai-rout

彭博原站未能直接读取，以下依据 The Edge 刊载的完整彭博报道。报道援引知情人士称，在预计次周启动正式 IPO 营销之前，Anthropic 潜在买家正在讨论约 1.2—1.3 万亿美元估值，部分人考虑低至 1.1 万亿美元。此前买家向承销银行表达的合理估值约为 1.4—1.5 万亿美元，10 月初曾有人估到 2 万亿美元。

背景是科技股大幅下跌和数据中心扩张面临更强审视。报道列出纳斯达克 100 指数周四跌 6.4%、市值减少 2.3 万亿美元，并提到市场波动率上升令 IPO 更难推介。上述数字是报道采用的市场背景，不应与其他指数或不同交易日混用。

知情人强调磋商仍在进行，未作最终决定，Anthropic 发言人拒绝置评。文章讨论了先以保守规模和估值试探需求、需求转好后提高目标，或推迟营销等可能路径，并引用分析人士对延迟成本的不同判断。因此标题中的“低至”只是部分潜在买家的看法，不能写成公司已接受的新估值，也不能把估值总额当成此次拟募资金额或上市后成交市值。

HN 热度 308 points | 评论 611 comments | 投稿者：dgellow | 发布时间：2026-11-07 00:54:36 +08:00 #

https://news.ycombinator.com/item?id=50394906

  • 即使较早期预期下降，1.1 万亿美元仍是极大的估值，使用“低”字需要保留比较基准。
  • IPO 配售价决定初始认购和融资，上市后的交易再形成二级市场价格，两者不能混为一谈。
  • 本地模型和更便宜的组合方案可能压缩部分高价服务需求，长期收入不能只按当前使用热度外推。
  • 另一方强调本地模型是否够用依赖任务复杂度与质量要求，个人替代成功不代表企业需求普遍消失。
  • 用户对订阅与额外 API 额度的巨大价差感到意外，并据此质疑当前套餐的长期经济性。
  • 仍有读者认为 AI 使用范围和商业需求会继续扩张，估值回落未必等于行业增长已经见顶。
  • 当推理能力趋于商品化，差异化产品、工作流与客户关系可能比单纯模型接口更能支撑商业壁垒。
  • 数据中心监管、锁定期和市场窗口等外部因素也会影响认购意愿，技术进步不能单独决定 IPO 时点。

7. Asahi Linux 7.3 进展：M3 支持开放，雷电仍有限，启动 GPL 转换 (Asahi Linux Progress Linux 7.3) #

https://asahilinux.org/2026/11/progress-report-7-3/

Asahi Linux 的 Linux 7.3 进展报告宣布，M3 系列支持不再需要安装器 EXPERT 标志，显示控制器 DCP 的启用改善了性能、电池与显示区域使用，并让相应设备可启用睡眠。但 GPU 是明显例外：M3 GPU 逆向工程目前达到初始化和绘制三角形，不能据“普遍可用”理解成所有图形功能已与 M1/M2 一致。

上游工作包括音频与视频解码驱动提交审查，以及 M4 Pro/Max、M5 的初始设备树；后者只足以启动到 TTY。雷电支持开始下发，但目前仅 USB3、XDomain 和雷电网络，尚不支持多数扩展坞所需的 PCIe 与 DisplayPort 隧道。Fedora Asahi Remix 45 则首次与 Fedora 主版本同日发布。

游戏方面，团队试验 Google 的每进程页大小 P3S，让部分 x86 游戏无需 muvm 运行，以减少虚拟机开销；但补丁仍针对特定页大小硬编码、上游前景未明，因此暂不正式下发。报告还宣布开始将仓库转为 GPLv2+ 等强 copyleft 许可，理由是团队声称遭到未署名搬运、商业替代与 LLM 改写遮蔽来源。这里是项目方的解释和转换计划，不能写成所有仓库已转换，或把未点名对象的行为当成独立证实。

HN 热度 295 points | 评论 241 comments | 投稿者：ackyshake | 发布时间：2026-11-07 13:20:18 +08:00 #

https://news.ycombinator.com/item?id=50401867

  • 外接 USB-C 显示器是部分用户真正的迁移门槛，初步雷电支持不等于显示输出问题已解决。
  • 硬件支持不是全团队按一个优先级逐项推进，不同开发者和子系统难度会造成看似不均衡的进展。
  • 支持转换许可的一方希望共享改进继续开放，并愿意增加捐助来支持长期逆向与维护。
  • 反对者认为既然曾主动选择宽松许可，就不应把他人商业使用或分叉本身视为违背规则。
  • 从 MIT 转向强 copyleft 还可能提高 BSD 等其他开放系统复用成果的难度，这也是许可选择的实际取舍。
  • 下游快速整合与上游基础工作各有价值，比较进度时不能忽略新发行版依赖已有 Asahi 支持的事实。
  • 原生 Linux 对重视软件选择和 GPU 性能的用户仍有价值，macOS 中的虚拟机并不满足完全相同的需求。
  • AI 能否加快硬件逆向引发争论，但自动生成代码与稳定支持真实设备之间仍需要验证其贡献。

8. Firecracker 逃逸演示第二篇：宿主内核漏洞之后，还须看运行配置 (Firecracker VM Escape: PwnEscape Part 2) #

https://pwn.ai/blog/firecracker-escape

pwn.ai 延续前篇 Linux 漏洞研究，展示在已经获得部分宿主物理内存访问能力后，如何定位运行中的 Firecracker 进程与 vCPU 线程保存状态，并改变其恢复执行的路径。演示的可观察结果是宿主进程输出一个八字节标记，随后恢复临时栈修改，Firecracker 与客户机 SSH 仍继续工作。这是作者保留记录中的结果，本次未运行其中的利用代码。

原文给出非常重要的环境限定：Firecracker v1.16.1、x86-64、特定宿主与客户机内核；VMM 直接以 root 启动，没有使用 jailer。因此被控制调用获得 root 权限来自该进程原有权限，不能忽略生产环境通常使用的降权、命名空间和 seccomp。作者也承认不同构建的代码签名与恢复路径要重新验证。

另读 Vercel 对挑战赛的说明，其确认根因位于宿主 Linux 网络栈：生产沙箱展示了宿主内存泄漏，崩溃与执行代码在研究者自建、匹配配置的环境中演示，补丁细节当时仍在审查。因而这里既不能把问题缩小成“只要加 jailer 就万无一失”，也不能把后续进程劫持说成独立发现了 Firecracker 自身的新解析漏洞。

HN 热度 279 points | 评论 127 comments | 投稿者：SerCe | 发布时间：2026-11-07 03:33:38 +08:00 #

https://news.ycombinator.com/item?id=50397219

  • 文章应更醒目说明 root 与无 jailer 的演示环境，否则读者容易把特定后续利用误读成所有部署的默认状态。
  • 另一方提醒前置原语已经涉及宿主内核，用户空间的 jailer 并不自动阻止攻击者转向其他宿主目标。
  • 这是已有 PwnEscape 漏洞的后续利用说明，进入新讨论不等于又发现一个独立漏洞。
  • 硬件虚拟化也依赖庞大的宿主软件栈，讨论隔离强度时应比较完整攻击面而非只看是否用了 microVM。
  • 在 microVM 外再加受限 zone 或其他隔离层能增加纵深，但也不能假定第二层没有自己的逃逸风险。
  • 有人更看好让小型独立 hypervisor 承担隔离，把复杂 Linux 放在管理域中，同时也需认识其他架构已有类似思路。
  • 质疑者认为既然前提已能读写宿主内存，接管特定 VMM 进程的新增安全意义需要解释得更清楚。

9. “上传你的 RAM”是恶搞，但本地内存占用是真的 (Upload Your RAM) #

https://uploadyourram.org

UploadYourRam.org 把“闲置个人内存不够高效”的争论包装成捐赠网站：用户可选择 2GB、4GB 或 16GB，文案承诺支持好事业、拯救一个 LLM，甚至获得 Sam Altman 亲自致谢。这些是讽刺性表演，不是可以将已购买的物理内存通过网络交给 AI 公司的技术或真实捐赠服务。

读取首页和 allocate.html 的代码可见，按钮会创建多个小 iframe，各自反复构造 Uint8Array，完成后给父页面发送消息，页面再显示感谢提示。所读实现没有把内存内容上传到云端的网络传输逻辑；它消耗的是当前浏览器的本地资源。界面的“1GB”及各档位标签也不能直接视为精确测量后的内存转移量。

这使笑话多了一层真实副作用：看似虚构的捐赠界面并不只是改一下文字，也可能造成内存压力。这里仅静态阅读页面与脚本，没有点击分配按钮或验证实际资源上限；浏览器能否完成、何时回收以及不同设备上的表现仍不确定。站点的讽刺立场也不能替代对其引用言论完整上下文的核验。

HN 热度 265 points | 评论 247 comments | 投稿者：susanthenerd | 发布时间：2026-11-07 18:15:26 +08:00 #

https://news.ycombinator.com/item?id=50403214

  • 有用户选择大额档位后浏览器标签页崩溃，恶搞页面的虚构承诺与真实内存耗用应明确区分。
  • 部分读者认为被讽刺言论的完整上下文并不那么奇怪，不应只靠一个摘句评价原意。
  • 也有人把网站视为普通的轻松讽刺，即使认为原话被断章取义，仍觉得这个玩笑有趣。
  • 讨论更深的担忧是计算与知识能力向少数云端平台集中，个人设备的自主性可能被持续削弱。
  • 内存扩产涉及高额投入和周期风险，需求突然逆转会造成过剩，不能把供应不足简单归咎于厂商不肯生产。
  • 关于普通人是否需要大量 RAM 的争论，应比较现代多任务、显示和应用规模，而不是只列出几十年前也能完成的任务名称。
  • 本地模型与家庭实验环境提供了新的内存用途，消费者需要资源并不只是为了更臃肿的软件。
  • 有人把集中化看成新负载出现后的周期阶段，区分本地足够好与本地追平最大前沿系统这两个目标。

10. 用 Linux 和 UEFI 从零开始写裸机程序 (First steps in bare-metal programming using UEFI) #

https://kevinboone.me/efitest_index.html

Kevin Boone 的系列面向有 Linux 与 C 经验、但不懂 UEFI 的开发者，讲解如何写在开机时由固件直接执行的程序。这里的“裸机”指没有通用操作系统参与运行，但仍利用 UEFI 提供的控制台、内存和文件服务，并不是完全抛弃固件、从复位入口自行实现所有硬件驱动。

教程以 64 位 Intel/AMD PC 为目标，使用 GCC 与 gnu-efi，把程序编译、链接并转换为 UEFI 识别的 PE32+ 格式。它特别解释 Linux 常用调用约定与 EFI 的区别、包装函数的作用，以及 16 位字符串等容易让普通应用开发者困惑的细节。后续覆盖 EFI 系统分区、可启动 DVD/USB 介质和 Simple File Protocol：先从协议与卷的根目录取得文件接口，再读写、枚举目录或查询卷。

局限写得很明确：内容只到入门阶段，固件支持和开发库路径会因系统而异，EFI 没有 Linux 那样的统一文件系统和完整标准库。准备磁盘的步骤会覆盖分区，作者要求使用闲置磁盘或虚拟磁盘，并推荐虚拟机试验。文中也承认部分句柄释放等经验做法并不理想，因此适合作为理解接口的起点，而非无需审查就可部署的生产级参考实现。

HN 热度 246 points | 评论 54 comments | 投稿者：LaSombra | 发布时间：2026-11-07 00:50:29 +08:00 #

https://news.ycombinator.com/item?id=50394855

  • 读者认可教程从真实开发困难出发、解释概念且承认局限的写法，认为它适合建立 UEFI 入门知识。
  • 缺少常规 C 库并非完全无路可走，社区提出 EDK II libc 和有限 POSIX 兼容层作为不同取舍。
  • 把未解析外部符号检查加入构建过程，可以比启动后才崩溃更早发现不完整的 EFI 程序。
  • GCC/Linux 并不是唯一开发路线，BSD 系统、其他架构和既有 OSDev 资料也提供不同工具与背景。
  • 如果目标并非替换启动器，可以考虑由 Multiboot2 等现有引导接口进入程序，而不必从头处理全部 PE32+ 流程。
  • UTF-16、VFAT 和特定调用约定让一些开发者觉得 UEFI 过于繁复，接口历史兼容性不等于现代开发体验友好。
  • “裸机”是否仍可调用 UEFI 引发概念讨论，一方更看重没有操作系统阻止程序直接接触硬件，而非启动前完全没有固件。

查看原文