## OpenBSD 防火墙 (pf) 更新：简化 IPv4/IPv6 转换 David Gwynne 提出了一项补丁，旨在简化 OpenBSD 数据包过滤器的 (pf) 处理地址族转换 (af-to) 的方式，该过程用于实现 IPv4 和 IPv6 网络之间的通信。目前，pf 中的 af-to 存在独特的限制——它仅适用于传入数据包并自动转发它们，导致代码复杂且连接为单状态。 Gwynne 的补丁移除了强制转发，允许转换后的数据包像 redirect-to (rdr-to) 一样，由本地网络堆栈更常规地处理。这简化了代码，消除了特殊情况处理。然而，此更改引入了一个要求，即操作员必须显式允许与 af-to 转换相关的传出流量，添加以前不需要的规则。 开发者正在寻求使用 af-to 的用户的反馈，以确保功能保持完整并收集潜在改进的意见。主要目标是简化代码，欢迎通过 tech@ 邮件列表以及直接方式提供关于补丁的意见。
每日HackerNews RSS
这个Hacker News讨论围绕IPv4/IPv6转换方案，起因于一篇关于OpenBSD上的“af-to”的文章，旨在简化这一过程。用户们讨论了当前方法的局限性，特别是像Jool（一个Linux内核模块）这样的工具无法转换本地发起的包。
Jool被认为是一个强大的选择，提供SIIT-DC和NAT64等模式，适用于不同的网络设置。`socat`等替代方案被提及用于更简单的单主机转换，但被认为可能速度较慢。 几位评论员澄清，只有在处理IPv6专用*服务器*时才*需要*转换，而双栈服务器上的进程则不需要。
对话还涉及6to4，作为为IPv4专用主机提供IPv6访问的另一种解决方案。最后，一位用户批评OpenBSD倾向于引入与其防火墙配置（pf）不兼容的更改，优先考虑语法糖而不是用户便利性和安全性。
## 理解执行环境：从裸机到无服务器 “在我的机器上可以运行！”的沮丧源于*执行环境*的差异——代码运行的阶段。实现可靠的软件需要理解和控制这个环境。本文追溯了这些环境的演变，强调了隔离性、性能和便利性之间的权衡。 从**物理机器**（完全控制，高成本）开始，旅程进展到**虚拟机**（强大的隔离性，操作系统开销），和**容器**（快速、轻量级、共享内核）。**进程沙箱**通过限制进程的系统访问来提供集中的安全性，而**虚拟环境**则隔离特定于语言的依赖项。 现代趋势倾向于分层方法——虚拟机托管容器，然后容器利用虚拟环境——以实现强大的工作流程。像 `uv` 和 `conda` 这样的工具旨在简化依赖管理。 越来越多的，**容器**正成为默认的执行单元，但仍然依赖于内核兼容性。**无服务器**平台完全抽象了基础设施，以便利性为代价。**WebAssembly (Wasm)** 引入了指令级别的新的隔离层，承诺可移植性和安全性。 关键要点？每个环境都代表一种权衡。选择合适的环境取决于识别需要一致性的*最低层*——硬件、内核、操作系统，或仅仅是依赖项。误解这些边界会导致微妙且通常是关键性的故障。
## 隔离的范围：摘要
最近的 Hacker News 讨论围绕一篇文章展开，探讨了计算环境中不同程度的隔离，从裸机到虚拟环境（如 Python 的 venv）和 WebAssembly。核心思想是，安全性并非仅仅在于选择*最*隔离的系统（如裸机），而是关于分层隔离技术以平衡安全性和实用性——成本、维护和能力。
评论者指出，每一层——虚拟机、容器、沙箱——都存在权衡。虽然增加抽象化可以降低隔离性，但它也能够实现诸如更轻松的升级和资源限制等功能。一种稳健的方法是结合多层，例如在裸机上隔离客户，同时在*该*环境中利用容器以实现灵活性。
讨论还涉及文章可能依赖于 LLM 生成的内容，一些人认为写作风格重复。其他提出的观点包括缺少隔离技术（LPAR、Firecracker 等）以及由于 JIT 编译器限制而导致的 WebAssembly 性能限制的复杂性。最终，对话强调需要根据特定用例定制解决方案，而不是采用一刀切的方法。
这篇帖子探讨了“链”在两个领域中的应用：数论和加密货币。在数论中，它关注**坎宁安链**，即一系列素数，每个数几乎是前一个数的两倍（2p ± 1）。链可以是第一类（2p+1）或第二类（2p-1）。虽然目前尚不清楚是否存在无限多个，但数学家推测存在所有长度的无限链——已知最长的分别是第一类和第二类，长度分别为17和19。文中还提到了**双生链**，它连接了形成两种类型的坎宁安链的素数。 帖子随后转向**Primecoin**，一种早期加密货币，利用素链发现作为其“工作量证明”。矿工通过找到指定长度的素链（坎宁安链或双生链），并将其与区块的哈希值关联来赚取Primecoin。难度通过改变所需的链长度进行调整，从而激励持续的素数探索。
这个Hacker News讨论围绕着**Primecoin**和其他**创新的工作量证明（PoW）加密货币**展开。原始帖子链接到一篇关于“质数链”的文章——具有特定关系的质数序列。
对话迅速扩展到探索各种替代PoW算法。用户提到了**Riecoin**（寻找密集的质数簇）、**Nexus**（稀疏的质数簇）、**Cuckoo Cycle**、**Monero的RandomX**（CPU优化）和**Chia**（内存密集型，在SSD上挖矿）。一个关键主题是创建既安全又抗拒专用挖矿硬件（如GPU）的PoW函数的挑战。
几位评论员强调了“有用的PoW”概念，例如**Ofelimos**，它旨在在验证交易的同时解决优化问题，以及**Gridcoin**，它奖励BOINC贡献者。然而，一些人对这些“有用的PoW”系统的长期可行性表示怀疑。Primecoin目前的市值约为250万美元，但它在2018年曾达到超过8300万美元。
## Bugbot：利用人工智能扩展代码质量 随着编码代理能力增强，代码审查成为瓶颈。为了解决这个问题，Cursor开发了Bugbot，这是一款人工智能驱动的代码审查工具，旨在识别拉取请求中的逻辑错误、性能问题和安全漏洞。Bugbot最初通过定性评估构建，其开发后来转向使用定制的“解决率”指标进行数据驱动的方法——衡量标记的错误是否在合并的代码中得到实际修复。 自2025年7月发布以来，Bugbot经历了40多次重大实验，将其错误解决率从52%提高到70%以上，并且每次审查标记的平均错误数量从0.4增加到0.7。一个关键的改进是采用“代理”架构，允许Bugbot动态推理、利用工具并调查可疑的代码模式。 现在，Bugbot每月为Rippling和Discord等公司审查超过两百万个PR，并且不断发展。当前的工作包括Bugbot自动修复（自动修复错误）以及探索持续代码库扫描，旨在在人工智能驱动的开发扩展时保持代码质量。
## Bugbot 与 LLM 代码审查：好坏参半
一则 Hacker News 讨论围绕使用 LLM 驱动的代码审查工具的体验，特别是 cursor.com 的 “Bugbot”。 一些用户报告 Bugbot 在识别真实错误方面出乎意料地有效——甚至能发现人工审查员遗漏的错误——而另一些用户则对其不一致性感到沮丧。
一个主要问题是，LLM 有时会推荐修复方案，然后在实施后又反驳这些修复方案。 这种“反复无常”引发了对混淆经验不足的开发人员的担忧。 一些人提倡以“仅请求”模式使用 LLM 审查，避免自动评论以保持清晰度。
这场辩论凸显了对质量的不同看法。 一些人认为 LLM 相对于糟糕的人工代码来说是一种相对的改进，而另一些人则优先考虑绝对的代码质量，并认为两者都不够好。 还有人担心开发人员会盲目地将 LLM 的建议视为绝对真理，即使这些建议值得怀疑。 最终，共识似乎是 LLM 审查可以作为标记错误的工具*有用*，但需要仔细的人工监督和批判性思维。
BGPScout.io功能定价（即将推出）登录全球BGP数据尽在掌握触手可及，访问来自全球数千个网络的全面边界网关协议数据免费演示账户实时更新通过我们的实时数据源系统访问BGP路由变更历史数据使用我们全面的历史数据库分析路由趋势API访问使用我们强大的API将BGP数据直接集成到您的应用程序中30,000+ ASN监控100+数据点2个国家/地区100+设施准备好开始了吗？加入BGPScout！立即注册查看定价BGPScout.io您的ASN搜索工具产品（即将推出）实时数据历史数据API访问企业解决方案资源文档API参考博客支持联系我们邮箱：hello (at) bgpscout.io© 2025 HIVE DATA CENTER INC. 版权所有。隐私政策
## BGP侦察：一种新型网络浏览器
一名开发者发布了[bgpscout.io](https://bgpscout.io)，这是一款旨在简化浏览边界网关协议 (BGP) 网络数据的工具。该创建者注意到，尽管原始数据唾手可得，但探索网络历史（网络出现的时间、位置和整体可见性）仍然很困难。
BGP侦察旨在通过允许用户按注册日期和地理位置浏览自治系统编号 (ASN)、可视化网络存在情况以及保存搜索以查找新网络出现情况来解决这个问题。该工具聚合了现有的公共数据，以便于访问。
该开发者正在寻求反馈，以确定这是否解决了实际问题，以及哪些功能使其对日常使用有价值。初步反馈表明，需要实时监控 BGP 在事件期间的变化，以及与现有免费工具（如[bgp.tools](https://bgp.tools/)）以及 HE.net 和 RIPE NCC 提供的工具进行比较。一些用户还报告了网站的可用性问题，例如链接损坏和需要登录。
旧金山正在通过一项新举措大幅扩大儿童保育的可及性，旨在解决该市高昂的生活成本。在市长卢里的“家庭机会议程”下，年收入低于23万美元的家庭将获得免费儿童保育，而年收入高达31万美元的家庭将获得50%的补贴。 这扩大了之前的资格标准，之前的标准仅限于地区中位收入的110%。 该计划由先前批准的税收措施提供的超过5.5亿美元资金支持，旨在使目前每年每名儿童花费2万至3万美元的儿童保育费用更实惠。与此同时，纽约和新墨西哥等其他城市和州也在探索普及或免费的儿童保育方案。 旧金山的方案采用地区中位收入，而不是联邦贫困指导方针，以此来认识到该地区的独特支出。 目标是将儿童保育费用降低到家庭收入的推荐比例7%，即使对于湾区的高收入家庭来说，这仍然是一项艰巨的任务。
## 旧金山计划提供免费托儿服务 – 摘要
旧金山计划向年收入高达23万美元的居民提供免费托儿服务，并为年收入高达31万美元的家庭提供50%的补贴。围绕这一消息的Hacker News讨论迅速转向了后勤和经济问题。
许多评论员质疑在旧金山这样昂贵的城市提供负担得起的托儿服务的可行性，提出了员工住房和交通问题。关于收入门槛，出现了一些争论，一些人认为门槛过高，会使收入更高的家庭受益，而牺牲了低收入家庭的利益。另一些人指出了“悬崖效应”——略高于门槛的收入可能会抵消这项福利。
对话还涉及更广泛的社会问题，例如大家庭支持体系的瓦解、高昂的生活成本以及对托儿劳动的重视程度。一些人认为该政策可能会阻止一位家长工作，而另一些人则强调了提高劳动力参与的可能性。最终，这场讨论揭示了围绕托儿服务可及性所交织的经济现实和社会价值观。
这份清单详细介绍了世界各地非凡的树木，它们因其年龄、大小、历史意义或独特的故事而闻名。这些树木的范围从古老的——例如大盆地刺松“玛土撒拉”，树龄达4700年——到巨大的，例如谢尔曼将军树，按体积计算是最大的单干树。
许多树木因其巨大的尺寸而引人注目；图莱树拥有最粗壮的树干，而海珀里翁则是已知最高的活树。另一些树木具有文化重要性，例如汉普顿大学的解放橡树，是非裔美国人教育的标志，或奥斯汀的条约橡树，曾是美洲原住民部落的会议场所。
一些树木已成为当地的传奇——博因顿橡树据说从一名被判谋杀罪的罪犯的坟墓中生长出来，而“拥有自己的树”在法律上被承认为拥有其周围的土地。独特的案例包括具有可供车辆穿行的孔洞的吊灯树，以及被雕刻成艺术形式的马戏团树。这个系列展示了人类对这些自然奇观的持久力量和迷恋。
## 独立树木：黑客新闻讨论摘要
一个由维基百科“独立树木”列表链接引发的黑客新闻帖子，引发了关于著名树木的迷恋、编目它们的挑战以及可用信息的惊人深度的热烈讨论。
用户分享了发现本地树木地图的故事，利用现有数据（如园林部门记录）进行研究的效率，以及人们与特定树木建立的情感联系。对话内容从幽默的——一棵“被”公园长椅吞噬的树，一棵树促进……活动——到令人心痛的，提及被砍伐的古树以及最近因人为破坏而失去的赛可莫尔间隙树。
许多评论者强调了维基百科收集这些小众记录的价值，而另一些人则争论了该平台的编辑性和潜在的偏见。讨论还涉及森林砍伐、树木的寿命（尤其是红杉和刺松），以及全球树木的惊人数量（估计为 3 万亿）。最终，该帖子庆祝了独立树木对人们和社区的独特个性和重要意义。
## 关于ThinkPad的真相 围绕ThinkPad的流行说法——耐用、可修复且价格实惠——很大程度上是对联想/IBM商业模式的误解。这些笔记本电脑并非为了*你的*利益而设计，而是为了通过向企业批量销售和有利的服务合同来最大化利润。 ThinkPad之所以易于维修且寿命长，并非出于善意，而是因为最大限度地减少维修时间和更换次数可以最大化这些服务协议的利润。当合同到期时，企业会将这些笔记本电脑作为过时设备处理掉，从而形成二手市场，爱好者可以以低价购买它们。 这个循环今天仍在继续。虽然可修复性等功能在消费电子产品中可能不太常见，但它们仍然是ThinkPad设计的核心，仅仅是出于经济原因。 “廉价ThinkPad”并非源于联想的慷慨，而是企业将二手硬件视为电子垃圾的结果。 ThinkPad系列确实在持续的质量和工程方面有所特别，但这只是商业需求的结果，而非利他主义。如果你需要一台二手ThinkPad，请享受它，但要理解它的价值并非根植于企业的善意——而是特定市场和以利润为导向的设计的幸运结果。
## React 的 `act()` 函数：总结 `act()` 函数对于编写可靠的 React 测试至关重要，但常常被误解。它确保组件内的所有状态更新和副作用在你的测试断言运行之前被完全处理，防止测试检查到“旧”状态。 **为什么使用 `act()`？** 如果没有它，测试可能会错误地通过，因为断言发生在 React 完成组件更新之前。 **何时使用 `act()`：** 包装直接更新 React 状态的代码——手动状态更改、事件触发（尤其是使用 `fireEvent`）、定时器 (`setTimeout`)，以及使用 `renderHook()` 测试的钩子内部。 **不要包装：** React Testing Library 函数，如 `userEvent.click()`、`screen.findByText()` 和 `waitFor()` 已经内部处理了 `act()`。 **从 `@testing-library/react` 导入：** 始终使用 `import { act } from '@testing-library/react'` 以确保兼容性和正确的环境设置。 **调试“更新未被 act 包装”：** 此警告意味着你的测试可能断言的是过时的状态。将有问题代码包装在 `await act(async () => { ... })` 中，或者更好的是，使用 `waitFor()` 或 `findBy...` 等待预期的状态。优先避免不必要的 `act()` 调用，以加快测试速度。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
关于 React 测试中 act() 的所有信息 (howtotestfrontend.com)
15 分，by howToTestFE 2 天前 | 隐藏 | 过去 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
去年11月，肯塔基州发生一起UPS MD-11F货机坠毁事故，造成15人死亡。调查人员认为，事故很可能源于一个已知的结构缺陷，该缺陷可追溯到15年前。国家运输安全委员会（NTSB）调查发现，发动机安装组件存在裂纹和疲劳断裂——波音公司此前已经在四架其他飞机上发现了同样的问题。 尽管有之前的发现，波音公司认为该缺陷不会危及飞行安全，并发布了一份非强制性的“服务通知”，建议进行目视检查。专家认为，鉴于该组件在将发动机连接到机翼上的关键作用，波音的这一结论“非常不同寻常”。 这起事故加剧了对波音公司安全实践的日益关注，此前该公司曾出现737 Max问题和最近的质量控制问题。波音公司表示，将继续支持NTSB的调查，并向受影响者表示慰问。调查仍在进行中，最终报告尚未发布。