1991年9月17日，AT&T位于33 Thomas Street的常规发电机切换触发了电压尖峰，跳闸了一个调试不当的继电器，并使20楼整流器离线；电池在6.5小时内静默向纽约联邦航空管理局传输设备舱供电48V。四个失效的报警链路——一个烧毁的灯泡、一根缺失的25英寸搭接带、一个被夹住的铃铛，以及没有人员巡检/交接——阻止了故障被发现。下午4:30，一名技术人员发现低压报警，但重新连接整流器失败，因为亏空的电池在负载仍接通时无法接受充电电流。下午4:40，电池耗尽，关闭DS3机柜，并切断了与纽约TRACON以及JFK/LGA/EWR之间的雷达、无线电和飞行计划链路。管制员使用了备用系统和手动继电器；1,174个航班被取消或延误，超过85,000名乘客受到影响。恢复耗时七小时以上，需要先断开负载再复位整流器。AT&T最初指责技术人员，随后指责一名主管，而整改措施增加了自动重启整流器、负载分散、楼外遥测及其他控制措施。该事件说明了缓冲如何掩盖上游故障、冷启动可能使恢复超载，以及缺失的报警链路会静默失效。
每日HackerNews RSS
曼哈顿一个配电室在1991年导致FAA空中交通管制瘫痪。 One Manhattan power room took down FAA air traffic control in 1991
2 天前
Hacker News 上的一篇帖子链接到一篇文章，介绍 1991 年曼哈顿一间供电室导致 FAA 空中交通管制瘫痪的事件。讨论中，一位楼宇自动化技术人员解释了开放报警带如何因报警线仅在故障时通电而模拟正常运行的设备；这便是数字报警通常采用常闭、模拟传感器采用 4–20mA 的原因，以便将名义零与故障区分开。另一位评论者请求帮助定位曼哈顿公寓中持续的尖锐音调，回复建议使用带频率控制的定向“蝙蝠探测器”。其他评论对文章清晰的系统故障解释及被链接网站的设计作出回应。帖子中还包含无关评论和 Y Combinator 的申请通知。
Paul Tyma，雪城大学博士生和早期Java作者，回顾了他与科技记者Bob Cringely长达30年的友谊。Cringely在1996年读了他的Java书后首次联系他，随后雇他开发“Pronto”，一个从未发布的杂志下载系统。多年来，Cringely给Tyma发送创业点子，Tyma加入了两个项目，但他认为Bob真正的天赋在于屏幕魅力，而非创办创业公司。2001年，Tyma深夜邮件预言.NET会击败Java，被Cringely写成博客文章，激怒了Sun Microsystems，Tyma因此得到一件Sun T恤。2004年，Cringely转发了VH1的“极客”采访请求，让Tyma登上一档与Mark Cuban等人同台的节目。Tyma最后哀悼Cringely的去世，并重看他的经典视频。
对不起。
2026年10月20日，发现八张eMudhra中间CA证书的私钥被泄露，它们链向主要根证书计划信任的根证书。报告者于10月17日通过用每把私钥签名消息证明泄露。主要浏览器和操作系统厂商迅速行动：Firefox和Chrome于10月17日封禁证书，Apple于10月19日，Microsoft于10月20日；该问题于10月19日向下游信任库披露。此泄露可能让攻击者冒充任意网站，但主要厂商通过吊销分发（OneCRL、CRLite、CRLSets）缓解，且CA已吊销这些中间证书。不过，许多不消费吊销数据的客户端仍需软件更新。用户应尽快更新浏览器和操作系统；Linux用户可采用临时信任库变通方案。信任库运营者应查阅Mozilla的dev-security-policy讨论帖。八张受影响中间证书的详情见affected-certificates.json。
eMudhra/emSign 中间 CA 证书使用了极其脆弱的私钥签发：八个 ECC P-384 密钥为小单字节标量，可近乎即时恢复私钥。公司将此归因于在经批准的导出/封装测试中所用密钥生成脚本的缺陷，弱测试密钥被误用于 CSR 并由 Sectigo 交叉签名。这些中间证书已由浏览器和生态更新撤销/阻止，但非浏览器、嵌入式和不更新的客户端可能仍存在漏洞。在修复前未发现欺诈性浏览器信任证书。此事件重新引发了关于 Web PKI 设计的争论：任何 CA 都可为任何域名签发证书，浏览器之外的吊销机制薄弱，而 DANE 或名称约束等替代方案存在局限。eMudhra 可能被移出根证书计划。
Cloudflare 和 VoidZero 与 Owner.com 的 Max Schwenk 正在开发 tsrs，这是 TypeScript 编译器的 Rust 移植版，与 TypeScript 团队协作并在 Oxc 项目中进行。它不是分支；TypeScript 保留语言控制权。早期基准测试显示，在匹配配置下，tsrs 比 TypeScript 7.0 快达 8 倍，内存使用少约 70%，而 TypeScript 7.1 beta 快达 2.5 倍。选择 Rust 部分是因为 WebAssembly 和内存效率，从而可在浏览器、Workers 和嵌入式环境中进行类型检查。该项目旨在合并 tsc-rs 和 tsrs，通过自动同步保持上游兼容性，将优化回馈上游，并在稳定发布前减少行为差异。Cloudflare 计划进行更深入的集成，例如在 Oxlint 中进行类型感知 linting，同时与 TypeScript 社区协作。
Hacker News 讨论了 Cloudflare 的“tsrs”，这是 TypeScript 编译器的 AI 辅助 Rust 移植版本。帖子获得 383 点和 184 条评论。一位 TypeScript 团队成员表示，他们正在与 tsrs 维护者合作，tsrs 的一些优化正在为更快速、更精简的官方 TypeScript（包括 TS 7.1）提供参考，而 Cloudflare 的 WASM/oxlint 用例证明了这项投资的合理性。
评论者争论基于 Go 的 tsgo 是否仍值得维护，有些人认为 Rust 提供了更好的速度、内存效率和 WASM 可嵌入性，而其他人指出 AI 移植依赖现有架构/测试，可能引发可维护性担忧。报告的增益包括相较于 TS 7 最高约 8 倍的速度和约 70% 的内存减少，VSCode 类型检查大约快 3 倍。
技术讨论强调了 tsrs 的 arena 风格内存模型，它避免了 Rust 的 GC 问题，但引发了健全性/不安全问题。更广泛的主题包括 Rust 重写的炒作、AI 生成的代码、工具多样性，以及大多数项目是否需要如此极致的编译器性能。
2026年10月2日，333个被攻陷的Tor出口节点（约10%的出口节点）使用Ebury 1.8.3发起协同攻击。它们过滤端口以截获未加密邮件并中间人攻击SSH连接：经受感染节点出口的流量被重定向到12台拦截服务器。用户看到主机密钥变更警告；忽略这些警告会使攻击者窃取密码、观察命令，并用Ebury感染目标服务器。Tor网络健康团队于10月2日至5日响应，通知运营者，将中继标记为BadExit，并关闭这些中继；部分攻击者将其重新启动为中间中继。作者使用exitmap通过固定出口节点并比较SSH指纹/连接来源识别受感染出口，发现伪造指纹和重定向；sshesame揭示了基于Paramiko和Perl的Ebury安装。攻击者如何获得访问权限仍未知，但Ebury的历史表明可能存在更多被攻陷的中继。结论：将中继视为高价值目标，并使用SSH密钥/硬件密钥而非密码。
研究人员发现333个Tor出口节点（约占全部出口节点的10%）将SSH（22端口）重定向到12台拦截服务器，这些服务器运行基于paramiko的中间人攻击，窃取密码并试图部署Ebury恶意软件。作者使用exitmap工具报告这些节点；Tor网络健康团队通知运营者，运营者随后关闭了它们。此事件引发了关于防御与风险的讨论：SSH密钥认证（理想情况下使用硬件/FIDO2密钥）可防止密码被盗，验证主机密钥并重视SSH的指纹变更警告很重要；相互认证可限制中间人攻击的影响。评论者指出，运行出口节点存在法律与滥用风险，云提供商可访问来宾内存，且Tor约3000个出口节点数量很少。一些人讨论了SSH over Tor的合法用例，如匿名性与NAT穿越。总体而言，此案强调了加强SSH防护与Tor使用卫生。
本网站正在使用安全服务以保护自身免受在线攻击。您刚才执行的操作触发了该安全解决方案。可能触发此封锁的操作有多种，包括提交某个特定词语或短语、SQL命令或格式错误的数据。
对不起。
作者用5万条AI生成的虚假统计数据搭建网站研究AI搜索。Google很快将其取消索引，但ChatGPT仍持续检索，产生1万+次会话和330+条反向链接；这些编造数字甚至出现在学术和金融研究中。实验显示大语言模型与Google不同：检索、重排序和实时抓取可能让低权威页面浮出，尤其是填补内容空白的统计数据。大语言模型偏好具体、新鲜、可引用的数字且不验证，造成引用洗白风险——重复引用会让虚假数据显得可信。作者建议做合法的统计页面：每句一个主张、来源与年份、标题匹配模型扇出查询、明确更新日期、服务端渲染HTML、结构简单、原始数据。追踪AI机器人、引荐会话、引用、反向链接和未链接提及。该策略不应替代更广泛的GEO策略，也不应被滥用。
Hacker News 正在讨论一个 peec.ai 实验： fabricated statistics 被发布到网上后，随后被 LLMs 引用，包括在学术论文和银行研究报告中。评论者认为这个问题并不完全新鲜—— misinformation 和 SEO 垃圾内容早已存在于网络——但 LLMs 通过移除来源上下文并以权威口吻呈现主张而使问题更糟。有些人提出可能的缓解措施：来源追踪、精选或官方来源、更好的 grounding，以及怀疑精神，但许多人怀疑这些是否能足够可靠。其他人强调，人类和系统最终必须信任来源，同时警告激励机制奖励作弊，且 LLMs 可能越来越多地在自身生成内容上训练。总体而言，该讨论强调虚假数据可通过 AI 工具传播，使验证和来源信任比以往更重要。
作者在 NixOS 服务器上开始使用 FreshRSS；此前 RSS 订阅只保存在手机上，其中的已读/未读状态很脆弱，且迁移时经常丢失。他们曾想使用服务器端订阅聚合器，但因部署和维护似乎太麻烦而避免。NixOS 使 FreshRSS 的设置（包括备份）只需几行代码加上 nginx 代理配置，并且运行稳定、几乎无需人工干预；损坏的服务器大约 15 分钟就能重建。这种可复现性让尝试新软件变得容易。相比之下，非 NixOS 安装需要很多手动步骤，容器镜像也会随时间漂移。作者不喜欢维护副项目，也发现其他配置/部署工具帮不上忙；NixOS 配置就像可执行、可复现的说明。
用户讨论 NixOS 的声明式、可复现系统配置，以及 LLM 代理（尤其是 Claude Code）如何让其晦涩的语法和摸索过程不再那么令人生畏。许多人称赞回滚、flakes、Home Manager 和一致的跨机器设置；其他人则指出 Nix 学习曲线陡峭、工具复杂以及硬件相关问题。有些人根据需求偏好 Arch、Omarchy、Guix、容器或 Ansible。评论者还讨论供应链信任、社区纷争与分叉，以及 LLM 是否降低了理解底层系统的必要性。总体而言，NixOS 被认为对可复现的开发和系统配置很强大，尤其在 AI 辅助下，但并非放之皆宜。
作者抱怨 iPadOS 27 破坏了 AirPlay 演示：在 iPad 上演示时，点击另一个窗口会使外部显示器显示完整的 iPad 屏幕，暴露私人笔记或投票结果并分散观众注意力。以前，控制外部显示器虽然别扭但可用；现在最近点击的应用会接管。效果因应用而异：GoodNotes 返回到演示者视图，Keynote 退出演示，PowerPoint 卡住。作者建议，任何处于演示模式的应用都应保持外部显示器优先，直到演示停止、文档关闭或应用退出。他们已在 Mac Power Users 提出问题，提交 Apple 反馈 FB23615646，目前不建议将 iPadOS 27 用于教学或演示。
该帖子讨论了 iPadOS 27 的一项变更破坏了演示工作流。此前，具有演示模式的应用可以在用户切换到其他应用查看笔记或控制时继续投屏到外部显示器；现在最近活跃的应用会接管显示器，暴露仅限演示者的内容。评论者就修复方案展开争论：显式选择窗口/应用、控制中心 AirPlay 接管、保持上一会话直到停止，或增加用户控制。许多人批评苹果“魔法式”设计移除了控制权、品控不佳以及年度发布 churn；另一些人认为新行为更符合朴素的 AirPlay 镜像预期或是一种权衡。更广泛的评论指出 iPad 作为通用计算机的局限性、硬件/软件不匹配以及可靠性问题。有人建议变通方案：多设备、有线显示器或替代工具。总体而言，用户希望外部显示器输出可预测且由用户控制，而非由操作系统推断。
Chessbook-1 是一个 199M 参数的人类风格国际象棋模型，旨在像 Lichess 上任意等级与时限的对手一样下棋。与 Maia-3 和 Allie 2.0 相比，它在闪电棋走法预测上与 Maia-3 持平，在所有时限和时间紧逼局面中优于 Maia-3，但在原始走法预测上略逊于 Allie 2.0，原因是 Allie 体积更大。它的主要优势在于校准：在每个等级段都能接近正确棋力，失误率与人类相仿，并能适应低剩余时间。它还能预测每步候选走法的思考时间，比 Allie 2.0 更贴合人类用时，并比 Stockfish 不考虑棋手等级的评估更准确地估计比赛结果。模型使用 64 个棋格 token、142 个特征、历史、等级和时钟；一个 18 层 transformer，采用 FiLM 条件化和 Smolgen 注意力；并在一次前向中预测走法分布、结果和 Beta 思考时间分布。它在 12 个月的 Lichess 对局上训练，服务速度足以支持在线对弈。
Hacker News 线程讨论了 Marc Buffett 花 10 个月打造类人象棋机器人的努力。链接的帖子关注机器人表现如何，而早期帖子解释了模型。评论者探讨传统引擎为何不像人类：人类依靠直觉、模式识别和浅层评估而非暴力计算。他们建议概率化走法选择、棋手画像以及更好的局面复杂度模型。一些用户最初报告不真实的失误，但后来发现机器人有趣且比弱版 Stockfish 更真实；计时/预先走子 bug 据称已修复。该机器人可通过 Chessbook 训练对局访问，目前处于抢先体验阶段。