2026年07月12日 · 星期日 第 160046 期

The Hacker Daily

丙午年(马)五月廿八

30 篇文章 · 1055 条评论 ·聚焦:AI编程工具 · GPU算力资源 · 开源硬件/系统
No.01 Mesh LLM: distributed AI computing on iroh
Mesh LLM:基于 iroh 的分布式 AI 计算平台
216 分 49 条评论 作者: tionis
Mesh LLM 是一个构建在 iroh 之上的分布式 AI 计算系统,旨在将多台机器的 GPU 资源池化,统一暴露为 OpenAI 兼容 API(localhost:9337/v1),用户无需关心任务实际运行在哪台机器。请求可由本地 GPU 处理、路由至已有模型的节点,或通过内部名为「Skippy」的分片模式跨多机流水线执行层范围切分。iroh 提供公钥寻址的 QUIC 连接和 NAT 穿透能力,无需中央服务器,中继节点负责跨地域 fallback。系统内置 40+ 模型,从可运行于笔记本的小模型到 235B MoE 巨兽均有支持,安装包约 18MB。社区质疑主要集中在:缺乏实际吞吐量/tokens-per-second 性能数据;网络延迟对跨广域网部署的影响尚不明朗;隐私方面,加密负载在不同节点间流转时是否可被读取仍存争议;以及 AMD GPU 兼容性和公开 mesh 的贡献激励机制尚未明确。

评论精华

  • 性能数据缺失,实际吞吐量与 token/sec 未披露,跨 WAN 延迟影响不明确
  • Skippy 分片模式比 llama RPC 快得多,但节点间 5ms 延迟已是瓶颈,跨地域更慢
  • 隐私风险:节点间传递请求时,即使是可信节点也可能访问用户私人数据
  • 激励机制不明,加入公开 mesh 贡献 GPU 资源能获得何种回报尚无保障
  • AMD GPU 兼容性弱,旧款显卡与可安装的 llama.cpp 构建存在兼容问题
No.02 The 'Father of the Internet' is finally retiring
「互联网之父」Vinton Cerf 正式退休,结束 Google 20年职业生涯
24 分 9 条评论 作者: compiler-guy
83岁的 Vinton Cerf 将于下周从 Google 首席互联网福音官职位退休,结束其标志性的技术生涯。他与 Robert Kahn 共同设计的 TCP/IP 协议是现代互联网的基石,Cerf 因此获得图灵奖、总统自由勋章等无数荣誉。自2005年加入 Google 以来,他推动了无障碍访问和「Greyglers」群体权益倡导。退休前他预测 AI 代理时代将迫使科技公司重返标准化协议之路——多个来源的代理相互协作需要互操作性和正式标准;他认为自然语言通信存在歧义风险,精确的机器可读协议必不可少。评论中不乏质疑声音,有人认为他在 Google 后期「只是荣誉性职位」,也有人肯定他是真正的创新者,理应获得丰厚回报。

评论精华

  • 有用户讽刺感谢 Al Gore(暗讽 Gore 声称发明互联网的争议),暗示对 Cerf 成就的复杂态度
  • 有评论指出 Cerf 在 Google 20年「没做什么实事」,质疑高薪荣誉职位的合理性
  • 与当下裁员潮和 Gemini 收费争议对比,认为「首席互联网福音官」职位已无预算必要
  • 有用户认可他是真正的创新者,无论对 Google 看法如何
  • 83岁高龄应退休让位,支持者称赞他将荣誉职位转化为推动无障碍访问的平台
No.03 Show HN: Ant – A JavaScript runtime and ecosystem
展示: Ant — JavaScript 运行时与生态系统
248 分 106 条评论 作者: theMackabu
Ant 是一个新兴的 JavaScript 运行时,主打沙箱隔离、小型二进制文件和快速启动。其核心卖点是与 Node/Deno/Bun 不同的安全模型——默认启用 VM 级沙箱,能有效防止供应链攻击和恶意代码蔓延。项目还配套推出了 ant.land 包注册表。由于声称「接近 V8 性能」且体积远小于 V8,被社区用于嵌入式场景讨论。但批评者指出:该项目命名与 Apache Ant、Ant Design(阿里巴巴)等重名,毫无辨识度;性能数据缺乏独立基准支撑;作者个人 GitHub 托管、无明确路线图,信任度存疑;还有评论指其代码疑似由 LLM 从 Elk 项目改写而来。总体而言,沙箱设计是亮点,但成熟度与商业可信度是主要短板。

评论精华

  • 沙箱隔离是最大亮点,质疑 Node/npm 为何不默认启用此项以防范供应链攻击
  • 命名引发广泛争议——Apache Ant、Ant Design、Anthropic ant CLI 均已占用「Ant」一词
  • 性能声明遭质疑,zoo.js 基准测试显示与 V8 差距明显,非「near-V8 speeds」
  • 项目由个人 GitHub 托管,无明确路线图和团队,信任度与长期维护能力存疑
  • 适合 FaaS/边缘计算场景,快速启动和小体积是核心竞争力
No.04 Show HN: Mindwalk – Replay coding-agent sessions on a 3D map of your codebase
展示: Mindwalk – 在代码库3D地图上回放编码代理会话
7 分 1 条评论 作者: cosmtrek
Mindwalk 是一个开源工具,能在代码库的 3D 可视化地图上回放 coding-agent 的操作会话。开发者可像观看视频一样浏览 AI 编程助手执行命令、修改文件的完整轨迹,直观理解代理的决策路径和代码改动上下文。工具基于 Git 仓库结构构建 3D 拓扑图,节点代表文件或目录,边反映引用关系,帮助开发者审计 AI 编程过程、调试代理行为、识别常见执行模式。评论者以略带讽刺的口吻建议作者制作演示视频,以便更直观展示工具效果。

评论精华

  • 评论者建议作者制作演示视频,以更清晰展示 Mindwalk 的实际使用效果
No.05 RISCBoy is an open-source portable games console, designed from scratch
RISCBoy:从零设计的开源便携游戏机,平行宇宙中的 GBA
126 分 18 条评论 作者: mariuz
RISCBoy 是一款从零开始设计的开源便携式游戏机,由树莓派 ASIC 设计工程师 Luke Wren 开发。它被描述为「平行宇宙中 RISC-V 于 2001 年就存在的 Game Boy Advance」,也是作者献给童年掌机时代的情书。硬件采用自研 Hazard3 RISC-V 内核(RP2350 芯片的核心),使用开放的 AMBA AHB/APB 总线协议。有开发者询问能否运行 Godot 引擎,社区建议可以自行移植。评论区的亮点在于:Luke Wren 其实是在业余时间设计了 Hazard3 内核,而非公司任务;AMBA 总线早已是开放标准,并非 ARM 专有;还有用户特意称赞 README 零 emoji 的简洁风格,暗讽当下 AI 生成的灌水内容。

评论精华

  • Luke Wren 是树莓派 ASIC 工程师,设计了 RP2350 芯片内置的 Hazard3 RISC-V 内核,此项目为业余作品
  • AMBA(AHB/APB)总线协议早已是开放标准,并非 ARM 专有,这一细节令部分开发者意外
  • RISCBoy 采用开源 AMBA 总线,打破了对总线协议产权的误解
  • 有用户询问是否可运行 Godot 引擎,社区回复称需要自行搭建工具链并移植
  • README 无 emoji 获得好评,被视为与 AI 生成「slop」内容抗衡的清流
No.06 Text art tools
文本艺术工具资源列表
22 分 5 条评论 作者: surprisetalk
本文原为 Notion 页面的文本艺术工具(Text Art Tools)资源列表,内容未通过 JavaScript 渲染显示。据评论可推断,该列表汇总了 ASCII 艺术、文本模式编辑器及各类替代设计工具。评论者 scriptsmith 提到自己开发的「tart」工具,用于为大学 HPC 登录节点 MOTD 创建样式化文本艺术;california-og 指出该列表最初聚焦 ASCII 编辑器,后扩展至更广泛的替代设计工具,并举办过相关工作坊;另有评论提及 Slanted 杂志近期也推出了数字工具专题并附带截图。社区讨论还涉及一个实际问题:大多数设计作品最终需落地印刷或实物输出,而 Pantone 颜色标准在这一领域占据垄断地位,支持 Pantone 成为文本艺术工具面临的重要挑战。

评论精华

  • scriptsmith 开发的 tart 工具可为大学 HPC 登录节点 MOTD 创建样式化 ASCII 文本艺术
  • california-og 的列表最初为 ASCII 及文本模式编辑器,现已扩展至各类替代设计工具
  • Slanted 杂志近期推出数字工具专题,附有大量工具截图
  • 文本艺术工具面临 Pantone 色彩支持挑战,因为设计作品最终需要实物输出
No.07 An agent in 100 lines of Lisp
用 100 行 Lisp 写一个 AI Agent
123 分 14 条评论 作者: jamiebeach
作者在 2000 年上 AI 课时学过 Lisp,被教授称为「AI 的语言」,25 年后他用 Lisp 实现了一个仅约 100 行代码的 AI Agent 核心逻辑。核心洞察是:Agent 就是一个递归函数——向模型发送消息列表,模型或回答或请求工具,如需工具则执行后继续递归,最终返回结果。实现巧妙之处在于:只提供一个工具「eval」,由于 Lisp 是同像性语言(代码即数据、数据即代码),模型可以直接生成并执行 Lisp 代码——问第 30 个斐波那契数,它就写一个递归函数并运行;作者插入 Brave Search API key 后,Agent 甚至用 eval 自己构造出了一个 brave-search 函数。作者认为这才是 Lisp 作为 AI 语言的 2026 版本——程序操纵程序,只是把符号推理外包给了语言模型。评论中有人质疑这只是相当于 bash 执行 python -c,Lisp 的优势并不明显;也有人指出同像性让 Lisp 程序生成 Lisp 代码比 JS 生成 JS 更容易(只需生成嵌套列表而非字符串),以及作者从零构建最小 Agent 的思路本身很有价值。

评论精华

  • 评论者 goranmoomin 指出,虽然他热爱 Common Lisp,但作者对同像性的论证站不住脚,不能算是支持 Lisp 的有力论据
  • hankbond 质疑:这和让 Agent 执行 python -c 有什么区别?并没有体现出 Lisp 的独特优势
  • lelandbatey 认为这确实是从 Lisp 视角出发的有趣实验,他自己也写过一个零依赖的单文件 Agent 框架
  • jstanley 反驳:既然 Agent 只输出文本且很擅长写 Python,Lisp 的同像性优势实际上并无用处
  • pama 指出文章的核心价值在于展示从零搭建最小 Agent 框架,证明 Agent 不需要复杂的基础设施
No.08 Nvidia, CoreWeave, and Nebius: Inside the Circular Financing of the GPU Boom
Nvidia、CoreWeave 与 Nebius:GPU热潮中的循环融资真相
241 分 80 条评论 作者: adletbalzhanov
文章分析了 CoreWeave 与 Nebius 这两家「Neocloud」如何在 AI 算力需求爆发中快速崛起。它们通过优先获取 Nvidia 最新 GPU(两周内部部署)及高于同行的 GPU 利用率(MFU 超 50%),吸引微软、Meta 等超大规模企业签下累计超 1450 亿美元的长单。然而,这些公司收入规模相较承诺金额差距悬殊——CoreWeave 2026 年预计营收仅 126 亿美元,Nebius 约 34 亿美元,且均未盈利、依赖高额债务融资。Nvidia 向两家公司各投资 20 亿美元换取股权,形成「供应商入股客户」的循环融资结构,引发市场对风险传导的担忧。评论中有多人认为「循环融资」言过其实,融资本身皆为循环,且 Nvidia 的 20 亿美元投资仅占 CoreWeave 2026 年 CapEx 的 5.7%,影响有限;也有人担忧一旦需求放缓或定价无法维持,整个链条将产生连锁反应。

评论精华

  • 有评论指出融资本质皆为循环,文章用「循环融资」制造恐慌,实际风险有限
  • Nvidia 20 亿美元投资仅占 CoreWeave 年 CapEx 的 5.7%,不足以构成重大问题
  • 这些 neocloud 能否盈利才是核心问题,多数企业无法承受真实算力成本
  • 担忧一旦资金或需求逆转,整个 AI 算力链条可能产生连锁崩溃
  • 有评论提到 Nebius 实为 Yandex 背景,暗示地缘政治风险被低估
No.09 I Did Not Kill Stanley Lieber: How to Draw (With 9front)
用 9front 绘画:paint(1) 与 9front 艺术机完全指南
60 分 16 条评论 作者: c-c-c-c-c
这是一份关于如何在 9front 操作系统上使用 paint(1) 绘画程序的详细教程。作者以一种极度戏谑、无厘头的英式幽默风格写成,声称教程「不会吸引艺术家、无神论者和偶像破坏者」,只会吸引「变态、机器人和女巫」。文章介绍了 9front 的绘画设备选择:推荐 ThinkPad X 系列翻转本和 GAOMON S620 数位板;详细说明了 paint(1) 的核心操作——无图层、无复制粘贴、无压感支持(yet),一切操作都像在真实纸张上进行;包括文件保存读取(w/r)、画布变换(| rotate)、重定向(< >)等命令,以及 crop、rotate 等图像操作工具。Stanley Lieber 即 Stan Lee 原名,9front 则是 Plan 9 操作系统的激进分支。评论中有读者指出文章其实并不教绘画技巧,只教软件用法;也有读者对「不吸引无神论者和偶像破坏者」的玩笑言论表示不适。

评论精华

  • 读者对在触摸屏上使用实体尺子画直线这一「具身性」操作印象深刻。
  • 有读者认真询问 Stanley Lieber 是否就是漫威的 Stan Lee(同名不同人)。
  • 文章被批评名不副实:实际上并不教绘画,只教特定软件使用方法。
  • 有读者对「不吸引无神论者和偶像破坏者」的玩笑感到不适,认为冒犯了特定群体。
  • 有读者解释:9front 是 Plan 9 操作系统的分支,Stanley Lieber 是贡献者名字,「jurassic park 运行 Plan 9」是玩笑(电影中实际是 IRIX)。
No.10 EF Core 11 makes your split queries faster
EF Core 11 优化-split 查询:移除子查询中多余的 JOIN
30 分 4 条评论 作者: rellem
EF Core 11 改进了 AsSplitQuery 的性能表现。问题在于此前版本中,即使只 Include 了引用导航属性(如 BlogType),collection 查询(如 Posts)也会附带这些不必要的 JOIN 和 ORDER BY,造成数据库做了大量无用功。EF Core 11(自预览版 3 起)会裁剪掉 collection 查询中的冗余引用导航 JOIN。基准测试显示:.NET 10 下耗时 68.53ms、分配 33.35MB,升级到 .NET 11 后降至 62.07ms、30.15MB,提升约 9.4%。引用导航越多,优化效果越显著。

评论精华

  • exceptione 质疑 AsSplitQuery 相比单次多表 JOIN 查询在性能上的优势
  • preetham_rangu 指出真正收益在于裁剪掉引用导航的 JOIN,这些一直是无效开销
  • fuzzy2 解释多表 JOIN 会导致结果集按倍数膨胀,在网络上传输的数据量会成倍增加
  • exceptione 提出用「结果集字节偏移」代替实际数据复制来规避重复传输的思路
No.11 Protobuf-py: Protobuf for Python, without compromises
Protobuf-py:无需妥协的 Python 原生 Protobuf 实现
9 分 1 条评论 作者: ming13
Buf 宣布推出 protobuf-py,一个完全从零编写的 Python 原生 Protobuf 库。该库通过 Google 全部二进制和 JSON 一致性测试,支持 proto2/proto3/editions、扩展、自定义选项、未知字段、动态消息和知名类型。核心创新在于将数据保留在 Python 对象中(使用 __slots__),生成的代码可读、类型安全,oneof 可模式匹配,枚举是真正的 IntEnum 成员。相比 Google 的 C++ 风格绑定,API 更符合 Python 习惯。性能方面,配合 Rust 加速器后,在真实生产负载(社交媒体动态构建)下性能优于 upb。Rust 加速器为可选依赖,无加速器时自动回退到纯 Python 实现,兼容 Python 3.10+ 且无运行时依赖。
No.12 Jellyfish Undersea Roundabout
法罗群岛「水母」海底环岛:世界首个水下环形交叉道
32 分 3 条评论 作者: hydrogen7800
法罗群岛建成世界首个海底环形交叉道,位于Eysturoyartunnil隧道群核心,海底72米深处。该隧道网络于2020年12月开通,全长11.2公里,耗资约2.6亿欧元,将首都托尔斯港至第二大岛的通行时间从1小时缩短至15分钟。环形交叉中央保留天然岩柱,由艺术家Tróndur Patursson进行灯光装饰,周围环绕80米钢雕——手拉手的等身人物雕像,象征法罗群岛「团结协力」的精神。隧道还配备先进排水系统,雨水经管道排至最低点,由16 bar水泵送回海面。单程通行费75丹麦克朗(约10欧元),无年订户则需24欧元,收费将资助后续隧道建设。法罗群岛仅5.3万人口,却已建成20条隧道(含3条海底),堪称「隧道狂魔」,另有2条在建、14条规划中。
No.13 UPI: Anatomy of a Payment Transaction
UPI支付架构深度解析:印度2272亿笔交易的幕后结构
170 分 63 条评论 作者: prtk25
UPI(统一支付接口)是印度实时支付系统,2026年6月单月处理超过2272亿笔支付,位居全球之首。本文详细拆解其技术架构:用户手机上的应用(PhonePe、Google Pay等)仅收集支付意图和PIN,实际资金流转由赞助银行连接NPCI中央交换机完成。交换机先将请求路由至收款人银行验证账户,再依次完成借方扣款和贷方入账。值得关注的是,发起端以State Bank of India为首,但收款端Yes Bank远超其他银行——因其是多数商户应用的主要赞助行。文章还区分了两类支付失败:业务拒绝(余额不足、密码错误)和技术拒绝(系统故障)。社区评论聚焦于:UPI作为公共基础设施与Alipay/WeChat Pay私有模式的本质区别,KYC要求带来的隐私争议,以及其对系统设计实践的参考价值。

评论精华

  • UPI是工程壮举,让印度老人都转向数字支付,成就举世无双
  • UPI中心化且KYC完善,与真正点对点支付相去甚远,隐私是隐患
  • UPI是公共基础设施驱动的互操作路由层,Alipay则是私有公司内部账户体系
  • 系统设计启示:1.5B人口规模下的支付系统设计值得借鉴
  • 月均22B笔交易推算年化264B笔,远超大多数支付系统规模
No.14 Under federal rule, colleges must leave grads better off or lose financial aid
联邦新规:大学毕业生收入必须优于未受高等教育者,否则失去助学贷款资格
61 分 93 条评论 作者: nradov
美国教育部推出「不伤害」新规,要求高校证明其毕业生收入超过从未受大学教育者,否则将被切断联邦助学贷款。新规来自去年的《一揽子美丽法案》,预计约80万学生就读于可能不达标的专业,主要集中在营利性学校、短期证书课程和艺术类项目。包括茱莉亚学院、新英格兰音乐学院、印第安纳大学雅各布斯音乐学院等顶尖音乐院校的本科项目也在失败之列。艺术教育支持者担忧此规将导致高校削减音乐、戏剧等低收入创意艺术课程,认为收入并非衡量艺术教育价值的唯一标准。该测试将于2027年开始计算首批毕业生收入,2028-2029学年正式生效。

评论精华

  • 欢迎新规打击「学历工厂」,营利性学校和垃圾专业早该被淘汰
  • 反对声音担心此举将减少高等教育入学率,导致国民教育水平下降
  • 质疑学生贷款为何不可通过破产免除,而其他债务均可
  • 艺术教育支持者认为收入不能衡量文化与社会价值,需保留人文专业
  • 比较欧洲模式:教育由税收资助,学生无需 upfront 支付费用
No.15 We scaled PgBouncer to 4x throughput
PgBouncer 4倍吞吐量实战:如何突破单线程瓶颈
201 分 43 条评论 作者: saisrirampur
PgBouncer 原本是单线程连接池,一个进程只能用一颗 CPU 核心,16核机器上其余15核闲置。ClickHouse Managed Postgres 通过多进程 Fleet 模式解决:每颗核心运行一个 PgBouncer 实例,用 so_reuseport 让内核在多进程间自动分配连接,进程间通过 peering 机制互相感知以解决查询取消请求迷路问题。实测 16vCPU 机器上,单进程最高约 87k txn/s,16进程 Fleet 持续爬升至约 336k txn/s(约 4 倍),且集群整体连接数可叠加而不超限。核心结论:当连接池本身成为瓶颈而非 Postgres 时,多进程 Fleet 是让池化层重新变回「管道」的有效方案。

评论精华

  • PgBouncer 取消请求为何不能直接转发 Postgres 处理,而要在进程间转发?
  • 有用户推荐 Odyssey(可扩展 PgBouncer)和 Pgdog 作为替代方案
  • peering 功能已内置于 PgBouncer,配置简单(peer_id + unix_socket_dir)
  • 有人指出跨 AZ 延迟对连接池性能有显著影响
  • 社区仍质疑 Postgres 连接模型过重,PgBouncer 本不该存在
No.16 A pure scheme web programming tool
展示: Goeteia — 浏览器内自举的 Scheme-to-Wasm 纯前端 Web 开发工具
86 分 20 条评论 作者: guenchi
Goeteia 是一个完全运行在浏览器端的 Scheme 编译器,目标平台为 WebAssembly。核心亮点:编译器本身由 Scheme 子集编写,实现了自托管(self-hosted)——源码编译后输出字节一致,CI 每次变更都会验证这个固定点。技术特性包括:fixnum 用 i31ref 无装箱、GC 结构体存储配对和记录、语法规则和语法案例支持卫生宏、尾调用优化(100M 循环约 150ms 完成、常量栈)、基于 Wasm 异常处理提案的 escape continuation(O(1) 捕获)。内置 Web 开发框架提供:响应式信号系统(sx)、HTML 渲染器、JavaScript FFI、Three.js 绑定(three)、原生 WebGL 命令缓冲(gl/glsl)、与后端 Scheme 服务器(Igropyr)的 s-expression RPC 通信。编译产物(约 70KB gzip,缓存在浏览器)可在任何支持 Wasm GC 和尾调用的引擎上运行——Node 22+、Chrome、Firefox、Safari、wasmtime。评论区既有对 AI 辅助编程与 JS 静态验证性不足的讨论,也有人指出 Scheme 本身同样缺乏静态验证保证;另有用户反映编辑器存在光标定位 bug。

评论精华

  • JavaScript 在 AI 时代缺乏静态验证性,且 DOM 操作容易静默失败,社区认为这是核心痛点。
  • Hoot(Spritely 项目)已实现类似功能,但 Goeteia 的自托管编译器和卫生宏实现有其独特价值。
  • 用户反映编辑器存在 bug:每次编辑操作都发生在光标位置上一行,实际使用需手动调整光标。
  • 有评论认为 AI 生成内容过多「honest residue」风格措辞,影响阅读体验,建议精简。
  • 作者强调三大特色:浏览器内自托管卫生宏、宏展开式 HTML/CSS 开发、s-expression RPC 通信。
No.17 The Energetic Costs of Cellular Computation (2012)
细胞计算的能耗成本 (2012)
19 分 1 条评论 作者: lioeters
本文研究细胞执行计算时的能量消耗问题。研究者以经典的「Berg-Purcell问题」(细胞如何估算外部化学配体浓度)为例,基于兰道尔原理构建了两组分细胞网络模型。研究表明:细胞要获取外部浓度信息,必然需要打破热力学细致平衡并消耗能量;学习精度越高,所需能量越大。这一发现提示,能耗成本可能是资源匮乏环境(如细菌孢子萌发网络)中细胞计算系统设计的重要约束因素。

评论精华

  • visarga:成本约束决定系统内部结构,结构与成本共同演化,而哲学家往往忽视这一因素
No.18 Billions of Sketches Reveal Hidden Cultural Variation in Human Concepts
数十亿张简笔画揭示人类概念中隐藏的文化差异
88 分 13 条评论 作者: Anon84
研究团队分析来自236个国家和地区的26亿张人类手绘简笔画(基于Google QuickDraw数据集),发现同一概念在不同文化中会呈现多种不同的视觉表达,揭示了语言无法捕捉的潜在文化差异。涉及触觉交互(如工具使用)的概念差异最为显著,表明视觉想象与身体体验密切相关。对比简笔画与多语言词向量模型后发现,视觉表征保留了语言模型压缩掉的丰富语义和文化结构;基于简笔画的跨文化相似度与既有文化距离指标的对齐程度比文本方法高出45%。研究指出,人类概念的普遍性结论高度依赖于测量模态,大规模简笔画数据可作为一种直接、高分辨率的文化概念多样性探测手段。

评论精华

  • 第6页将简笔画按聚类可视化排布,非常有趣
  • 不同文化用单手比划数字3的方式差异很大,这是现实中最典型的例子
  • 研究基于Google QuickDraw数据集公开的5000万样本
  • 有批评认为「概念若有差异则根本是不同的概念」,论点成立存疑
  • 2017年就有人分析过不同国家用户画圆圈的方向偏好
No.19 Unexpected Solidlike Fracture in Simple Liquids
简单液体也会碎裂:一种颠覆流体力学常识的意外发现
85 分 44 条评论 作者: Anon84
Drexel 大学研究者在与 Exxon Mobil 合作项目中,意外发现非弹性「简单液体」在高速拉伸时会发生类似固体的脆性断裂。传统理论认为只有具有弹性的复杂流体(如聚合物熔体)才能以这种方式断裂,但研究者回溯 Joseph 在 1990 年代的理论后发现,任何液体在足够撕裂应力下都可能断裂。实验显示,简单液体中的裂缝传播速度可达 500 至 1500 米/秒,远快于复杂流体的 0.07 米/秒,研究者推测原因是简单液体缺乏可吸收能量的分子链。有趣的是,两类流体都在约 2 兆帕的临界应力下断裂,表明断裂行为可能与维持分子聚集的「内聚能」有关,而非弹性本身。该发现对纤维纺丝等工程应用具有潜在价值。

评论精华

  • Exxon Mobil 资助此类研究引发伦理争议,被指是当年最早预测气候变化却掩盖信息的同一家公司
  • 部分评论者认为这就是空化现象,文章结论并不新颖,但研究者反驳指出简单液体(非弹性)与粘弹性聚合物是本质区别
  • 有评论讨论重力对物质状态的影响——足够强的重力下,水会转变成奇异的高密度相
  • 基础研究与应用科学的关系:即便当前无直接应用,纯粹的好奇心驱动的发现本身就有价值
  • 研究者可能将此应用于纤维纺丝领域,30 年内或可见实际工业影响
No.20 Fixed three bugs that made Qwen3.5-122B a daily driver on Mac Studio
修复三个 bug:让 Qwen3.5-122B 在 Mac Studio 上成为可用日常主力
50 分 22 条评论 作者: marzukia
作者将本地推理框架从 DS4 Flash 切换到 Qwen3.5-122B,主要原因是长上下文(50k tokens)时首 token 生成需 3-5 分钟,无法实现流式配对编程。Qwen3.5 MoE 架构约 10B 活跃参数,契合 M3 Ultra 内存带宽,且 96GB 统一内存足以支撑 SSD 回退的 KV 缓存。然而真正障碍是三个栈上 bug 导致每次回复都冷启动:①系统提示词含每轮动态消息 ID,破坏 KV 缓存的字节级匹配;②模型回复被中断时已解码 token 未写入历史,造成缓存分歧;③后台检查点写入器产生无匹配键的「毒」数据填满磁盘额度。三个修复完成后,同一 130k token 对话从每轮冷填充 30k token 降至亚秒级响应,恢复 token 数从个位数到数百不等。

评论精华

  • 技术细节详尽受到肯定,有读者认为比多数同类文章有价值
  • 有读者指出图表应使用对数坐标以更好呈现数据细节
  • 社区对 AI 辅助写作持两极态度:部分人拒绝阅读 AI 文风文章,作者本人承认用 Claude 润色
  • 最反直觉的 bug(动态消息 ID 破坏整个 KV 缓存)被多位读者标记为典型「隐形陷阱」
  • 有读者认为 1.5 分钟仍算不上交互式体验,3-5 分钟的改进幅度有限
No.21 The early History of the Singular Value Decomposition (1993) [pdf]
奇异值分解早期历史(1993)
112 分 62 条评论 作者: wolfi1
这是一篇关于奇异值分解(SVD)发展史的1993年论文,由G.W. Stewart撰写,献词对象为数值分析学家Gene Golub。SVD是一种将任意矩阵分解为三个矩阵乘积的代数方法,被评论者称为「矩阵的基本频率」和「原始自编码器」。文章指出,低秩近似需约束U和V为正交矩阵,否则系数会不稳定地在三个矩阵间游移。SVD与特征值的区别在于:特征值仅适用于方阵,而SVD可处理任意矩形矩阵,是广义特征值的延伸。在计算机视觉和图像处理领域SVD应用广泛,评论者提到Direct Linear Transform(DLT)求解PNP问题就涉及SVD。Gilbert Strang的线性代数课程和Axler的《Linear Algebra Done Right》被推荐为入门材料。

评论精华

  • SVD是矩阵的「基本频率」,低秩近似需约束U和V正交以避免系数在SVD三矩阵间游移
  • Gene Golub是SVD实用化的奠基人,其车牌为「P…」开头
  • SVD在计算机视觉中无处不在,如PNP问题的Direct Linear Transform方法本质上就是SVD
  • SVD相当于「OG自编码器」,而ADAM优化器与SVD有关联(当二阶导矩阵恰好对角时)
  • 入门推荐Gilbert Strang的MIT线性代数课程和Axler的《Linear Algebra Done Right》
No.22 Prefer strict tables in SQLite
SQLite 应优先使用严格表模式
267 分 129 条评论 作者: ingve
SQLite 自 3.37.0 版本(2021年11月)引入「严格表」模式,在建表语句末尾加 STRICT 即可启用。严格表强制执行类型检查:禁止向 INTEGER 列插入文本、禁止使用 GARBAGE/DATETIME/JSON 等非法类型名(仅允许 INT、INTEGER、REAL、TEXT、BLOB、ANY)。若需灵活性,可用 ANY 类型容纳任意值。作者认为严格检查能消除一类错误、提升数据完整性,且实测性能差异可忽略。但他也坦诚了缺点:无法 ALTER 现有表变为严格模式(必须重建表并迁移数据,若原数据有类型错误会迁移失败);SQLite 官方文档明确偏好灵活类型(flexible typing),认为这对键值存储、CSV 导入等场景有价值;旧版 SQLite 无法读取含严格表的数据库。作者观点是利大于弊,推荐新表默认启用严格模式。

评论精华

  • 「严格 X in Y」是通用好建议,宽松的 DWIM 行为迟早反噬。
  • STRICT WITHOUT ROWID 是很多开发者的默认建表选项,性能和一致性俱佳。
  • 严格表缺点了 Date 类型支持,但这是 SQLite 本身的限制,非 STRICT 之过。
  • 很多人将严格类型与 MongoDB 类比——初期灵活方便,后期维护噩梦。
  • 性能可调优,正确性调优难以接受:默认值的取舍反映项目哲学取向。
No.23 Biff.graph: structure your Clojure codebase as a queryable graph
Biff.graph:用查询图结构化 Clojure 代码库
127 分 14 条评论 作者: jacobobryant
Biff.graph 是一个轻量级 Clojure 库,允许将代码库结构化为可查询的图。它本质上是一个精简版的 Pathom(知名 Clojure 图查询库),只实现了 Pathom 功能的一个子集,目标是更易于理解和上手。核心思想是将「想要什么」与「如何获取」分离——调用方只需声明需求,引擎自动解析依赖并高效获取数据。它还具有中间键缓存机制:在不同解析器中复用中间计算结果,避免重复计算。开发者 jacobobryant 仅用少量代码就实现了这一迷你 Pathom,代码组织更清晰。有人认为图查询范式是一种全新的编程思维方式;也有人觉得它过于抽象、增加理解成本。

评论精华

  • Biff.graph 本质上是 Pathom 的轻量实现,resolver 声明更简洁,但功能相近
  • 图查询范式是一种全新的编程思路,能让人重新审视代码组织方式
  • 图查询的核心价值在于中间键不被重复计算——调用方只需关注需求而非获取过程
  • 有开发者认为 Pathom 等图查询库过于抽象,理解成本高,实际使用体验复杂
  • 作者正在探索能否将类似思路移植到 Python,改善 ORM 对象传递的体验
No.24 A Erlang style pure Scheme Webserver and further
纯 Scheme Web 服务器 Igropyr:Erlang 风格的进程监督与热替换
58 分 6 条评论 作者: guenchi
Igropyr 是一个完全使用纯 Scheme(基于 Chez Scheme)编写的 Web 服务器框架。其核心设计借鉴 Erlang/OTP 的「Let It Crash」哲学:每个请求在监督工作池中运行,处理器崩溃后由监督者自动重启;stuck-ms 超时机制则快速杀死卡死的工作者并返回结构化错误而非 500。该框架支持在运行时热替换路由或处理器——监听器、现有连接和请求池保持运行。独特的对话模型允许用绿色进程处理多步骤业务流程(如预订向导),进程暂停时携带数据库事务状态,进程死亡则保证事务回滚(响应 gone)。与 Goeteia Scheme 编译器配合时可实现端到端的 s-expression RPC,大整数和精确有理数完整传输无损失。完全使用 R6RS 库,不依赖 C 代码,通过 FFI 直接调用 libuv、zlib 等。性能测试中 ab -n 50000 -c 500 零失败请求。社区评价分化:有声音认为这是有实质的工程项目,也有人批评网页文案缺乏原创思考。

评论精华

  • 评论者感慨项目 LLM 时代前的历史积累似乎被完全抹去
  • 有评论者总结项目特色:Let It Crash、热代码替换、远程重试环、continuation Web 编程、s-expression RPC
  • 指出 Swish 同样基于 Chez Scheme 实现类似设计,已存在约 10 年
  • 批评者认为又是一个空洞的 vibe-coded 项目,网页文案缺乏原创性
  • 另一评论者引用但丁名句回应负面评价,暗示不必在意
No.25 Optimization Solver as a Service
优化求解器即服务
34 分 27 条评论 作者: paddi91
Quicopt 是一个云端优化求解器服务,支持 LP、QP、MILP、MINLP、QUBO 等多种问题类型。用户可用 OR-Tools MathOpt 或 Pyomo 标准 Python 前端建模,调用 client.solve() 即可在云端求解,无需注册账号或管理 API key(首次调用自动创建)。服务提供免费层用于尝鲜体验。目前支持的问题类型有运行示例,非线性模型暂不支持整数变量(除二元变量外),黑盒目标函数即将推出。社区评论质疑较多:与 NEOS(免费托管 CPLEX/Gurobi)或 Timefold 等现有平台相比,Quicopt 未公布基准测试数据,实际求解能力存疑;有用户指出其仅是开源求解器的包装层,缺乏自研核心竞争力;也有观点认为对于百万级变量的大规模 MIP 问题,仍需本地部署以支持列生成等自定义算法。

评论精华

  • NEOS 可免费托管 CPLEX/Gurobi 等商业求解器,比 Quicopt 更快且集成 Pyomo
  • 缺乏基准测试数据,仅展示 3 个精选案例,Timefold 等平台已支持百万级调度问题
  • 质疑仅是 OR-Tools 的包装层,未公布硬件配置和求解器版本
  • 大规模 MIP 需本地部署以支持列生成等自定义算法,云服务难以满足
  • Timefold 等平台已商业化运营,Quicopt 需明确差异化价值
No.26 Show HN: Learn by rebuilding Redis, Git, a database from scratch
展示: 从零构建 Redis、Git、数据库——80+免费实践课程平台
159 分 43 条评论 作者: acley
shipthatcode.com 是一个通过从零构建真实系统来学习的免费编程教育平台,提供 Redis、Git、数据库、操作系统内核等 80+ 课程,涵盖 Python、Go、Rust 等 9 种语言。平台核心理念是「选择→编写→运行」的刻意练习,摒弃传统教程的复制粘贴模式,让学习者直接面对真实规格说明。创始人自称受线下教学经验启发,希望改变「只知其然不知其所以然」的行业现状。社区反馈显示注册环节存在 rate limit 故障,测试依赖云端服务器(需约 20GB 内存),引发隐私和长期运营疑虑;另有用户质疑内容是否抄袭《Building Git》等已有著作,平台真实性有待验证。

评论精华

  • 被指与 CodeCrafters 类似,但后者收费,有用户质疑平台是 AI 生成还是人工构建
  • 注册环节频繁出现 rate limit 错误,疑似机器人攻击导致部分功能被临时关闭
  • 创始人澄清测试需在云端服务器运行(需 20GB 内存),无法本地执行
  • 内容原创性受质疑,有评论提及《Building Git》《Writing a C Compiler》等类似资源
  • 有人建议去掉「bro」等称呼,认为显得攻击性强,建议改善沟通风格
No.27 A dock that wakes up reliably
换了显示器后,Thunderbolt dock 唤醒问题竟然好了
66 分 42 条评论 作者: ingve
作者 Fabien Sanglard 分享了一个困扰他多年的硬件问题:笔记本通过 Thunderbolt dock 无法可靠地从睡眠中唤醒。他先后使用 CalDigit TS3 和 TS4,都偶尔失败。2020 年 Intel 宣称 Thunderbolt 4 将解决「PC connected to Thunderbolt dock 唤醒」问题,但实际体验仍不理想。直到 2025 年他更换了 ASUS ROG Swift PG27UCDM 显示器后,唤醒变得完美可靠,至今未再出现故障。他至今不确定根本原因——可能是旧 BenQ 显示器固件有 bug,或固件已更新。文章最后他分享了配置细节,供有类似困扰的人参考。

评论精华

  • 多人反映各类 dock(HP、Lenovo、OWC)唤醒问题普遍,不限于 Mac,Windows 也有
  • 有人指出 Thunderbolt/USB-C 协议已达电气极限,与同速率以太网设备相比成本高昂
  • 固件更新是关键——老旧 dock 型号花费 20 美元更新固件后可正常工作
  • 部分评论者认为是 Apple 软件问题:Dell 显示器可靠唤醒 Windows 主机,但 Mac 唤醒仍不稳定
  • 高端显示器(Samsung Odyssey Neo G9)内置 KVM 功能,可作为 dock 替代方案
No.28 How Doctors die. It’s not like the rest of us (2016)
医生如何面对死亡:为何他们选择「不治疗「
146 分 80 条评论 作者: downbad_
本文由退休医生Ken Murray撰写,揭示了一个悖论:医生在临终时接受的医疗干预远少于普通患者。文章以Charlie医生为例——他确诊胰腺癌后放弃手术,回家平静度过最后几个月。医生们清楚医学的边界:他们知道CPR正确操作会压断肋骨,ICU的「无效医疗」只会给垂死病人带来无法挽回的痛苦。他们害怕的是在恐惧和孤独中死去,而非生命本身。问题的根源在三方:患者家属面对生死抉择时往往回答「不惜一切代价」;医生因避免诉讼和收费模式压力而执行无效治疗;整个系统缺乏引导人们提前规划临终意愿的机制。作者主张,与其做无谓的挣扎,不如「平和地离去」(go gently)。

评论精华

  • CPR有效率取决于条件:立即施救+有AED时存活率明显更高,不应一概而论否定其价值
  • 预先指示文件(如DNR、POLST)至关重要,但即便如此,系统仍可能在紧急时刻忽略患者意愿
  • 临终姑息治疗中使用大量吗啡的真正意图引发伦理讨论,有人认为这与辅助死亡的边界模糊
  • 医患双方都在系统面前是受害者,过度治疗的根源包括诉讼风险和按服务收费模式
  • 文章发布于2011年,部分数据(如CPR成功率)已过时,需要结合当下医学进展重新审视
No.29 Why Write Code in 2026
为什么 2026 年还要写代码
41 分 25 条评论 作者: zdw
作者认为,尽管 AI 编程代理日益强大,人类仍应亲手写代码。其核心论点并非 AI 写代码比人类差,而是写代码能让人直接「思考」在执行环境中,而非通过英语作为中间层代理。写代码帮助人类保持对系统的注意力与理解力,体验代码的脆弱性,从而识别架构问题——如果人类难以在代码基础上构建不破坏任何东西,AI 代理同样会遇到困难。此外,英语是表达计算的高度不精确语言,真正的算法工作需要可执行步骤的精确校准。作者将 AI 代理比作「刚入职的实习生」而非编译器:它们会放大人类的偶发错误保守策略,若人类不参与其中,代码质量会逐渐崩塌。最终,软件工厂的细节决定成败,建筑模式、算法和性能都需要人类把关,但工厂的薄弱环节有时也需要人类亲自拆解装配线才能发现改进机会。

评论精华

  • 有人坚持纯手写代码,质量更高、可扩展性更强,且不必花时间 Review AI 生成内容
  • 部分观点认为 LLM 放大了系统思维者能力,调试过程本身也是一种参与感
  • 评论者指出写代码是避免代码库积累大量无用抽象层的关键,只有真正理解问题才能泛化
  • 有人认为 AI 代理过于保守,会将人类一时错误的决策用大量间接层包裹放大,反而增加复杂度
  • 存在相反观点认为 AI 已比自己写得好,且接手代码的下一个 AI 会持续改进,无需人类手写
No.30 Martha Lillard, last US polio patient using iron lung, dies at 78 in Oklahoma
美国最后一位铁肺使用者玛莎·利拉德去世,享年78岁
74 分 22 条评论 作者: daniel_iversen
玛莎·利拉德是美国最后一位使用铁肺的小儿麻痹症患者,于2025年6月26日在俄克拉荷马州去世,享年78岁。她5岁时确诊小儿麻痹症,被医生预言活不过20岁,但凭借顽强意志活到了78岁。她在铁肺中度过了大部分人生,颈部以下瘫痪,但通过康复训练恢复了左臂和双腿的部分功能。她曾就读于肖尼高中,通过校内通话系统与师生交流。她还曾开车旅行,并通过互联网在聊天室里认识了来自埃及的丈夫,两人通信20多年后于今年2月结婚。COVID-19大流行期间她两次感染,因原本肺功能不足25%,最后两年几乎全天候依赖铁肺。她的家人曾急切寻找能维修铁肺的技师,但随着她成为最后一位使用者,这个需求已不复存在。她生前撰写了自己的讣告,描述自己是一名动物保护志愿者。

评论精华

  • 她命运多舛:患小儿麻痹症后又两次感染新冠近期才结婚,接连不幸令人唏嘘
  • 人类确实能够有效终结疾病,小儿麻痹症疫苗的普及使美国在1979年宣布消灭该病
  • 口服脊髓灰质炎疫苗使用的活病毒可在低接种率社区传播和变异,存在根除难题
  • 有评论者提醒小儿麻痹症在2022年出现了多年来的首例病例,可能卷土重来
  • 她的乐观和创造力令人敬佩,即使瘫痪也能独自生活、创作诗歌歌曲并经营自己的 obituary