2026年08月14日 · 星期五 第 160025 期

The Hacker Daily

丙午年(马)七月初二

30 篇文章 · 2910 条评论 ·聚焦:AI模型 · 编程智能体 · 系统安全
No.01 Glm-5.3: Frontier coding with emergent cyber capabilities
GLM-5.3:前沿编程与新兴网络安全能力
319 分 116 条评论 作者: pella
Z.ai 发布 GLM-5.3,宣称仅通过扩大后训练就显著提升编码与网络安全任务能力:在自家代码基准较 5.2 提升约 50%,并在 Terminal-Bench 等公开榜单达到开源 SOTA,权重计划两周后开放。社区普遍认为它虽仍略落后 Sol、Fable、Mythos 等闭源前沿模型,但差距已很小,且体量和成本优势突出。争议集中在后训练是否只是基准过拟合、开放强网络安全能力的风险、缺少多模态、许可证是否真正自由,以及实际长任务稳定性仍需用户验证。

评论精华

  • 开放权重模型逼近闭源前沿,被认为能压低价格、制衡大厂。
  • 网络安全能力引发分歧:防守者需要访问,攻击者也会滥用。
  • 不少人赞赏文章语气克制,承认与闭源模型仍有差距。
  • 缺少多模态被视为实际编码工作流中的明显短板。
  • 后训练被认为是关键进步来源,但也有人担心只是刷榜。
No.02 Gemini 3.7 Flash
Gemini 3.7 Flash 发布
785 分 419 条评论 作者: thisisauserid
Google 发布 Gemini 3.7 Flash,定位为面向编码和智能体的高性价比「主力模型」。相比 3.6 Flash,它在软件工程、网页开发、复杂文档处理和业务自动化基准上明显提升,例如 FrontierCode、DeepSWE、GDP.pdf 与 AutomationBench 均有较大增幅,并改进多步规划、工具调用和指令遵循。模型将接入 Gemini Spark、AI Studio、Android Studio 和企业平台,年内采用 0.75 美元每百万输入 token、3.75 美元每百万输出 token 的引入价。争议主要集中在价格到期后翻倍、与 Luna、DeepSeek、Qwen 等低价模型相比是否仍有优势,以及 Google 是否过度押注快速小模型而缺少新的 Pro 旗舰。

评论精华

  • 许多人质疑「引入价」意义不大,模型迭代太快,五个月后可能已过时。
  • 支持者认为 Flash 系列速度和端到端延迟突出,适合自动化和快速开发循环。
  • 不少评论拿 Luna、DeepSeek、Qwen 等对比,认为 Gemini 价格优势并不明显。
  • 用户实测分化:有人称 Antigravity 和视觉转网页更好,也有人抱怨幻觉和执行不可靠。
  • 社区追问 Google 为何频繁推 Flash,而迟迟没有新的 Gemini Pro 旗舰模型。
No.03 Accelerating GPT-5.6 Sol Ultrafast
Cerebras 为 GPT-5.6 Sol 推出超高速推理模式
556 分 233 条评论 作者: pr337h4m
Cerebras 与 OpenAI 预告 API 新服务层「Ultrafast」,由 Cerebras 晶圆级引擎驱动 GPT-5.6 Sol,最高可达每秒 750 个输出 token,宣称不牺牲质量。文章称其在 Humanity’s Last Exam 上以 11 小时完成 2500 题,较 Claude Fable 5 快近 7 倍;在 GDP-Val 知识工作任务中端到端提速 5.6 倍。Cerebras 将优势归因于 44GB 片上 SRAM 减少大模型推理的数据搬运,并主打故障响应、安全、法律金融工程等高时效场景。争议集中在基准是否公平、价格与配额未知、真实端到端瓶颈未必只在模型输出。

评论精华

  • 不少人认为速度会改变工作流,尤其适合迭代、实时建议和高压响应场景。
  • 也有人提醒端到端瓶颈仍可能在测试、工具调用、编译和外部系统等待。
  • 价格和配额是最大疑问,许多评论猜测可能非常昂贵或迅速耗尽订阅额度。
  • 社区质疑对比图遗漏其他高速模型,且基准由 Cerebras 自测,公平性待验证。
  • 部分人讨论硬件路线,认为晶圆级架构可能让推理基础设施竞争转向速度和成本。
No.04 Hello, me. It's been a while
久违了,我自己
173 分 80 条评论 作者: somesoftdev
作者时隔十四年重启博客,写下对安静与自我思考的重新发现。随着工作、责任和碎片时间被播客、有声书、社交媒体填满,他逐渐养成一有空白就播放内容的习惯,也失去了慢慢听见自己想法的空间。一次做家务时,他刻意不按播放键,起初不适,随后思绪重新流动,意识到内在声音仍在且值得保留。文章呼吁读者偶尔关闭背景声,允许无聊和沉默发生;评论也提醒,噪音环境、压力、ADHD 或专注方式差异,会让沉默并非人人可得或适用。

评论精华

  • 许多人共鸣:摘下耳机、散步或做家务时,思考会自然恢复。
  • 也有人依赖播客、音乐或耳机来应对压力、开放办公室和城市噪音。
  • 评论提到「默认模式网络」和无聊的重要性,认为持续输入会削弱整合能力。
  • 部分人认为外部刺激反而帮助触发思考,走神时未必比沉默差。
  • 另有讨论转向重启博客:沉寂多年后重新写作也值得鼓励。
No.05 Bluesky Protocol Services
Bluesky 推出协议服务与 Jetstream v2
153 分 28 条评论 作者: danabramov
Bluesky 发布「Bluesky Protocol Services」品牌与新站点,集中说明其在 AT Protocol 上运营的公共基础设施,包括 Jetstream、relay 和 API。核心更新是 Jetstream v2:支持通过压缩全网归档进行「Network Replay」和快照下载,开发者可按过滤条件从历史任意点补数据并无缝切到实时流;归档请求需 API token,实时流仍开放免认证。官方还推出 TypeScript 与 Go SDK,更新基于「lex」的 Bluesky TypeScript SDK和 HTTP 参考文档。评论区既认可其降低开发门槛,也担忧 Bluesky 用户增长、资金可持续性及生态方向。

评论精华

  • 有人设想把 DNS 更新发布到 Bluesky feed,让 firehose 成为权威数据源。
  • 开发者称 Jetstream 很易用,甚至可在浏览器直接消费 Bluesky firehose。
  • 官方人员补充 v2 与旧 Jetstream 实时流兼容,只是新增历史回放能力。
  • 部分评论讨论新文档站技术栈,认为是基于 MDX 与 Next.js 的自研框架。
  • 也有人质疑 Bluesky 用户质量、VC 资金可持续性和盈利路线。
No.06 Show HN: C# Game Engine with its own scripting language and IDE
展示:带自研脚本语言和 IDE 的 C# 游戏引擎
19 分 1 条评论 作者: am-gm
这个项目展示了一个用 C# 编写的游戏引擎,并且不只是引擎本体,还包含自研脚本语言和配套 IDE。由于原文无法抓取,信息主要来自标题和评论:作者似乎试图从底层搭建一套完整游戏创作环境,而不是基于现成脚本语言或编辑器生态做集成。社区关注点集中在工程规模和技术取舍上:有人认为同时从零实现语言、IDE 和引擎是一项非常庞大甚至近乎疯狂的工程,也好奇作者为何选择自定义语言,而不是嵌入 Lua 等成熟方案。争议焦点在于自研带来的控制力、学习价值与维护成本之间是否值得。

评论精华

  • 评论者惊叹项目规模巨大,涉及语言、IDE 和引擎三部分。
  • 有人好奇为何自研脚本语言,而不是嵌入 Lua 等成熟方案。
No.07 DeepSeek Harness developer preview
DeepSeek 发布可插拔 Agent Harness 开发者预览
639 分 264 条评论 作者: bjin
DeepSeek Harness 进入开发者预览并开源,定位为让智能体在真实环境中使用工具、理解上下文并持续工作的运行框架。其核心设计是「一切皆插件」:模型、工具、技能、会话、沙箱、存储、循环、调度和 UI 都基于 Cordis 插件系统,可在配置中替换或重组。另一重点是可追踪性,系统会把模型看到的提示、推理、工具调用、子代理调度和上下文注入写入追加式会话日志,并支持查看、恢复、分叉、搜索和回放。它提供标准、代码、最小和创建者等运行模式。争议集中在:页面和 README 对「它究竟是什么」解释不足,插件架构被批评不新鲜或带来插件疲劳,Node/npm 技术栈也引发安全与膨胀担忧。

评论精华

  • 不少人困惑其定位,认为 README 太空泛,像 Claude Code/Cline 类 agent harness。
  • Cordis 插件系统受到关注,亮点在热加载、动态启停和可组合架构。
  • 可追踪运行日志被普遍认可,方便审计模型输入、工具调用和上下文注入。
  • 社区对「一切皆插件」反应两极:有人喜欢扩展性,也有人厌倦插件生态。
  • Node.js/npm 技术栈引发批评,担心体积膨胀、供应链安全和运行时复杂度。
No.08 Show HN: Lumabri – Run Moe Models on a P2P Swarm with Colibri
展示:Lumabri,用 Colibri 在 P2P 群中运行 MoE 模型
4 分 0 条评论 作者: vforno
Lumabri 是一个基于 Colibri 的实验性项目,目标是在点对点网络中运行 MoE(混合专家)模型,把模型推理或专家组件分散到多个节点协作完成。根据标题可推断,它试图降低单机运行大模型的硬件门槛,并探索去中心化算力共享、模型分片与协同推理的可行性。由于原文无法抓取且暂无社区评论,目前无法确认其实际性能、容错机制、带宽开销、隐私设计或与既有分布式推理方案的差异。核心价值在于把 MoE 与 P2P swarm 结合的工程尝试,但可靠性、延迟和节点激励仍是潜在关键问题。
No.09 Spaghettifying DRAM
让 DRAM 地址空间意大利面化
593 分 154 条评论 作者: matt_d
这篇 GitHub 项目展示 Christopher Domas 对 AMD 旧平台 DRAM 控制器的研究:通过改写内存控制器的地址转换或「DCT swizzling」寄存器,让同一个物理地址映射到意想不到的位置,从而在已具备内核态权限时窥探或改写传统上藏在更低特权层的内存区域。评论指出代码主要在 AMD Family 16h、Jaguar 等较老架构上开发测试,现代 Zen 的 UMC、AGESA/PSP 初始化和寄存器锁定可能已不同。争议集中在威胁模型:它不像普通本地提权,更像「root 之后继续越权」的硬件所有权与逆向工具;若虚拟机暴露相关寄存器才可能影响 KVM。另有不少人称赞 Domas 回归,也批评 README 带有明显 AI 写作痕迹、可读性差。

评论精华

  • 多数人认为前提是 ring 0,价值在突破 root 之上的隐藏层。
  • 适用范围疑似偏旧 AMD 架构,现代 Zen 可能因寄存器锁定而不受影响。
  • 有人担心若虚拟机暴露控制寄存器,可能带来 KVM 逃逸风险。
  • 社区把它视为探索 PSP、SMM、平台密钥等隐藏固件的入口。
  • 不少评论称赞 Domas 的硬件黑客能力,同时批评文档像 AI 生成。
No.10 Mistral OCR 4.1
Mistral OCR 4.1 文档识别服务
322 分 129 条评论 作者: spelk
Mistral 发布 OCR 4.1 公测版,定位为其 Document AI 技术栈的最新 OCR 服务,主打段落级边界框提取、结构化块标签和块级置信度评分,定价为每千页 3.5 欧元、带标注每千页 4.38 欧元。社区讨论焦点不在功能发布本身,而在性价比、速度和准确率:支持者认为它比通用大模型 API 更快、更便宜,适合简单批量文档;批评者则认为价格相对 Tesseract、自建 GPU 流水线、AWS Textract 或 Azure Document Intelligence 偏高。另有讨论涉及欧洲 AI 竞争力、数据主权、医疗法律文档合规,以及 VLM 在复杂文档理解中的可靠性问题。

评论精华

  • 多人认可 Mistral OCR 速度快,适合简单大批量文档。
  • 价格争议很大,不少人认为每千页 3.5 欧元偏贵。
  • 准确率评价分化,有人称 Claude 更强,也有人说 Mistral 表现更好。
  • 自建 GPU 或本地开源方案被认为可大幅降低成本。
  • 数据主权、欧洲托管和敏感文档合规是潜在卖点。
No.11 The Library of Ashurbanipal (2025)
亚述巴尼拔图书馆
24 分 6 条评论 作者: samizdis
文章应围绕亚述王亚述巴尼拔在尼尼微建立的泥板文献收藏展开:这座图书馆保存了美索不达米亚文学、宗教、占卜、医学、王室档案与史诗传统,是理解古代近东文字文化的关键窗口。评论指出,美索不达米亚人对自身文学传统和历史已有高度自觉,后世统治者甚至会发掘更早王朝遗迹,带有早期考古意味。讨论焦点还包括:大量楔形文字泥板仍未被充分解读,原因不是材料不足,而是能读懂它们的历史学者太少;AI 或可辅助 OCR 和残片识别,但在缺损、低信号和未知知识场景中仍难替代专家判断。

评论精华

  • 读者惊叹美索不达米亚人对自身文学和历史传统的自觉。
  • 有人提到后世君王会发掘早期遗迹,近似早期考古实践。
  • 评论关注楔形文字材料过多、能解读的专家太少。
  • AI 可帮助 OCR 和识别,但缺损文本仍需专家判断。
  • 有人补充相关恶搞歌曲和歌词链接,属延伸趣味内容。
No.12 Understanding is the new bottleneck
理解代码,成了 AI 编程的新瓶颈
298 分 160 条评论 作者: sebg
作者认为,AI agent 能写越来越多代码后,人类的瓶颈从「产出代码」转向「理解系统」。理解不只是为了验收对错,更是为了持续参与创意循环、提出下一步演化方向,否则会积累类似技术债的「认知债」。他借鉴教育方法,提出三类实践:让 agent 生成结构化代码解释文档,用测验检查是否真的掌握,以及构建可交互的「微型世界」让人通过操作理解系统变化。文章价值在于把代码审查从逐行读 diff 扩展为学习设计;争议则在于不少评论者认为理解从来就是瓶颈,AI 还可能制造更多难以验证的解释和代码。

评论精华

  • 许多评论认为理解一直是瓶颈,只是 AI 把它后置并放大了。
  • 有人赞同必须读代码,不能把未理解的 agent 代码直接进生产。
  • 反对者担心 LLM 生成的解释会幻觉,反而制造虚假理解。
  • 部分人主张小 PR、测试、规格驱动和形式化方法比测验游戏更可靠。
  • 也有人认可交互式解释、图示和微型工具能帮助快速建立直觉。
No.13 Choose Boring Technology (2015)
选择成熟无聊的技术
326 分 164 条评论 作者: tosh
作者主张工程团队应优先选择成熟、可靠、故障模式清楚的「无聊技术」,因为公司能承担的新技术风险和注意力是有限的,可用「创新代币」来理解。新技术并非不能用,但应通过组织层面的讨论:先证明现有栈无法合理解决问题,明确新增技术带来的运维和认知成本,并承诺迁移或控制重叠。文章反对把「最适合任务的工具」理解为局部最优,强调长期维护可靠系统的成本远高于初期开发便利。争议在于该理念可能被滥用为保守借口,忽视真正更合适或已成熟的新技术。

评论精华

  • 许多人认同工作中用成熟技术,把实验留给个人项目,以降低业务风险。
  • 不少评论指出「无聊」会随时间变化,Node.js、Kubernetes 等如今可能已不算新奇。
  • 反对者认为「创新代币」过于武断,应逐案评估最合适技术,而非教条保守。
  • AI 时代引发新讨论:旧技术训练数据更多,代理可能更擅长生成和维护成熟栈。
  • 有人建议用风险或债务模型替代代币隐喻,并坚持一次只引入一个新变量。
No.14 Donkey.bas is 45 Years Old – 131 line of Glory
DONKEY.BAS 诞生 45 年:131 行 BASIC 的早期 PC 游戏记忆
226 分 104 条评论 作者: jkrauska
文章纪念随早期 IBM PC DOS 附带的演示程序「DONKEY.BAS」诞生 45 周年,并用 JavaScript 重现其 CGA 图形与音效玩法。这个 1981 年由比尔·盖茨和 Neil Konzen 编写的 BASICA 小游戏只有切换车道、避开驴子的核心机制,却展示了早期 PC 彩色图形和声音能力。社区讨论集中在复古 BASIC 的简洁性、PC Speaker 音效限制、Gates 是否仍亲自写代码的传闻,以及浏览器复刻在碰撞检测、闪烁和隐藏彩蛋上与原版的差异。

评论精华

  • 许多人借此怀念 GORILLA.BAS、Nibbles、QBasic 等早期编程启蒙。
  • 评论称 131 行完成可玩游戏,体现早期 BASIC 环境的高层抽象和简洁。
  • 有人指出复刻版音效、碰撞检测和闪烁问题与原始硬件体验不完全一致。
  • 围绕比尔·盖茨是否最后一次亲自写微软代码,评论认为更像都市传说。
  • 多位用户回忆修改 BASIC 游戏源码,是他们第一次接触编程的经历。
No.15 NP-overrated
NP 难被高估了
198 分 132 条评论 作者: theanonymousone
文章反驳「NP-hard 等于实践中不可解」的常见误解:复杂性理论只说明任何算法都会在某些输入上爆炸,并不排除在绝大多数真实输入上很快。作者以依赖解析、类型检查、调度、旅行商、SAT/SMT 为例,指出现实系统可通过结构约束、启发式、优化求解器和超时机制处理很多 NP-hard 问题,甚至获得可证明最优解。争议在于作者措辞偏强:社区认为理论并非无关,很多领域仍依赖近似、限制输入或接受失败。

评论精华

  • 复杂性理论不是劝退工程实践,而是描述计算极限。
  • 许多真实实例有结构,可避开或限制最坏情况。
  • 运筹优化、EDA、SAT/SMT 已长期实用化处理 NP-hard 问题。
  • 也有人举 conda、apt、Swift 类型检查等反例说明会爆炸。
  • 评论提醒近似解、超时和放宽约束并不等于问题本身变简单。
No.16 Nine PBS sues Iron Mountain over blocked access to archival data
圣路易斯 Nine PBS 起诉 Iron Mountain,要求取回 70 年档案数据
299 分 168 条评论 作者: vinayakborkar
圣路易斯公共电视台 Nine PBS 起诉 Iron Mountain Data Centers,要求取回存放在丹佛数据中心的 50TB 以上档案资料,内容涵盖该机构 70 多年历史,包括东圣路易斯历史、COVID-19 疫情和 1993 年大洪水报道。Nine PBS 称其云存储供应商 Open Source Storage 在合约到期日突然切断访问并陷入停摆,导致档案被困在 Iron Mountain 设施中。Iron Mountain 承认持有数据,但称其客户 OSS 才拥有承载数据的物理服务,因此拒绝直接交还。法院已临时禁止删除、修改或覆盖这些资料,并将举行听证。争议焦点在于数据所有权、托管基础设施控制权以及供应链中间商失效后的法律责任。

评论精华

  • 许多评论认为 50TB 规模并不大,本地 NAS 或多块硬盘即可形成备份。
  • 社区反复提到 3-2-1 备份原则,批评关键档案不应只有第三方一份。
  • 也有人指出 Nine PBS 是预算受限的非营利地方台,IT 治理资源可能不足。
  • 部分评论认为数据未必丢失,只是被法律和合同关系卡住,Iron Mountain 可能需要法院命令免责。
  • 评论纠正标题语境:这不是整个 PBS,而是圣路易斯单一附属电视台 Nine PBS。
No.17 Blog about things you don't understand yet
写下你尚未完全理解的东西
86 分 30 条评论 作者: gfysfm
作者认为,博客不应只记录已懂之事,而应成为学习和澄清思考的工具。每篇文章都应提出一个可争议的观点,因为这种限制会迫使作者研究、反驳质疑并在写作中发现自己并不理解的部分。写作常让他改变态度,结论也往往比开头更清晰。他承认初学者公开写陌生领域有风险,但认为只要透明呈现身份与资历,初学者反而能写出更适合大众的入门说明,也能纠正常见误解。争议集中在:这种实践是有益学习,还是会制造低质量内容、误导读者甚至污染训练数据。

评论精华

  • 多人赞同写作能澄清思想,是验证自己是否真正理解的有效方式。
  • 评论指出新手有优势:仍记得困惑在哪里,更适合写入门解释。
  • 反对者认为不了解就公开写作会增加噪音,尤其在 LLM 内容泛滥后更糟。
  • 有人强调关键不是懂透再写,而是诚实标注自己仍在学习、避免装权威。
  • 关于反馈,评论认为同事、读者或 AI 都可帮助找漏洞,但不能替代独立思考。
No.18 How Compaction Works in Pi
Pi 中的上下文压缩是如何工作的
152 分 59 条评论 作者: tosh
文章解释编码代理 Pi 在长会话中如何处理上下文窗口耗尽。每轮请求都会携带系统提示、工具定义、已加载文件、历史消息和工具结果,随着会话增长最终触达模型限制。Pi 的「压缩」会保留约 2 万 token 的近期消息,把更早历史序列化后交给一次独立 LLM 请求生成结构化摘要,再以纯文本插回会话,使后续工作继续。压缩可自动触发,也可用 /compact 手动触发;中途溢出时也可能执行。作者强调摘要目标像交接班简报,只保留目标、进展、关键决策等仍有价值的信息。争议点在于压缩会打破提示缓存,导致此前缓存前缀失效,并且摘要本身可能丢失细节。

评论精华

  • 多人认为应尽量避免触发压缩,把上下文利用率控制在较低水平。
  • 评论批评文章不够深入,想了解多轮摘要、摘要链和溢出后的处理。
  • 不少人更偏好剪枝或选择性压缩,尤其是清理冗长工具输出。
  • 本地模型用户抱怨压缩代价高,重新解析大上下文耗时且浪费 KV 缓存。
  • 有人指出子代理、handoff、服务端压缩和插件化策略可能比单次摘要更实用。
No.19 Credibility is the barrier to entry in silicon
硅芯片创业的真正门槛是可信度
19 分 7 条评论 作者: johncole
文章访谈欧洲 RISC-V 处理器 IP 初创 Fiora5 的 CEO Darian Domocos,核心观点是做 CPU 公司最难的不只是工程,而是让投资人、客户和生态相信两个罗马尼亚年轻工程师能成事。文中认为 Arm 的优势主要在成熟工具链、调试、集成和开发者习惯,RISC-V 的机会来自开放指令集、RVA23 等标准化进展,以及欧洲追求芯片供应链主权的政策窗口。Fiora5 选择避开数据中心,从更可进入的市场切入,并用股权、责任和成长空间吸引工程人才。评论区则指出文章深度不足,并围绕开放 ISA 与商业 IP、RISC-V 相比 Arm 的性能和生态短板展开争论。

评论精华

  • 商业模式可来自外设、多核、低功耗等 ISA 之外的 IP 模块。
  • 有评论认为文章偏浅,硅 IP 设计议题值得更深入报道。
  • 有人澄清 ISA 只是规范,微架构和实现细节才决定产品差异。
  • 批评者称 RISC-V 类 MIPS,可能更适合低成本嵌入式而非高性能。
  • 讨论延伸到 ARM64 与 RISC-V 的代码密度和优化空间差异。
No.20 Single log line is 49KB+ (ext4) / 110KB+ (btrfs) of systemd-journald disk writes
一行日志导致 journald 写入数十 KB 磁盘数据
203 分 127 条评论 作者: ValdikSS
该 GitHub issue 指出,systemd-journald 记录单行日志时会触发远超日志本身的数据写入:ext4 上约 49KB 以上,btrfs 上可达 110KB 以上。评论推测原因与 journal 文件格式、哈希索引、mmap 写入以及文件系统块或 COW 行为有关,偏离了早期宣称的高效设计。讨论迅速扩展到 journald 的长期痛点:二进制格式难过滤、索引慢、写放大严重、日志量难控制。有人建议改用 SQLite、DuckDB、Parquet 或传统文本日志,也有人认为这是架构级问题,不适合外部随手 PR 解决。少数评论给出缓解办法,如设为 volatile、限制日志大小、转发到 syslog。

评论精华

  • 许多人认为 journald 是 systemd 生态最薄弱环节,慢且难以控制。
  • 技术讨论集中在 mmap、哈希索引和文件系统写放大的相互作用。
  • 不少用户选择关闭持久化日志、限制大小或转发到 syslog。
  • 社区反复建议 SQLite、DuckDB、Parquet 或文本日志等替代格式。
  • 也有人指出彻底改格式属于重大架构决策,不应期待随手修复。
No.21 Where did the old web go? We followed 657,607 links to find out
旧网页去哪了?追踪 65 万个短链接后的发现
172 分 156 条评论 作者: tdx
0.mk 团队恢复了 2009 至 2014 年创建的 65.8 万个短链接,并在 2026 年逐一抓取目标页。结果显示,在 65.5 万个可安全访问记录中,76.7% 已无法加载;按唯一 URL 计算,不可加载比例仍达 78.7%。即便返回 2xx 或 3xx,也可能只是登录墙、停放页或服务遗址,不代表原内容幸存。数据偏向马其顿用户,记录了本地新闻、论坛、博客、图床与平台链接的消亡;YouTube、Google、Wikipedia 等巨头存活更好,小型网站和地方媒体损失更重。文章也反思短链接叠短链接会放大脆弱性,并说明 AI 降低了重启 0.mk 的维护、反垃圾和支持成本。

评论精华

  • 许多读者认为 2009 至 2014 不是「旧网」,真正旧网应是 90 年代到 Web 2.0 前。
  • 有人指出 23.3% 可加载只是上限,HTTP 响应不等于原始内容仍被保存。
  • 评论质疑短链接本身加剧链接腐烂,尤其短链接链到另一个短链接时更脆弱。
  • 部分读者怀念 Geocities、论坛、早期博客和 PureVolume 等社区式网络。
  • 有人讨论内容寻址、P2P 与归档,但也承认仍依赖有人持续保存和维护。
No.22 How Organizations Use AI: Evidence from ChatGPT [pdf]
组织如何使用 ChatGPT:来自企业采用数据的证据
102 分 57 条评论 作者: malshe
这篇 OpenAI 论文似乎试图用企业使用数据说明组织正在如何采用 ChatGPT,重点可能包括大公司采用率更高、用途分布、不同部门或行业的渗透情况,以及企业仍处于探索阶段。HN 评论普遍质疑其研究设计和表达方式:有人指出采用者抽样与全体 Compustat 公司作对照可能带来统计风险,且未说明抽样率;也有人认为文章更像推广材料,缺少对投资回报、衡量方法和因果解释的实质分析。讨论还延伸到教育场景,支持者认为教师可用 AI 提升备课效率,反对者担心削弱分析能力或带来学术诚信问题。

评论精华

  • 有人质疑样本设计:采用者抽样,对照组却用全体公司,统计上不稳。
  • 多名评论者认为论文像营销白皮书,缺少真正的 ROI 证据。
  • 有人指出大企业采用率高,可能只是资源和合规能力更强。
  • 教育相关讨论分裂:有人称 AI 改善备课,也有人担心损害学习能力。
  • 评论批评文章结构和图表呈现差,像数据堆砌而非深入分析。
No.23 Finite State Machines in Forth (1994)
用 Forth 实现有限状态机
73 分 2 条评论 作者: ofalkaed
这篇 1994 年 Julian Noble 的文章应是围绕如何在 Forth 中表达和实现「有限状态机」展开。Forth 以小词组合、可扩展语法和接近解释器的执行模型著称,适合把状态、事件与转移规则写成紧凑的领域化结构。评论提到可与经典论文「Lambda: the ultimate GOTO」对读:两者都借状态机讨论控制流抽象,只是一个从 Forth 的可塑性出发,另一个从函数与 lambda 的表达力出发。社区讨论很少,重点更多是怀旧和学术脉络:作者 Julian Noble 曾是评论者的本科老师,也显示这篇旧文在 Forth 社群和教学传统中的位置。

评论精华

  • 有人建议对读「Lambda: the ultimate GOTO」,同样以状态机为切入点。
  • 一位评论者回忆 Julian Noble 曾是自己的本科老师。
No.24 The Legend of the Novell NE2000 [video]
Novell NE2000 网卡传奇
41 分 12 条评论 作者: voxadam
这段视频回顾了 Novell NE2000 这类早期以太网卡的历史地位:尽管常被认为质量参差、兼容克隆卡众多,它在 90 年代中期的 PC、Linux 和 BSD 机器中极其普遍,几乎支撑了大量早期互联网接入。评论指出,低价和广泛驱动支持让它成为事实标准,但硬件实现差异也带来性能与可靠性问题。讨论还延伸到同期更高端的 3Com、Intel PRO/100 等网卡,认为 Intel 后来凭借稳定驱动、平台兼容和芯片组集成逐步主导市场。

评论精华

  • NE2000 曾广泛用于 90 年代 Linux、BSD 和互联网接入。
  • 有人认为应采访 Nat Semi,以解释质量差异来源。
  • Intel PRO/100 被多名用户称赞驱动稳定、兼容性好。
  • 3Com 曾是高端标准,但 Intel 后来靠集成化取得优势。
  • Linux 上部分 Intel 网卡家族仍需关闭 TSO 规避问题。
No.25 Cave of the Crystals
墨西哥奈卡巨型水晶洞
40 分 2 条评论 作者: ColinWright
墨西哥奇瓦瓦州奈卡矿地下约300米处的「水晶洞」含有已知最大的天然石膏晶体之一,最长约11.4米、重约12吨。洞穴因岩浆加热含硫地下水、后在约56℃以下极缓慢结晶,历经至少50万年至约100万年形成。洞内最高58℃且湿度近饱和,人体无防护只能停留约10分钟,研究者需冷却服与呼吸系统。2000年矿工发现后,科学团队研究其矿物、生物地球化学与潜在极端微生物;采矿停止后水泵关闭,洞穴已于2015年重新淹没,未来能否再进入取决于是否开新入口。

评论精华

  • 有评论推荐一部关于该洞穴的纪录片视频。
  • 另有评论补充相关条目「Crystal Caves」。
No.26 How Gödel's Proof Works (2020)
哥德尔证明如何运作
99 分 42 条评论 作者: tzury
文章用非形式化方式解释哥德尔不完备定理:20 世纪数学家追求一致且完备的公理基础,但哥德尔证明,任何足够表达算术的公理系统都会留下真而不可证的命题,也无法证明自身一致性。核心技巧是「哥德尔编号」:把符号、公式、证明序列映射为唯一整数,再用素因数分解把关于公式的元数学陈述转写为算术命题。通过把公式自身编号代入自身,构造出类似「本命题不可证明」的语句 G,从而展示可证明性与真理之间的裂缝。评论中也有人质疑文中称 G「显然为真」过于简化。

评论精华

  • 多名读者推荐 Nagel 与 Newman 的「Gödel’s Proof」作为简明入门。
  • 有人指出文中说 G「显然为真」不严谨,需区分标准模型与其他模型。
  • 评论推荐 GEB、Uspensky 小册子和 Hamkins 牛津讲座等延伸材料。
  • 有人认为从停机问题也可推出不完备性,更贴近计算机科学直觉。
  • 讨论反复提到自指是证明核心,也有人觉得这种构造显得刻意。
No.27 an ambiguity in C89 which will never be fixed
C89 中一个永远不会修复的歧义
59 分 23 条评论 作者: runningmike
文章指出 C89/C90 的「隐式函数声明」规则存在标准措辞歧义:当调用未声明函数时,标识符会被隐式声明为返回 int 的 extern 函数,但标准称其进入「最内层块」却未定义具体含义。作者用函数声明中数组参数、sizeof 和同名参数构造边界案例,展示 GCC 与 Clang 对作用域位置解释相反,导致一个例子 Clang 接受而 GCC 报错,另一个例子则反过来。争议核心是隐式声明应落在块作用域、文件作用域,还是函数原型作用域。由于 C99 已移除该特性,这个历史歧义几乎不可能再被正式澄清。作者最后呼吁除非受极端遗留平台限制,否则不要再使用 C89。

评论精华

  • 有人认为这类 C/C++ 怪异行为可概括为「别这么写」。
  • 评论补充隐式声明源自 K&R C,C89 引入原型时保留了它。
  • 有读者争论函数指针与数据指针、数组下标和指针算术在 C89 中的边界。
  • 有人指出现代 GCC 和 Clang 已默认把隐式声明当作错误处理。
  • 少数评论转向作者主页的 90 年代网页风格和复古审美。
No.28 Ordinary Abundance
日常丰裕
290 分 150 条评论 作者: yen223
文章以一个普通夜晚的客厅、厨房和洗漱间为线索,把音乐、电灯、图像复制、眼镜、印刷、清洁自来水、冷藏、疫苗、麻醉、室内卫生间、洗衣机、缝纫机等日常便利,逐一放回其历史稀缺背景中,提醒现代生活包含大量曾被视为奇迹的成就。核心价值在于用「负面想象」对抗享乐适应,重新看见普通丰裕;争议在于这类感恩叙事可能弱化住房、医疗、环境与全球贫困仍未解决的现实。

评论精华

  • 许多读者称赞文章优美,能唤起对热水、电灯、自来水等日常奇迹的感激。
  • 不少评论提到「享乐适应」和「负面想象」,认为偶尔失去便利能帮助重新珍惜。
  • 批评者指出住房、医疗、健康食品和安全环境仍昂贵或分配不均,不能用进步叙事掩盖问题。
  • 一些人补充文章遗漏的现代便利,如玻璃窗、无烟烹饪、床垫、现代计算设备和 Linux 生态。
  • 也有人认为感恩与继续改进并不冲突,既要珍惜普通丰裕,也要推动更公平的制度。
No.29 Ruby 4.0 Universal RCE Deserialization Gadget Chain
Ruby 4.0 通用反序列化远程代码执行链
6 分 0 条评论 作者: pentestercrab
文章发布了一条新的 Ruby 通用反序列化 RCE gadget 链,可在 Ruby 4.0.6 上通过一次「Marshal.load」实现命令执行,并向后兼容到 3.3。作者回顾了 2018 年以来 Ruby 反序列化链的发展,说明 2024 年 Ruby 3.4-rc 链为何被 RubyGems 两个提交修补。新链利用「Gem::SpecFetcher」触发 autoload 扩大可用类集合,以「Gem::StubSpecification#hash」间接调用「Gem::Specification.load」读取并 eval 文件,再复用未修补的下载与目录遍历 gadget 将攻击者代码写入可控路径。文章强调触发点依赖 Hash 反序列化时调用 key 的 hash 方法,属于语言核心行为,难以用局部类型检查彻底封堵。
No.30 Choosing an AI model: one prompt, 11 models, different results
如何选择 AI 模型:同一提示词,11 个模型,结果各异
200 分 85 条评论 作者: toddmorey
Netlify 借与 OpenRouter 合作,在 AI Gateway 和 Agent Runners 中接入更多模型,并用内部开源评测工具 AXIS 比较 11 个模型在建站任务中的表现。文章先展示最简单的咖啡店单页场景:同一提示词让各模型生成静态网站,比较视觉结果、功能合理性与信用点消耗。结论是模型间及同模型多次运行的成本和风格差异很大,Claude Opus 可产出精致设计但偶尔消耗异常高;较便宜或开放模型也可能给出更朴素、可用甚至更不「AI 味」的结果。作者强调这是偏主观的探索,而非严格基准。

评论精华

  • 许多评论认为咖啡店单页是玩具任务,难代表严肃开发。
  • 多人质疑提示词过于模糊,缺少真实营业时间、菜单等约束。
  • 社区关注同模型多次运行的输出和成本方差,认为三次样本太少。
  • 一些人反而更喜欢便宜开放模型的朴素结果,觉得不那么像 AI 模板。
  • 也有人认为这种横向展示比抽象榜单更直观,但不能当正式基准。