1. “聊天审查”这次真的被欧盟议会按下去了，但数字自由的仗还远没打完 (End of “Chat Control”: EU parliament stops mass surveillance)
这篇文章记录了欧盟“Chat Control”争议在议会层面一次极其关键的转折。根据文中说法，欧洲议会在一场几乎可以用惊险来形容的表决中，以极其微弱的优势否决了继续推进对私人聊天与照片进行无差别自动扫描的方案，并使现有 derogation 将在 4 月 4 日到期。这意味着 Meta、Google、Microsoft 等平台对欧洲公民私人通信进行普遍扫描的合法基础将不再延续。文章特别强调，这并不意味着儿童保护出现“法律真空”，因为基于具体嫌疑和司法授权的定向监控、对公开内容的检查、用户举报机制等仍然存在。它真正终结的是把大规模私密通信扫描常态化的那部分逻辑。与前几天“Chat Control 仍想卷土重来”的那条新闻连起来看，这次结果尤其有分量，因为它表明看似几乎要被重新拉回来的 mass surveillance 路线，最终还是被议会挡下来了。但作者也提醒，这只是一个阶段性胜利，后续的三方协商和年龄验证等议题，依然可能用新的形式重新威胁匿名通信和数字自由。
论坛讨论链接：https://news.ycombinator.com/item?id=47529609
评论区虽然对这次结果感到振奋，但整体并不乐观。很多人注意到文中自己就写了：后续仍可能通过程序性路径、永久性法规谈判或者强制年龄验证等方式，把类似控制能力换个壳重新推回来。也有人直言，这场胜利最重要的意义在于给外界看到了一件事：即便是已经进入惯性推进状态的大规模监控提案，也并非不可逆。整体氛围是短暂松一口气之后的清醒警惕，大家很清楚这不是战争结束，更像刚赢下一场关键战役。
2. LiteLLM 恶意投毒 72 分钟全纪录：现在连非安全工程师，也能在 AI 帮助下更快拉响警报 (My minute-by-minute response to the LiteLLM malware attack)
这篇文章把 LiteLLM 恶意投毒事件的发现、分析、验证和公开披露过程，完整展开成一份分钟级时间线。作者的笔记最有意思的地方，不只是技术上发生了什么，而是它展示了一个变化中的现实：以前开发者如果不是专职安全研究员，面对异常进程、 fork bomb、恶意 .pth 文件、持久化尝试和包供应链分析，往往很难在这么短时间里判断情况并对外发出有用预警；而这次借助 Claude Code，作者在 72 分钟内完成了从察觉异常到验证恶意包、联系 PyPI 与维护者、撰写并发布披露文章的一整套响应动作。文章因此不像普通“复盘文”，更像一次工具链角色变化的现场录像：AI 不只会让攻击写得更快，也可能让第一时间发现问题的人更快形成报告、找对联系人、组织证据和启动公共响应。它没有证明安全研究已经被自动化，但确实说明‘有经验的普通开发者 + 好的 AI 协作’已经足以大幅缩短早期披露链条。
原文链接：https://futuresearch.ai/blog/litellm-attack-transcript/
论坛讨论链接：https://news.ycombinator.com/item?id=47531967
评论区对这种变化既兴奋又谨慎。有人觉得这是明显的净正向：更多非安全背景开发者能够更早发现问题、整理证据并向社区发出告警，本身就能显著提升开源生态的免疫速度。也有人提醒，文章里也暴露了另一面，例如再次打开受感染环境本身就可能带来更多风险，说明 AI 辅助响应并不能替代严格的隔离与操作纪律。整体看，大家并不是在争‘AI 有没有用’，而是在认真评估：它是否已经开始改变安全事件最初几个小时的社会组织方式。
3. 我们还没见识到赌博和预测市场最糟糕的样子：它们正在把公共生活本身变成可套利对象 (We haven’t seen the worst of what gambling and prediction markets will do)
这篇文章试图把美国赌博合法化扩张与预测市场兴起带来的风险往前推一层。作者不是单纯反对体育投注或 Polymarket 这种产品，而是想指出一个更深的问题：当越来越多现实事件都能被包装成下注目标时，人们不只是在围观世界，而是在被激励去影响、操纵甚至破坏世界，以便让某个盘口兑现。文中举的案例很抓人，从棒球投手通过投出故意坏球让特定下注赢钱，到大额投注几小时后美国真的轰炸伊朗，再到预测市场与日常舆论、政治和暴力事件之间的相互塑形。作者的核心担忧是，一旦金融化和游戏化的逻辑深入渗透到体育、政治、战争、灾难甚至名人丑闻里，我们将面对一种新的社会副作用：越来越多人会把现实世界当作一个可被设计、诱导和套利的赌场界面。这篇文章真正不安的地方不在赌徒会输多少钱，而在社会本身会被重新训练成一种“任何事件都能下注、任何人都能被当盘口”的环境。
原文链接：https://www.derekthompson.org/p/we-havent-seen-the-worst-of-what
论坛讨论链接：https://news.ycombinator.com/item?id=47534848
评论区里有人先纠正文章把交易量说成收入的表述，但更大的争论集中在预测市场到底是‘集体智慧工具’还是‘新型零和成瘾机制’。支持者认为，让人真金白银押注会提升预测信号质量；批评者则指出，一旦赌注对象从比赛结果扩展到战争、犯罪和公共政策，市场激励就会开始污染事件本身。整体讨论的焦点不是赌博道德，而是：一个允许从坏事里系统性获利的社会，会不会越来越主动制造、放大或纵容这些坏事。
4. 他自制的 FPGA 板子已经能跑起 Quake II 了，下一步难点不再是能不能做，而是还能压出多少性能 (My DIY FPGA board can run Quake II)
这是作者自制 FPGA Quake II 项目的第四部分，重点是从第一代原型继续往前升级硬件板卡，换上更高规格的 Efinix FPGA 和 1GB DDR3L，并真正开始面对高速内存、BGA 封装、六层板、布线匹配和去耦布局这些现实电子设计问题。文章最可贵的地方在于，它没有把‘FPGA 跑 Quake II’浪漫化成一句标题，而是细致展示了真正把一个复杂系统从想法推到稳定板级实现时，会遇到的那些麻烦细节。作者在 DDR1 上吃过亏后，不再试图重复造轮子，而是开始借助官方软核控制器和设计指南来压住项目复杂度，这种取舍本身就很有工程味。对读者来说，这个系列的吸引力并不只在经典游戏情怀，而在它把“从零做一块能做正经事的 FPGA 板子”这件事拆得足够具体：从器件选择到焊接自信、从层数成本到时序要求，全都是现实中的硬骨头。如今能跑起 Quake II，意味着这个项目已经跨过了很多 hobby 级实验不会真正碰到的门槛。
原文链接：https://blog.mikhe.ch/quake2-on-fpga/part4.html
论坛讨论链接：https://news.ycombinator.com/item?id=47483286
评论区一边在感叹作者真的把高层数板和 BGA 都啃下来了，一边也很快转入 PCB 打样、板厂报价和多层板成本经验交流。很多人提到从双层板第一次迈进四层或六层板时那种‘账单震撼教育’，也有人分享 JLC、PCBWay 等板厂的价格与质量体验。整体氛围非常贴近硬件圈：大家既佩服项目本身，也乐于把这篇文章当作一次关于现实制板、布线和成本选择的经验对照。
5. 把 DOOM 塞进 DNS TXT 记录里并不能算“通过 DNS 运行”，但这仍然是一次非常漂亮的协议滥用秀 (DOOM Over DNS)
这个项目做的事情非常 HN：它把 shareware DOOM 的数据压缩切片，塞进大约两千条 DNS TXT 记录里，再用 PowerShell 脚本和公共 DNS 查询把这些数据在运行时重新拼回来，让游戏资源不落盘、而是直接从 DNS 层被取出并装载到内存里。严格说，评论区指出得没错，这并不是“DNS 在执行 DOOM”，而是 DNS 被当成了一个全球缓存、边缘分发的奇怪存储后端。但即便如此，这个项目依然相当精彩，因为它把一个原本为域名解析设计的基础协议，强行拗成了文件分发通道，还完整打通了构建、上传、查询和运行链路。它真正有趣的地方不在实用价值，而在于这种对系统边界的黑客式探索：一个协议到底还能被掰到多离谱，只要你愿意承受性能、可维护性和礼义廉耻上的代价。
原文链接：https://github.com/resumex/doom-over-dns
论坛讨论链接：https://news.ycombinator.com/item?id=47490705
评论区最先做的事就是给标题抬杠，认为更准确的说法应该是‘从 DNS 记录里加载 DOOM’，因为 DNS 在这里承担的是存储而不是计算。这个抬杠其实挺有价值，它反映出 HN 对这类项目的经典态度：玩法很酷，但概念一定要说准。也有人进一步发散，说既然记录里能存数据，那理论上靠持续改写状态和缓存操作是不是也能做出某种极慢的计算。整体气氛轻松而技术味十足，大家显然都知道这不是拿来部署生产系统的，但很乐于看见协议被这样极限恶搞。
6. 很多人会写 ls、cd、grep，但真正让终端顺手的，往往是那些 1989 年就已经解决好的小技巧 (Shell Tricks That Make Life Easier (and Save Your Sanity))
这篇文章的角度很朴素：大多数工程师在 shell 里生活很多年，却往往只学会了最基础的命令集合，却没有认真整理过自己在终端里的操作体验。作者因此系统梳理了一批并不神秘、但经常没人教的 shell 小技巧，包括几乎到处都可用的 Emacs 风格编辑快捷键，以及 Bash、Zsh 这类交互式 shell 提供的质量提升功能。文章最讨喜的地方在于，它不把这些技巧包装成‘你不知道就不配用终端’的黑话炫耀，而是明确指出：很多我们每天重复忍受的痛苦，其实早在几十年前就被 shell 设计者解决过了，只是大家没有被带着真正学会。对于终端重度用户来说，这类文章并不会像新工具发布那样刺激，但它的价值往往更持久，因为一旦养成习惯，它会直接改变你每天敲命令时的手感、速度和耐心。某种意义上，这不是在教新能力，而是在把长期低效的身体动作一点点纠正回来。
原文链接：https://blog.hofstede.it/shell-tricks-that-actually-make-life-easier-and-save-your-sanity/
论坛讨论链接：https://news.ycombinator.com/item?id=47525243
评论区很快变成一场 shell 使用习惯交流会。有人推荐把上下箭头改成按当前前缀搜索历史命令，也有人说自己一旦熟练使用 Ctrl-r，就几乎再也不靠箭头翻记录了。讨论里最有趣的部分是，很多技巧并不是‘更强大的功能’，而是不同人找到的、更贴合自己肌肉记忆的命令行姿势。整体氛围非常实用，没有什么原则性争论，像一群老终端用户在互相交换那些真能省下日常几万次键击的小窍门。
7. 想从 GitHub 搬去 Codeberg，又懒得折腾？这篇文章专门写给只想先挪过去的人 (Moving from GitHub to Codeberg, for lazy people)
这篇文章讨论的是一个越来越多人考虑、但常常因为麻烦而迟迟不做的动作：把项目从 GitHub 迁到 Codeberg。作者的重点不在意识形态动员，而是给出一种尽量“懒人友好”的迁移现实主义。文章指出，issue、pull request、release 等历史内容的导入其实比想象中容易，Codeberg 提供的仓库导入在很多场景下已经相当顺手，甚至在某些方面比 GitHub 处理外部 issue tracker 的体验还更自然。真正麻烦的部分反而是 CI/CD，尤其是 GitHub 用免费 macOS runner 和公共仓库无限容量把大家深度锁进自己的工作流之后，迁移的成本就不再只是 git remote 的切换，而是整套自动化和托管能力的重组。这篇文章因此很有价值，因为它既没有把 Codeberg 吹成完全等价替代，也没有把迁移渲染成英雄壮举，而是诚实地拆出一条可执行路径：先把能轻松搬的部分搬过去，再决定哪些 GitHub 便利你愿意继续依赖，哪些需要自己接住。
原文链接：https://unterwaditzer.net/2025/codeberg.html
论坛讨论链接：https://news.ycombinator.com/item?id=47530330
评论区对 Codeberg 的态度比较两极。支持者看重的是它背后 Forgejo 的开源治理和对 GitHub 之外托管生态的补位意义；批评者则强调它并不是‘通用 GitHub 替代品’，尤其对私有仓库、临时项目、主页托管和宽松存储需求不够友好。也有人指出，真正完整的解法往往还是自己运营 Forgejo 或其他 git 服务，但那又带来了新的运维负担。整体讨论非常现实：没人否认迁移的价值，只是大家都清楚，离开 GitHub 从来不是技术上做不到，而是得先接受失去哪些便利。
8. 个人百科全书：把家族照片、票据和零散记忆，重新编成一套只属于自己的知识系统 (Personal Encyclopedias)
这篇文章从一柜散乱的老照片写起，却慢慢把问题推到了一个更大的方向：当我们拥有越来越多关于自己和家人的数字痕迹时，是否可以像构建百科全书一样，把这些碎片组织成有结构、可追溯、可阅读的个人知识档案。作者最初只是帮外婆整理上千张旧照片，并通过交谈补回照片背后的时间顺序、人物关系和事件背景；后来他进一步把这些材料、家庭故事乃至更多数字记录整合起来，尝试构建一种类似私人 Wikipedia 的形式。文章特别动人的地方在于，它不是在谈“量化自我”那种冷冰冰的数据主义，而是在讨论怎样让记忆、叙述与材料重新连接起来，使个人与家庭历史不再只是箱底一叠快要失去上下文的旧纸片。AI 在这个过程里扮演的角色也不是主角，而是一个可以帮助整理、关联和表达的工具。它因此更像是一篇关于数字时代记忆工程的随笔：当技术足够强大时，我们可以用它来自动化检索与归纳，但真正被保存下来的，仍然是那些人和人之间传递的故事。
原文链接：https://whoami.wiki/blog/personal-encyclopedias
论坛讨论链接：https://news.ycombinator.com/item?id=47522173
评论区对这个项目的情绪很复杂，但整体偏温暖。有人觉得它极其打动人，因为技术被用来放大一件很人类、很私密的事；也有人对其中用 AI 交叉比对银行记录、票据和其他生活轨迹的能力感到隐隐不安，觉得这既动人又有一点监控感。这个分裂本身很能说明问题：大家并不反对技术帮助我们保存记忆，但也开始意识到，当工具足够强时，‘可被整理的人生’会同时是一种礼物和一种压力。
9. 为什么那么多控制室会刷成海泡绿？那其实是一套被今天极简主义忘掉的功能性色彩学 (Why so many control rooms were seafoam green (2025))
这篇长文从控制室常见的 seafoam green 配色切入，重新挖出一整套曾在工业设计、控制界面和高压工作环境中被认真研究过的色彩功能学。作者并不是单纯怀旧，而是通过曼哈顿计划时代的控制室与工业空间，说明这些看似复古的颜色选择背后其实有非常现实的目的：减轻疲劳、改善可读性、降低眩光和帮助人在长时间操作中保持稳定状态。文章因此不仅是在解释一种审美风格从哪里来，更是在提醒我们，很多过去的设计之所以长那样，并不是因为‘那个年代就喜欢丑颜色’，而是因为他们真的做过人因研究，并让空间、面板、灯光和配色一起服务于工作效果。放到今天再看，这篇文章打中的其实是更大的命题：当代软件和工业设计越来越迷恋抽象化、极简化和品牌化时，我们是不是反而丢掉了很多明确以可用性和生理感受为核心的设计传统。海泡绿因此成了一个很好的入口，让人重新意识到某些“老设计”并不保守，它们只是更认真地把人放在系统中心。
原文链接：https://bethmathews.substack.com/p/why-so-many-control-rooms-were-seafoam
论坛讨论链接：https://news.ycombinator.com/item?id=47518960
评论区里有不少共鸣来自对现代极简主义的不满。有人感叹今天很多界面连按钮都快做得不像按钮了，而过去那些看似朴素甚至古怪的工业设计，其实在 affordance、可读性和长期使用疲劳上考虑得更深。也有人把话题扩展到路灯配色、环境照明与睡眠影响，指出很多旧时代的选择并非拍脑袋，而是做过长期实验后留下来的。整体氛围是对‘功能性设计被审美潮流吞掉’的一次集体反思。
10. xv 作者 John Bradley 去世了，HN 这次更像在送别一个曾认真帮很多人完成第一代图像工作的老前辈 (John Bradley, author of xv, has died)
这条新闻本身抓到的正文并不理想，原始来源更像一篇私人悼念文章而非完整生平回顾，因此关于 John Bradley 的信息更多还是来自 HN 讨论补充。但即便如此，这条帖子的重要性并不难理解：对于很多老 Unix / X11 用户来说，xv 不只是一个看图工具，而是早期图像处理、格式转换和扫描工作流里极其关键的一块基础软件。它属于那种不会每天被大声纪念，却真实塑造过一代人计算经验的程序。正因如此，这条新闻的意义更多在于社区记忆而非新闻结构完整性。你看到的不是一场宏大追悼，而是一群曾被某个工具帮过的人，开始回忆它在自己工作流里曾经多么重要。某种意义上，这类离世消息之所以会在 HN 上获得关注，不是因为作者有多高调，而恰恰因为他的作品长期安静地存在于很多人的日常里，直到失去时大家才突然意识到，它曾是自己技术成长的一部分。
原文链接：https://voxday.net/2026/03/25/rip-john-bradley/
论坛讨论链接：https://news.ycombinator.com/item?id=47534086
评论区最动人的部分来自具体回忆。有人讲到自己当年为了扫描唱片封面，写命令行程序控制扫描仪，最后意识到‘很多功能我其实都想按 xv 的方式来做’，于是联系 John Bradley，希望在 xv 基础上做带扫描功能的商用版本，而对方不仅回信，还答应了分成合作。这类故事让整条帖子远比一则简单 obituary 更有人味。整体气氛是温和而真诚的送别：大家不是在讨论某位名人离场，而是在感谢一个曾认真写出好工具、也认真对待陌生开发者的人。