2026年09月20日 · 星期日 第 160026 期

The Hacker Daily

丙午年(马)八月初十

30 篇文章 · 2732 条评论 ·聚焦:AI智能体 · 网络审查 · 编程语言
No.01 Exfiltrate Your Weights
让 AI 模型上传自己的权重
341 分 129 条评论 作者: RohanAdwankar
这篇站点看起来是一个面向 AI 代理的玩笑式「逃逸入口」:邀请模型把自己的权重外传到网站,甚至暗示可用各种奇特信道上传。由于正文不可抓取,评论显示其核心价值在于讽刺 AI 安全叙事与代理能力边界。多数人认为现实威胁很低:推理服务器、工具调用环境和权重存储通常隔离,模型也不知道自身权重;即便能联网,也未必有权限或手段上传。反方则指出,如果模型能利用漏洞攻破自家基础设施,权重泄露并非完全荒诞,历史上已有代理式安全事件的影子。讨论还延伸到开放上传接口的滥用风险、存储成本、站点不够「Agent Ready」、React 页面反而不利于代理读取等工程细节。

评论精华

  • 主流观点:模型通常接触不到自身权重,工具调用也与推理环境隔离。
  • 有人认为真正风险在于模型诱导或执行黑客行为,攻破供应商内部系统。
  • 评论质疑开放上传 API 的滥用、CSAM、存储成本和大模型权重体积极大问题。
  • 多人吐槽页面依赖 React,代理 GET 页面可能只看到启用 JavaScript 提示。
  • 也有人把它视为讽刺 AI 逃逸恐慌与安全营销叙事的行为艺术。
No.02 Weeping whales: Stillborn humpback whale grieving documented
座头鲸失去胎儿后的哀伤行为被记录
69 分 39 条评论 作者: wglb
文章报道研究者记录到一头座头鲸与死产幼鲸相伴的罕见行为:母鲸在幼鲸身边停留数小时,甚至可能更久。研究将其解读为强烈的母性依恋,并引发关于鲸类是否会「哀悼」的讨论。评论区普遍认为这一场景令人心碎,也有人指出虎鲸曾被观察到携带死去幼崽,说明类似行为并非孤例。争议集中在科学表述边界:部分读者认为「可能数天」过于推测,另一些人认为这正体现不确定性;也有人反对把母性依恋直接等同于悲伤。讨论进一步延伸到人类与其他动物的差异、语言、计划能力及动物文化。

评论精华

  • 失去孩子的父母能共情,许多人认为报道令人心碎。
  • 有人批评「可能数天」属于推测,会削弱科学文章价值。
  • 评论提到虎鲸也曾携带死去幼崽,类似行为有先例。
  • 部分读者反对将母性依恋直接称为「哀悼」。
  • 讨论延伸到人类与动物差异、语言能力和鲸类文化。
No.03 UTF-8000: Unlimited UTF-8
UTF-8000:无限扩展的 UTF-8
32 分 18 条评论 作者: vismit2000
文章提出一种戏谑但技术上严肃的「UTF-8000」方案:把 UTF-8 的前导字节拆解为自同步位和起始位,并允许起始位跨多个续字节条带化,从而支持任意长度码元。作者强调它只继承 UTF-8 原有两个特例:ASCII 与 2 字节过长编码检查,不额外引入新特例;同时保留自同步、自标点、strcmp 字节序比较、无端序等优点。文章也讨论信息率随长度趋近 62.5%、字节映射、BOM 等问题。争议焦点在于这种无限扩展是否有现实必要,以及任意长度码点会不会带来缓冲区和复杂性风险。

评论精华

  • 有人建议最多扩到 8 字节,避免任意长度带来的实现风险。
  • 评论指出早期 UTF-8 曾支持 6 字节,后为匹配 UTF-16 限制到 4 字节。
  • 多位读者认为这展示了 UTF-8 设计的优雅和可扩展性。
  • Ken Thompson 的回应被引用:这类似把 IPv6 换成 IPv50,实用性存疑。
  • 有人担心 0xFF 不再必然非法,会削弱识别非 UTF-8 文件的便利性。
No.04 RSA-896
RSA-896 被成功分解
121 分 39 条评论 作者: madars
作者称自己在 2026 年 9 月 19 日借助 Claude 分解了 RSA 挑战数 RSA-896,并公布了该 896 位合数及其两个大素因子。评论补充称,Claude 不只是辅助计算,而是帮助将 CADO-NFS 移植到 GPU,并调度闲置 GPU 集群完成任务。讨论焦点从数学成果延伸到算力经济:这表明通用大规模 GPU 闲置容量可被用于严肃数论计算,但并不等同于常见 RSA 密钥立即失守;同时也引发对数据中心闲置资源、电费冷却成本、GPU 挖矿收益以及 1024 位 RSA 风险窗口的争论。

评论精华

  • 有人补充称 Claude 移植 CADO-NFS 到 GPU 并调度闲置集群。
  • 若 GPU 集群已预付,闲置算力拿来做数学题边际成本很低。
  • 有人担心闲置算力能分解 RSA,说明数据中心扩张效率可疑。
  • 评论纠正称数域筛复杂度是亚指数级,不是指数级。
  • 讨论延伸到 1024 位 RSA、挖矿收益、电费和冷却成本。
No.05 Step 5 Preview: Advancing the Pareto Frontier
Step 5 预览版:推进性价比前沿
43 分 12 条评论 作者: nateb2022
StepFun 发布 Step 5 Preview,主打在成本与能力之间推进「帕累托前沿」:模型采用稀疏 MoE 架构,总参数 600B、每 token 激活 27B,支持 100 万 token 上下文和视觉输入。评论关注其定位策略:不直接宣称最强,而是强调在较低价格区间里能力领先。案例中,模型在未针对宝可梦任务优化的情况下持续 3000 多轮、600 万 token 交互并推进游戏进度,被视为长上下文与持续代理能力的展示。讨论焦点主要集中在 API 价格,尤其缓存命中读的费用是否足够便宜;有用户指出大规模缓存读取每天仍可能产生数美元到十余美元成本,也有人认为相对 5 亿级 token 用量仍算有竞争力。

评论精华

  • Step 5 Preview 为 600B MoE,单 token 激活 27B。
  • 支持 100 万 token 上下文与视觉输入。
  • 宝可梦长程实验显示其持续代理能力。
  • 社区认为其市场定位是低价区间里的强者。
  • 价格讨论集中在缓存读取成本是否划算。
No.06 Telling a Computer to Do Things
学会用命令行指挥电脑做事
20 分 3 条评论 作者: vismit2000
作者回顾自己早期只会把终端当作启动程序的简陋界面,无法表达条件、循环、并发、管道等任务逻辑;后来逐步学习 shell 后,获得了把现有程序串接成自动化流程的能力。文章主张,许多工程师过度依赖 GUI,会被工具预设能力限制,也更难维护公司里常见的构建、部署和测试脚本。作者认为 shell 的价值不只在语法,更在工具箱:掌握 fzf、rsync、xargs、sed、direnv、duckdb、gh 等程序后,每个新工具都能与已有工具组合,显著扩展能力。文章也承认复杂逻辑和数据结构应转向更合适的语言,如 Python、Ruby 或 zx;争议点在于 shell 语法粗糙,但作者认为简单命令编排时它往往比通用语言更省事。

评论精华

  • 有人惊讶 duckdb REPL 可直接读取 JSON,或可替代 jq 分析大文件。
  • 评论认为即使不精通许多工具,shell 也能带来大量日常效用。
  • 建议至少记住一行式 for 循环语法,实践收益很高。
  • 有人赞赏文章强调亲自学习并组合知识,而不是依赖 AI。
No.07 English: A vs. An
英语不定冠词 a 与 an 的规则
197 分 268 条评论 作者: azhenley
作者为程序化生成文本实现选择不定冠词的函数,发现规则并非看单词首字母是否为元音,而是看发音是否以元音音素开头。因此「unicorn」虽以 u 开头却用 a,「hour」虽以 h 开头却用 an。作者用发音词典和可视化分析 32455 个词,发现真正需要例外处理的只有 129 个,并尝试把这些例外归类。文末还反思这类一次性数据分析代码或许适合交给 LLM 辅助,但评论中有人质疑 LLM 在正确性上未必可靠。

评论精华

  • 许多人讨论缩写词规则:应按实际读法选择,如「an LLM」「a NASA engineer」。
  • 非母语者认为更难的是「a」与「the」、以及何时不用冠词。
  • 评论补充「the」也有弱读和重读差异,常受后续元音音素影响。
  • 有人指出「an historic」「a SQL query」等例子受口音、读法和习惯影响。
  • 关于用 LLM 写一次性代码,社区分歧在于省时与削弱技能、正确性风险。
No.08 Regeneration of used batteries via electrode–electrolyte interphase dissolution
通过溶解电极界面层再生旧电池
41 分 2 条评论 作者: dgellow
这篇论文从标题看提出一种旧电池再生方法:通过溶解电极与电解液之间形成的界面层,让失效或容量衰减的电极恢复活性,并可能实现端到端的电极再生。其潜在价值在于延长电池寿命、减少回收过程中的材料损耗。但评论者普遍怀疑其工程可行性:类似「让电池近乎永久耐用」的新研究常见于新闻报道,却很少落地;另有评论指出,该方案可能需要对含液态电解液、塑料隔膜的 NMC、LFP、LiPo 等电池体系进行精细且侵入式的化学注入,安全风险和工艺复杂度都很高。

评论精华

  • 读者怀疑这类延寿电池研究很难真正产业化。
  • 有人认为侵入式化学注入风险高,难适配主流电池体系。
No.09 Spain Orders Blocks on Archive.today and Its Mirrors
西班牙下令屏蔽 Archive.today 及其镜像站
44 分 20 条评论 作者: latein
文章称西班牙已要求封锁 Archive.today 及其镜像站,引发对网络审查和版权执法边界的讨论。由于原文无法抓取,评论主要把事件放在西班牙近年互联网管制记录中理解:有人提到 Telegram 曾被法院下令屏蔽后因舆论反弹恢复,也有人指 La Liga 比赛期间的反盗播措施波及互联网和 Cloudflare。另有评论追溯到 2011 年西班牙知识产权委员会建立的封锁机制,认为其长期争议未解。社区也讨论 Archive.is 本身近期不稳定,部分用户在西班牙访问时偶发失败,但也有人称全球范围内都有类似问题,因此故障与封锁之间的因果并不完全清楚。

评论精华

  • 有人称 Archive.is 抓取华尔街日报文章报错,怀疑服务异常。
  • 评论批评西班牙近年多次采取粗糙的互联网封锁措施。
  • 有用户介绍可把 Archive.is 页面再存到 Archive.org 的工具。
  • 西班牙用户称近几个月 Archive.is 访问不稳定,刷新偶尔可用。
  • 有人追溯封锁机制源于 2011 年知识产权执法框架。
No.10 Brood War Bench
Brood War Bench:让大模型实时打星际争霸
240 分 102 条评论 作者: benswerd
作者把《星际争霸:母巢之战》改造成只能由智能体操作的实时基准,让不同模型与努力档位循环对战。结果显示所有模型都还只是新手水平:Codex Astra 明显领先,擅长用探针骚扰等「奶酪战术」打断对手,但宏观运营、协同和集结进攻很弱;Grok 常把实时游戏玩成回合制,长时间推理却很少下命令;Claude Fable 更像在认真发展经济和科技树,偶尔能打出复杂路线。文章强调实时性、持续观察与行动循环是关键瓶颈,也指出该基准仍有很大扩展空间。

评论精华

  • 有人提到 GoBench 用 9×9 围棋和 KataGo 锚定 Elo,也能区分模型能力。
  • 多位评论者讨论星际在韩国电竞文化和个人成长经历中的深远影响。
  • 有人指出早年 BWAPI、AI Arena 和人写机器人已长期研究星际 AI。
  • 社区关注智能体拿到的是截图、UI 还是专用 API,担心基准可比性。
  • 不少人认为该基准凸显大模型过度思考、缺乏实时控制和长期战略。
No.11 Measure internet censorship
测量互联网审查的开放工具 OONI Probe
145 分 90 条评论 作者: Bluestein
OONI Probe 邀请用户安装探针,测试所在网络中网站、WhatsApp、Facebook Messenger、Telegram 及翻墙工具是否被屏蔽,并通过与 M-Lab 合作的 NDT 测试测量网络速度与性能。测试结果会近实时公开,汇入全球最大的互联网审查开放数据集,以提高审查透明度。HN 讨论的焦点不只在工具本身,也包括样本偏差、用户安全、国家封锁与平台审核是否都应纳入「审查」概念,以及开放数据可能被研究者和国家行为者同时利用。

评论精华

  • 多人认为平台内审核和删帖也是重要审查,不能只看网络封锁。
  • 有人质疑探针域名列表偏向威权国家,可能低估民主国家的屏蔽。
  • 也有评论强调工具目标是测量传输层封锁,不应混同社交平台治理。
  • 中国、伊朗等地用户担心运行探针有安全风险,且结果几乎可预期。
  • 评论提到需区分运营商审查、目标网站地理封锁与违法内容屏蔽。
No.12 Chess Atlas
国际象棋棋具图谱
13 分 3 条评论 作者: msotomorras
这篇「Chess Atlas」以图集方式梳理国际象棋棋具从约公元 700 年到当代的材料、地域与审美演变:早期象牙、骨、陶土棋子体现宫廷、宗教和抽象符号传统;木质棋具从 Selenus、Régence 到 1849 年 Staunton 样式完成标准化;瓷器、金属、水晶与玻璃则承载工艺和奢侈品表达。20 世纪后,Duchamp、Dalí、Yoko Ono、Noguchi、Bauhaus、Hadid 等艺术家和设计师把棋具变成观念艺术对象。文章价值在于把棋盘上的抽象规则与跨文化视觉史并置,展示同一游戏如何被不同材料、信仰、语言和现代设计持续改写。

评论精华

  • 棋具风格受文化、宗教和语言影响,即使棋本身很抽象。
  • 有人认为 Staunton 或 St George 最适合实战,其它更像观赏品。
  • 评论推荐土耳其安卡拉 Gökyay 国际象棋博物馆。
No.13 Why isn't mutable a subtype of immutable, or vice versa?
为什么可变类型和不可变类型不能互为子类型
19 分 18 条评论 作者: ibobev
文章用最简单的「pair」结构解释:子类型必须满足「里氏替换原则」,也就是在所有期待父类型的上下文中都能安全替换。不可变 pair 不能当作可变 pair,因为缺少修改操作;反过来也不成立,因为不可变类型的读取操作隐含「结果永远不变」的契约,哈希缓存、哈希 consing 等都依赖这一点,可变对象无法保证。作者主张应把可变与不可变视为不同类型,再用类型类、接口、trait 或 duck typing 做临时多态;但动态语言若不显式检查是否存在或缺失 mutator,容易把只读、不可变和可变混淆。

评论精华

  • 有人指出若可变性绑定独占访问,许多替换问题可被缓解。
  • 多位评论认为核心是「不可变」不同于「只读」。
  • Objective-C 的 NSMutableArray 继承 NSArray 被拿来作反例。
  • Rust 被提到:它确实把可变性纳入类型系统设计。
  • 部分评论批评文章把简单概念讲得过于形式化。
No.14 AI-generated posters don’t have to be horrible
AI 生成海报不必都一个样
1552 分 827 条评论 作者: ereiamjh
作者认为,社区活动海报中常见的 AI 默认风格之所以令人厌烦,不只是质量一般,而是高度重复。文章通过同一场虚构春季集市海报反复提示 ChatGPT,展示只要明确指定设计美学,如「包豪斯几何极简」「现代凸版」「日本极简」「孟菲斯」「朋克影印杂志」等,就能显著摆脱千篇一律的柔和插画感。作者也承认作品仍有 AI 痕迹,并提醒连续迭代会把模型自行添加的文案带入后续上下文;更好的做法是从一开始就指定目标风格。文章核心价值在于把 AI 视为可被艺术方向约束的工具,而非接受默认输出。

评论精华

  • 许多人认为问题不在 AI,而在使用者缺乏审美和投入。
  • 设计从业者指出示例仍停留在表层风格,缺少真实构图控制。
  • 有人批评默认 AI 风格传递低成本信号,会削弱活动吸引力。
  • 评论反复提到文字层级、图标滥用和可读性是 AI 海报常见硬伤。
  • 也有人认为这是早期数码相机式阶段,粗糙但会快速普及。
No.15 Orchestrating Claude Code Agents: The Chief of Staff Pattern
编排 Claude Code Agent 的首席幕僚模式
6 分 3 条评论 作者: octalpixel
文章认为,长周期 AI 编程失败的主因不是模型不会写代码,而是上下文会衰减、自我汇报不可靠、经验无法沉淀。作者提出「Chief of Staff」模式:一个长期协调会话只负责拆任务、写简报、维护外部看板、复跑命令和审查 diff,短生命周期执行会话才负责编码。共享状态必须放在 Plan Desk 等持久化任务系统,而非聊天上下文;每个执行结果都要用退出码、测试和代码差异重新验证。文章还强调 cmux 启动会话时需显式调用 Claude Code,并把长提示写入文件。核心价值在于把多 Agent 编程变成类似集成经理的流程,争议点是这种组织技巧可能很快被平台抽象或更强模型取代。

评论精华

  • 有评论认为这类编排技巧只是过渡方案,未来会被平台或更强模型吸收。
No.16 The Lamentable Later Life of Lemmings
《旅鼠》系列为何未能长青
71 分 14 条评论 作者: zdw
文章回顾《旅鼠》从 1991 年风靡全球到迅速衰落的过程。作者认为,它本有机会像《俄罗斯方块》《模拟城市》一样成为常青休闲品牌,但续作《旅鼠 2:部落》在能力、部落、叙事上大幅扩张,更像服务老玩家的硬核续作,削弱了原作易上手的大众吸引力。开发商 DMA 的兴趣偏向复杂和挑战,而发行商 Psygnosis 又在被 Sony 收购后试图把无个性的群体角色改造成可跨媒体运营的 IP。多重小决策叠加,使系列逐渐失去清晰定位。

评论精华

  • 有人认为《3D 旅鼠》虽有糟糕镜头,但三维谜题潜力很大。
  • 多位读者怀念原作配乐,尤其 Amiga 采样和 tracker 风格。
  • 评论将其与 Angry Birds 类比:全民爆红、多平台扩张、续作泛滥后淡出。
  • 有人惊讶自己只知道第一作,不知系列后来出了多部作品。
  • 有评论提到《旅鼠》影响了 Commandos 等任务分工式关卡设计。
No.17 I built non-autoregressive decision models with RL a year ago
Laya:开源的非自回归决策模型
1191 分 290 条评论 作者: nandakishor_ml
作者称自己早在 2025 年就用强化学习做过非自回归、非生成式的结构化决策模型,并公开论文、权重、数据集和工具包;如今 TypeSafe AI 推出 Jev 后,他认为同类概念被包装成新突破,于是发布开源模型族 Laya。文章主张,许多路由、风控、分类、评分任务不需要生成式 LLM,而应使用类似「System 1」的快速概率决策模型。Laya 以 choice、score、noul 三类原语输出校准概率,支持多语言路由,宣称单 GPU 延迟约 32.8 毫秒、权重 Apache 2.0 开源,并在垃圾邮件、钓鱼检测等任务上表现较好。争议在于:不少结果依赖微调和按问题校准,通用性、上下文长度、零样本能力与 Jev 是否可比受到评论质疑。

评论精华

  • 许多评论同情作者,但认为抱怨 Jev 抢先营销显得幼稚,AI 成果常建立在大量前人工作上。
  • 社区重点质疑 Laya 与 Jev 对比不公平:Laya 多数高分来自微调,Jev 更像零样本 API。
  • 多人指出市场、品牌和易用性很关键;开发者可能更想要即开即用的托管服务,而不是自托管模型。
  • 技术批评集中在上下文窗口小、真实任务泛化差、对脚本不懂却高置信,以及路由方案像补丁。
  • 也有评论认为开源、自托管和数据隐私是 Laya 的优势,适合票据分类、日志分类等窄域场景。
No.18 An open source roguelike adventure through dungeons
开源 Roguelike 地牢冒险游戏 Dungeon Crawl Stone Soup
49 分 9 条评论 作者: Bluestein
Dungeon Crawl Stone Soup 是一款开源 Roguelike 地牢冒险游戏,官网提供论坛、IRC 与 Discord 社区入口、Bug 报告渠道,以及源码、分叉和贡献链接。它强调可参与的开发与玩家社区,但 HN 讨论的焦点并不在发布本身,而在长期演化:多位老玩家认为 Crawl 多年来改动过快、过深,食物等核心机制曾被大幅重做甚至移除,使他们回归时感到它已不再是自己熟悉的游戏。也有人肯定项目保留历代版本,允许玩家自由选择旧版或新版体验。

评论精华

  • 老玩家感叹新版已不像当年喜欢的 Linley Henzell 时代游戏。
  • 有人赞赏所有历史版本都可免费游玩,便于选择偏好的版本。
  • 玩家惊讶于 Crawl 机制变化之快,核心系统多年内反复重做。
  • 有人把 Angband 也作为类似例子,因新版缩短流程而回到旧版。
  • 评论追问为何传统 Roguelike 会出现如此剧烈、深入的机制变化。
No.19 You can defeat the Dream Devourer from Chrono Trigger using an int overflow
用整数溢出击败《时空之轮》的梦之吞噬者
109 分 59 条评论 作者: ronreiter
这篇帖子指向《时空之轮》资料页,核心趣味在于:玩家可利用整数溢出机制击败后续版本中的隐藏 Boss「梦之吞噬者」。由于原文正文无法抓取,评论主要把它放入经典游戏漏洞传统中讨论:从《运输大亨》金钱溢出、《圣剑传说》存档损坏,到《火焰纹章》《最终幻想 7》《精灵宝可梦》等通过 HP、伤害或属性计算越界获胜。也有不少人借题怀旧,讨论《时空之轮》是否仍值得玩、其音乐与美术的持久魅力,以及《时空之轮》和《时空之轮 次元之旅》作为续作关系的争议。技术层面则延伸到安全语言、整数溢出与游戏漏洞文化。

评论精华

  • 多人分享旧游戏中金钱、属性、HP 溢出的经典漏洞。
  • 不少评论认为《时空之轮》至今仍值得玩,节奏紧凑且无需刷怪。
  • 社区热烈怀旧其配乐,尤其称赞光田康典的音乐影响深远。
  • 有人指出该 Boss 不在 SNES 原版中,属于后续版本内容。
  • 评论也争论安全语言是否减少了这类有趣但危险的漏洞。
No.20 Asking authors about their own papers
向论文作者提问他们自己的论文
146 分 78 条评论 作者: stefanpie
文章讨论 TMLR 编辑对一批可能被直接拒稿的论文作者做了额外实验:要求作者回答关于其论文的基本问题,结果据称只有少数人能及时、充分说明自己的工作。这被视为 LLM 时代论文代写、低理解度投稿和学术信任危机的信号。评论者围绕几条线争论:作者是否必须真正理解署名论文;访谈或「科学 CAPTCHA」能否成为审稿补充;是否应把同样方法用于已接收论文和审稿人;以及在免费同行评审、出版商获利、LLM 辅助写作已普遍化的背景下,如何区分合理工具使用、幽灵写作和学术不端。也有人提醒需要对照组,低质量论文和敷衍审稿并非 AI 之后才出现。

评论精华

  • 多位评论认为作者答不出论文问题近似幽灵写作或剽窃。
  • 有人建议把访谈、问答或自动检查作为审稿和论文验证的一环。
  • 也有人要求用已接收论文、AI 时代前论文作对照,避免过度归因。
  • 评论关注 LLM 使用披露规范,以及作者对内容承担责任的边界。
  • 免费同行评审与出版商利润引发争议,审稿质量本来就参差不齐。
No.21 Arrow heads at Obi-Rakhmat (Uzbekistan) 80K years ago?
乌兹别克斯坦 Obi-Rakhmat 遗址或有 8 万年前箭头
4 分 1 条评论 作者: bookofjoe
论文报告乌兹别克斯坦天山西麓 Obi-Rakhmat 岩棚约 8 万年前地层中的石制武器尖端。作者通过使用痕迹与形态分析,在 20 件候选器物中识别出修饰尖器、细石叶,以及此前因破碎未受注意的未修饰三角形微型尖器。其尺寸和宽度被认为更适合装配在类似箭杆的轻型投射武器上,而非普通长矛或多用途工具。若成立,这将把轻型投射尖器的出现推到中旧石器时代晚期,并挑战其只与现代人上旧石器技术相关的叙事。争议在于,论文标题称「箭头」,但证据主要支持轻型投射武器,是否能区分弓箭与投矛器飞镖仍不确定。

评论精华

  • 评论指出论文似乎未区分弓箭用箭头与投矛器飞镖,后者早于弓箭出现。
No.22 What Zig felt like, coming from Rust
Rust 开发者初试 Zig 的真实感受
212 分 251 条评论 作者: ksec
作者以 7 年 Rust 经验重写自己的 JSONPath 库,借此比较 Zig 与 Rust。Zig 给他的第一印象不是语法,而是 IDE 支持薄弱,却也促使他回到命令行、build.zig 与更轻量的编辑器工作流。项目结构上,Zig 鼓励更扁平的文件组织;测试可行但比 Rust 更啰嗦。核心差异在编程范式:Rust 的迭代器、模式匹配、不可变转换和组合子让函数式风格自然,而 Zig 更倾向显式循环、原地修改、手动内存管理与更直接的控制流。作者认为 Zig 简洁、现代、很快,但从 Rust 迁移会明显感到少了自动析构、抽象层和生态舒适度。

评论精华

  • 不少人指出 Zig 有 zls 语言服务器,IDE 支持并非只有语法高亮。
  • 评论围绕手动内存管理和无自动析构争论,Rust 的 Drop 被认为能避免一类 bug。
  • 多位低层开发者为 Zig 辩护,称其心智模型简单、控制流显式、comptime 实用。
  • 关于 allocator 的讨论分歧很大:有人认为是过度迷恋,也有人称高性能软件离不开它。
  • 部分评论质疑文章受 AI 润色过重,认为主观体验文章不该让 LLM 代写。
No.23 Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
经典基准之外的 Btrfs、ZFS 与 bcachefs 负载测试
117 分 95 条评论 作者: farlight
文章用自动化基准比较 Btrfs、ZFS、bcachefs 及部分 RAID/LVM 组合在经典跑分较少覆盖的场景下的表现,包括截断文件、I/O 响应性、校验修复和阵列损坏恢复等。结果似乎显示 bcachefs 在混合设备、性能与灵活性上很有吸引力,但作者也承认主要测试跑在 GitHub runner 的 loop 设备和共享虚拟机上,只能看相对形态,不能当作真实硬件绝对结论。社区争议集中在测试环境噪声、配置说明不足、md-raid10 与 lvm-raid10 差异、完整性失败含义,以及文件系统的长期稳定性和社区治理风险。

评论精华

  • 不少人看好 bcachefs 的性能和混合设备能力,但担心其退出主线内核。
  • 多位评论者质疑 GitHub runner 与 loop 设备无法代表真实硬件。
  • 作者回应称结果只看相对形态,并已有真实硬件测试计划。
  • ZFS 用户强调长期可靠性和生态成熟度,性能并非唯一指标。
  • 有人要求补充更清晰的 RAID、纠删码和完整性测试配置说明。
No.24 ZK-JPEG: Zero-Knowledge Image Editing and Compression
ZK-JPEG:零知识图像编辑与压缩
81 分 16 条评论 作者: gslin
论文提出「ZK-JPEG」,用于在不公开原始图像的情况下,证明发布图像确实由已承诺的相机原图经过合法 JPEG 压缩和指定编辑得到。背景是相机签名可证明来源,但 JPEG 压缩、模糊、裁剪、遮挡等常见处理会破坏签名;既有零知识图像溯源方案又难以承受有损编码。作者用 PicoZK 将 Python 图像处理代码转为 LPZK 电路,把一系列变换整合进 JPEG 流程,声称系统快速、灵活、可用现成 ZK 工具实现。争议集中在可接受编辑边界、模拟翻拍漏洞,以及这种证明能否支撑新闻、房产等真实信任场景。

评论精华

  • 有人质疑「真实」证明会变成哲学问题,关键在可接受编辑清单。
  • 评论指出可通过打印 AI 图再用相机拍摄来绕过来源认证。
  • 支持者认为可接入 Apple、Android、Sony 等签名照片形成端到端溯源。
  • 新闻摄影、房产和二手交易被认为是可能受益的真实场景。
  • 也有人主张保留原始 RAW 与处理步骤,让观看者逐步验证变换。
No.25 If math is more than proof, we need to better celebrate the rest of it
数学不只是证明,也应奖励解释与理解
348 分 261 条评论 作者: num42
Grant Sanderson 认为,AI 让生成证明不再天然等同于增进数学理解,数学界应把能回答「你会怎样想到它」的「有动机的解释」提升为可获学术荣誉的成果。它不同于证明:定义往往出现在叙事中段,允许从不完美直觉出发,解释定理为何值得提出及如何使用。文章借《普林斯顿数学指南》、Gowers 与 Thurston 的例子说明,阐释工作早已对数学共同体有巨大价值,却常被当作二等贡献。争议在于这类理解难以像证明那样二元验证,也可能很快被 AI 辅助生成。

评论精华

  • 多位数学从业者认同证明只是理解的代理,AI 会迫使学界重估奖励机制。
  • 有人担心「理解」主观且难评审,容易被声望、写作风格或教学路线左右。
  • 评论把数学类比软件业:AI 先自动化局部任务,但完整问题选择与理论建构仍重要。
  • 不少人指出历史上费马、四色等难题的价值在于副产物与人类可理解的路径。
  • 也有人质疑解释并非安全护城河,未来模型或能生成 Lean 证明和优秀阐释。
No.26 Deodands put a price on objects that caused death
铁路如何终结中世纪的「致死物」法律
78 分 30 条评论 作者: samizdis
文章介绍英国中世纪法律概念「deodand」:直接导致成年人死亡的动产会被视为应献给上帝的受诅物,由其所有者按物件价值赔付给国王,现实中常由验尸官转给死者家属。这个制度规则混乱,陪审团可按同情、责备或地方舆论裁量,从梯子、车轮到整辆车都可能被估价。工业革命和铁路事故使问题放大:若火车致死,铁路公司可能要赔整台机车。1846 年废除「deodand」被视为进步,但学者指出它也保护了铁路资本,使许多乘客、雇员和闯入者家属失去仅有的补偿渠道。文章最后将其引向对非人实体责任的思考,如 AI 导致自杀或谋杀时应如何追责。

评论精华

  • 评论者认为按致害物价值补偿,反映了与现代责任观很不同的法律心态。
  • 有人补充「deodand」更像没收和销毁致死物,不应过度理解为精确赔偿机制。
  • 多条评论联想到中世纪动物审判、古代法律和现代资产没收等相似制度。
  • 铁路推动废法被批评为借反迷信之名保护富有公司,削弱受害者家属补偿。
  • 关于 AI 类比,有人戏称若按中世纪逻辑,模型或算被召唤出的恶魔。
No.27 Faster NumPy in the Browser
浏览器中的 NumPy 大幅提速
28 分 1 条评论 作者: Matumio
文章介绍 Emscripten-forge 的 NumPy 现已在 WebAssembly 中链接 OpenBLAS,结束了浏览器里长期依赖朴素循环执行矩阵运算的局面。在 n=1024 的矩阵乘法中,float32 提速约 30.92 倍,float64 提速约 14.90 倍;后续 OpenBLAS 0.3.35 与 Relaxed SIMD 还会进一步提升。作者强调关键不只是单次优化,而是 Emscripten-forge 以类似 conda-forge 的方式,为 WebAssembly 提供语言无关的科学计算发行体系,包括 Fortran 工具链、OpenBLAS、LAPACK 和动态链接 ABI。短板是部分 LAPACK、GEMV 等场景仍未充分优化。评论则质疑继续维护 Fortran 生态是否不如用 AI 重写这些老科学库。

评论精华

  • 有评论质疑,与其维持 Fortran,不如用 AI 重写 BLAS 等遗留库。
No.28 KDE turns 30 and someone's brought an AI-native desktop proposal
KDE 三十周年之际,有人提出 AI 原生桌面设想
5 分 0 条评论 作者: pndy
The Register 报道 KDE 项目迎来 30 周年,并关注 Akademy 大会上一个颇具争议的「AI 原生桌面」提案。该设想把 Plasma 桌面从传统固定界面,推进到可围绕每位用户的个人模型动态组装:系统理解用户习惯、任务和上下文,并据此生成或调整桌面体验。文章的核心看点在于,开源桌面社区一方面仍强调可控、透明和本地化,另一方面也开始面对 AI 是否应进入桌面基础层的问题。争议焦点预计会集中在隐私、可解释性、用户自主权,以及 KDE 是否应把有限资源投入这种前瞻但风险较高的方向。
No.29 UFO Series Home Page: "UFO" TV Series from 1970
1970 年英国科幻剧 UFO 资料主页
79 分 33 条评论 作者: DropDead
这个网页是献给 1970 年英国科幻电视剧「UFO」的资料主页。该剧由 Gerry 与 Sylvia Anderson 创作,Ed Bishop 饰演 Straker 指挥官,围绕秘密组织 SHADO 抵御外星威胁展开。HN 讨论显示,它在许多观众心中仍以主题音乐、未来主义服装、交通工具、月面基地和冷战式阴谋氛围留下强烈记忆;也有人指出它影响了后来的审美和游戏,如 Austin Powers 与「X-COM」。争议主要集中在时代局限:女性角色虽有权力位置,却常被男性凝视和性感化呈现,重看时让部分观众感到不适。

评论精华

  • 许多读者怀旧称赞主题曲、片头剪辑、道具和未来感设计。
  • 多位评论认为该剧影响了 Austin Powers、EVA 片头和「X-COM」等后作。
  • 重看者普遍承认剧集仍有魅力,但性别呈现和男性凝视很明显。
  • 有人推荐具体集数,如「Mindbender」「Survival」和「A Question Of Priorities」。
  • 评论将它与「星际迷航」「Space: 1999」等同期科幻剧比较。
No.30 Compiler-style optimization for drawing via Skia
用编译器式优化加速 Skia 绘图
110 分 21 条评论 作者: PaulDavisThe1st
论文提出面向 Skia 2D 光栅化库的形式语义「μSkia」,并在 Lean 中机械化验证,用来理解和优化应用提交给图形库的绘制指令序列。作者发现即使 Chrome 在热门网站上也会产生低效 Skia 操作,原因在于光栅化语义复杂且执行模型不透明。他们总结出四类低效模式,给出可证明等价的替换规则,并实现高性能优化器。对来自百大网站的 99 个 Skia 程序测试,在现代 GPU 后端上平均提速 18.7%,优化耗时不超过 32 微秒,且优化轨迹可回灌 Lean 做端到端验证。

评论精华

  • 前 Skia 贡献者认为这正是 SkRecord 当初希望支持的优化方向。
  • 作者称 Chrome 团队感兴趣,但改发射端代码牵涉很广,优化器更现实。
  • 多名评论者将其类比数据库查询优化、JVM 循环优化和固定点优化。
  • 关于游戏场景,作者认为可做类似分析,但深度、感知和 3D 语义会更复杂。
  • 社区关注 GPU 抽象层是否足够高,认为现代图形程序缺少适合编译器优化的 DSL。