2025-11-21 Hacker News Top Stories #
- Google DeepMind 发布基于 Gemini 3 Pro 的 Nano Banana Pro 图像生成与编辑模型，支持最高 4K、多语言准确文字、品牌风格控制并附带 SynthID 水印，用于多平台创作与广告。
- Meta 推出 SAM 3，提供基于自然语言或视觉提示的精确图像与视频分割与跟踪能力，已在 Instagram Edits 等产品中落地以提升创作与开发工作流效率。
- 美国专利商标局拟推新规大幅限制 IPR 复审，使经挑战幸存的专利难再被审理，可能加剧滥用专利对中小企业的诉讼威胁。
- 随着 Valve 的 Proton、Steam Deck 及面向游戏的发行版（如 CachyOS）发展，在桌面上用 Linux 玩游戏变得更易上手且前景乐观。
- 作者认为 AI 被过度吹捧，虽在检索等小任务有用，但在复杂设计与大规模自动化上常投入大于产出，并助长资本与权力集中化风险。
- OpenAI 推出面向复杂长周期开发的 GPT-5.1-Codex-Max，提升代码生成与长期推理能力，支持百万级 token 窗口并在安全沙箱中运行以便审查。
- Arduino 被高通收购后悄然修改服务条款与隐私政策，加入永久许可、AI 行为追踪与禁止逆向工程等限制，引发教育与开源社区担忧。
- NTSB 报告称集装箱船因松动电线引发断电失去推进并撞上弗朗西斯·斯科特·基大桥致桥塌和六人死亡，指出电气安装缺陷与防护不足并下发多项安全建议。
- 粉丝项目 Chrono Divide 在浏览器中重制《红色警戒2》，实现跨平台运行、完整原版地图与多人对战并兼容大量 MOD。
- 《Calvin and Hobbes》四十周年回顾称比尔·沃特森的漫画以独特幽默与深刻思想影响一代读者，作者于高峰期主动完结并持续引发讨论。
Google DeepMind 正式发布全新图像生成与编辑模型 Nano Banana Pro (Nano Banana Pro) #
https://blog.google/technology/ai/nano-banana-pro/
Google DeepMind 正式推出全新图像生成与编辑模型 Nano Banana Pro，基于 Gemini 3 Pro 构建，具备更强的推理能力与现实世界知识，可实现更精准、高保真的视觉创作。
该模型支持在图像中生成准确且清晰的多语言文字，适用于海报、 mockup、国际内容创作等场景。无论是创建教育类信息图、展示食谱步骤，还是结合实时天气数据生成艺术风格的视觉内容，Nano Banana Pro 都能提供高质量输出。
用户可通过 Gemini 应用、Google Ads、Google AI Studio 等多个平台体验 Nano Banana Pro。模型支持高达 4K 分辨率，具备一致的品牌风格控制与高级创意功能，助力从想法到成品的高效转化。
所有生成内容均附带 SynthID 水印，确保生成内容的透明性与可追溯性，提升可信度。
HN 热度 753 points | 评论 469 comments | 作者：meetpateltech | 9 hours ago #
https://news.ycombinator.com/item?id=45993296
- Google AI Studio 的支付和认证流程过于复杂，用户在申请 API 密钥时遇到权限拒绝等问题，体验极差。
- 尽管 Google 推出新模型表现优秀，但其产品体验远不如竞争对手，尤其在 UI 界面和基础功能稳定性上存在明显短板。
- 用户对 Google 在快速发布新产品的同时缺乏充分的内部准备表示不满，认为应先解决产品问题再大规模推广。
- Google 的服务生态存在严重碎片化，如 Cloud、Vertex AI 等命名混乱，导致开发者难以理解使用路径。
- 有用户指出，Google 为吸引开发者而推出的“付费订阅”机制门槛过高，甚至需要填写表单才能获取访问权限，流程繁琐。
- 部分用户期待新的账单系统能加入硬性预算上限和预付余额功能，以避免意外扣费。
- 虽然 Google 服务规模庞大，但其在用户体验和基础设施上的表现已大不如前，与过去“行业标准”的形象相去甚远。
- 一些评论调侃称，Google 的支付流程甚至比其产品本身更精致，反讽其核心体验仍不成熟。
- 有用户提到，即便对技术细节不熟悉，也因流程复杂而难以顺利接入服务，反映出对非技术用户的不友好。
- 有人指出，当前的错误提示信息与实际问题不符，例如环境变量设置错误却提示需登录或检查密钥权限，加剧了调试难度。
- 对于希望快速上手的普通用户或非开发者而言，整个流程如同“闯关游戏”，严重阻碍了产品普及。
Meta 推出全新 Segment Anything Model 3（SAM 3）(Meta Segment Anything Model 3) #
Meta 推出全新 Segment Anything Model 3（SAM 3），这是一个支持文本和视觉提示的先进图像与视频分割模型，即将集成至 Instagram Edits 和 Meta AI 应用中的 Vibes 功能。
SAM 3 具备多项强大功能：可通过自然语言描述（如“蓝色汽车”）或视觉示例（如框选一个物体）精准识别并分割图像或视频中所有匹配对象；支持点击、框选、掩码等多种交互方式；若模型出现误判，用户可添加后续提示进行修正，实现动态优化。
该模型在图像与视频的文本和视觉分割任务中均达到业界领先水平，同时继承了 SAM 2 的全部性能与功能，专为真实应用场景设计，已在 Instagram Edits 视频创作工具中落地，帮助创作者快速为人物或物体添加特效。
SAM 3 采用统一的可提示架构，基于大规模多样化数据集训练，结合强大的感知编码器，实现跨模态、跨任务的高效分割与跟踪能力。
作为 Segment Anything 系列的最新演进，SAM 3 持续推动媒体工作流的智能化升级，为开发者、研究人员及创作者提供更强大、灵活的工具支持。
HN 热度 643 points | 评论 132 comments | 作者：lukeinator42 | 1 day ago #
https://news.ycombinator.com/item?id=45982073
- Meta 持续开源模型值得肯定，尽管公司本身存在争议，但其行动对整个行业有益。
- 2023 年 Llama 权重泄露事件后，Meta 转向积极维权，说明其开源并非出于纯粹善意，而是战略调整。
- Llama 权重泄露并非来自 Meta 内部，而是早期研究人员分享所致，Meta 原本计划开放权重。
- 有人认为 Meta 的开源行为是出于商业策略，如“ commoditize your complement”（使互补品商品化），以应对 OpenAI 和 Anthropic 的竞争。
- 尽管 Meta 在社交媒体领域声誉不佳，但其在开源领域的贡献不可忽视，是顶级科技公司中开源最成功的。
- Meta 的开源项目如 PyTorch、Llama、SAM、FAISS、OCP 等，已成为行业基础设施，广泛应用于学术界和工业界。
- 有人指出，Meta 的开源行为虽有战略动机，但结果仍推动了 AI 技术的整体进步。
- 虽然可以质疑 Meta 的动机，但不应因此否定其开源带来的实际价值。
- 开源行为本身值得感谢，即使背后动机复杂，但对开发者和研究者而言，成果是实实在在的。
- Meta 的开源策略与 Zuck 的公开承诺一致，不刻意美化，反而显得相对坦诚。
- 与 OpenAI 等公司相比，Meta 在开源方面确实更为彻底，尤其在模型权重层面。
- 有人强调，不应因公司名声而否定其开源贡献，技术进步应独立看待。
- Meta 的开源项目已形成“开源圣殿”效应，其 GitHub 组织总星标数超过谷歌、微软和亚马逊总和。
- 从技术角度看，Meta 的开源不仅限于模型，还包括构建系统、数据处理、压缩算法等，覆盖 AI 全栈。
美国专利商标局拟推新规，使错误专利难以被挑战 (The patent office is about to make bad patents untouchable) #
https://www.eff.org/deeplinks/2025/11/patent-office-about-make-bad-patents-untouchable
美国专利商标局（USPTO）拟推出新规则，将严重限制公众挑战错误授予专利的途径，尤其是通过“双方复审”（Inter Partes Review, IPR）程序。这一改变将使专利流氓（patent trolls）得以长期保留无效专利，进一步加剧对小企业、开发者和普通技术用户的诉讼威胁。
IPR 是一种由美国专利审判和上诉委员会（PTAB）主持的快速、低成本的行政审查程序，允许个人或组织在专利被授予后，基于现有技术（prior art）挑战其有效性。该机制曾成功撤销多个滥用专利，例如“播客专利”“健身数据上传专利”和“快递通知专利”等，保护了整个行业免受恶意诉讼。
然而，新规则将带来三大致命影响：第一，被告必须放弃在法院挑战专利有效性的权利，才能申请 IPR，这在实际诉讼中几乎不可行；第二，一旦专利在任何一次挑战中幸存，无论理由是否充分，都将永久“不可挑战”；第三，若预计联邦法院案件进展更快，IPR 将被直接禁止，使被告只能面对昂贵且漫长的司法诉讼。
这些规则实质上剥夺了公众纠正专利错误的机会，使专利流氓得以利用漏洞持续施压。尽管 USPTO 声称法院仍可挑战专利，但现实中，联邦法院诉讼成本高昂、耗时多年，对大多数中小企业和个体开发者而言根本不可行。
文章呼吁公众立即提交反对意见，强调 IPR 是国会为纠正专利系统错误而设立的重要机制，其存废应由立法机构决定，而非由行政机构通过规则随意削弱。保护 IPR，就是保护创新与公平竞争的根基。
HN 热度 560 points | 评论 84 comments | 作者：iamnothere | 1 day ago #
https://news.ycombinator.com/item?id=45985890
- Groklaw 曾是科技与法律交叉领域的重要信息来源，其关闭与斯诺登事件后互联网监控加剧有关，因无法保障协作隐私而被迫停更。
- Groklaw 网站如今被用于推广加密货币赌博，反映出许多已关闭网站被恶意收购并转化为广告引流工具的现象。
- 一些黑灰产营销者通过收购废弃网站，替换内容并植入赌博、信用卡等推广链接，实现长期盈利。
- 网站的衰落与互联网早期缺乏加密通信（如 HTTPS）有关，导致大量数据可被轻易截获。
- 尽管 HTTPS 在 2011-2012 年开始普及，但政府仍能通过在数据中心内部部署监听设备实现数据获取。
- 有观点认为，政府监听可能通过在服务器私有子网中部署监听设备，获取未加密的内部通信数据。
- 但也有观点指出，私有子网本身并不对外暴露，因此监听设备难以直接接入内部网络。
- 现代大型服务已趋向将多台服务器整合至单台高性能设备，减少了传统私有网络的复杂性。
- 一些老旧服务器（如 Sun V880）仍在运行，其性能仅相当于现代 Raspberry Pi，反映出技术演进的巨大差距。
- 有人调侃 Cloudflare 本质上就是“TLS 魔法盒子”，暗示其在加密通信中的关键作用。
在 Linux 上玩游戏从未如此简单 (Gaming on Linux has never been more approachable) #
https://www.theverge.com/tech/823337/switching-linux-gaming-desktop-cachyos
作者 Nathan Edwards 决定尝试将 Linux 安装到自己的游戏电脑上，原因是对 Windows 11 的现状感到失望。他指出，Windows 近年来不断引入令人困扰的新功能，如强制使用 OneDrive、Edge 浏览器、Bing 和 Copilot，同时削减用户自主性，例如禁用本地账户设置和旧硬件支持，并推动 AI 功能融入系统，使体验愈发令人不适。
尽管 Windows 11 目前运行正常，但作者认为其发展方向令人担忧，且 Windows 10 即将停止支持，迫使用户升级硬件或面临安全风险。因此，他决定“彻底换水”，尝试转向 Linux。
他回顾了自己过去与 Linux 的零星接触：曾在树莓派上尝试搭建 Homebridge、使用小型 Linux 手持设备 Beepy、在 Chromebook 上运行 Linux 虚拟机，以及在 Windows 子系统中搭建键盘固件开发环境。这些尝试大多耗时较长，且影响了他宝贵的自由时间，因此始终未能真正下定决心全面切换。
然而，如今 Linux 在游戏领域的可用性大幅提升。Valve 通过 Steam Deck 推动 Linux 生态发展，Bazzite 等基于 SteamOS 的发行版已在部分设备上实现优于 Windows 的性能表现。此外，同事和朋友的亲身经历也增强了他的信心。
作者计划在自己刚组装不久的高性能 PC（搭载 AMD Ryzen 7 9800X3D 和 NVIDIA RTX 4070 Super）上安装 CachyOS——一个基于 Arch 的、专为现代硬件和游戏优化的 Linux 发行版。他虽不期待过程顺利，但认为现在是尝试 Linux 的合适时机，尤其是对追求自由、控制权和更好游戏体验的用户而言。
文章最后暗示，2026 或将成为 Linux 在桌面端真正崛起的一年，至少对作者而言是如此。
HN 热度 512 points | 评论 385 comments | 作者：throwaway270925 | 1 day ago #
https://news.ycombinator.com/item?id=45985506
- 使用 Steam 在 Linux 上运行游戏已变得非常顺畅，尤其是通过 Valve 的 Proton 技术，许多游戏无需额外配置即可运行。
- 尽管 Linux 原生游戏版本存在兼容性问题，但通过强制 Steam 运行 Windows 版本可有效解决大部分问题。
- 有观点指出，Win32 API 在 Linux 环境中反而成为最稳定的接口，因为 Wine 能够稳定地封装 Windows 应用运行。
- 有人担忧微软未来可能对 Win32 进行破坏性更新，迫使 Proton 团队持续跟进，但也有观点认为这种风险在实际中较低。
- 由于 Linux 软件生态缺乏统一的二进制兼容标准，旧版本应用在新系统上运行困难，这与 macOS 的版本兼容机制形成对比。
- macOS 的应用通过版本化工具链和 SDK 实现良好兼容，而 Linux 仍依赖“用户可自行重新编译”的文化，导致分发混乱。
- Unity、Unreal Engine 等主流游戏引擎的普及，使得跨平台开发变得容易，减少了对底层系统 API 的依赖。
- Godot 等开源引擎也提供了良好的跨平台支持，无需平台特定代码即可实现多系统部署。
- 图形 API 从 DX11/OpenGL 向 DX12/Vulkan 的迁移虽然提升了性能，但增加了开发复杂度，限制了中小型开发团队的参与。
- 由于现代图形 API 难度高，有能力的开发者更倾向于加入大厂或引擎公司，而中小型团队则更倾向使用技术门槛较低的方案。
- Steam Deck 的成功推动了 Linux 游戏生态的发展，促使开发者优化游戏以获得“Steam Deck 认证”标签。
- 有迹象表明《半条命 3》或相关作品可能在不久的将来发布，尽管仍存在不确定性。
- 微软若推出仅限 Windows 的反作弊系统，可能对非 Windows 平台玩家造成限制，但除非性能显著提升，否则开发者未必愿意采纳。
- 为绕过 Windows 原生反作弊系统而深入内核层进行修改，存在巨大安全风险且不切实际，难以被广泛接受。
AI 是资源与权力集中化的工具 (AI is a front for consolidation of resources and power) #
https://www.chrbutler.com/what-ai-is-really-for
本文作者克里斯托弗·巴特勒基于三年对人工智能的深入观察，提出一个核心观点：AI 技术虽有实用价值，但其实际效能远低于市场宣传，正处在一个严重被夸大的泡沫之中。
作者从设计行业的实际经验出发，指出 AI 在真实工作流程中的应用往往不切实际。许多展示 AI“端到端”设计的案例，仅适用于理想化、无外部约束的创作场景，而一旦嵌入现有设计系统，AI 便暴露出诸多问题：难以复现特定插画风格、无法准确处理图文层级关系、布局生成后需大量手动重构。多数设计师在实际工作中，自己动手完成 UI 和页面设计的速度与质量，远超使用 AI 工具。
作者进一步指出，AI 在小规模任务中可能带来显著效率提升，如信息检索、摘要生成和分析，但在大规模流程自动化或职能替代方面，投入成本往往超过节省的劳动，整体得不偿失。这与 MIT 研究结果一致：企业 AI 项目失败率高，源于对“全面 AI 化”的盲目追求；而成功案例多为聚焦具体目标的小型应用。
当前 AI 泡沫的规模远超历史上的互联网泡沫。全球市值最高的七家公司深度绑定 AI 投资，形成相互依赖的资本循环。然而，至今尚未出现能支撑其天价估值的可持续商业模式。作者类比当年的 Segway，指出 AI 被宣传为将彻底改变所有工作方式的技术，但其真实能力可能仅相当于“一辆电动滑板车”，而市场预期与现实之间的差距，已达到万亿级。
更令人担忧的是 AI 对社会信任体系的冲击。在已有信息茧房、假新闻和社交媒体操控的基础上，AI 能以更快、更精准的方式制造虚假内容，加剧公众对信息真实性的怀疑。这种对社会认知基础的侵蚀，本身就是不可接受的代价。
最后，作者质疑 AI 的真正目的：我们被宣传为 AI 是为了提升效率、解放人力，但投资者的真实动机是否如此？他暗示，部分利益相关方可能清楚 AI 的局限，却仍在推动泡沫，以获取短期资本收益。这种“明知故犯”的行为，使 AI 不仅是一场技术泡沫，更可能是一场带有欺诈动机的系统性风险。
HN 热度 504 points | 评论 397 comments | 作者：delaugust | 1 day ago #
https://news.ycombinator.com/item?id=45983700
- 通用技术初期普遍落后于现有实践，但会快速进步，并在不同领域陆续超越现有方法，关键在于识别并抓住技术突破的临界点。
- 技术成功的关键不在于寻找当前无效的应用场景，而在于持续寻找那些随着技术进步而变得可解的增量难题。
- 特斯拉通过在高端市场率先采用锂电池技术，实现了对传统车企的领先，尽管当时主流车企认为该技术不适合大众市场。
- 通用技术并非都能成功，许多技术在初期阶段就停滞不前，最终被历史遗忘，因此不能忽视失败案例的普遍性。
- 通用技术通常先在特定领域实现“足够好”的应用，从而逐步取代专业设备或人员，当其在多个领域都达到“足够好”时，才开始大规模普及。
- 当前纯电动汽车在多数地区仍比传统燃油车或混合动力车更昂贵，政府补贴是推动其销售的主要因素，因此传统车企的保守判断未必错误。
- 电池技术的经济性取决于使用场景，例如长续航电池或快充功能在非高频使用场景下可能造成资源浪费，因此并非所有情况下电动车都更便宜。
- 通用技术的长期影响难以预测，尤其是像 AI 这样覆盖面极广的技术，其未来形态和优劣势尚不明确。
- GPU 曾被寄予厚望成为通用计算主力，但受限于数据传输瓶颈和专用硬件的存在，最终仅在游戏和 AI 领域取得成功，未实现全面替代 CPU。
- 人工智能的发展路径与早期 GPU 类似，尽管前景乐观，但实际落地可能受限于技术瓶颈，最终未必达到预期。
OpenAI 推出全新前沿编程模型 GPT-5.1-Codex-Max，专为复杂、长时间的开发任务设计 (Building more with GPT-5.1-Codex-Max) #
https://openai.com/index/gpt-5-1-codex-max/
OpenAI 推出全新前沿编程模型 GPT-5.1-Codex-Max，专为复杂、长时间的开发任务设计。该模型基于更新的推理基础模型，经过软件工程、数学、研究等领域的代理任务训练，具备更强的智能与效率。
GPT-5.1-Codex-Max 在多个前沿编程评测中表现优于前代模型，如 SWE-Lancer 和 Terminal-Bench 2.0，尤其在真实开发场景中展现出更优的代码生成与协作能力。其推理过程更具效率，在 SWE-bench Verified 任务中，以“中等”推理强度实现更高准确率，同时减少 30% 的思考 token 消耗。
该模型支持“压缩”（compaction）技术，可跨多个上下文窗口持续工作，实现百万级 token 的任务处理。这一能力使其能胜任项目级重构、长时间调试和多小时的自动化代理循环任务，内部测试中已实现超过 24 小时的持续运行。
在安全性方面，GPT-5.1-Codex-Max 在长周期推理任务中表现更优，尤其在网络安全评估中达到当前最高水平，但尚未达到“高能力”标准。OpenAI 已加强网络安全监控与防护机制，防止滥用，并通过 Aardvark 等项目支持防御性应用。
Codex 默认运行在安全沙箱中，限制文件写入与网络访问，建议开发者保持此安全模式。尽管模型能生成高质量代码，但仍需人工审查，尤其是部署前。模型会生成终端日志，记录工具调用与测试结果，辅助开发者验证。
GPT-5.1-Codex-Max 已在 Codex CLI、IDE 插件、云平台及代码审查中上线，API 接口即将开放。该模型标志着向可靠编程伙伴迈进的重要一步。
HN 热度 467 points | 评论 297 comments | 作者：hansonw | 1 day ago #
https://news.ycombinator.com/item?id=45982649
- Codex 严格遵循指令，甚至会因微小的措辞而过度复杂化解决方案，被形容为“字面意义上的精灵”，适合需要高度准确性的长期复杂任务。
- Claude 更倾向于忽略指令，自行判断并修正明显错误，适合快速迭代的开发场景，如样式调整等。
- 在大型项目重构中，Codex 能够根据简短指令完成复杂系统重写，如飞行模拟器从浮点原点切换到真实地球坐标系，且结果基本正确。
- Codex 在实现代码重构功能（如“提取函数”）时表现出色，能快速生成可运行的原型，极大缩短从零到可用的开发时间。
- Codex 有时会做出过于通用的架构决策，比如试图构建类似 Unity 的万能引擎，而非专注于特定类型的游戏，需明确限制才能避免。
- 使用“指令彩蛋”（如指定称呼或开头符号）可作为检测模型是否遵守指令的手段，但可能引入不必要的上下文干扰。
- 有人认为这类“彩蛋”指令可能污染上下文，影响模型输出质量，尤其在频繁交互中。
- 也有观点认为，只要指令不极端（如禁止使用某个字母），其影响有限，且“彩蛋”有助于识别模型是否在执行指令。
- 有人指出，即使指令看似荒诞，模型也会模拟相应行为，使对话更自然，但需注意避免干扰真实任务。
Arduino 之死？ (The Death of Arduino?) #
Arduino 被高通收购后，悄然更新了其服务条款和隐私政策，引发社区广泛担忧。新条款引入多项限制性规定，包括用户上传内容将被授予永久、不可撤销的许可，平台对 AI 功能实施类似监控的用户行为追踪，禁止用户识别潜在专利侵权，以及在账户注销后仍保留用户名长达数年。更关键的是，用户被明确禁止在未获许可的情况下逆向工程或理解平台工作原理，这一变化严重背离了 Arduino 长期倡导的开源精神。
这些变更标志着 Arduino 从开放社区平台向高度控制的商业服务转变，其用户数据（包括未成年人）将被整合进高通全球数据生态系统。此举对教育、创客、研究等领域造成重大冲击，尤其影响学术机器人研究。许多评论指出，高通对开源社区缺乏理解，其商业策略可能适得其反。
有观点认为，这反而为开源替代品创造了机会。Adafruit、PlatformIO、VSC 等平台可能成为新的主流选择。已有开发者呼吁重建开源生态，自行开发替代方案。有评论讽刺称，高通正用巨额资金购买豪华飞机，却忽视了社区信任这一核心资产。
整体来看，此次更新被视为对开源精神的重大背离，可能促使社区加速向更开放、透明的替代平台迁移。
HN 热度 427 points | 评论 229 comments | 作者：ChuckMcM | 1 day ago #
https://news.ycombinator.com/item?id=45984143
- Arduino 的条款仅针对其云服务等在线平台，不影响开源硬件项目本身。
- 该条款是法律团队将标准 SaaS 服务条款套用到平台服务上的结果，属于常见做法。
- “平台”定义明确限于网站、在线服务、论坛等，不包括本地开发工具或硬件。
- 限制逆向工程的条款可能引发公关危机，未来可能被移除。
- Adafruit 作为销售商发布此类文章存在利益冲突。
- 该条款对 Arduino 用户上传内容的限制表述不合理，因 Arduino 并非主要上传平台。
- Arduino 的历史存在争议，其早期工作可能借鉴了他人成果而未充分致谢。
- 有人呼吁提交 Hernando Barragan 的故事，强调其应得的认可。
- Arduino 的角色更像一个发行版维护者，而非多数代码的原始版权持有者。
- CLA 对已有 GPL 代码的再许可作用有限，除非获得所有原始贡献者的授权。
- Arduino 对生态系统中多数组件并无版权，难以通过条款实现全面控制。
- Qualcomm 对开源社区的控制行为虽可预见，但措辞过于强硬，令人意外。
- 该条款可能影响用户对 Arduino IDE 和库的本地使用与开发。
松动电线导致断电，撞上弗朗西斯·斯科特·基大桥 (Loose wire leads to blackout, contact with Francis Scott Key bridge) #
https://www.ntsb.gov/news/press-releases/Pages/NR20251118.aspx
2024 年 3 月 26 日，巴尔的摩的弗朗西斯·斯科特·基大桥因一艘 984 英尺长的集装箱船“达利号”发生电气故障而倒塌，造成六名公路工人死亡。美国国家运输安全委员会（NTSB）于 2025 年 11 月 18 日召开公开会议，宣布调查结果。
事故的直接原因是“达利号”船上一根松动的电线导致断路器意外跳闸，引发两次电力中断，致使船舶失去推进力和舵控能力。该电线因标签绑带阻碍未能完全插入端子块弹簧夹，造成连接不良。尽管船员和岸上调度员迅速采取应对措施，但因距离大桥过近，无法有效操控船舶。
撞击发生时，船上共有七名道路维护人员和一名检查员，六人不幸遇难。得益于船员、岸上调度员和马里兰州交通局及时关闭桥面交通，避免了更多伤亡。
调查发现，弗朗西斯·斯科特·基大桥缺乏抵御大型船舶撞击的防护措施。1980 年，一艘 390 英尺长的船只“蓝长崎号”撞击大桥仅造成轻微损坏，而“达利号”体积是其 10 倍，撞击后果严重。该事件暴露了美国全国范围内大量桥梁在面对大型船舶撞击时的脆弱性。
为此，美国交通部于 2025 年 3 月发布初步报告，指出许多桥梁所有者未意识到此类风险，尽管美国州公路与运输官员协会（AASHTO）早已建议进行风险评估。该报告已致信 30 个桥梁所有者，要求评估并制定减灾方案，所有单位均已回应。
基于调查结果，美国国家运输安全委员会向多个机构和企业发出 68 项安全建议，包括美国海岸警卫队、联邦公路管理局、日本船级社（ClassNK）、美国国家标准协会、现代重工、船级社、电气组件制造商瓦戈公司（WAGO）以及多个桥梁管理单位。
完整调查报告将在未来几周内发布。公众可通过 NTSB 官网获取事件摘要和建议进展。如需报告事故或联系应急响应中心，可拨打 1-844-373-9922 或 202-314-6290。
HN 热度 416 points | 评论 210 comments | 作者：DamnInteresting | 1 day ago #
https://news.ycombinator.com/item?id=45984659
- 事故的直接原因是松动的电线，但深层问题在于多重系统缺陷，如手动切换变压器、缺乏培训、燃料泵非冗余设计、主发动机无应急冷却等，体现了“瑞士奶酪模型”中的多层失效。
- 船舶运营环境恶劣，船员薪资低、责任重，实际工作条件与安全要求严重脱节，事故后被“软禁”处理，反映出系统性压榨。
- 航运业竞争激烈，成本控制严苛，导致维护和安全投入不足，许多船舶处于“事故待发”状态，只是尚未暴露。
- NTSB 报告建议用红外相机全面检查船舶，但实际操作中难以实现，因船舶在港时系统多处于低负载状态，无法发现运行中的隐患。
- 船舶维修常由供应商技术人员在航行中完成，缺乏系统性测试，且船舶停靠时间极短，无法进行充分安全验证。
- 航运公司对事故调查结果反应迟缓，未主动改进其他船舶的安全措施，反映出对安全责任的漠视。
- 事故的根本原因并非个别故障，而是整个航运系统缺乏有效监管和资源投入，监管机构（如 MARAD）未被问责，暴露了监管缺位。
- 真正的“罪魁祸首”是系统性问题，包括低利润、低监管、高风险的行业生态，而非某个具体责任人。
- 航运公司为追求利润最大化，将风险转嫁给保险公司，缺乏主动改进安全的动力。
- 航运业事故率低，是因为侥幸未出事，而非系统真正安全，这种“幸存者偏差”掩盖了潜在危机。
- 应通过加强监管、提高行业准入标准、提升船员待遇和保障来根本改善航运安全，而非仅关注技术细节。
《红色警戒 2》网页版：Chrono Divide——基于网页技术的粉丝重制项目 (Red Alert 2 in web browser) #
Chrono Divide 是一个由粉丝制作的项目，旨在使用网页技术重现经典即时战略游戏《命令与征服：红色警戒 2》。游戏完全在网页浏览器中运行，无需安装额外插件或应用程序，支持跨平台使用，可在电脑、手机和平板设备上畅玩。
目前项目已进入测试阶段，提供可玩的 Beta 版本，支持全部原版地图和完整的多人游戏功能。玩家可通过浏览器直接进入游戏，享受经典 RTS 玩法，同时支持左键或右键操作模式，可观看对战回放，并兼容大量原版 MOD。
项目采用客户端-服务器架构，避免了传统联机游戏中的端口转发和防火墙问题，提升了联机体验。游戏对硬件要求较低，最低配置为 Intel Atom Z3700 处理器和 4GB 内存，推荐使用 Intel Core i5 及 8GB 内存以获得更好性能。推荐使用最新版 Chrome、Edge 或 Safari 浏览器，Firefox 可能影响性能。
Chrono Divide 致力于实现与原版游戏功能完全一致，持续开发中。项目为非营利性质，不隶属于 Electronic Arts，所有版权仍归原所有者所有。欢迎玩家通过捐赠支持项目发展，帮助覆盖服务器成本和推动后续开发。
更多详情可查看官方更新日志，或加入 Discord 社区参与讨论。
HN 热度 376 points | 评论 126 comments | 作者：nsoonhui | 11 hours ago #
https://news.ycombinator.com/item?id=45991853
- Red Alert 2 的源代码据传早已丢失，因此 Chrono Divide 团队能在浏览器中实现该游戏令人惊叹。
- Mental Omega 模组项目仍在活跃，使得 Red Alert 2 至今仍具可玩性，希望其能在浏览器版本中正常运行。
- EA 已公开了多数《命令与征服》系列游戏的源代码，但 Red Alert 2 未被包含，可能因源代码已丢失。
- Tiberian Sun 和 Firestorm 的源代码也据传丢失，1999 年时期的即时战略游戏至今仍难以被复制。
- Mental Omega 模组据传拥有完整的源代码和工具链，因此能实现远超原引擎能力的扩展。
- 游戏开发中源代码丢失的现象在当时极为普遍，反映出当时对资产和代码管理的严重缺失。
- 早期游戏公司普遍缺乏对源代码的保护意识，即使在游戏发布后也随意删除代码和资产。
- 一些公司甚至在项目终止后，为防止“知识产权”外流而强制清除开发人员本地的代码和数据。
- 有开发者回忆自己曾亲手删除大量珍贵的原始视频资料和代码，因公司倒闭而被当作废品处理。
- 有些游戏如 Panzer Dragoon Saga 和 MicroProse 的 Shandalar 的源代码也已丢失，属于行业普遍问题。
- Westwood 被 EA 收购并关闭后，资产交接混乱，可能导致源代码在转移过程中丢失。
- 当时游戏工作室普遍不认为旧游戏未来会有价值，因此未进行系统性归档。
- 世界范围内，许多经典游戏的原始源代码因公司倒闭或管理不善而彻底消失。
- 《星际争霸》在韩国的流行可能对即时战略游戏的发展方向产生负面影响，导致后续作品更侧重多人平衡而非单人体验。
- 《最终幻想 14》的源代码丢失事件也表明，即使大公司也难以长期保存核心资产。
- 现代游戏公司已开始重视遗产保护，推动重制和重玩，但问题主要集中在早期作品上。
- 《暗黑破坏神 2》和《寂静岭 2》等经典游戏的源代码也曾丢失，反映出行业早期的管理混乱。
- 源代码丢失的背后，是当时对软件资产价值认知的严重不足，以及缺乏系统性的数据保存机制。
《Calvin and Hobbes》四十周年 (‘Calvin and Hobbes’ at 40) #
1985 年 11 月 18 日，漫画《 Calvin and Hobbes 》首次登上了报纸的漫画栏。这部作品由漫画家比尔·沃特森创作，讲述了一位 6 岁男孩卡尔文与他幻想中的玩具老虎霍布斯的冒险故事。尽管霍布斯在现实中只是一只玩具老虎，但在卡尔文的想象中，他是一位机智、富有哲思的伙伴，陪伴卡尔文面对日常生活中的挑战与奇思妙想。
这部漫画在短短十年间（1985–1995）风靡全美，以其独特的幽默感、深刻的思想性与高质量的绘画风格赢得了广泛赞誉。编辑李·萨莱姆回忆，初读时便被其震撼，认为它既新鲜又真实，唤起了许多人对童年生活的共鸣。他特别提到一幅经典画面：卡尔文发着高烧躺在床上，一边听着电视里夸张的肥皂剧，一边对读者笑着说：“有时候，我待在家里比去学校学到的还多。”这句充满讽刺意味的台词，也引来部分读者误解，甚至有人批评漫画“鼓励孩子逃学看成人剧集”，但萨莱姆认为这种讽刺的深层意味并未被所有人理解。
与以往经典儿童漫画角色如查理·布朗、丹尼斯·梅纳奇相比，卡尔文更具独立精神与冒险气质，更像《汤姆·索亚历险记》中的汤姆和哈克。霍布斯不仅是卡尔文的幻想伙伴，更是他内心世界的投射，是其思想与情感的镜像。萨莱姆指出，霍布斯是否真实存在并不重要，关键在于他对卡尔文而言是真实存在的，是朋友、是导师、是灵魂的另一半。
比尔·沃特森在 1995 年选择主动结束这部作品，因为他希望在更广阔的创作空间中，以更从容的节奏进行艺术表达。此后他极少公开露面，也未再推出新作。2019 年，编辑李·萨莱姆去世，但《Calvin and Hobbes》的影响持续至今，成为一代人心中不可替代的童年经典。
HN 热度 328 points | 评论 127 comments | 作者：mooreds | 12 hours ago #
https://news.ycombinator.com/item?id=45991787
- 《 Calvin and Hobbes 》是许多读者童年的重要组成部分，其智慧远超当时的主流文化与教育内容，但主角 Calvin 的反叛与疏离性格并非理想的人生榜样。
- 三十多年后，读者意识到可以以更务实和包容的方式面对生活中的矛盾与虚伪，而非一味坚持 Calvin 式的批判与傲慢。
- 有人认为 Calvin 并非角色模型，而是对童年孤独、聪明但不合群的精准描绘，而 Hobbes 才是理性与成熟的象征。
- 《 Calvin and Hobbes 》作为一部深刻反映人性的作品，其价值在于提供一种精神上的“避风港”，而非提供生活指南。
- 有观点指出，Calvin 所代表的讽刺、反英雄式角色在 90 年代流行文化中普遍存在，这种形象对成长中的孩子产生了负面影响，导致他们崇尚叛逆而非责任与共情。
- 与之对比，Cartman 等角色在《南方公园》中被塑造为无道德约束却总能得逞的“成功者”，其行为模式对儿童具有潜移默化的模仿效应，尽管节目本身并非为儿童设计。
- 一些人认为，尽管 Cartman 被设定为反派，但因其频繁获得笑声和成功，孩子会将其视为“有趣且有效”的行为模板，从而模仿其傲慢与操控。
- 《 Calvin and Hobbes 》的结束方式优雅而深刻，充满希望与谦逊，是极少数能以温柔方式谢幕的长篇作品。
- 有读者指出，Hobbes 的形象在后期失去了原本的爪垫细节，象征着角色从幻想走向现实的微妙转变。
- 《 Calvin and Hobbes 》的创作过程和作者沃特森的评论，揭示了作品随时间演变的深层逻辑与漫画出版行业的变迁。
- 有人反驳将 Calvin 与宗教人物约翰·加尔文相联系的说法，强调两者在性格与思想上并无关联，且加尔文本人实为富有同情心与进步思想的人物。
- 《 Calvin and Hobbes 》所代表的“疏离感”与“反叛精神”是 80-90 年代文化氛围的产物，与当时流行文化如《费里斯·布勒》等共同塑造了一代人的精神气质。
Hacker News 精彩评论及翻译 #
Loose wire leads to blackout, contact with Francis… #
https://news.ycombinator.com/item?id=45985858
I strongly recommend watching/reading the entire report, or the summary by Sal Mercogliano of What’s Going On In Shipping 0.
Yes, the loose wire was the immediate cause, but there was far more going wrong here. For example:
-
The transformer switchover was set to manual rather than automatic, so it didn’t automatically fail over to the backup transformer.
-
The crew did not routinely train transformer switchover procedures.
-
The two generators were both using a single non-redundant fuel pump (which was never intended to supply fuel to the generators!), which did not automatically restart after power was restored.
-
The main engine automatically shut down when the primary coolant pump lost power, rather than using an emergency water supply or letting it overheat.
-
The backup generator did not come online in time.
It’s a classic Swiss Cheese model. A lot of things had to go wrong for this accident to happen. Focusing on that one wire isn’t going to solve all the other issues. Wires, just like all other parts, will occasionally fail. One wire failure should never have caused an incident of this magnitude. Sure, there should probably be slightly better procedures for checking the wiring, but next time it’ll be a failed sensor, actuator, or controller board.
If we don’t focus on providing and ensuring a defense-in-depth, we will sooner or later see another incident like this.
crote
我强烈建议您完整阅读或观看这份报告，也可以阅读 Sal Mercogliano 关于《航运业究竟发生了什么》的摘要 0。
是的，松动的电线是直接原因，但其中存在的问题远不止于此。例如：
- 变压器切换被设置为手动模式，而非自动模式，因此它没有自动切换到备用变压器。
- 船员并未定期进行变压器切换程序的演练。
- 两台发电机都依赖一个非冗余的单一燃料泵（而这个泵的设计初衷并非为发电机供油），该泵在电力恢复后未能自动重启。
- 当主冷却水泵断电时，主发动机自动关闭，而不是使用紧急供水系统，或是允许其过热运行。
- 备用发电机未能及时启动。
这是一个典型的“瑞士奶酪模型”案例。要导致这起事故，必须同时发生一连串的失误。只关注那根电线是无法解决所有其他问题的。电线，就像所有其他部件一样，偶尔会发生故障。单根电线的故障绝不应该引发如此规模的重大事件。诚然，或许应该有更好的检查线路的程序，但下一次出问题的可能是一个传感器、一个执行器，或是一块控制板。
如果我们不专注于并确保实施“纵深防御”，那么我们迟早会再次看到类似的事件。
Europe is scaling back GDPR and relaxing AI laws #
https://news.ycombinator.com/item?id=45984395
I get that too many regulations is a bad thing. But when we talk privacy and personal data there should be no gray zone. It has to be black and white. When I see a stupid cookie banner I search for “Reject all”. There’s no some data that companies can collect and process without my consent, they just shouldn’t be able to collect anything without me actively opting in. Business never respects anything, but profits. Seeing news about relaxing these laws with the “AI” going after this leaves a bitter taste. And with them also trying to push the Chat Control thing, it gets even worse.
rckt
我明白过多的规定是个坏事。但当我们谈论隐私和个人数据时，就不该存在灰色地带。必须是黑白分明的。当我看到那种愚蠢的 Cookie 提示条时，我会直接搜索“拒绝全部”。没有任何数据可以在未经我同意的情况下被公司收集和处理，他们本就不应该在我主动选择加入之前收集任何信息。商业公司从来只尊重利润，对其他概不尊重。看到新闻说要放宽这些法律，还打着“人工智能”的旗号，真是令人不快。而他们又在试图推行“聊天控制”（Chat Control）这类东西，情况变得更糟了。
Europe is scaling back GDPR and relaxing AI laws #
https://news.ycombinator.com/item?id=45981361
There has been a change in the community here over the last decade, we’ve lost a lot of the hacker spirit and have a larger proportion of “chancers”, people who are only in tech to “get rich quick”. The legacy of ZIRP combined with The Social Network marketing.
radicalbyte
过去十年间，我们这里的社区氛围发生了变化，许多‘黑客精神’已经消逝，取而代之的是更多想‘快速致富’的投机者。这是零利率政策（ZIRP）与《社交网络》这部电影营销共同留下的遗产。
Microsoft AI CEO pushes back against critics after… #
https://news.ycombinator.com/item?id=45985168
The fact that people are unimpressed that we can have a fluent conversation with a super smart AI that can generate any image/video is mindblowing to me.
It’s not that people are unimpressed with AI - they’re just tired of constantly being bombarded with it, and it sneaking its way into where it’s not wanted. “Generate any image you want!” “Analyse this thing with AI!” gets pretty tiring.
If I want AI I’ll actively seek it out and use it - otherwise, jog on.
hifix
人们能和这样一个能生成任何图像/视频的超级智能AI进行流畅对话，他们却毫无印象，这一点让我感到震惊。
人们并不是对AI本身不感兴趣，只是厌倦了无时无刻不被它狂轰滥炸，以及它悄无声息地渗透到不希望出现的角落。“生成你想要的任何图像！”“用这个AI分析一下这个！”真的让人很疲惫。
如果我需要AI，我会主动去寻找和使用它，否则，请走开。
Nano Banana Pro #
https://news.ycombinator.com/item?id=45995765
Google has been stomping around like Godzilla this week, and this is the first time I decided to link my card to their AI studio.
I had seen people saying that they gave up and went to another platform because it was “impossible to pay”. I thought this was strange, but after trying to get a working API key for the past half hour, I see what they mean.
Everything is set up, I see a message that says “You’re using Paid API key [NanoBanano] as part of [NanoBanano]. All requests sent in this session will be charged.” Go to prompt, and I get a “permission denied” error.
There is no point in having impressive models if you make it a chore for me to -give you my money-
ceroxylon
谷歌这周简直像哥斯拉一样横冲直撞，这是我第一次决定把我的信用卡绑定到他们的AI工作室。
我看到有人说他们放弃了，转去了别的平台，因为“支付根本不可能”。我觉得这很奇怪，但在过去半小时尝试获取一个能用的API密钥后，我明白他们是什么意思了。
一切都设置好了，我看到一条消息写着：“您正在使用付费API密钥[NanoBanano]，作为[NanoBanano]的一部分。本次会话中发出的所有请求都将被收费。”可我一去调用提示，就收到了一个“权限被拒绝”的错误。
如果你的模型再厉害，却让我花钱都这么费劲，那又有什么意义呢？
Europe is scaling back GDPR and relaxing AI laws #
https://news.ycombinator.com/item?id=45984688
I’ve stopped thinking of regulations as a single dial, where more regulations is bad or less regulations is bad. It entirely depends on what is being regulated and how. Some areas need more regulations, some areas need less. Some areas need altered regulation. Some areas have just the right regulations. Most regulations can be improved, some more than others.
energy123
我不再把监管看作是一个简单的旋钮，认为监管多了不好，监管少了就一定好。这完全取决于监管的对象和方式。有些领域需要更多监管，有些领域则需要更少。有些领域需要调整监管方式，有些领域的监管则恰到好处。大多数监管都有改进的空间，只是程度不同而已。
CBP is monitoring US drivers and detaining those w… #
https://news.ycombinator.com/item?id=45997140
It’s been fascinating watching the party of “small government” turn into one that supports ever expanding powers of a three letter agency whose job is supposed to be patrolling the border. It’s like a new 9/11 Patriot act moment, except it’s only one side supporting it this time.
hypeatei
看着“小政府”党派转变为支持一个三字母机构不断扩大的权力，而这个机构的职责本应是巡逻边境，这真是令人着迷。这就像一场新的“9·11”《爱国者法案》时刻，只不过这一次，只有一方在支持它。
Thunderbird adds native Microsoft Exchange email s… #
https://news.ycombinator.com/item?id=45982201
While its been a long time since Ive used Thunderbird, I just wanted to take the time to publicly say thank you.
Many HNers probably wont (or cant) remember the world of desktop mail clients but basically during the height of MSFT dominance there was only one real mail client: Outlook. Which Microsoft was starting to monetize heavily, ignore UX, and keep it windows only (cant blame them for that).
Then Thunderbird arrived on the scene, an OSS mail client that beat the pants off of Outlook in features, spam detection, IMAP support and a bunch of other things.
And it was free.
And you could use it on any machine.
This was a huge moment for OSS.
We owe a lot of credit to Mozilla and Thunderbird for rescuing us from a closed source world.
bnchrch
虽然我已经很久没用过雷鸟（Thunderbird）了，但我想借此机会公开地表达我的感谢。
很多 Hacker News 的用户可能已经（或无法）记起桌面邮件客户端的时代，但基本上在微软鼎盛时期，只有一个真正的邮件客户端：Outlook。而微软当时正在对其进行大规模商业化，忽视用户体验，并且坚持仅在 Windows 平台使用（为此他们无可指责）。
接着，雷鸟横空出世，作为一个开源邮件客户端，它的功能、垃圾邮件检测、IMAP 支持以及其他诸多方面都把 Outlook 甩在了身后。
而且它是免费的。
你可以在任何机器上使用它。
这对开源软件来说是一个重要的时刻。
我们欠 Mozilla 和雷鸟很多，感谢他们将我们从封闭源码的世界中拯救出来。
Gaming on Linux has never been more approachable #
https://news.ycombinator.com/item?id=45986917
I recently had my Framework Desktop delivered. I didn’t plan on using it for gaming, but I figured I should at least try. My experience thus far:
- I installed Fedora 43 and it (totally unsurprisingly) worked great.
- I installed Steam from Fedora’s software app, and that worked great as well.
- I installed Cyberpunk 2077 from Steam, and it just… worked. Big thanks to Valve for making this as smooth as it was. I was able to go from no operating system to Cyberpunk running with zero terminals open or configs tweaked.
I later got a hankering to play Deus Ex: Mankind Divided. This time, the game would not work and Steam wasn’t really forthcoming with showing logs. I figured out how to see the logs, and then did what you do these days - I showed the logs to an AI. The problem, slightly ironically, with MD is that it has a Linux build and Steam was trying to run that thing by default. The Linux build (totally unsurprisingly) had all kinds of version issues with libraries. The resolution there was just to tell Steam to run the Windows build instead and that worked great.
vinkelhake
我最近收到了我的 Framework 台式机。我本来没打算用它玩游戏，但觉得至少应该试一试。到目前为止的体验是：
- 我安装了 Fedora 43，结果（完全不出所料）运行得非常好。
- 我从 Fedora 的软件应用商店安装了 Steam，也运行得非常好。
- 我从 Steam 上安装了《赛博朋克 2077》，结果它……居然直接就运行了。
非常感谢 Valve，整个过程才会如此顺利。我能够从一个没有操作系统的状态，到《赛博朋克 2077》成功运行，全程没有打开任何终端或修改任何配置。
后来我又突然想玩《杀出重围：人类分裂》。这一次，游戏就是无法运行，而且 Steam 也没有显示日志。我找到了查看日志的方法，然后做了现在大家都会做的事——我把日志拿给 AI 看。MD 的问题（带点讽刺意味的是）在于它有 Linux 版本，而 Steam 默认试图运行这个版本。这个 Linux 版本（再次完全不出所料）在与各种库的版本兼容上存在一堆问题。解决方法很简单，就是告诉 Steam 运行 Windows 版本，结果就完美运行了。
CBP is monitoring US drivers and detaining those w… #
https://news.ycombinator.com/item?id=45997278
License plate scanners are one of the most under-appreciated violations of personal privacy that exist today.
It’s not just government use either. There are private companies that scan vast numbers of license plates (sometimes by driving around parking lots with a camera), build a database of what plate was seen where at what time, then sell access to both law enforcement and I believe private investigators.
Want to know if your spouse is having an affair? Those databases may well have the answer.
Here is a Wired story from 2014 about Vigilant Solutions, founded in 2009: https://www.wired.com/2014/05/license-plate-tracking/
I believe Vigilant only provide access to law enforcement, but Digital Recognition Network sell access to others as well: https://drndata.com/about/
Good Vice story about that: https://www.vice.com/en/article/i-tracked-someone-with-license-plate-readers-drn/
simonw
车牌扫描器是当今存在最不受重视、也最能侵犯个人隐私的行为之一。
这不仅仅是政府在用。一些私营公司也会扫描海量的车牌信息（有时会开着车在停车场里用摄像头拍摄），建立关于车牌何时何地被拍到的数据库，然后将数据库的访问权限出售给执法部门，我想也包括私家侦探。
想知道你的伴侣是否出轨吗？这些数据库很可能就能给你答案。
这是一篇2014年发表在《连线》杂志上关于Vigilant Solutions公司的文章，该公司成立于2009年：https://www.wired.com/2014/05/license-plate-tracking/
我相信Vigilant公司只向执法部门提供访问权限，但数字识别网络公司（Digital Recognition Network）也会向其他机构出售：https://drndata.com/about/
VICE杂志有一篇关于此的精彩报道：https://www.vice.com/en/article/i-tracked-someone-with-license-plate-readers-drn/
What Killed Perl? #
https://news.ycombinator.com/item?id=45982756
The backwards incompatibility of Perl 6 absolutely killed Perl.
There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Once you need to rewrite everything, there’s no reason to stay with something you know since you need to fully retool anyway.
As a Perl programmer since v5 was released, the confusion around 6 completely destroyed almost everyone’s enthusiasm, and immediately caused all new projects to avoid Perl. It seemed like 5 had reached the end of the line, and 6 was nowhere to be found. Nobody wants to gamble so many hours of their lives, and the future of their business, on such an uncertain environment.
If Perl 6 had any visible movement within the first few years, it might have survived, but it was a good decade before they even admitted Perl 6 might take longer than expected, and then more time after that before they admitted it should have been a new language. 6 was interesting for language geeks, and they probably did some cool things, but you can’t run a large popular project like it’s a small research project. That completely destroyed all momentum in the community. Perl 5 development only resumed far too late, after the writing was already on the wall.
Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle. Python only just barely survived the jump from 2 to 3. JavaScript can only survive this because there’s no other option in a browser.
orev
Perl 6 的不向后兼容性彻底扼杀了 Perl。
至今仍有许多语言在使用，它们存在各种缺陷和丑陋之处，但它们之所以得以保留，是因为它们依然保持着强大的发展势头，并且内置了大量遗留功能。因此，仅仅因为语言丑陋或老旧，并不足以让人们大规模地抛弃它。
一旦你需要重写所有东西，那就没有理由继续留在你所熟悉的平台上了，因为你反正也需要完全重新学习工具。
作为一名自 Perl 5 发布起就开始使用的 Perl 程序员，关于 Perl 6 的混乱局面彻底摧毁了几乎所有开发者的热情，并立即导致所有新项目都避开了 Perl。当时看起来，Perl 5 似乎已经走到了尽头，而 Perl 6 却杳无音信。没有人愿意用自己的生命时光和企业的未来，去为一个如此不确定的环境下注。
如果 Perl 6 在最初的几年里能展现出任何可见的进展，它或许还有生存的机会，但他们花了整整十年时间才承认 Perl 6 可能会比预期耗时更长，又过了更长时间才承认它本该是一门新语言。Perl 6 对语言极客们来说很有趣，而且他们可能确实做了些很酷的事情，但你不能把一个大型知名项目当成一个小型研究项目来运作。这完全摧毁了社区的所有发展势头。Perl 5 的开发重启得太晚了，当时一切都已为时已晚。
无论是比尔·盖茨还是林纳斯·托瓦兹，都理解向后兼容性是一个神圣不可侵犯的原则。Python 差点就没能从 2 版本成功过渡到 3 版本。JavaScript 之所以能存活下来，仅仅因为在浏览器环境中别无选择。
Building more with GPT-5.1-Codex-Max #
https://news.ycombinator.com/item?id=45983286
I would love to see all the big players put 1% of the effort they put into model training into making the basic process of paying and signing in suck less.
Claude: they barely have a signin system at all. Multiple account support doesn’t exist. The minimum seat count for business is nonsense. The data retention policies are weak.
OpenAI: Make ZDR a thing you can use or buy without talking to sales, already. And for those using containers or a remote system or really anything other than local development with the codex CLI, you really really need to fix this bug. I bet Codex could do at least the client part for you!
https://github.com/openai/codex/issues/2798
(Hint: Claude Code gets this right by default, despite the fact that everything else about Claude sign-in is a joke.)
Google: get all your B2B AI product managers in one room and tell them that they need to make one single product menu on one single webpage with all the pricing on that page and that the Google Cloud people are not permitted to make anything that isn’t actually logically Google Cloud depend on Google Cloud Billing. Your product cannot compete with OpenAI or Anthropic if people need to ask an LLM to figure out what your product is and if your own fancy LLMs can’t give a straight answer. My company pays for a non-Google product primarily because it’s too complicated to pay for the Google product! Right now, trying to use Google’s AI is like trying to ride Bay Area public transit before the Clipper Card.
amluto
我真希望所有行业巨头，能将其在模型训练上投入的1%的努力，用于改善付费和登录这类基本流程的用户体验。
Claude：他们的登录系统简直形同虚设。不支持多账户切换。商业版的最小座位数要求太离谱了。数据保留政策也过于薄弱。
OpenAI：拜托了，让ZDR成为一款可以直接购买或使用的产品，别再强制用户联系销售了。此外，对于那些使用容器、远程系统，或者任何不通过 codex CLI（命令行接口）进行本地开发的人来说，你们真的、真的必须修复这个bug。我打赌，Codex 至少能帮你们搞定客户端这部分！
Google：把你们所有的B2B AI产品经理叫到一个房间里，告诉他们：他们需要在一个网页上创建一个统一的产品菜单，并列明所有产品的价格。同时，严禁Google Cloud团队让任何在逻辑上并非真正属于Google Cloud的产品，去依赖Google Cloud的计费系统。如果用户需要求助大语言模型（LLM）才能搞懂你们的产品是什么，而你们自己那些花里胡哨的LLM也无法给出明确答案，那么你们的产品就无法与OpenAI或Anthropic竞争。我们公司之所以购买非谷歌的产品，主要原因是购买谷歌的产品实在太复杂了！目前，尝试使用谷歌的AI，就像在湾区Clipper公交卡普及之前乘坐那里的公共交通一样。
Claude Code 在这方面默认就做得很好，尽管Claude的其他登录功能简直是个笑话。
Show HN: I made a down detector for down detector #
https://news.ycombinator.com/item?id=45976849
As a European solo developer, I’ve switched entirely to European alternatives for all my infrastructure since the beginning of the year.
Cloudflare > Bunny.net
AWS > Hetzner
Business email > Infomaniak
Not a single client site has experienced downtime, and it feels great to finally decouple from U.S. services.
spyridonas
作为一名欧洲独立开发者，我从年初开始就将所有基础设施完全切换成了欧洲的替代服务。
Cloudflare > Bunny.net AWS > Hetzner 商务邮箱 > Infomaniak
没有任何一个客户网站出现过停机，我终于摆脱了对美国服务的依赖，感觉太棒了。
Europe is scaling back GDPR and relaxing AI laws #
https://news.ycombinator.com/item?id=45983324
I sympathize with the startup argument: heavy compliance costs can stifle early innovation. But the solution shouldn’t be “weaker rules.” It should be smarter rules, clearer safe harbors for small actors, browser-level consent primitives for users, and stronger enforcement against dark-pattern CMPs. That keeps privacy meaningful without killing small businesses.
danishSuri1994
我认同初创公司的观点：高昂的合规成本会扼杀早期的创新。但解决方案不应是“更宽松的规定”，而应是更智能的规定、为小型参与者提供更明确的“安全港”、用户在浏览器层面的同意基础机制，以及对“暗黑模式”CMP（隐私合规管理平台）更严格的执法。这样才能在保护隐私的同时，又不扼杀小型企业。
Android/Linux Dual Boot #
https://news.ycombinator.com/item?id=45990978
sideloading
It’s called installing. Language matters and I see no reason to concede this point in Google’s favour.
24t
这叫安装。用词很重要，我看不出有什么理由要在这个问题上向谷歌让步。
Building more with GPT-5.1-Codex-Max #
https://news.ycombinator.com/item?id=45983533
I’ve been using a lot of Claude and Codex recently.
One huge difference I notice between Codex and Claude code is that, while Claude basically disregards your instructions (CLAUDE.md) entirely, Codex is extremely, painfully, doggedly persistent in following every last character of them - to the point that i’ve seen it work for 30 minutes to convolute some solution that was only convoluted because of some sentence I threw in the instructions I had completely forgotten about.
I imagine Codex as the “literal genie” - it’ll give you exactly what you asked for. EXACTLY. If you ask Claude to fix a test that accidentally says assert(1 + 1 === 3), it’ll say “this is clearly a typo” and just rewrite the test. Codex will rewrite the entire V8 engine to break arithmetic.
Both these tools have their uses, and I don’t think one approach is universally better. Because Claude just hacks its way to a solution, it is really fast, so I like using it for iterate web work, where I need to tweak some styles and I need a fast iterative loop. Codex is much worse at that because it takes like 5 minutes to validate everything is correct. Codex is much better for longer, harder tasks that have to be correct – I can just write some script to verify that what it did work, and let it spin for 30-40 minutes.
johnfn
我最近一直在大量使用 Claude 和 Codex。
我注意到 Codex 和 Claude 代码之间一个巨大的区别是：尽管 Claude 基本上完全无视你的指令（CLAUDE.md），但 Codex 却会极其痛苦、顽固地坚持遵循指令的每一个字符——以至于我曾看到它为了一个仅仅是因为我在指令中随手写下的、我自己已经完全忘记的句子而导致变得复杂的解决方案，而花了 30 分钟来绞尽脑汁。
我把 Codex 想象成一个“字面愿望精灵”——它会给你你要求的东西。不多不少，正是如此。如果你让 Claude 修复一个意外中写着 assert(1 + 1 === 3) 的测试，它会说“这显然是个笔误”，然后直接重写测试。而 Codex 则会重写整个 V8 引擎来破坏算术运算。
这两个工具各有其用武之地，我不认为哪种方法普遍更好。因为 Claude 会用一种“野路子”快速找到解决方案，所以速度非常快，我喜欢用它来迭代处理网页工作，这种工作只需要调整一些样式，并且需要快速的迭代循环。Codex 在这方面就差多了，因为它需要大约 5 分钟来验证一切是否正确。Codex 更适合那些需要绝对正确的、更长、更艰巨的任务——我可以写一个脚本来验证它的成果是否有效，然后让它自己花上 30 到 40 分钟去运行。
Building more with GPT-5.1-Codex-Max #
https://news.ycombinator.com/item?id=45983698
Claude basically disregards your instructions (CLAUDE.md) entirely
A friend of mine tells Claude to always address him as “Mr Tinkleberry”, he says he can tell when Claude is not paying attention to the instructions on CLAUDE.md when Claude stops calling him “Mr Tinkleberry” consistently
nico
克劳德基本上完全无视你的指令（CLAUDE.md）。我朋友让克劳德一直称呼他为“廷克尔伯里先生”，他说，当克劳德不再持续称呼他“廷克尔伯里先生”时，他就能看出克劳德没有在关注 CLAUDE.md 上的指令。
Cognitive and mental health correlates of short-fo… #
https://news.ycombinator.com/item?id=45985084
As someone who pays for YouTube, I don’t understand why I can’t disable shorts fully. They already have my money. What more do they want?
nverba
作为一个付费用户，我真的搞不懂为什么我无法彻底关闭Shorts。他们已经收了我的钱，还想怎样？
Gaming on Linux has never been more approachable #
https://news.ycombinator.com/item?id=45985945
Community forums/support from big companies like Microsoft and Adobe tend to be completely useless. In most cases, all threads follow the same flow:
-
Question with reasonable amount of detail.
-
A reply from some “Community Helper” (Rank: Gold): “did you try reading the help files?”
-
Another person with a “Staff” badge: “this isn’t our department”
[Thread closed.]
ronsor
像微软和Adobe这样大公司的社区论坛/支持通常完全没用。在大多数情况下，所有帖子都遵循相同的流程：
-
一个包含合理细节的问题。
-
某个“社区达人”（等级：黄金）回复：“你试过读帮助文件了吗？”
-
另一个带有“员工”徽章的人：“这不归我们部门管。”
[帖子已关闭。]
I just want working RCS messaging #
https://news.ycombinator.com/item?id=45976915
Yeah… I just started getting back into building sms/mms/rcs apps on Android and oh boy. It’s much more of a mess than I expected, and much more “oh so it’s basically just Google now, and they seem to be trying to lock it down further” than I expected (or hoped).
And you can’t even implement it yourself because it requires special permissions on Android, which you can only get if you’re a carrier/oem-blessed app. And the early “you’ll be able to build other apps, there will be an API like this: https://github.com/android-rcs/rcsjta " promises (which would put it on par with sms/mms) never materialized, despite a reference implementation that did exactly that over a decade ago.
At this point I’m just totally against RCS and I’m intentionally turning it off. Why hand all of your messaging communications over to Google, when they’ve got such a consistent history of being hostile? We’re much better off going back to telling people not to use sms (or mms or rcs) at all because it’s insecure.
Groxx
是啊……我刚重新开始在安卓上开发短信/彩信/RCS应用，天呐。这比我预想的要混乱得多，而且比我想象（或希望）的要严重得多，感觉“哦，原来这基本上就是谷歌说了算，而且他们似乎还试图进一步把它管死”。
你甚至都无法自己实现它，因为它需要安卓的特殊权限，而这些权限只有运营商或设备制造商授权的应用才能获得。早期那些“你将能够开发其他应用，会有这样的API：https://github.com/android-rcs/rcsjta”的承诺（本会让它达到与短信/彩信同等的水平）也从未实现，尽管早在十多年前就已经有一个完全实现了这一点的参考实现。
到了这个地步，我完全反对RCS了，并且我有意把它关掉。既然谷歌一直有这种不友好的“黑历史”，我们干嘛要把所有的消息通信都交给他们？我们最好还是回到劝别人根本别用短信（或彩信或RCS）的老路，因为它不安全。
Cloudflare outage on November 18, 2025 post mortem #
https://news.ycombinator.com/item?id=45973896
This showed up to Internet users trying to access our customers' sites as an error page indicating a failure within Cloudflare’s network.
As a visitor to random web pages, I definitely appreciated this—much better than their completely false “checking the security of your connection” message.
The issue was not caused, directly or indirectly, by a cyber attack or malicious activity of any kind. Instead, it was triggered by a change to one of our database systems' permissions
Also appreciate the honesty here.
On 18 November 2025 at 11:20 UTC (all times in this blog are UTC), Cloudflare’s network began experiencing significant failures to deliver core network traffic. […]
Core traffic was largely flowing as normal by 14:30. We worked over the next few hours to mitigate increased load on various parts of our network as traffic rushed back online. As of 17:06 all systems at Cloudflare were functioning as normal.
Why did this take so long to resolve? I read through the entire article, and I understand why the outage happened, but when most of the network goes down, why wasn’t the first step to revert any recent configuration changes, even ones that seem unrelated to the outage? (Or did I just misread something and this was explained somewhere?)
Of course, the correct solution is always obvious in retrospect, and it’s impressive that it only took 7 minutes between the start of the outage and the incident being investigated, but it taking a further 4 hours to resolve the problem and 8 hours total for everything to be back to normal isn’t great.
gucci-on-fleek
对于试图访问我们客户网站的互联网用户来说，这显示为一个错误页面，表明Cloudflare的网络内部出现了故障。
作为一个随机网页的访问者，我真的很欣赏这一点——这比他们那句完全不真实的“正在检查您的连接安全性”的提示要好得多。
此问题并非由任何形式的网络攻击或恶意活动直接或间接导致。相反，它是由我们其中一个数据库系统的权限变更所引发的。
同样，这里也体现了他们的诚实。
2025年11月18日11:20 UTC（本文中的所有时间均为UTC），Cloudflare的网络开始无法有效传输核心网络流量，并出现了严重故障。
到14:30，核心流量已基本恢复正常。在随后的几个小时里，我们努力应对网络各部分因流量集中恢复而激增的负载。截至17:06，Cloudflare的所有系统均已恢复正常运行。
为什么花了这么长时间才解决？我通读了整篇文章，我理解了这次故障发生的原因，但当大部分网络都瘫痪时，为什么第一步不是回退任何最近的配置更改，即使这些更改看似与故障无关？（还是我哪里读错了，文章里其实有解释？）
当然，事后看来，正确的解决方案总是显而易见的，而且值得称赞的是，从故障发生到开始调查只用了7分钟，但在此基础上又花了4个小时才解决问题，总共耗时8小时才恢复正常，这并不理想。
A $1k AWS mistake #
https://news.ycombinator.com/item?id=45978260
These sort of things show up about once a day between the three big cloud subreddit. Often with larger amounts
And it’s always the same - clouds refuse to provide anything more than alerts (that are delayed) and your only option is prayer and begging for mercy.
Followed by people claiming with absolute certainty that it’s literally technically impossible to provide hard capped accounts to tinkerers despite there being accounts like that in existence already (some azure accounts are hardcapped by amount but ofc that’s not loudly advertised).
Havoc
这类事情在三大云服务的子论坛上大概每天都会出现一次，而且往往涉及更大的金额。
情况永远如此——云服务商除了提供延迟的警报外，什么也不给，而你唯一的选项就是祈祷和乞求怜悯。
然后总会有人斩钉截铁地声称，对于 tinkers（爱好者/开发者）来说，提供真正有硬性上限的账户在技术上简直是绝无可能的，尽管事实上已经存在这样的账户（比如有些 Azure 账户是按金额硬性限制的，当然这不会被大肆宣传）。
Verifying your Matrix devices is becoming mandator… #
https://news.ycombinator.com/item?id=45988038
I decommissioned my server 3 months ago and migrated my community back to IRC. I still had the IRC Podman containers kicking around, so that was easy.
I dealt with ~monthly issues around my devices not being correctly verified, messages not correctly decrypting, and various other rough UX edges. There seemed to be a lot of velocity in the beginning but the last couple of years have addressed approximately nothing in terms of the UX and it’s a crying shame as Matrix/Element (I no longer fully understand the difference/relationship between these entities) had a lot of potential.
unbolted3032
三个月前我停用了我的服务器，并将我的社群迁移回了IRC。因为我手头还留着IRC的Podman容器，所以这个过程很顺利。
我过去每个月都要处理设备验证不正确、消息无法正确解密，以及其他各种糟糕的用户体验问题。Matrix/Element（我已不再完全清楚这两者之间的区别与关系）在初期似乎发展势头很猛，但过去几年里，其用户体验方面基本没有任何改进，这真是令人扼腕叹息，因为它本拥有巨大的潜力。