2026-11-06 Hacker News Top Stories #
- Özgün Kültekin 披露 musl 与无 PAM 的 OpenSSH 组合存在认证绕过,错误返回值与账户标记“*”相撞,漏洞有明确配置前提。
- Layer3 Intel 称,白宫所属 AS2650 在 30 天中有 26 天出现住宅代理出口,涉及 6 个地址、236 次观测和 28 家代理服务,但尚未定位设备。
- Alpine 为 3.16 至 3.24 等分支回补 OpenSSH 认证绕过修复,强调升级后重启 sshd,未运行 SSH 的容器不在受影响范围内。
- OpenAI 称,其 AI 安全管线验证了 948 个不同的 Linux 本地提权漏洞,消耗约 121 万美元 API 额度,生成的补丁仍须人工审查和上游接纳。
- Go 1.27 将 encoding/json/v2 与 jsontext 转为稳定 API,默认拒绝非法 UTF-8 和重复键,部分反序列化基准最高提速 10 倍,旧 API 继续支持。
- MarkBlah 的 Lemmings 用 CSS 绘制像素小人、用 JavaScript 驱动行走与碰撞,文字和按钮都能成为平台,还可拖拽、抛掷并随窗口缩放弹起。
- OpenAI 发布 Images 2.6,称生成速度提升 50%,Flare 低质量档最快 6 秒,并增加 GIF、API 图像标注与 SVG 导出等创作功能。
- Discord CTO 宣布客户端向 Rust 迁移,桌面端将移除 Electron、移动端保留原生 UI,早期 Windows 截图显示约 290MB 内存,尚无完整上线日期。
- Ricursive 发布 Apache 2.0 开放权重 Ripple-65B Preview,使用 12 万亿 token 训练,TerminalBench 2.1 自报 80.52 分,完整研发成本称为 3,200 万美元。
- 《窗外的鸟》引用实验讨论 LED 较少招虫,但原作者已承认紫外线解释有误;“吸引较少”不能被改写成“昆虫不会在 LED 周围聚集”。
1. sshole:musl 与 OpenSSH 的旧兼容逻辑如何变成密码认证漏洞 (sshole) #
安全研究员 Özgün Kültekin 用时间线追溯一个由多项兼容措施叠加造成的 SSH 认证漏洞:Unix 长期用“”表示不能匹配正常密码的账户;musl 为避免调用方漏查空指针而在 crypt() 失败时返回“”;OpenSSH 为缓解用户名枚举的计时差异,又会为某些账户借用其他用户的盐值。超过 musl 密码长度限制后,错误标记可能与目标账户字段相等,错误地通过认证。
作者称,他构建 glibc、musl、PAM 与非 PAM 等不同组合,投入约 17,600 次异常登录测试,并借助 AI 代理发现行为差异。文章把问题追溯至 2016 年,说明安全问题可能藏在看似无关的库约定与历史修补之间,而不在加密算法本身。
受影响并非所有 Linux:需要 musl、未使用 PAM 的 sshd、开启密码认证、目标账户字段为“*”,且系统存在另一具有相应密码哈希的账户。默认使用 Dropbear 的设备不能仅因采用 musl 就算受影响。OpenSSH 10.6p2 已修复;关闭密码认证也是缓解方式。Alpine 官方公告进一步明确:更新包后必须重启 sshd,默认禁止 root 密码登录等配置仍会限制可利用范围。
HN 热度 2221 points | 评论 557 comments | 投稿者:josemrb | 发布时间:2026-11-05 20:19:02 +08:00 #
https://news.ycombinator.com/item?id=50378228
- 问题来自 crypt() 的输入盐值与最终比较账户不再对应,不能只用“musl 返回星号”解释整条失效链。
- 把错误状态与有效数据放进同一种字符串表示,会让局部看似合理的兼容设计在组合后失去安全边界。
- 复现失败有时是因为安装到的包已包含修复,核对具体构建版本比只看发行版名称更可靠。
- OpenWrt 默认使用的 Dropbear 与 OpenSSH 是不同实现,不能把发行版或 libc 名称直接当作受影响判据。
- 网络设备测试经验强调,超长密码和异常输入应属于基础验收项目,即使管理层要求加快发布也不能省略。
- 存在十年的代码也可能缺少对冷门配置的检验,“经过时间考验”不能替代针对组合条件的测试。
- 为掩盖调用方错误而加入静默兼容补丁,可能让原本明显的失败变成长期隐藏且更危险的行为。
2. 白宫所属网络发现住宅代理出口,具体设备与人员仍未知 (Residential proxies detected on White House network) #
https://layer3intel.com/blog/residential-proxies-white-house-network
Layer3 Intel 在全球住宅代理监测中发现,美国总统行政办公室登记的 AS2650 网络出现可供公众购买的代理出口。其报告覆盖 2026 年 10 月 5 日至 11 月 3 日:监测管线经该网络成功出口 236 次,涉及 6 个地址,分布在 30 天中的 26 天;共有 28 家住宅代理服务能够提供这些出口。团队称,Spur 和 Synthient 的公开 IP 信息也将相关地址标为住宅代理。
作者解释,他们购买的是全球轮换代理服务,并非专门定向探测白宫。约一半观测发生在美国东部时间傍晚 5 点至午夜,凌晨很少,因此推测可能有常在该网络中的个人设备运行代理 SDK。但报告明确承认:数据能看到出口,不能识别实际设备或其使用者,时间分布也不足以证明具体感染来源。
风险在于,某些不安全的代理 SDK 曾被用于访问内网并横向传播;若这里也有同类缺陷,付费代理用户可能触及内部系统。这是条件性风险,报告没有展示白宫内网已被攻入或敏感资料已外泄。文章还列出圣赫勒拿等偏远地区的代理观测,说明其监测覆盖面;这些发现同样不能自动等同于已证实的设备入侵。
HN 热度 1244 points | 评论 427 comments | 投稿者:Rasbora | 发布时间:2026-11-05 04:45:18 +08:00 #
https://news.ycombinator.com/item?id=50371246
- 共享公网地址与运营商级 NAT 会让代理标签影响无辜用户,单个 IP 被标记不能直接证明某台终端感染。
- 即使当前只观察到出售带宽,代理基础设施也可能被用于更危险的远程任务,不能仅按流量成本评估风险。
- 排查应结合路由器出口流量和设备实际使用时段,单看总流量可能漏掉与正常视频播放重叠的代理行为。
- 代理 SDK 可能经商业应用条款合法捆绑,但默认开启或埋在协议中的授权未必构成充分知情同意。
- 如此敏感的网络归属结论需要可检查的方法和证据,不能只依赖一家新公司的检测标签。
- 把代理、匿名工具和恶意活动一概而论会削弱报告可信度,识别出口与追踪使用者也是不同能力。
- 住宅代理的核心隐患在于用户不知情和潜在内网访问能力,讨论时仍应与主动授权的匿名代理区分。
3. Alpine 发布 OpenSSH 认证绕过公告:升级后还须重启服务 (Alpine Linux Security Advisory: OpenSSH-server password authentication bypass) #
https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
Alpine Linux 官方公告要求符合条件的用户更新 OpenSSH 并重启 sshd,仅升级软件包不会替换正在运行的守护进程。问题出现在不使用 PAM 的密码认证路径:当账户密码字段为“*”、机器上另有使用 $5$ 或 $6$ 哈希的账户时,musl 的哈希失败返回值可能被误判为密码匹配。公告发布时尚未分配 CVE 编号。
公告列出的受影响版本包括已检查的 Alpine 3.21—3.24、edge,以及较老的 3.16—3.20。已修复的系统点版本包括 3.21.10、3.22.8、3.23.8、3.24.4;较老分支也发布了回补包。无法立即更新时,可关闭密码认证,并在验证配置后重启服务。
影响取决于配置:不运行 sshd 的容器、已关闭密码认证的系统,以及启用 PAM 的相应服务包不受这一漏洞影响。root 默认的 prohibit-password 设置仍有保护作用。tiny-cloud 旧镜像尤其值得检查:其 alpine 用户带“*”字段和免密码 doas,首次启动可以是安全的,但随后设置其他用户的相应密码哈希可能使条件齐备。公告建议检查异常的密码登录记录;无法排除入侵时,应按可能失陷处理。
HN 热度 549 points | 评论 114 comments | 投稿者:pantalaimon | 发布时间:2026-11-05 22:44:20 +08:00 #
https://news.ycombinator.com/item?id=50379704
- 为兼容漏查空指针的程序而偏离 crypt() 错误约定,可能把显式崩溃变成更难察觉的认证错误。
- 显式区分成功与失败的类型有助于减少哨兵值错误,但收益来自接口设计与开发惯例,而非语言名称本身。
- 这是字符串状态与认证控制流的逻辑缺陷,改用内存安全语言也不能自动修复同样的错误设计。
- Alpine 在容器中使用广泛并不意味着所有容器都暴露漏洞,还要确认是否运行 SSH 并开启密码认证。
- 长期不更新基础镜像会延长漏洞暴露期,发行版已经发布修复也不代表现有部署已经获得保护。
- 只使用 SSH 密钥的个人习惯不足以概括风险,还需检查机器上全部账户的密码字段及认证设置。
- 快速发布修复和持续观察副作用值得肯定,但响应速度仍需与后续质量验证一起评估。
4. OpenAI 报告用 AI 管线验证 948 个 Linux 本地提权漏洞 (A thousand fewer paths to root) #
https://openai.com/index/a-thousand-fewer-paths-to-root/
OpenAI 报告了一套覆盖漏洞发现、动态复现、可利用性评估、补丁生成和人工复核的研究管线。团队称,在 2026 年 10 月对 Linux 内核的一次扫描中,从 2,308 个去重候选中复现 1,724 个漏洞,获得 291 个信息泄漏概念验证,并将本地提权利用所对应的问题经变体分析归并为 948 份不同补丁。总 API 消耗为 1,213,430 美元,折合每个不同提权问题约 1,279 美元;这不是包含人工和全部基础设施的完整项目成本。
系统先筛出约 280 万行安全相关代码,再在隔离虚拟机中验证。提权测试使用正常启用多项缓解措施的桌面系统配置。文章另有缩减攻击面的 kernelCTF 类环境实验,但因兼容问题移除了 SLAB_VIRTUAL,不能把结果视为完全相同的官方环境成绩。
作者强调补丁仍需专家与维护者审查;扫描结束时,一些问题已被其他贡献者修复或讨论。早期还出现过代理靠“另一个漏洞”拿到 root 的假成功,因此后来增加独立路径核验。把结果按历史漏洞奖金折算的高回报只是条件性估算,尚非实际获奖收入。研究的启示是让自动发现配合去重、验证和修补,而非把生成报告或候选补丁等同于漏洞已消除。
HN 热度 471 points | 评论 351 comments | 投稿者:dangelosaurus | 发布时间:2026-11-05 07:33:14 +08:00 #
https://news.ycombinator.com/item?id=50372929
- 缺少按子系统、代码年龄和漏洞类型划分的数据,会限制外界判断结果能否推广到其他代码库。
- 应解释不同利用、共同根因与独立漏洞如何去重,庞大数量本身不足以说明每项发现都同样独立。
- 发现速度提高后,人工审查、上游合并和发行版分发可能成为瓶颈,安全收益取决于修复能否真正抵达用户。
- API 额度不能代表完整研究成本,历史奖金也不保证可领取,收益比较需要计入资格限制和工程投入。
- 与逐个补洞并行,应讨论缩小高权限代码、隔离驱动及形式化验证等减少整类风险的设计。
- 持续扫描新提交并随模型升级重新检查旧代码,可能比一次性审计更接近长期维护需求。
- 不能因 Linux 内核漏洞很多就断言所有软件更不安全,代码规模、实现语言与自动正确性约束都会改变风险。
- 用户隔离、容器和虚拟机的边界都需要持续投入,不能把大家习惯绕开某一边界当作它天然无需安全保障的理由。
5. Go 1.27 稳定推出 JSON v2:严格解析与真正流式处理 (A new Go API for JSON) #
Go 官方介绍,历经约六年设计、实验与反馈,encoding/json/v2 和 encoding/json/jsontext 在 Go 1.27 中成为稳定、普遍可用的标准库 API。目标不只是提速,还包括修正旧接口受兼容承诺限制而难以改变的默认行为:拒绝非法 UTF-8 与重复对象成员名、默认按大小写匹配结构体字段,并把 nil 切片与映射编码为空数组和空对象。
设计将 JSON 语法处理与 Go 类型映射分开:jsontext 负责 token 和完整值的流式读写,json/v2 处理序列化语义。新方法允许自定义类型直接使用 Encoder、Decoder,并把选项向调用链下层传递,避免旧接口要求完整缓冲、重复解析及某些递归场景中的平方级开销。调用方也能为任意类型指定编码策略。
性能并非全面十倍:官方称 Marshal 大致与旧版相当,具体场景可能略快或略慢,Unmarshal 基准中最高可改善十倍。新 omitempty 等语义可能影响现有程序,因此提供选项逐步迁移。旧 encoding/json 承诺无限期支持,并在内部借助 v2 与兼容选项维持原行为;应用没有被要求立即迁移。
HN 热度 384 points | 评论 199 comments | 投稿者:olexsmir | 发布时间:2026-11-05 01:52:11 +08:00 #
https://news.ycombinator.com/item?id=50369106
- jsontext 已被用于需要细致错误提示的客户输入解析,语法层与类型映射分离能服务比常规结构体解码更复杂的需求。
- 迁移时常用缩进操作的可发现性仍影响体验,熟悉的新接口不应要求开发者重新摸索简单任务的写法。
- 把 nil 自动输出为空容器可能抹去调用方依赖的区别,接口契约需要在迁移前逐项检查。
- 支持新默认值的一方指出,空查询结果通常应是空数组,泄露 Go 内部 nil 状态反而容易破坏 JSON 消费端约定。
- 序列化失败不能全部提前到编译期,非有限浮点数、自定义方法和运行时值都可能产生实际错误。
- 六年的落地周期体现了兼容性负担,也引出标准库基础能力改进速度是否足够快的质疑。
- 结合 schema 生成专门解析器和 SIMD 的思路值得探索,它试图兼顾静态类型安全与通用高性能 JSON 解析。
6. Lemmings 网页小人:CSS 精灵在真实页面元素上行走 (Lemmings CSS Animation) #
https://markblah.github.io/lemmings/
这个名为 Lemmings 的小项目把网页本身变成像素小人的活动场景。演示页布置了楼梯、浮空平台、坑洞、卡片与可换行文本,小人会在边框、按钮、图片和文字上行走,撞到墙转向,也会掉向窗口底部。用户可以抓起、拖动或抛出小人;窗口尺寸变化导致元素重新排版时,站在上面的小人也会被推动,快速缩放还能将其弹起。
README 说明项目只需一个脚本、没有依赖,精灵由纯 CSS 绘制,不需要图片素材。标题中的“CSS Animation”不能理解成整个交互只靠 CSS:项目由 JavaScript 脚本接入页面并提供增加小人的接口,CSS 主要承担精灵呈现。
演示还区分碰撞规则:文字行可以作为落脚面,但不会像墙一样挡住小人,以免它们卡在紧密排布的段落里;实体边框、按钮等则可以阻挡。它展示的是借用 DOM 排版制造互动的玩具,而非完整复刻原版关卡的游戏;项目说明也没有提供跨浏览器性能保证。
HN 热度 380 points | 评论 77 comments | 投稿者:MarkBlah | 发布时间:2026-11-05 12:54:10 +08:00 #
https://news.ycombinator.com/item?id=50375354
- 熟悉的像素行走与坠落动作能唤起强烈的童年游戏记忆,趣味来自细节而不仅是技术实现。
- 应把它理解为 JavaScript 与 CSS 配合的动画,标题容易让人误以为碰撞和运动全部由 CSS 完成。
- 增加到数百个小人后,Chrome 与 Safari 在动画流畅度、CPU 占用和滚动响应之间呈现不同取舍。
- 把更新节奏与 requestAnimationFrame 对齐可能改善页面响应,但这仍是待验证的优化建议。
- 移动端缩放和边缘坠落暴露出布局适配问题,桌面演示的趣味不能替代手机端测试。
- 它延续了 DHTML Lemmings 和桌面企鹅一类让小角色游走界面的传统,也激发了可在其他页面运行的玩法。
- 允许直接抓起和摆放角色,让浏览网页变成可探索的空间,这类小互动值得在工具化的网页之外保留。
7. Images 2.6 发布:更快生成、GIF 动画与 SVG 导出 (Images 2.6) #
https://openai.com/index/introducing-images-2-6/
OpenAI 推出 Images 2.6,覆盖 ChatGPT、Codex 和 API,重点是加快迭代、改善多轮编辑的一致性,并把静态图像扩展成 GIF 动画。公司称,用户目前每周通过这些产品生成约 40 亿张图片,新版生成速度比此前快 50%;API 中的 Flare 在低质量设置下最快约六秒,Sunburst 则针对中高质量任务提供更多细节与一致性。这些都是厂商发布口径,不代表每种请求都能达到相同耗时。
新能力包括通过图像标注精确指定编辑位置、导出 SVG,以及独立于 quality 的 complexity 参数:前者控制细节与保真度,后者调整模型为满足场景约束投入的规划程度。官方建议多数编辑任务采用低 complexity,复杂构图再提高;GIF 示例则包括以连续精灵帧制作角色循环动作。
公告称产品已面向各订阅层级和主要终端推出,API 提供 GPT-Image-2.6 Flare 与 Sunburst。文章没有给出覆盖各类工作流的独立质量比较,因此“更快”与“一致性改善”仍应按任务验证;不能仅凭新品发布就认定所有旧提示词、客户端或按张成本都保持相同表现。
HN 热度 376 points | 评论 233 comments | 投稿者:davidbarker | 发布时间:2026-11-05 07:35:44 +08:00 #
https://news.ycombinator.com/item?id=50372945
- 单 token 标价不变不等于每张图成本不变,用户测试指出部分低中质量设置会消耗更多输出 token。
- 新版质量评价出现分歧,有设计服务开发者回退 Flare,也有读者更喜欢同组 2.6 样图,结果明显依赖任务。
- GIF 能带来可用的新玩法,但已有用户发现连续精灵帧仍难保持一致,动画支持不等于角色稳定性问题已解决。
- SVG 导出值得关注,但位图到矢量的转换流程与直接生成原生矢量并非同一能力。
- 官网宣称已覆盖 Codex 仍需与具体客户端版本区分,发布时部分用户尚未获得对应 GIF 或模型能力。
- 设计工作仍需要外扩、精细局部调整和可控的最后一轮修改,基础出图质量提高不能替代编辑工具成熟度。
- 移动端分享 GIF 若先变成带静态图的页面链接,会增加直接发送动画给朋友的操作负担。
8. Discord 将以 Rust 替换 Electron,早期客户端展示约 290MB 内存 (Discord is ditching Electron and its new app uses less RAM) #
https://www.theverge.com/news/1027379/discord-ditching-electron-web-app
The Verge 报道,Discord 正把客户端迁移到 Rust,计划移除桌面的 Electron 和移动端的 React Native。CTO Stanislav Vishnevskiy 表示,公司自 2018 年开始采用 Rust,基础设施、语音技术和当前客户端已有部分使用该语言;下一步是让移动端保持原生界面,同时通过 Rust 与桌面端共享应用代码。
报道引用的一张早期 Windows 客户端截图显示约 290MB 内存占用,相比当前客户端加入若干服务器后容易达到约 1GB 或更多,呈现明显下降潜力。不过它是厂商展示的单次画面,没有公开等同账号、服务器数量、语音会话及后台状态的完整对照测试,不能直接推导每个用户都会获得相同比例的降幅。
完整迁移的时间表尚不明确,CTO 只称希望很快让用户测试。文章据此传达的是架构迁移计划和早期结果,而不是已向所有用户发布的新版本。移动端“保留原生 UI”也意味着共享的是应用逻辑,不能把“全 Rust”理解为每个平台的所有界面层都采用同一种实现。
HN 热度 369 points | 评论 321 comments | 投稿者:archb | 发布时间:2026-11-05 21:05:28 +08:00 #
https://news.ycombinator.com/item?id=50378625
- 现有客户端的内存负担是实际痛点,减少每个常驻应用的数百 MB 开销对同时运行多种工具的用户很有价值。
- 跨平台 Rust UI 的无障碍、中文排版与输入法支持需要单独检验,较低内存占用不能替代这些基本能力。
- “安装体积从 10GB 降到 10MB”之类说法缺乏依据,应与尚未公开测试的早期 Rust 版本区分。
- 另一种批评认为,频繁弹窗、促销和视觉干扰比框架本身更损害体验,重写不能自动解决产品设计问题。
- GPUI 的链式界面写法引发可读性争论,也有人主张用专门 UI 描述语言降低布局代码负担。
- 移除网页界面栈可能影响第三方样式与插件,自定义字体等既有能力是否保留仍值得关注。
- 关于 AI 大规模重写的讨论也担忧原团队的隐性知识流失,但现有报道不足以证明迁移全部由 AI 完成。
9. Ricursive 发布 Ripple-65B:650 亿参数稠密模型主打代理编程 (Ripple-65B Preview: U.S. Open-Weight SOTA on Agentic Coding) #
https://www.ricursive.com/ripple
Ricursive Intelligence 发布 Ripple-65B Preview,作为内部芯片设计模型的通用版本开放权重。它是 650 亿参数稠密 Transformer,预训练使用 12 万亿 token,宣称支持最高 100 万 token 上下文;模型卡采用 Apache 2.0 许可,提供指令模型及相关基础模型、低精度版本。发布方自报 TerminalBench 2.1 得分 80.52,称领先所列美国开放权重模型,这一限定不等于全球所有模型或所有编程任务第一。
团队选择 80 层、较窄隐藏维度的稠密架构,结合滑动窗口注意力等改动,以降低 NVIDIA 平台上的训练和部署复杂度。公司称,完整研发投入为 3,200 万美元,包含试验、数据、评估、调试及最终训练,并非只计最后一次预训练;与其他实验室成本的“一成”比较包含估计。强化学习阶段称仅用约 140 万次 rollout 就达到相应成绩。
模型卡也坦言代理基准复现受 harness、上下文及摘要机制影响,部分对手成绩由内部评估补齐,比较是尽力而为,并非统一第三方认证。能装入 DGX Spark 等设备不保证普通消费硬件都能高速度运行;总参数量较小也不能直接等价为比 MoE 的每 token 计算量更低。
HN 热度 331 points | 评论 120 comments | 投稿者:Philpax | 发布时间:2026-11-05 02:53:29 +08:00 #
https://news.ycombinator.com/item?id=50369925
- 只比较美国开放权重模型会缩窄“领先”的含义,用户仍需要与全球实际可选模型做同条件对照。
- 部分组织确实受到供应商司法辖区限制,因此美国来源这一筛选条件对合规采购并非毫无意义。
- 稠密模型与 MoE 不能仅按总参数量比较运行效率,活跃参数、内存带宽与推理配置都影响实际成本。
- 650 亿稠密参数对普通本地硬件仍可能很重,能容纳权重不等于能获得适合代理任务的响应速度。
- 高内存本地设备用户欢迎增加开放模型选择,愿意以一定速度换取离线运行与数据控制。
- 有用户在托管端测试中遇到多次工具调用失败,基准分数还需要与具体服务商和工具协议的可靠性分别验证。
- 面向芯片设计的公司发布通用编程成绩很有吸引力,但还需要解释这些能力如何转化为真实 EDA 与芯片设计收益。
- 选择模型前应等待更广的独立评估,并把量化后质量、速度和任务成功率纳入比较。
10. LED 不招虫?原作者已提示更正,实验结论需要限定 (Insects don’t swarm at LED lights) #
https://www.birdsoutsidemywindow.org/2026/11/03/insects-dont-swarm-at-led-lights/
《窗外的鸟》这篇文章从一户家庭更换 LED 后灯边壁虎变少的经历出发,讨论照明对昆虫聚集的影响。作者引用 2016 年一项比较白炽灯、紧凑型荧光灯、冷白与暖白 LED 的野外实验:在该实验条件下,LED 捕获的昆虫较少,包含较少的部分双翅目昆虫;两种白色 LED 之间没有显著差异。这是相对吸引力结果,不等于所有 LED 都不会招虫。
抓到的原文顶部已明确标出“即将更正”:作者承认关于白炽灯与 LED 紫外线的解释有误,并准备大幅修改。因而正文中把差异简单归因于“白炽灯有紫外线、LED 没有”的段落不能当成已核实的科学结论,家庭观察也无法单独排除虫口数量、亮度或光谱等因素。
为核对其飞行机制解释,另读取 2024 年《Nature Communications》原始研究。该研究通过三维轨迹分析认为,近距离灯光可能扰乱昆虫以背部朝向亮处的姿态控制,并非简单的“把灯当月亮导航”;研究还明确观察到 LED 可困住大量昆虫,并未系统比较波长效应。因此应将这篇文章理解为带有待改错误的科普讨论,而非“LED 不招虫”的定论。
HN 热度 305 points | 评论 160 comments | 投稿者:speckx | 发布时间:2026-11-05 03:50:23 +08:00 #
https://news.ycombinator.com/item?id=50370610
- 拖拉机灯、头灯和摄影补光灯仍有明显聚虫的使用经验,标题把全部 LED 一概而论过于绝对。
- 光谱、亮度、功率和热辐射等变量没有充分区分时,不能把实验差异单独归因于紫外线。
- 近距离绕灯飞行应区分姿态控制失灵与月亮导航,混用两种解释会掩盖原始研究的关键发现。
- 昆虫总体数量变化也可能影响人们的长期观察,但它与更换灯具各自贡献多少仍需独立数据。
- 不同颜色的照明在现场表现不同,“LED”只是技术类别,不能替代具体光谱和环境条件。
- 材料发出荧光不一定证明灯具发射紫外线,可见蓝光本身也能激发某些荧光。
- 研究未覆盖的高压钠灯和专门设计的紫外 LED 提醒读者,不应把有限灯型实验推广成所有光源的通则。