## 全球粮食自给自足：摘要 最近的全球动荡凸显了粮食供应链的脆弱性，促使人们重新评估国家自给自足能力。对186个国家/地区的新分析，利用联合国粮农组织的数据和世界自然基金会“健康生活”饮食方案，揭示了一幅复杂的图景。虽然154个国家/地区可以满足7种必需食物组中的2-5种的国内需求，但圭亚那是唯一实现完全自给自足的国家。六个国家，主要在中东，无法通过本地生产满足其任何营养需求。 全球肉类自给自足率相对较高，但在乳制品（尤其是在非洲和 Oceania 地区）和鱼类（全球60%无法满足其一半需求）方面存在显著缺口。蔬菜自给自足率尤其低下，撒哈拉以南非洲地区面临重大短缺。 该研究强调了*应对多样性*的重要性——多元化进口来源——以减轻贸易中断。许多国家/地区严重依赖单一供应商，增加了脆弱性。虽然贸易至关重要，但过度依赖少数合作伙伴会带来风险。到2032年的预测表明，肉类和豆类方面可能会有所改善，但重大差距仍将存在，尤其是在乳制品和鱼类方面。最终，实现营养目标需要国际合作和转向可持续饮食。
每日HackerNews RSS
启用 JavaScript 和 Cookie 以继续。
## CVE-2026-31431 (“复制失败”) & 无 root 容器安全 本文详细分析并实际测试了 CVE-2026-31431 漏洞（“复制失败”），这是一种允许潜在权限提升的内核漏洞，并展示了无 root Podman 容器如何有效缓解该漏洞。作者反汇编了漏洞的 shellcode，发现它是一个完整的 ELF 可执行文件，旨在用恶意二进制文件覆盖 `/usr/bin/su`。 在运行无 root Podman 的 Fedora 43 虚拟机内的测试表明，该漏洞*成功地*在容器*内部*提升了权限。然而，由于 Linux 用户命名空间，容器的 root 用户被映射到非特权宿主机用户（UID 1000），从而阻止了任何宿主机层面的破坏。eBPF 追踪证实了内核的响应，`/proc/self/uid_map` 验证了 UID 映射。 关键要点是，虽然该漏洞在容器内部按预期工作，但无 root 架构的隔离阻止了它逃脱容器边界。这突出了用户命名空间在隔离潜在内核级权限提升方面的有效性，并强化了作者为 GNOME 的 GitLab runners 采用这种方法的决定。作者还建议在 OpenShift 中启用用户命名空间支持，以获得类似的保护。
注视你的汽车：现代汽车的广告基础设施
The Car That Watches You Back: The Advertising Infrastructure of Modern Cars
4 天前
启用 JavaScript 和 Cookie 以继续。
PGX 正在确保流行的 PostgreSQL 备份和恢复工具 pgBackRest 的持续稳定，现在以 **pgxbackup** 的名义进行。pgBackRest 由 David Steele 创建，以其可靠性以及并行处理、时间点恢复和强大的安全性等功能而闻名。
由于原始项目开发活动放缓，PGX 正在介入提供持续支持，以满足其客户的需求。这包括关键的错误修复、与新 PostgreSQL 版本的兼容性，以及确保现有备份仍然可以恢复——所有这些都尊重 Steele 避免以 pgBackRest 名义进行分叉的要求。
pgxbackup 仍然在相同的许可下开源，鼓励社区贡献错误报告和兼容性补丁。该项目可在 GitHub 上找到：[github.com/pgexperts/pgxbackup](github.com/pgexperts/pgxbackup)。
启用 JavaScript 和 Cookie 以继续。
最近《纽约客》的一项调查对萨姆·奥特曼和 OpenAI 提出了质疑，引发了对其可信度的担忧。虽然 Y Combinator 联合创始人保罗·格雷厄姆发表评论为奥特曼辩护，但讨论中缺少一个关键细节：Y Combinator 在 OpenAI 中拥有的巨额财务股份。 最初由 Y Combinator 的一个分支 YC Research 投资，OpenAI 现在估值 8520 亿美元。消息人士透露，Y Combinator 持有 OpenAI 约 0.6% 的股份，价值超过 50 亿美元。 作者认为，这种未公开的财务利益——影响格雷厄姆及其妻子（同样是 Y Combinator 的创始人）——在评估格雷厄姆支持奥特曼的公开声明时应予以考虑。虽然这并不一定否定他的观点，但由于数十亿美元的利益相关，潜在的偏见需要透明度。核心问题不是 *格雷厄姆是否* 辩护了奥特曼，而是 *为什么* 他的观点在没有承认他与 OpenAI 成功之间存在巨大财务联系的情况下被呈现出来。
## 人工智能时代的认知债务 一个日益增长的担忧是“认知债务”——系统复杂度和团队对其理解之间的差距，被生成式和代理式人工智能所放大。虽然人工智能提高了开发*速度*，但它可能会侵蚀对系统*运作原理*的“共同理解”，导致开发者迷失方向并对变更失去信心。 这不仅仅是代码质量的问题；它还会影响开发者的福祉，造成压力、疲劳和更重的审查负担。 就像技术债务一样，认知债务需要通过积极维护的文档、测试、对话，甚至人工智能代理来“偿还”——捕捉意图和原理，而不仅仅是代码。 传统的工程实践已经不够；人工智能降低了创造复杂性的成本，使得系统更容易超越理解范围。成功的团队需要主动适应，优先实践那些将意图外化并促进集体知识的做法。 关键问题是团队将如何利用人工智能来*支持*理解，而不是使其模糊不清，因为共同理解可能会成为最大的性能瓶颈。
## Windows 11 与老式 IPMI：校验和难题 排查与一台老式天雁（Tyan）服务器 IPMI 模块的网络通信问题出乎意料地困难。最初使用天雁的旧版软件和 Windows 本机 IPMI 工具（ipmiutil）在 Windows 11 和 10 上均失败。然而，Linux 的 `ipmitool` 连接却完美无缺，表明这是一个 Windows 特有的问题。 使用 Wireshark 进一步调查证实 UDP 数据包*到达* Windows 11 机器，但未被软件处理。PktMon 显示 TCP/IP 堆栈由于“无效校验和”而丢弃数据包，尽管 Wireshark 已经验证了它们。 解决方案？禁用问题 Windows 机器上 Intel 网卡驱动程序（e1r68x64.sys & e1i65x64.sys）中的 IPv4 UDP 接收校验和卸载。一台使用不同网络硬件的笔记本电脑无需此更改即可正常工作。 根本原因尚不清楚。作者怀疑是与 IP 数据包 ID 处理和 Intel 驱动程序中的 UDP 校验和卸载相关的冲突，可能由 IPMI 模块简单的包结构触发。虽然找到了解决方法，但该问题凸显了潜在的晦涩驱动程序行为，并引发了对某些 Intel 网卡校验和验证准确性的质疑。