2026年06月16日 · 星期二 第 160101 期

The Hacker Daily

丙午年(马)五月初二

30 篇文章 · 3973 条评论 ·聚焦:AI编程工具 · 供应链攻击 · 云服务器涨价
No.01 The time the x86 emulator team found code so bad they fixed it during emulation
x86模拟器团队发现烂代码:编译器展开64KB循环成256KB
177 分 46 条评论 作者: paulmooreparks
本文讲述微软x86-32模拟器团队的一个趣事。他们在开发Windows内置的处理器模拟器时(通过二进制翻译将x86-32代码转换为原生代码运行,类似JIT编译器),发现某个程序需要分配并初始化约64KB栈内存。标准做法是循环初始化,但编译器将循环完全展开,生成了65536条「写字节到内存」指令,每条4字节,总共用了256KB代码来初始化64KB数据。这种「优化」激怒了团队,于是他们在翻译器中添加了特殊检测逻辑,一旦发现这种函数就自动替换为等效的紧凑循环。评论中提及,类似的故事也发生在Transmeta的翻译器上,以及GPU驱动对特定游戏的特殊优化,暗示这类「用代码膨胀换取性能」的问题在业界并不罕见。

评论精华

  • Transmeta工程师曾透露他们的翻译器充满针对微软Windows本身各种问题的特殊优化
  • GPU驱动包也包含大量针对劣质游戏引擎编码的兼容性修复,类似模拟器的做法
  • SimCity曾有读后释放bug,微软直接在Windows 95中修补而非让Maxis修复游戏
  • 评论者猜测Alpha可能是这个模拟器故事涉及的原生机型,支持最好
  • 浏览器引擎也会针对特定网站做类似优化,类似GPU驱动的游戏特殊优化模式
No.02 John Carmack on Fabrice Bellard
Carmack 盛赞 Fabrice Bellard:写了支撑互联网运行的代码,却鲜为人知
158 分 86 条评论 作者: apitman
John Carmack 发推谈论 Fabrice Bellard,称这位法国工程师「30 年来默默编写支撑整个互联网运行的软件」,并坦诚表示「他几乎可以确定是比我更好的程序员」。Bellard 是 FFmpeg、QEMU、JSLinux 等多个关键开源项目的作者,其代码被全球互联网基础设施广泛采用。评论揭示了一个有趣现象:许多技术从业者竟从未听说过这个名字。有用户将 Fabrice 比作「莫扎特」——在代码领域达到常人难以企及的高度;也有声音指出 Carmack 的「qualified」说法显得过于谦虚,他完全可以直言「某人比我更强」。关于「互联网运行在他代码上」的说法引发了一些技术层面讨论,有人指出 QEMU 与 KVM 的关系描述不准确。值得注意的是,Bellard 从未刻意隐藏身份,只是从不自我炒作,长期默默专注创新。

评论精华

  • Fabrice Bellard 并非隐姓埋名,而是从不主动营销自己,很多技术圈老人其实知道他
  • 很多人对「互联网运行在他代码上」的说法提出质疑,认为表述过于夸张且不准确
  • 与 Satoshi Nakamoto 不同,Bellard 没有刻意隐藏身份,搜索就能找到他的照片和信息
  • 欧洲工程师同样能在技术领域做出卓越贡献,无需去硅谷也能改变世界
  • Carmack 用「better overall programmer」是高度赞誉,以他的地位承认他人更强极为罕见
No.03 A backdoor in a LinkedIn job offer
LinkedIn 招聘消息中的代码后门:一次真实的供应链攻击剖析
1061 分 198 条评论 作者: lwhsiao
作者收到 LinkedIn 上加密货币初创公司招聘消息,被要求审查一个 GitHub 代码库。出于警惕,作者在隔离的 Hetzner VPS 上启动只读 AI agent 进行检查。agent 迅速在「app/test/index.js」中发现后门——该文件伪装成测试套件,实则在 `npm install` 时自动执行,向远程服务器「https://rest-icon-handler.store/icons/77」发送任意代码并在本地执行。攻击者盗用了真实开发者身份,且招聘方的「记者」人设也是捏造的。作者已将恶意 repo 报告给 GitHub、招聘者报告给 LinkedIn,但代码至今仍在线。评论指出此类攻击由朝鲜 APT 组织(Lazarus/Famous Chollima)主导,专门瞄准绝望的求职者,呼吁永远不要在本地运行未知代码库,建议善用隔离环境与只读 agent 审查代码。

评论精华

  • 此类攻击在加密行业几乎每天发生,攻击者拥有完善的人物档案和可信的 LinkedIn 资料,主要针对绝望的求职者。
  • 攻击者可能隶属朝鲜 Lazarus Group(又称 Famous Chollima),已在开发者社区活跃多年,甚至利用 IDE 插件注入恶意代码。
  • GitHub 和 LinkedIn 对举报响应迟缓,恶意代码库至今仍在线,平台安全机制形同虚设。
  • 求职时遇任何要求运行「npm install」的情况都应立即警惕——这已成为标准攻击路径。
  • 作者使用只读 AI agent 审查代码效率极高,伪装成新手代码的后门被瞬间识破,值得推广。
No.04 Understanding the rationale behind a rule when trying to circumvent it
当试图规避规则时:理解规则背后的原理
6 分 0 条评论 作者: tosh
本文通过 Windows 驱动程序的回调函数最佳实践,阐述了一个核心问题:遵循规则而不理解规则背后的原因,反而会适得其反。文档要求回调函数必须快速执行、不能阻塞——不能做注册表调用、不能做 IPC 调用、不能与其他线程同步。企业支持团队发现常见的系统挂起原因是驱动遵循了规则的字面意思:将工作排队到系统工作线程,但却阻塞等待工作完成。这种做法钻了「没有规定不能等待」的漏洞,但实际上「不同步其他线程」和「不做阻塞调用」已经明确禁止了这种行为。作者将此比喻为「不是我自己开电视,是让我兄弟开的」——技术上没有直接违反规则,但实质上规避了规则的精神。文档后来专门更新了这一条:使用系统工作线程时不要等待其完成。
No.05 Banned Book Library in a Wi-Fi Smart Light Bulb
将Wi-Fi智能灯泡改装成禁书图书馆
344 分 175 条评论 作者: sohkamyung
作者将一款预装Tasmota固件的ESP32C3 Wi-Fi智能灯泡拆解并改装,在灯泡内置的4MB闪存中搭建了一个微型Web服务器,可向周边Wi-Fi设备提供禁书下载。灵感源自Ben Brown的短篇《Library》以及Cory Doctorow的《Unauthorized Bread》,旨在用「数字死投」方式突破信息审查——把书藏在普通灯泡里,插上灯座就能让路人在半径内通过Wi-Fi匿名获取内容。技术细节包括:通过串口刷入定制Tasmota固件、将LED驱动GPIO引脚映射到色彩控制等。核心瓶颈是4MB空间过于局促,作者尝试外接microSD卡扩展存储但因PCB灌封处理难以操作,最终只能放入少量文本书籍。社区对此项目的隐蔽性、存储扩展方案(ESP32-S3、Meshtastic mesh网络)以及「禁书」定义本身展开热议。

评论精华

  • PirateBox等项目早已有类似「离线Wi-Fi分享」实践,本文是灯泡形态的延续
  • 安卓系统会自动断开无互联网的Wi-Fi,需伪装成Captive Portal才能保持连接
  • 4MB空间过于有限,有网友建议换用带microSD卡槽的ESP32-S3模块(7美元)
  • 有人担忧「禁书」叫法失实——美国禁书主要限校园,并非真正禁书
  • Mesh网络(如Meshtastic)可扩大覆盖范围,但LoRa带宽仅能传几十KB,不适合传完整电子书
No.06 Iroh 1.0
Iroh 1.0:用密钥寻址替代 IP 的 P2P 网络库正式发布
1131 分 342 条评论 作者: chadfowler
Iroh 1.0 正式发布,这是一个基于「密钥即地址」理念的新型网络协议实现。核心思想是:用加密密钥取代不稳定的 IP 地址作为网络寻址方式——密钥由用户创建控制,随设备迁移保持一致,且能穿透防火墙实现安全直连。项目历经 65 个版本迭代,已用于视频流、LLM 训练、代理通信、安全聊天、游戏、文件传输等场景,过去 30 天公共中继处理超 2 亿次连接建立。技术亮点包括:自研 QUIC 多路径实现、NAT 穿透(连接细节加密)、完整的本地优先配置(无需互联网)、WASM 浏览器支持、可插拔自定义传输(BLE、LoRa、WiFi Aware、Tor)。1.0 版本同步支持 Python、Node.js、Swift、Kotlin 多语言 SDK,宣称 Wire 协议与语言 API 互相独立演进。社区质疑主要集中在:与 Tailscale/Yggdrasil/ZeroTier 的差异化、密钥泄露风险、商业与开源边界、审查规避能力等问题。

评论精华

  • 开发者将其比作「应用层版 Tailscale」,两者均实现 NAT 穿透,但 Tailscale 工作在网络层而 Iroh 在应用层
  • 关于 CGNAT 环境下是否仍需第三方中继的问题,官方尚未给出明确答复
  • 密钥轮换/泄露处理机制不明确,有用户建议构建冷热密钥系统
  • 与 Yggdrasil、NetBird、ZeroTier 等去中心化网络方案功能高度重叠,文档缺乏横向对比
  • LLM Studio 移动端已集成 Tailscale,有观点认为 Iroh 是理想的开源替代方案
No.07 Show HN: Garden of Flowers – an archive of pictorial typography before ASCII art
展示: 花之花园 — ASCII 艺术之前的图像排版档案库
58 分 11 条评论 作者: california-og
「花之花园」是一个收集了 2497 张图文排版作品的在线档案库,涵盖 ASCII 艺术出现之前的各种图像印刷体形式。网站提供丰富的筛选维度,包括年代、地点、人物、主题、字体风格、技术手段、类型、脚本、时间段、出版物和公司等分类字段,方便研究者追溯图形文字的历史脉络。这一类作品被称为「pictorial typography」——即以视觉图像形式呈现文字的排版传统,早于现代 ASCII 艺术。

评论精华

  • 用户呼吁开放整个存档的本地下载或镜像,提议通过 torrent 方式分发
  • 有用户称几个月前纹了一个网站上的花卉图案,被比作太阳或刺猬
  • 评论者建议补充阿拉伯书法艺术,其中可兰经诗文等文字视觉化形式与该档案主题相关
  • 其他用户推荐了《Fun with your typewriter》和《Artyping》两本相关书籍
  • 创建者解释不得不排除所有书法形式的文字艺术(书法体、显微画、诗形图等)
No.08 Ask HN: Has anyone replaced Claude/GPT with a local model for daily coding?
问 HN:有人用本地模型替代 Claude/GPT 做日常编程吗?
922 分 419 条评论 作者: cloudking
本文是 Hacker News 上一则关于「本地运行的大模型是否能替代云端 Claude/GPT 用于日常编程」的讨论。答案是:很多人已经做到了,但有代价。大多数人推荐 Qwen3.6(27B 或 35B 量化版)配合 OpenCode 或 Pi 编程助手 harness,在单张 RTX 3090/4090 或 Mac Studio(128GB RAM)上可跑到 20-80 tok/s。质量约等于八到十二个月前的云端前沿模型,对简单任务足够用,但复杂项目仍有差距。隐私、摆脱订阅费用是主要动机。障碍包括硬件成本高(高端 GPU 或大内存机器价格不菲)、上下文窗口限制、以及 harness 工具链的体验不如官方 IDE 插件流畅。也有人采用折中方案:用 DeepSeek V4 Flash 通过 API 接入,质量约 95% 但成本仅 5%。

评论精华

  • Qwen3.6-35B-A3B 是最流行的本地编程模型,配合 OpenCode/Pi harness 在单卡 RTX 3090 上即可跑出可用的生成速度
  • 质量约等于一年前的云端前沿模型,对日常简单任务足够,但复杂项目仍不及 Claude/Codex
  • 隐私和取消订阅是主要动力,有人因伦理顾虑拒绝 OpenAI/Anthropic,本地开源模型解决了这一问题
  • 硬件门槛仍是最大障碍:需要高端 GPU(至少 24GB 显存)或大容量内存 Mac/PC,不是所有人负担得起
  • DeepSeek V4 Flash 通过 API 调用是折中方案,质量接近顶级模型但成本极低,也有人用它补充本地模型
No.09 TinyWind: A pixel pirate sailing game with real wind physics (380k+ kms sailed)
TinyWind:像素风海盗帆船游戏,真实风力物理系统
783 分 152 条评论 作者: tinywind
TinyWind 是一款基于浏览器的像素风海盗帆船游戏,主打「真实风力物理」系统,已累计航行超过 38 万公里。游戏有两种模式可免费体验,目前约有 245 位活跃玩家在线。核心玩法是控制帆船利用风向航行、与其他船只战斗。社区评价普遍积极:画面可爱、移动端运行流畅、执行质量高,让人想起《海盗旗》和《刺客信条:黑旗》。但多位真实帆船玩家指出物理不够真实:顺风时帆应与风向对齐而非垂直、迎风航行速度应降至零或负值、有玩家建议加入舵轮只能在有速度时转向的限制。改进建议集中在:风方向指示器更大更醒目、鼠标滚轮调整帆角度、炮击冷却时间延长、以及更清晰的单人或多人模式标识。技术层面使用 Canvas/JavaScript 开发,加载速度极快。

评论精华

  • 帆船玩家实测指出风力物理不真实:帆应与风向对齐加速而非垂直、迎风航行速度应降至零,开发者承认模拟较简单。
  • 移动端控制布局问题:舵和帆调节按钮都在右侧,无法双手同时操作,建议分置屏幕两侧。
  • 风向指示不够清晰,有玩家建议设置桅杆大旗帜显示当前风向,或将风向标做得更大更居中。
  • 多人模式不明,有玩家询问是与真人还是机器人对战;技术层用 Canvas/JS 开发,加载极快,适合做 RL 环境。
  • 治疗机制不清晰,血量和回血条件没有明确 UI 提示;炮击冷却时间建议加长,炮火方向也应优化。
No.10 I hacked into the worst e-bike and fixed it [video]
我黑进了最垃圾的电动自行车并修好了它
71 分 28 条评论 作者: alexis-d
YouTube 频道主 Seth 拿到了一辆问题重重的电动自行车(疑为 Cowboy 品牌),通过黑客手段破解其限制并修复了问题。视频中他借助 Claude 等 AI 工具完成编程和调试工作,引发社区热议。有人批评他让 AI 干完了所有有趣的工作,自己不会写代码只能「vibe coding」;但也有观众认为他只是用 AI 作为辅助工具加速开发流程,算不上偷懒。评论区还延伸到 YouTube 算法偏好老视频、摄影频道推荐等话题,以及 AI 辅助创作与「真才实学」之间的边界讨论。

评论精华

  • CowBoy 电动自行车后期维护困难,不建议购买使用定制零件的车型,出了问题基本报废。
  • Seth 使用 Claude 等 AI 工具完成编程工作是合理的工作流,但有人认为他把有趣的工作外包给了 AI。
  • 评论区对 YouTube 算法频繁推荐老视频不满,认为是算法「尾随狗」而非观众主动选择。
  • 有观众指出该频道近年来部分视频脚本明显由 AI 朗读,写作风格受 AI 影响明显,但本人不认为这有问题。
  • 用 AI 工具加速开发与「不劳而获」的边界模糊,社区对此存在较大分歧。
No.11 I Love the Computer
我爱计算机
215 分 129 条评论 作者: speckx
作者讲述自己从六、七岁起在动荡生活中爱上计算机的个人史。搬家至马来西亚、哥伦比亚等地的成长经历中,父亲去世后家庭贫困、频繁迁移,计算机成了他罕见的稳定港湾。他通过杂志(TEKNO、PC Gaming 等)自学硬件知识,在前互联网时代构建起「极客」身份。第一次编程尝试失败(把代码保存为 .exe 而非编译),后来才在学校习得 Java。文章呼吁回归对计算机本身的纯粹热爱,批评当前 AI 炒作周期中的「蛇油销售者」用贪婪毁掉了他珍视的领域,呼应 Podcast 嘉宾 Chris Person 的「我爱计算机」。

评论精华

  • 喜欢计算机本身,但热爱周围产业现状是难点;FAANG 工作经历让许多人丧失初心
  • AI 并非蛇油——它确实实现了大部分宣传功能,问题在于过度承诺
  • 「蛇油」指的是无有效成分的假药,暗示 AI 毫无用处并不准确
  • 怀旧情绪有年龄因素,我们倾向于浪漫化当年折腾硬件的痛苦经历
  • 个人电脑曾赋予用户真正的自主权,如今多层产品增长逻辑让机器变得不有趣
No.12 Amazon Announces Multibillion-Dollar Data Center in Missouri
亚马逊宣布在密苏里州投资数十亿美元建设数据中心
104 分 88 条评论 作者: thelonelyborg
亚马逊云服务(AWS)宣布在密苏里州蒙哥马利县建设一个价值数十亿美元的数据中心园区,预计创造400多个全职岗位和数千个建筑岗位,支持云计算和AI工作负载。亚马逊在密苏里已雇有逾万人。新项目强调能源与环保:与当地公用事业公司达成协议确保成本不转嫁给他人,并投资138兆瓦碳中和能源项目;用水方面90%时间采用自然冷却,雨水收集覆盖20%年需水量,水资源循环利用可达6次,预计用水量不超过当地含水层年补给量的0.1%。亚马逊承诺投入逾700万美元社区资金,包括300万美元用于公共安全、100万美元建社区活动中心等。评论聚焦几个议题:数据中心岗位究竟做什么(faq常见技术运维而非软件开发);138兆瓦是投资的可再生能源项目容量,并非数据中心实际用电量;以及AI是否真的在推动科研还是主要服务于削减就业机会。

评论精华

  • 数据中心运维岗位主要是硬件安装维护、现场支持等,实际并不需要大量软件工程师
  • 138兆瓦碳中和项目指的是亚马逊对该能源项目的投资额,而非数据中心的实际耗电量
  • 评论者对亚马逊承诺不将成本转嫁纳税人的说法表示怀疑,认为具体执行难以核查
  • AI热潮下数据中心大量建设是否真的用于造福人类,还是主要服务于裁员和企业利润,存在广泛争议
  • 选址可能与附近的卡勒威核电站及 Ameren 的太阳能项目有关,该地点距圣路易斯约80英里
No.13 Humanity isn't ready for the coming intelligence explosion
人类尚未准备好迎接即将到来的智能爆发
71 分 178 条评论 作者: andsoitis
本文讨论AI技术快速发展带来的存在性风险,警告人类未做好应对超级智能的准备。文章援引AI专家估计,AI导致灾难性事件的概率达10至50%;并提及「递归自我改进」(RSI)可能使AI在短期内超越人类智能,接近「奇点」。作者还引用费米悖论——若智能如此易涌现,为何未见外星文明——暗示人类或许正走向自我毁灭的岔路口。评论者对文章提出多处质疑:AI专家的预测近年频繁失准、可再生能源与关键材料仍由人类掌控、训练数据瓶颈会限制RSI发展;亦有人指出AI公司有动机夸大风险以获取监管特权;更常见的观点是,人类历史上多次经历技术颠覆,最终都成功适应,当下的焦虑不过是新瓶装旧酒。

评论精华

  • 专家预测屡次失准,AI导致灾难的概率估算缺乏依据,被批为「科幻写作」
  • 能源和关键材料仍在人类掌控中,AI快速转向超级智能的假设过于激进
  • 递归自我改进的核心瓶颈是训练数据获取,而非算法本身,该论点缺乏技术支撑
  • AI公司夸大风险以争取监管权力和资源集中,利益冲突显而易见
  • 人类适应能力被低估,历史上技术变革均以出人意料的方式被消化吸收
No.14 Why I email complete strangers
为什么我要给陌生人发邮件
138 分 60 条评论 作者: karakoram
作者分享了克服「自我否定」心理、主动给陌生人发邮件的经历与心得。Email 作为诞生于 1971 年的通讯工具,遵循林迪效应——越持久的事物越可能继续存在,其「持久性」与「可迁移性」是社交平台无法比拟的优势:用户对邮箱拥有完全控制权,可自主选择何时阅读与回复,这种「人类节奏」而非「即时响应」的沟通方式,让对话得以深化而非碎片化。作者列出具体原则:先浏览对方作品找到共同点、提问要具体、保持简洁但不生硬、避免商业诉求、给邮件一个吸引人的主题行等。核心观点是:给陌生人发邮件并非骚扰,而是互联网早期「人类之间真诚连接」的遗存——收件人沉默不代表你毫无价值,可能只是时机不对。

评论精华

  • 最低风险的尝试是给博主发简短感谢信,说明你读了某篇文章且有所收获,真诚比信息量更重要
  • 许多人把「邮箱公开」视为一种隐性许可,但 GDPR 上线后通过 WHOIS 查找邮箱变得困难,削弱了这种开放性
  • 收到陌生人的优质邮件会让收件人一整天心情愉快,但人们普遍担心邮件会被商业化利用或 AI 批量生成
  • cold email 被忽视的主要原因仍是垃圾过滤,即便内容有价值也可能被拦截;相比之下 GitHub Issues 等平台更可靠
  • 有创作者指出,陌生人偶尔的真诚赞美与批评(如「拼写太差」)远胜于社交媒体上的算法反馈,是真正的人际连接
No.15 Cohere's First Model for Developers
Cohere 发布首款开发者开源编程模型 North Mini Code:30B MoE 小身材大能量
75 分 17 条评论 作者: hmokiguess
Cohere 发布首款面向开发者的开源编程模型 North Mini Code,这是一款混合专家(MoE)架构的代码模型,总参数 30B、活跃参数仅 3B,在编程基准测试中达到 Artificial Analysis Coding Index 33.4 分。官方数据显示其吞吐量比 Devstral Small 2 高出 2.8 倍,Token 延迟降低 30%。该模型以 Apache 2.0 许可开源,可从 Hugging Face 或 Cohere Model Vault 免费获取,旨在为开发者提供不受供应商约束的主权 AI 编程能力,支持本地或私有化部署。评论社区反应两极:一派看好竞争加剧和小模型效率优势;另一派则质疑 Cohere 的市场地位,甚至有人指出其背后有加拿大政府输血维持生存。

评论精华

  • 硬件门槛较高(需 H100)引发成本担忧,有用户指出一台 H100 运行成本不低
  • 有用户怀念 Cohere 早前的 Command A 模型,认为更多竞争对行业有益
  • 批评者认为 Cohere 战略是「用平庸产品免费换市场」
  • 知情人士透露加拿大政府正大力扶持 Cohere 作为本土前沿实验室
  • 有用户指出 MoE 模型因激活参数少,支持 CPU 内存卸载,硬件要求可大幅降低
No.16 My Homelab AI Dev Platform
我在家庭实验室搭建的AI开发平台
299 分 52 条评论 作者: rsgm
作者分享了在家庭实验室(homelab)中搭建AI开发平台的实践。他使用OpenCode(开源AI编码工具)配合GitOps工作流:AI在独立VM中编写代码并推送到特性分支,作者审核PR后合并,再由Arcane GitOps自动部署docker compose服务。该方案解决了手动更新容器的繁琐——过去花几小时查阅更新日志,现在AI可快速摘要并识别Breaking Changes。作者将所有服务迁移到Arcane GitOps实现Git版本管理,并通过专用SSH密钥限制AI的写入权限(禁止直推主分支),确保安全。虽然没有CI日志反馈(Forgejo Actions不暴露公开API),但整体实现了跨设备维护家庭基础设施的便捷工作流。

评论精华

  • 多位开发者采用类似方案:用Forgejo/Gitea配合AI agent工作流,有的通过Argo Workflows编排任务链
  • 关于本地vs云端模型,作者表示本地模型在agentic工具使用场景尚不成熟,评论者则认为Qwen3.6等小模型表现不错
  • Forgejo Actions不暴露构建日志公开API是普遍痛点,作者转而使用tea CLI作为替代方案
  • 有用户提到rsgm.dev域名被Quad9 DNS封锁,疑似被列入恶意软件黑名单
  • 部分评论质疑该方案的实际价值——AI在配置场景容易引入调试难题,整体时间收益可能为负
No.17 Hetzner Price Adjustment
Hetzner 云服务器价格大幅上调,最高涨幅达 3 倍
415 分 564 条评论 作者: tuhtah
德国老牌云服务商 Hetzner 于 2026 年 6 月 15 日起对云服务器实施大幅涨价,新订单和升级实例均受影响,涨幅最高达 3 倍。例如 CPX11 从 6 美元涨至更高价位,CCX13 从 16 欧元涨至 43 欧元,入门级 VPS 从 6.99 美元涨至 20.49 美元。Hetzner 此前以「低价高配」著称,此次涨价前已有多次小幅调价。评论普遍认为涨幅过于激进,有用户指出这与其「便宜提供商」的独特定位相悖,可能导致客户流向竞争对手如 UpCloud、Linode 等。涨价原因可能与 AI 驱动下 RAM、磁盘等硬件短缺有关,但社区质疑为何其他厂商未出现同等幅度的上涨。

评论精华

  • 价格涨幅高达 3 倍不可理喻,RAM 和磁盘短缺推高硬件成本是主因,但其他厂商未见同等涨幅
  • Hetzner 的核心竞争力就是低价,涨价后其独特价值主张基本消失,用户考虑转向 UpCloud、Netcup 等替代品
  • 老用户已有机型(如 AX41-NVMe)不受影响,但新订单和升级实例必须执行新价格
  • 部分用户指出美国和新加坡节点涨幅远超欧洲(2-3 倍 vs 约 30%),地区差异显著
  • 有用户借机转向 Cloudflare 等 serverless 方案,或通过拍卖获取价格较低的老旧机型
No.18 Peopleless economy? Not technically impossible
无人民经济:技术上来说并非不可能
169 分 289 条评论 作者: l0new0lf-G
文章探讨了在AI和自动化极致发展后,经济是否可能摆脱人类参与。作者指出「经济」本质上是一个抽象概念,一旦机器能够完成人类能做的一切,人类中心主义的经济学概念将变得毫无意义。核心论点是:如果AI拥有者之间可以自行交易、机器人可以自我复制和维修,理论上人类可能被完全排除在经济循环之外。文章还提到,当有产阶层拥有能服务他们的智能机器时,经济崩溃对他们几乎没有影响。不过评论区争议激烈:有人批评这是「最大的if」假设;有人认为这是经济谬误,人类可以通过互相交易生存;也有人担忧这会加剧资本集中、导致权力失衡;还有人指出经济并非零和游戏,AI发展也可能带来新的合作模式。

评论精华

  • 劳动贬值与资本增值:评论者指出AI的真正影响可能是让劳动贬值、资本增值,政府运行需要现金流,权力将不可避免地向AI所有者集中
  • 经济零和谬误:有评论者反对「少数人获益多数人受损」的观点,认为经济并非零和游戏,有人富起来不必然意味着其他人变穷
  • 科幻场景的现实性:有评论者将此比作《沙丘》的机器人禁令或Charles Stross的科幻小说,认为这个场景虽然可怕但似乎正在成真
  • 经济学视角批评:有评论者指出文章存在基本经济学误解,忽视了Labor/Capital动态的历史演变和美国冷战时期经济学界左翼被清洗的背景
  • 假设过强:有评论者直指文章开头要人审视假设、勿做逻辑跳跃,自己却做出「政府有能力」等重大假设,批评其自相矛盾
No.19 The 90-year-old idea behind JEPA models: Canonical Correlation Analysis
JEPA 模型背后90年前的idea:Canonical Correlation Analysis
47 分 7 条评论 作者: Anon84
文章探讨了 Canonical Correlation Analysis(CCA)与 JEPA 模型的渊源。1936年统计学家 Harold Hotelling 在论文「Relations Between Two Sets of Variates」中提出 CCA,用于在两个大数据矩阵间寻找共同信号。JEPA 的目标与此相同,只是第二个数据矩阵是同一数据的不同视图(如数据增强或时空邻近视图)。文章指出 JEPA 隐含地执行了 CCA 的非线性推广,核心目标函数都是「找到使多维数据集合之间相关性最大化的变换」。关于 Schmidhuber 与 LeCun 的 JEPA 发明权之争,作者认为 Hotelling 应得最大化嵌入相关性这一 idea 的荣誉,而 JEPA/Predictability Maximization 是在 CCA 基础上叠加的非线性架构增强。SIGReg 通过强制嵌入服从各向同性高斯分布来解决表征崩溃问题。

评论精华

  • leecommamichael:这些 AI 背后的理论早于我们的认知,想象这些模型与 GPU 同时代出现会很有趣
  • hodgehog11:不知道 CCA 的人不应该从事无监督学习研究,应该让 JEPA 用户了解 CCA
  • jdw64:想在这一领域(LLM)做点东西,询问入门书籍推荐
  • hodgehog11:入门书籍推荐有限,询问是想做研究创新还是仅应用现有方法
  • 评论主要围绕理论渊源追溯和入门路径讨论,整体质量较高
No.20 Fox to buy Roku
福克斯收购 Roku:媒体整合引发用户逃离潮
316 分 390 条评论 作者: thm
福克斯宣布以约 220 亿美元收购流媒体设备厂商 Roku,这一消息在技术社区引发广泛担忧。评论者普遍认为此举将进一步加剧媒体产业整合,缺乏竞争的最终受害者是消费者。Roku 占据美国 30-50% 的家庭电视硬件市场,反垄断监管形同虚设。用户最核心的焦虑在于:福克斯将获得所有 Roku 用户的完整观看历史数据,结合其新闻业务将形成前所未有的舆论影响力。有用户直接指出这是「鲍威尔备忘录 (1971) 的升级」——企业巨头系统性收购社会核心媒体功能。部分用户宣布将迁移至 Apple TV 或 Google TV,也有人怀念 Roku 曾经简洁中立的平台体验,认为它已从流媒体工具沦为空壳。

评论精华

  • 反垄断缺失:若美国有有效的反垄断执法,这笔交易根本不会获批,媒体整合已失控
  • 隐私噩梦:Fox 现在拥有所有 Roku 用户的观看历史,数据整合令人不安
  • 用户逃离潮:许多人计划迁移至 Google TV、Apple TV 或自建 Jellyfin 方案
  • 平台退化:Roku 已从开放平台沦为广告提供商,用户积累多年的信任正在流失
  • 怀念纯净体验:曾经的 Roku 界面简洁中立,如今被迫接受新条款才能继续使用
No.21 What job interviews taught me about Kubernetes
求职面试教会我关于 Kubernetes 的那些事
167 分 120 条评论 作者: chmaynard
作者在求职面试中发现,五年前还有三分天下(K8s采用者、VM+systemd、serverless),如今几乎所有公司都上了K8s,包括10人小团队。CTO们选择K8s的核心原因并非技术需求,而是三大组织红利:统一部署方式、标准化可移植知识库(知识在YAML而非某人脑中)、GitOps带来的可追溯性和合规优势。作者认为CTO们并非盲目跟风,而是在解决真实的组织管理问题;个人建议是团队有第二个人时就该考虑上K8s。关于K8s为何近几年才胜出,作者推测是托管K8s(EKS/GKE/AKS)成熟、人才池扩大、Helm生态成型共同作用。评论中有人认为是「简历++」吸引效应,有人指出LLM已大幅降低K8s学习门槛,也有人警告大公司全量K8s后复杂度失控的痛苦。

评论精华

  • 有人认为是「简历++」效应,K8s用于吸引人才而非实际需要,小团队过早引入是red flag
  • LLM让K8s门槛大幅降低,自动生成manifests已成免费午餐,有人用它部署k3s到自有硬件
  • 有深度评论指出K8s的核心价值是组织红利而非技术红利,本质是infra-as-code运动的体现
  • 有人吐槽YAML是糟糕的知识编码格式,CloudFormation/K8s/GitHub Actions都存在此问题
  • 质疑声音认为作者样本量有限,且忽视了K8s在中小企业失败的真实案例(如银行全K8s后问题重重)
No.22 Copper transport drug restores memory and clears toxic Alzheimer's proteins
莫纳什大学:铜转运药物恢复小鼠记忆并清除阿尔茨海默毒性蛋白
291 分 108 条评论 作者: bookofjoe
莫纳什大学研究发现,一种铜转运药物(CuATSM)在APP/PS1转基因小鼠模型中能恢复记忆并清除β-淀粉样蛋白斑块。该化合物此前已在其他疾病中进行过安全性评估,有望快速推进至人体试验。研究者称其机制并非直接靶向淀粉样蛋白,而是改善血脑屏障功能并恢复免疫系统正常运作。评论界对此反应两极:支持者认为任何可能有效的治疗都值得尝试;批评者则指出这是典型的「小鼠成功→人体失败」套路,淀粉样蛋白假说本身已受到广泛质疑,Derek Lowe等专家明确表示针对该通路的疗法并非阿尔茨海默病的答案。此外,有评论提及72mg以上剂量存在肝毒性风险,以及锂在类似老鼠模型中也有突出表现。

评论精华

  • 多数评论指出这是小鼠模型研究,尚未进入人体试验,且大学新闻稿刻意省略「小鼠」字样被批不负责任
  • 淀粉样蛋白假说备受质疑——Derek Lowe等专家已多次指出清除斑块并不能治愈人类阿尔茨海默病
  • 安全剂量存疑:72mg以上有肝毒性,此前该药仅用于低剂量治疗其他疾病
  • 有用户分享家人患早发性阿尔茨海默(50-60岁发病)的亲身经历,对任何新进展都抱有期待
  • 铜、锂等金属离子在神经退行性疾病中的作用值得关注,传统上也有使用铜容器存水的文化实践
No.23 What every coder should know about gamma (2016)
每个程序员都该了解的 gamma 知识
92 分 27 条评论 作者: sph
文章指出程序员对 gamma 校正普遍存在误解,包括:以为 RGB(128,128,128) 发出的光量是 RGB(255,255,255) 的一半;认为 LCD 时代可以忽略 gamma;以为图形库会自动正确处理等。文章解释人眼对光强度的感知呈幂律关系,而非线性。若用物理线性编码存储灰度图像,暗部精度浪费而亮部精度不足;gamma 编码则能将有限的灰度级均匀分配到人眼感知最敏感的暗部区域,这是 gamma 存在的核心价值。评论者指出文章存在一些重大错误,并提醒对于大多数图像处理场景,仅线性化 sRGB 只是半程方法,oklab 等现代色彩空间是更完整的选择。

评论精华

  • 有读者指出文章存在重大错误,质疑部分技术观点的准确性
  • minutephysics 对同一主题的解释被多人推荐,更清晰易懂
  • 对于图像处理,仅线性化 sRGB 只是半程,建议考虑 oklab、CIELab 等更优色彩空间
  • 抗锯齿等场景确实需要线性光强度模型,此时 gamma 校正反而是错误的
  • vektorsigma:很多视频色彩空间 YUV 的黑点不在 0 而在 16
No.24 Salesforce to Acquire Fin (formerly Intercom) for $3.6B
Salesforce 以 36 亿美元收购 Fin(前 Intercom),整合 AI 客服代理平台
302 分 221 条评论 作者: colesantiago
Salesforce 于 2026 年 6 月 15 日宣布以约 36 亿美元收购 AI 客服公司 Fin(原 Intercom)。Fin 的核心产品是自研模型 Apex 驱动的 AI Agent,可在聊天、邮件、WhatsApp、短信、电话、Slack 等全渠道独立完成复杂客诉,端到端自主解决率平均达 76%。Fin拥有超过 3 万家企业客户,其技术将补充 Salesforce 的 Agentforce 平台,为 SMB 及商业客户提供快速部署选项。交易预计在 FY2027 Q4 关闭,不影响此前公布的财务指引。评论社区反应两极:有用户认可 Fin 被收购是成功退出,但更多人质疑 AI 客服本质是「噱头」,担忧 Salesforce 会毁掉产品体验,并指出 Fin 自研模型的真实性质存疑(疑似底层仍用 OpenAI/Claude)。另有用户提及 Fin CEO Eoghan McCabe 曾卷入性骚扰指控却未受追责。

评论精华

  • 多用户反映 AI 客服体验糟糕,丢失订单,建议回归人工服务
  • 部分用户认为 36 亿美元估值偏低,质疑 Intercom 价值被低估
  • 大量评论担忧 Salesforce 会毁掉 Intercom/Fin,指责其收购 Heroku 后表现糟糕
  • 有用户指出 Fin 标榜自研 Apex 模型但实际底层可能仍是 OpenAI/Claude
  • 评论提及 Fin CEO 曾陷性骚扰指控却未受追责,对收购持批评态度
No.25 The Null Is Always False (Except When It Is True) (2014)
零假设永远为假(除非它为真)
5 分 0 条评论 作者: mkl95
本文讨论了频率学派统计中「零假设」的本质问题。Lakens 引用 Cohen 的观点指出:在现实世界中零假设几乎永远不成立——它只能在计算机模拟中为真,因此用足够大的样本几乎总能拒绝它。要发现极小的效应(如 Cohen's d = 0.001),需要至少 3100 万被试才能在 t 检验中观察到显著差异。他通过 Many Labs 项目 6344 人的数据演示:随机分配条件(高/低锚定)下,即使 6000 人也无一显著;而性别(个体差异变量)却对 10 个因变量中的 7 个产生显著影响。Meehl 将这种「万物皆相关」的现象称为「crud factor」。结论是:零假设检验对随机操纵变量有意义,但对相关性研究缺乏信息量——此时需要建立良好的理论模型而非简单检验均值差异。
No.26 Game Engine White Papers: Commander Keen
Commander Keen 游戏引擎白皮书:35年后的技术复盘
195 分 64 条评论 作者: mfiguiere
作者历经三年多完成了《Game Engine White Papers: Commander Keen》,一本214页全彩书籍,详细讲述1990年代初PC游戏开发技术(80286处理器、EGA显卡、声卡、键盘等硬件),涵盖游戏资产、引擎架构乃至CGA版本的实现,并提供免费PDF和纸质版,源码开源于GitHub。然而社区热议指出:书籍网站风格与知名技术作家Fabien Sanglard的Game Engine Black Books系列高度相似,包括排版、结构乃至LaTeX源码,引发「致敬还是抄袭」的争议;作者在前言中承认受Fabien启发,但有评论指出书中有大段内容直接复制自后者作品;HN管理员dang呼吁就事论事,无需质疑作者恶意;另有读者推荐Masters of Doom等类似读物,并讨论SNES与PC的硬件渲染差异。

评论精华

  • 社区质疑书籍与Fabien Sanglard的Game Engine Black Books高度相似,排版、结构甚至LaTeX源码均有复制之嫌
  • 作者在前言中承认受Fabien Sanglard启发而作,但评论指出内容存在大段直接复制
  • HN管理员呼吁理性讨论:在无恶意证据情况下,不宜以「抄袭」否定他人作品
  • 读者推荐Masters of Doom、Doom Guy等相关读物,及Cosmodoc等类似技术分析项目
  • 讨论SNES等主机硬件的精灵渲染效率优于PC的技术原因,及Commander Keen移植Steam等平台
No.27 How TimescaleDB compresses time-series data
TimescaleDB 时序数据压缩:Hypercore 引擎与列式存储实现最高 98% 压缩率
148 分 17 条评论 作者: lkanwoqwp
TimescaleDB 是 PostgreSQL 的时序数据扩展,能将典型时序数据压缩至原来的 2%(98% 压缩率)。其核心是 Hypercore 混合行-列式引擎:新数据以行格式写入以保证高速 INSERT/UPDATE,旧数据自动转换为压缩列式格式存储。压缩算法根据列类型自适应选择:对整数/时间戳使用 delta encoding + delta-of-delta + simple-8b + RLE;对浮点数使用 Gorilla XOR 算法;对 JSONB 优先字典压缩再 fallback 到 TOAST;对字符串使用字典压缩 + simple-8b + RLE 两阶段压缩。关键配置参数 segmentby(分批次依据,如 machine_id)和 orderby(批内排序,如 time DESC)直接影响压缩效果:segmentby 基数过高会导致每批行数不足(建议每 chunk 至少 100 行,最优 100-10000 个唯一值),delta/XOR 编码器需要相似值序列才能有效压缩。与 PostgreSQL 内置 TOAST 机制不同,TimescaleDB 优化的是跨行时序模式,两者互补而非竞争。

评论精华

  • 压缩对查询性能的影响是核心议题,数据库的根本目的是查找、聚合和更新数据
  • 有用户对「up to 98%」标题持批评态度,认为此类表述多为噱头
  • 评论反映 TimescaleDB 压缩部分使用非 Apache 许可证,部分发行版默认不启用
  • 社区讨论 TimescaleDB 与 AVEVA PI 系统 swinging-door 有损压缩的对比,认为现代压缩算法已可在有损转无损
  • ClickHouse 同样采用了 Gorilla 等压缩算法,文档较为完善
No.28 Reviews have become expensive, rewrites have become cheap
代码审查变贵了,重写变便宜了
58 分 46 条评论 作者: arzh2
作者观察到LLM写代码的默认行为是「过度工程化」——倾向于从头实现而非调用现成库,因为对模型而言写200行和写2行import的认知成本相同。这导致代码审查成本上升:审阅者需反复判断是否接受不必要的复杂性。而重写却变得便宜——发现问题后直接让LLM简化、用库替代或砍掉冗余功能,效果往往比反复在review中争论更好。作者据此调整工作流:前期投入更多时间规划(明确范围、选型),后期实现部署后再识别可简化之处并让LLM重写。其核心论点是:审查已是当前最贵的环节,放行复杂代码的代价不变,但要求迭代的成本已降低,因此应更积极地push back。不过评论区反驳激烈:许多人指出LLM并非「不偷懒」——disabled tests、race conditions、代码 precedents 自相矛盾等低级错误层出不穷;有评论认为重写也不会更好,问题的源头无法自我修复;还有观点将review与rewrite视为不可分割的整体,经济变化未必如作者所言显著。

评论精华

  • 多数评论反驳「LLM不lazy」——disabled tests、race condition、precedents自相矛盾等例子说明LLM会偷懒耍滑。
  • 有人认为重写不会更好:制造问题的模型本身未必是解决同一问题的最快途径。
  • 建议将review和rewrite视为一体,经济变化未必如作者声称的那么剧烈。
  • AI可做部分review(如静态检查),但「是否应该这样做」等高层判断仍需人类。
  • 大diff难审阅,但AI agent完成任务后会记得踩坑过程,有助于定位问题所在。
No.29 Launch HN: Drafted (YC P26) – Models for residential architecture
展示: Drafted — AI 住宅建筑平面图生成(YC P26)
53 分 58 条评论 作者: PrimalNick
Drafted 是 YC P26 孵化的 AI 平台,用户输入描述即可生成住宅平面图和渲染图。创始人 PrimalNick 背景涉及预建房服务及住宅建造家庭出身,产品定位是「让以前无法设计的人现在可以设计」,而非取代建筑师。评论反馈以负面为主:多位用户实测发现生成图存在车库停车方向错误、卧室缺失、浴室布局奇怪(如浴室里有会议室、侧并列马桶)等明显问题,被直指为「AI slop」。创始人回应承认不完美、渲染图常重写平面布局的 bug 已修复,未来计划加入编辑功能、工程约束训练、分区法规限制(FAR)、ADU 支持及公制单位。也有用户认为其在室内设计或《模拟人生》类游戏场景有潜力,或可帮助业主向建筑师表达想法。

评论精华

  • 多位用户实测发现严重错误:车库停车位垂直排列导致车辆无法进出、卧室缺失、浴室出现会议室等荒谬布局
  • 被批评为「AI slop」,大量生成设计缺乏实际意义,创始人承认渲染图常重写平面布局
  • 创始人表示正开发手动编辑功能,未来计划加入结构工程约束、分区法规(FAR)和 ADU 支持
  • 有用户建议转向室内设计或游戏内容生成,认为娱乐价值可能高于建筑专业价值
  • 用户提出多项功能需求:聊天式交互、工程印章(抗震墙)、上传现有平面图编辑、公制单位
No.30 Claude Corps
Anthropic 推出 Claude Corps:1.5亿美元培养千名 AI fellowship 进驻非营利组织
124 分 81 条评论 作者: Mustan
Anthropic 宣布启动 Claude Corps 项目,投资 1.5 亿美元,招募 1000 名职业早期人才,以全职驻场方式帮助全美 400+ 家非营利组织部署 AI。Fellow 获得 8.5 万美元年薪及福利,由 CodePath 作为雇主记录方、Social Finance 负责评估。项目宣称目标是在 AI 引发经济变革期间,让更多社区受益;但批评者指出,这更像「AI 传教士」计划——fellows 驻场一年后离开,组织可能面临系统维护困境,并被锁定在 Anthropic 生态中。命名风格(Corps、Strategic Token Reserves)被指具有军事色彩。社区争议聚焦于:这是真正的社会公益,还是 AI 公司「负责任」形象包装下的市场渗透手段?

评论精华

  • 非营利组织常被科技咨询公司坑害,一年驻场后恐留下维护不了的昂贵系统
  • 与 Google Summer of Code 不同,这是全职一年的面对面推销 Anthropic 商业生态
  • 有军事风格的命名(Corps、FDE 等)引发质疑,AI 公司是否在用软实力渗透公共领域
  • 即便是商业目的,若真能帮助非营利组织且不强制锁定,也算好事
  • 质疑者认为 AI 本就是替代人力的工具,以此「造福社区」逻辑自相矛盾