Project Zero 的 Seth Jenkins 详述了他们开发的一条针对 Google Pixel 10 的新型零点击漏洞利用链,该工作建立在此前攻破 Pixel 9 的成果之上。原始的 Dolby UDC 漏洞(CVE-2025-54957)经少量调整后被移植到 Pixel 10,但由于 Pixel 10 使用 RET PAC 而非 -fstack-protector,利用中需要覆盖 dap_cpdp_init 而不是 __stack_chk_fail 。该更新后的利用链针对安全补丁级别为 2025 年 12 月或更早的未修补设备有效。 Seth Jenkins of Project Zero details the development of a new zero-click exploit chain targeting the Google Pixel 10, building on prior work that compromised the Pixel 9. The original Dolby UDC exploit (CVE-2025-54957) was adapted for the Pixel 10 with minor adjustments, though the Pixel 10's use of RET PAC instead of `-fstack-protector` required overwriting `dap_cpdp_init` instead of `__stack_chk_fail`. This updated exploit targets unpatched devices with a security patch level of December 2025 or earlier.
Project Zero 的 Seth Jenkins 详述了他们开发的一条针对 Google Pixel 10 的新型零点击漏洞利用链,该工作建立在此前攻破 Pixel 9 的成果之上。原始的 Dolby UDC 漏洞(CVE-2025-54957)经少量调整后被移植到 Pixel 10,但由于 Pixel 10 使用 RET PAC 而非 -fstack-protector,利用中需要覆盖 dap_cpdp_init 而不是 __stack_chk_fail 。该更新后的利用链针对安全补丁级别为 2025 年 12 月或更早的未修补设备有效。
利用链中的本地权限提升部分无法直接移植,因为 Pixel 10 上不存在 BigWave 驱动。不过,研究人员发现了 Tensor G5 上 Chips&Media Wave677DV VPU 的新驱动。该驱动由与 BigWave 相同的团队开发,直接将芯片硬件接口暴露给用户空间,允许用户态映射芯片的 MMIO 寄存器接口,而不是通过标准的 V4L2 API 。
在 VPU 驱动的 vpu_mmap 处理函数中发现了一个严重漏洞:该处理函数仅根据 VMA 的大小调用 remap_pfn_range,而没有将映射范围限定在实际寄存器区域的大小内。这导致用户态可以从 VPU 寄存器区域的物理地址起映射任意物理内存。由于内核镜像位于更高的物理地址,攻击者可以访问并修改内核。结合 Pixel 设备上固定的内核物理地址,这几乎是一种任意内核读写原语——实现基本原语只需五行代码,完成完整利用通常不到一天时间。
该漏洞于 2025 年 11 月 24 日被报告,Android VRP 将其评为高危(High),比类似的 BigWave 漏洞获得了更高的严重性评级。漏洞在 71 天后的 2 月 Pixel 安全公告中得到修补,这是作者报告的 Android 驱动漏洞首次在 90 天内被修复,反映了 Android 漏洞分类与修补流程的改进与加速。
尽管这是积极进展,研究仍强调 Android 驱动代码需更强的安全意识与更严格的审计。 VPU 漏洞在 BigWave 问题曝光仅五个月后被发现,表明相关驱动并未得到充分的横向审计。加强驱动安全仍是当务之急,建议厂商采取更主动的软件安全策略,强化代码审计与漏洞修补流程,防止类似问题流向终端用户。
Seth Jenkins of Project Zero details the development of a new zero-click exploit chain targeting the Google Pixel 10, building on prior work that compromised the Pixel 9. The original Dolby UDC exploit (CVE-2025-54957) was adapted for the Pixel 10 with minor adjustments, though the Pixel 10's use of RET PAC instead of `-fstack-protector` required overwriting `dap_cpdp_init` instead of `__stack_chk_fail`. This updated exploit targets unpatched devices with a security patch level of December 2025 or earlier.
The local privilege escalation component of the chain could not be ported because the BigWave driver is absent on the Pixel 10. However, a new driver for the Chips&Media Wave677DV VPU on the Tensor G5 chip was identified. This driver, developed by the same team behind BigWave, directly exposes the chip's hardware interface to userspace, including allowing userspace to map the chip's MMIO register interface, rather than integrating with the standard V4L2 API.
A critical vulnerability was discovered in the VPU driver's `vpu_mmap` handler. The handler calls `remap_pfn_range` based solely on the size of the VMA, without bounding it to the actual size of the register region. This allows userspace to map arbitrary physical memory starting from the VPU register region's physical address. Since the kernel image resides at a higher physical address, it can be accessed and modified. Combined with the kernel's fixed physical address on Pixel devices, this provides an arbitrary read-write primitive on the kernel with minimal effort, requiring only five lines of code for the basic primitive and less than a day for a full exploit.
The vulnerability was reported on November 24, 2025, and rated High severity by Android VRP, an improvement over the Moderate rating given to the similar BigWave bug. It was patched 71 days later in the February Pixel security bulletin, marking the first time an Android driver bug reported by the author was patched within 90 days. This demonstrates progress in Android's triage pipeline and efforts to patch serious vulnerabilities efficiently.
Despite this positive step, the research highlights the ongoing need for more robust and security-aware code in Android drivers. The VPU vulnerability was found just five months after the BigWave bugs were reported, suggesting that developers did not adequately audit their other drivers for similar issues. Strengthening driver security remains a crucial priority, and vendors are encouraged to adopt proactive approaches to software security, code auditing, and vulnerability patching to prevent such issues from reaching end-users.
Turso 正在终止运行近一年的漏洞赏金计划。该计划曾向能复现导致数据损坏的漏洞的提交者支付 1000 美元奖励,但大量低质量、 AI 生成的提交(被称为"slop")使得该计划不可持续。尽管计划识别出少数优秀的贡献者,经济激励却也吸引了大量自动化、无意义的拉取请求,耗费维护者大量时间来审核和驳回。 Turso is retiring its bug bounty program, which offered $1,000 for demonstrating bugs that lead to data corruption, after nearly a year of operation. The decision stems from an overwhelming influx of low-quality, AI-generated submissions, referred to as "slop," that have made the program unsustainable. While the initiative successfully identified a handful of exceptional contributors, the financial incentive attracted a flood of automated, nonsensical pull requests that consume significant maintainer time to review and dismiss.
Turso 正在终止运行近一年的漏洞赏金计划。该计划曾向能复现导致数据损坏的漏洞的提交者支付 1000 美元奖励,但大量低质量、 AI 生成的提交(被称为"slop")使得该计划不可持续。尽管计划识别出少数优秀的贡献者,经济激励却也吸引了大量自动化、无意义的拉取请求,耗费维护者大量时间来审核和驳回。
该计划最初是为了在重写 SQLite 时增强外界对 Turso 可靠性的信心。团队虽然采用了确定性模拟、模糊测试以及与 SQLite 的差分测试等严格方法,但也承认自动化测试有其局限。赏金的初衷是发现这些工具遗漏的边缘情况,起初确实有效——吸引了一些技术过硬的人,他们不仅发现了真实问题,还为测试基础设施的改进做出贡献。
然而,先进的 AI 工具改变了局面。 1000 美元的奖励成为一些人利用 LLMs 大规模生成漏洞报告的目标,不问真假就大量提交。例如有的 PR 故意破坏数据库头部便宣称发现"bug",或者误解并发写入等核心特性而提交错误报告。这类提交通常夹杂乱码和虚假断言,维护者要花数小时去处理,而提交者只需几分钟即可生成。
Turso 曾引入担保机制以自动关闭疑似机器人的提交,但这只促使机器人继续开新的问题,要求人工复核。生成 slop 的成本极低,而人工评估的成本很高,这种不对称使赏金计划难以为继。尽管 Turso 重视开放贡献模式,团队最终认为在开放体系中任何金钱激励都会被 AI 利用,不得不终止该计划,以维护维护者的精力和项目的完整性。
Turso is retiring its bug bounty program, which offered $1,000 for demonstrating bugs that lead to data corruption, after nearly a year of operation. The decision stems from an overwhelming influx of low-quality, AI-generated submissions, referred to as "slop," that have made the program unsustainable. While the initiative successfully identified a handful of exceptional contributors, the financial incentive attracted a flood of automated, nonsensical pull requests that consume significant maintainer time to review and dismiss.
The program was originally launched to bolster confidence in Turso's reliability as it rewrites SQLite, a system renowned for its stability. Despite employing rigorous testing methods like deterministic simulation, fuzzing, and differential testing against SQLite, the team acknowledged that automated tests have limitations. The bounty was designed to uncover edge cases their tools missed, and it initially worked well, attracting skilled individuals who found genuine issues and even contributed to improving the testing infrastructure itself.
However, the rise of advanced AI tools changed the landscape dramatically. The $1,000 reward became a target for users leveraging LLMs to generate bug reports at scale, regardless of validity. Examples include PRs that manually corrupt database headers and claim discovery of a "bug," or reports that misunderstand core features like concurrent writes. These submissions, often filled with garbled text and false claims, require hours of maintainer effort to address, while costing the submitters mere minutes to produce.
In response, Turso implemented a vouching system to auto-close suspected bot submissions, but this only led to bots opening new issues demanding manual review. The asymmetry between the low cost of generating slop and the high cost of human evaluation made the bounty untenable. Although Turso values its open contribution model, the team concluded that any financial incentive in an open system is now exploited by AI, forcing them to retire the program to preserve maintainer bandwidth and project integrity.
• 软件开发真正的瓶颈不是写代码,而是阅读和理解代码。 AI 生成的代码加剧了这一问题,因为它产出大量没人能完全理解的代码,包括 AI 自己。在我们能对 AI 的输出负责之前,不能把理解能力完全托付给它。
• "战术龙卷风"指的是那些能迅速产出代码但留下破坏性后果的开发者。管理层常因他们的速度而表扬他们,但对必须维护这些代码的工程师来说,他们并不是英雄。这类人往往在公司待很久,有时成为最后留下的工程师,而主张可维护性的人则选择离开。
• 在许多组织里,战术龙卷风往往没有任何惩罚,反而经常得到晋升和加薪。企业优先考虑快速上线以兑现销售承诺,因此无论代码质量如何,能快速交付的人都会被奖励。久而久之,许多工程师放弃了清理烂代码,只专注于把事情做完。
• 这种情况在管理层施压评审人员尽快合并代码时尤为严重,常以"如果我们为明天编码,我们永远也干不完"为由驳回关于可维护性的担忧。评审者最终学会放行这些开发者,接受以后有人来收拾烂摊子的现实。权力关系也会影响决策:资深或有影响力的开发者让别人很难反对。
• AI 可能成为终极的战术龙卷风,乐于添加数百行代码,用条件语句堆砌来修复问题,结果是交织混乱、难以理解的代码和臃肿的测试套件。虽然眼前的错误可能被修掉,测试覆盖率看似提高,但代码库的长期可维护性却在受损。
• 为了遏制 AI 生成的垃圾代码,有人提出对每次提交收取名义性费用(例如 5–10 美元),如果提交确有问题则退还。这样的金钱摩擦能过滤掉靠 AI "喷洒式"提交的恶意行为者,同时不会吓退认真的研究者。对被拒绝提交给予有质量的人工反馈,也会成为工程师宝贵的学习机会。
• 对漏洞赏金提交收费也可以推广到其他领域,例如对客户支持提交收取(例如 100 美元),以保证人工分类与升级。这能降低琐碎问题的噪音,确保真正的问题得到处理。但费用设计必须平衡,避免排斥低收入地区的用户或激励虚假的行为声明。
• 大型 PR 本身并非天生有害,只要组织得当且确为必要的基础性变更。然而,如果它们被用来规避适当的审查或引入不必要的重构,就会成问题。情境很重要:可信工程师在绿地项目上的大规模 PR,和中级工程师在无充分理由下重构成熟产品,是两回事。
• AI 生成代码与人类审查能力之间的不对称正变得越来越严重。 AI 能远快于人类生成和验证代码,但解决之道不一定是更多 AI 。相反,需要更好的流程:更小的迭代 PR 、更严格的审查标准,以维护代码质量。
• 一些组织在尝试限制 AI 生成的提交,比如要求工作量证明或先用 AI 预筛选 PR,但这些方案并不完美且实施成本可能很高。最终,问题可能需要系统性改变,比如对公共仓库采取"只读不动"策略,或建立类似行会的信任网络来审核贡献者。
• AI 生成的垃圾代码正在侵蚀开源协作——过去任何人都能贡献改进的模式正受到冲击。维护者被低质量 PR 和错误报告淹没,不得不关闭或限制贡献渠道。这种转变破坏了开源的社区精神,可能导致更多封闭、仅限邀请的社区出现。
• 尽管面临挑战,一些人认为 AI 将继续存在,必须学会适应。目前正在探索的解决办法包括对提交收费、使用 AI 过滤垃圾代码、建立基于声誉的信任网络;也有人主张完全关闭开放贡献模式,认为在 AI 噪音横行的时代,维持开放协作的成本超过收益。
讨论显示,在软件开发中快速采用 AI 与其带来的实际问题之间存在深刻张力。 AI 能加速代码生成,但常以可维护性、理解和信任为代价。无论是人类还是 AI 的"战术龙卷风",因速度被赞扬的同时也留下持久的损害,需要别人来收拾残局。社区正尝试各种应对方式——从金钱摩擦到贡献管理的系统性变革——但尚未达成共识。可以确定的是,开放、低摩擦的协作时代可能正在结束,取而代之的是更多门控和基于信任的模式。
• The real bottleneck in software development isn't writing code, but reading and understanding it. AI-generated code exacerbates this by producing massive amounts of code that no one fully understands, including the AI itself. Until we can hold AI accountable for its output, we cannot delegate comprehension to it.
• "Tactical tornadoes" are prolific programmers who pump out code rapidly but leave a wake of destruction. They are often celebrated by management for their speed, but they are rarely heroes to the engineers who must maintain their code. These individuals often stay at companies for decades, sometimes becoming the last engineers standing, while those who advocate for maintainability move on.
• In many organizations, tactical tornadoes face zero consequences and often receive promotions and raises. Businesses prioritize pumping out features to meet sales commitments, and engineers who deliver quickly are rewarded regardless of code quality. Over time, many engineers give up trying to clean up poor code and focus solely on getting work done.
• The situation arises when management pressures reviewers to merge code quickly, dismissing concerns about maintainability with arguments like "if we coded for tomorrow, we'd never get anything done." Reviewers eventually learn to let these developers proceed, accepting that they will have to clean up the mess later. Power dynamics also play a role, as senior or influential developers can make it difficult for others to push back.
• AI can be the ultimate tactical tornado, happily adding hundreds of lines of code wrapped in conditional statements to fix bugs. This results in interleaved, hard-to-understand code and bloated test suites. While the immediate bug may be fixed and test coverage may increase, the long-term maintainability of the codebase suffers.
• To combat AI-generated slop in bug bounty programs, one proposal is to charge a nominal fee (e.g., $5-$10) per submission, which is refunded if the bug is legitimate. This monetary friction would filter out bad actors using AI bots for spray-and-pray tactics while ensuring serious researchers are not deterred. Skilled human feedback on rejected submissions would also serve as a valuable learning experience for engineers.
• Charging for bug bounty submissions could extend to other areas like customer support, where a fee (e.g., $100) would guarantee human triage and escalation. This would reduce noise from trivial issues and ensure genuine problems are addressed. However, the fee must be balanced to avoid excluding users in lower-income regions or incentivizing false claims of intended behavior.
• Large PRs are not inherently problematic if they are well-organized and necessary for fundamental changes. However, they become problematic when they are used to bypass proper review processes or when they introduce unnecessary refactoring. Context matters: a massive PR from a trusted engineer on a greenfield project is different from an intermediate engineer refactoring a mature product without justification.
• The asymmetry between AI's ability to generate code and humans' ability to review it is a growing problem. While AI can produce code orders of magnitude faster than humans can verify, the solution isn't necessarily more AI. Instead, better processes, such as smaller iterative PRs and stricter review standards, are needed to maintain code quality.
• Some organizations are exploring ways to gatekeep AI-generated submissions, such as requiring proof-of-work or using AI to pre-screen PRs. However, these solutions are not foolproof and can be costly to implement. Ultimately, the problem may require systemic changes, such as moving to a "look but don't touch" model for public repos or establishing trust networks like guilds to vet contributors.
• The influx of AI-generated slop is ruining open source collaboration, which traditionally allowed anyone to contribute improvements. Now, maintainers are inundated with low-effort PRs and bug reports, forcing them to shut down or restrict contribution channels. This shift undermines the communal spirit of open source and may lead to more closed, invite-only communities.
• Despite the challenges, some argue that AI is here to stay and that adaptation is necessary. Solutions like charging for submissions, using AI to filter slop, and establishing reputation-based trust networks are being explored. However, others advocate for shutting down open contribution models entirely, arguing that the costs of maintaining them outweigh the benefits in an era of AI-generated noise.
The discussion reveals a deep tension between the rapid adoption of AI in software development and the practical challenges it introduces. While AI can accelerate code generation, it often does so at the cost of maintainability, comprehension, and trust. Tactical tornadoes, whether human or AI, are celebrated for their speed but leave lasting damage that others must clean up. The community is grappling with solutions, from monetary friction to systemic changes in how contributions are managed, but there is no consensus on the best path forward. What is clear is that the era of open, low-friction collaboration may be ending, replaced by more gated and trust-based models.
Amazon 员工正面临越来越大的压力,被要求把人工智能融入日常工作;但由于缺乏清晰的使用指导,一些员工为了满足使用预期而制造不必要的 AI 任务。据 Financial Times 报道,Amazon 通过内部工具 MeshClaw 追踪员工的 AI 代币消耗,有人仅为抬高数据而生成多余的 AI 代理,并未真正提升生产力。 Amazon employees are facing increasing pressure to integrate AI into their daily workflows, but the lack of clear direction on how to use it productively has led to some workers creating unnecessary AI tasks just to meet usage expectations. According to a report by the Financial Times, Amazon is tracking employees' consumption of AI tokens through its internal tool MeshClaw, and some workers are generating extraneous AI agents simply to inflate their numbers rather than to improve actual productivity.
Amazon 员工正面临越来越大的压力,被要求把人工智能融入日常工作;但由于缺乏清晰的使用指导,一些员工为了满足使用预期而制造不必要的 AI 任务。据 Financial Times 报道,Amazon 通过内部工具 MeshClaw 追踪员工的 AI 代币消耗,有人仅为抬高数据而生成多余的 AI 代理,并未真正提升生产力。
几位匿名员工描述了这样一种职场文化:AI 使用已成不可忽视的指标。一位员工说"使用这些工具的压力很大",有同事主要通过 MeshClaw 来最大化代币消耗。尽管 Amazon 表示 AI 使用统计不会纳入绩效考核,员工仍心存疑虑。另一位员工指出,经理确实在关注这些数据,追踪机制带来了"扭曲的激励",有人甚至把 AI 使用数据当成竞赛标尺。
据称,公司目标是每周有 80% 的开发者使用 AI,员工的代币消耗还在内部排行榜上显示。但 Amazon 否认这些说法,称公司没有全员统一的 AI 使用指标,也没有用于员工互比的内部排行榜,员工只能在个人仪表板上查看自己的使用情况。
MeshClaw 是争议的核心工具,灵感来自 OpenClaw——一款既有提升效率潜力又存在风险的工具。与云端模型不同,这两款工具都在用户的本地硬件上运行,因而拥有较高的自主性。这种独立性引发担忧:今年早些时候,Meta Superintelligence Labs 的对齐主管在使用 OpenClaw 时差点被删除整个邮箱,此事走红网络,凸显了赋予 AI 过多访问与控制权限的危险。
Amazon employees are facing increasing pressure to integrate AI into their daily workflows, but the lack of clear direction on how to use it productively has led to some workers creating unnecessary AI tasks just to meet usage expectations. According to a report by the Financial Times, Amazon is tracking employees' consumption of AI tokens through its internal tool MeshClaw, and some workers are generating extraneous AI agents simply to inflate their numbers rather than to improve actual productivity.
Several anonymous Amazon employees described a workplace culture where AI usage has become a metric that feels impossible to ignore. One worker said there is "just so much pressure to use these tools," with some colleagues using MeshClaw primarily to maximize their token consumption. While Amazon has told employees that AI usage statistics won't factor into performance evaluations, workers remain skeptical. Another employee noted that managers are paying attention to these metrics, and the tracking creates "perverse incentives," with some people becoming competitive about their AI usage numbers.
The company reportedly has a target of 80% of developers using AI each week, and employees' token consumption is tracked on an internal leaderboard. However, Amazon has pushed back on these claims, stating there is no company-wide metric for AI usage and no internal leaderboards where employees are measured against each other. Instead, the company says employees can only view their own AI usage on personal dashboards.
MeshClaw, the tool at the center of this controversy, is inspired by OpenClaw, another AI tool known for both its productivity potential and its risks. Unlike cloud-based AI models, both tools run locally on users' hardware, giving them significant autonomy. This independence has raised concerns, as demonstrated earlier this year when the director of alignment at Meta Superintelligence Labs went viral after OpenClaw nearly deleted her entire email inbox, highlighting the dangers of granting AI too much access and control.
多家大型科技公司正在推行激励或强制性的高 AI 代币消耗政策:有些企业把代币使用量纳入绩效考核,形成类似苏联式配额的扭曲激励,使得满足任意指标比提升实际生产力更重要。
在这种压力下,员工通过创建不必要的 AI 代理、用大模型处理琐碎事务或生成毫无价值的输出,人为抬高代币消耗。有报道说,某位员工通过自动化代理消耗的代币是同事的十倍,却因此获赞而非被质疑。
这与历史上的指标操纵类似:用代码行数(LOC)评估程序员会催生臃肿代码;"眼镜蛇效应"说明激励可能产生与初衷相反的结果——都应验了古德哈特定律:一旦指标成为目标,它就不再是有效衡量标准。
推动这种现象的因素多样:大力投资 AI 的高管需要证明支出合理,缺乏技术背景的管理层偏好易于追踪的指标,持有 AI 公司股权的企业希望推动收入增长,加之全行业的 FOMO——不论实际效用如何都要显得"AI 原生"。
相比之下,更有意义的指标像完成的故事点、引入的 bug 数量或交付功能的质量,显然比代币消耗更能反映产出。但领导层仍然关注投入指标,因为它们更容易在仪表盘上展示给利益相关者,即便这些指标与实际产出相关性很弱。
一些工程师确实开发出真正有用的 AI 应用——如自动化文档、跨平台代码库分析或自动生成测试用例——但这些生产性用途常被为追求代币数字的表演和大量需人工清理的低质量输出所掩盖。
这种现象并不限于单一公司,而是蔓延至多家 FAANG 企业和一些中小公司。有公司内部还建立了代币使用排行榜,尽管官方声称不会影响绩效,但无论是否创造实际价值,这类榜单都会形成隐性的消费竞争压力。
批评者把这类行为与历史及当下的浪费性支出相提并论:9/11 后情报机构的过度差旅、鼓励乘坐昂贵航班的差旅政策、资助无关学术旅行,乃至在发展中国家推广婴儿配方奶粉的营销手段——都是资金流动但未产出相应价值的例子。
环境影响也引发关注:大量"燃烧"代币需要依赖数据中心基础设施,耗费电力和水资源;一些地区通过税收优惠和廉价能源补贴吸引这些设施,而当地居民却承担更高的水电账单。
支持者认为,这种强制使用能促进探索与学习,逼着工程师尝试他们原本不会尝试的有价值用例;反对者则指出,当员工已经清楚工具的局限且真正有用的应用有限时,这种做法无非是在浪费资源。
更深层次上,这反映了现代资本主义的一种倾向:资金无论是否创造实际价值都要在实体间流动以显示增长,AI 代币消耗只是这种循环经济活动的又一载体,主要受益者往往是基础设施提供商,而回报却值得怀疑。
总体讨论揭示了对以指标驱动的 AI 管理文化的广泛不满:易于计量的投入指标(如代币消耗)取代了难以评估却更有意义的产出指标(如生产力或商业价值)。评论者频繁援引古德哈特定律和历史类比,说明激励结构会被操纵,员工倾向于优化被衡量的指标而非真正的组织目标。尽管有人承认 AI 工具存在正当用途,但普遍观点认为,通过绩效指标强制使用 AI 更多产生的是表演而非价值,浪费资源,并可能因把 AI 与官僚合规挂钩而阻碍实际采用。这一现象主要由高管证明 AI 投资合理的焦虑、管理者偏好简单仪表盘而非细致评估,以及全行业无视实际结果的从众压力所驱动。
• Multiple large tech companies are implementing policies that incentivize or mandate high AI token usage, with some incorporating token consumption into performance reviews, creating perverse incentives reminiscent of Soviet-style quota systems where meeting arbitrary metrics matters more than actual productivity.
• Employees are gaming these systems by creating unnecessary AI agents, running trivial tasks through LLMs, or generating worthless outputs purely to inflate their token usage numbers, with one employee burning 10x more tokens than peers through an automated agent and receiving accolades rather than criticism.
• This mirrors historical examples of metric manipulation like lines of code (LOC) measurements, where programmers wrote bloated code to meet quotas, or the "cobra effect" where incentives produce exactly the opposite of intended outcomes, all falling under Goodhart's Law where measures cease to be useful once they become targets.
• The push appears driven by multiple factors: executives who've invested heavily in AI needing to justify expenditures, managers lacking technical understanding defaulting to easily trackable metrics, companies with equity stakes in AI firms wanting to drive revenue, and industry-wide FOMO creating pressure to appear "AI-native" regardless of actual utility.
• Real productivity metrics like story points completed, bugs introduced, or quality of shipped features remain more meaningful than token consumption, yet leadership continues focusing on input metrics because they're easier to dashboard and present to stakeholders, even when these metrics correlate poorly with actual output.
• Some engineers report genuinely useful AI applications like automated documentation, codebase analysis across multiple platforms, or test generation, but these productive uses are overshadowed by the theater of token maximization and the generation of massive amounts of low-quality AI slop that requires extensive human cleanup.
• The phenomenon extends beyond Amazon to multiple FAANG companies and smaller firms, with some creating internal leaderboards tracking token usage despite disclaimers that it won't affect performance reviews, creating implicit pressure to compete on consumption regardless of value generated.
• Critics compare this to various historical and contemporary examples of wasteful spending: post-9/11 intelligence agency travel excesses, corporate travel policies that incentivized expensive flights, grant-funded academic travel, and even Nestlé's baby formula marketing in developing countries, all cases where money flowed without producing proportional value.
• The environmental impact concerns several commenters, who note that burning tokens requires massive data center infrastructure that consumes electricity and water resources, with some regions subsidizing this through tax breaks and cheap energy while local residents bear the costs through higher utility bills.
• Some defend the approach as forcing exploration and learning, arguing that mandating AI use helps resistant engineers discover valuable applications they wouldn't otherwise try, though critics counter that this wastes resources when employees already know the tools' limitations and actual useful applications remain limited.
• The situation reflects broader trends in modern capitalism where money must flow between entities to demonstrate growth regardless of tangible value produced, with AI token consumption becoming another vector for this circular economic activity that enriches infrastructure providers while producing questionable returns.
The discussion reveals widespread frustration with metric-driven management culture applied to AI adoption, where easily measurable inputs like token consumption replace harder-to-assess outputs like actual productivity or business value. Commenters consistently invoke Goodhart's Law and historical parallels to demonstrate how incentive structures inevitably get gamed, with employees optimizing for measured metrics rather than genuine organizational goals. While some acknowledge legitimate uses for AI tools, the consensus suggests that mandating usage through performance metrics creates theater rather than value, wastes resources, and may actually hinder adoption by associating AI with bureaucratic compliance rather than genuine utility. The phenomenon appears driven by executive anxiety about justifying AI investments, managerial preference for simple dashboards over nuanced evaluation, and industry-wide pressure to appear technologically progressive regardless of actual outcomes.
Radicle 是一个基于 Git 的开源点对点代码协作栈,旨在作为集中式代码托管平台的去中心化替代方案。与由单一实体控制的服务不同,Radicle 在主权网络上运行,仓库在节点间复制,用户对自己的数据和工作流拥有完全控制权。最新版 Heartwood 代表了协议的新一代,项目提供通过简单的 shell 命令安装或从源码构建的方式,目前支持 Linux 、 macOS 和 BSD 系统;对于偏好图形界面的用户,也提供桌面客户端。 Radicle is an open-source, peer-to-peer code collaboration stack built on Git, designed as a decentralized alternative to centralized code hosting platforms. Unlike services controlled by a single entity, Radicle operates on a sovereign network where repositories are replicated across peers, giving users full control over their data and workflow. The latest version, Heartwood, represents the most recent generation of the protocol, and the project provides installation via a simple shell command or building from source, currently supporting Linux, macOS, and BSD systems. A graphical desktop client is also available for those who prefer a visual interface.
Radicle 是一个基于 Git 的开源点对点代码协作栈,旨在作为集中式代码托管平台的去中心化替代方案。与由单一实体控制的服务不同,Radicle 在主权网络上运行,仓库在节点间复制,用户对自己的数据和工作流拥有完全控制权。最新版 Heartwood 代表了协议的新一代,项目提供通过简单的 shell 命令安装或从源码构建的方式,目前支持 Linux 、 macOS 和 BSD 系统;对于偏好图形界面的用户,也提供桌面客户端。
Radicle 的架构基于若干核心原则:使用加密身份来管理代码和社交工件,利用 Git 实现高效的数据传输,并通过自定义的 gossip 协议交换元数据。所有社交工件(如 issues 和 discussions)都存储在 Git 中,并用公钥密码学签名,保证内容的真实性和作者可验证性。该系统采用本地优先的设计,能够在无网络的情况下运行,且用户完全拥有自己的数据,便于迁移与备份。其模块化结构包含 CLI 、 Web 界面和 TUI,由 Radicle Node 与 HTTP Daemon 提供后端支持,并通过 Collaborative Objects (COBs) 实现可扩展性,便于开发者构建自定义的协作流程。
Radicle 采用定期发布的开发节奏,截至 2026 年 3 月,最新版本为 1.8.0,项目有频繁更新的历史,最近的发布包括 1.7.1 和 1.7.0,并在 2025 年中期推出了 Radicle Desktop 客户端。团队通过 Zulip 、 Mastodon 、 Bluesky 和 Twitter 等平台与社区积极互动,并维护博客,发布关于与 Jujutsu 集成、使用 Radicle CI 等主题的文章。鼓励通过 Zulip 或电子邮件提交反馈,相关内容会自动发布到专用频道。该项目在 MIT 和 Apache 2.0 许可下免费开源,欢迎社区贡献。
Radicle is an open-source, peer-to-peer code collaboration stack built on Git, designed as a decentralized alternative to centralized code hosting platforms. Unlike services controlled by a single entity, Radicle operates on a sovereign network where repositories are replicated across peers, giving users full control over their data and workflow. The latest version, Heartwood, represents the most recent generation of the protocol, and the project provides installation via a simple shell command or building from source, currently supporting Linux, macOS, and BSD systems. A graphical desktop client is also available for those who prefer a visual interface.
The architecture of Radicle is built on several core principles. It uses cryptographic identities for code and social artifacts, leverages Git for efficient data transfer, and employs a custom gossip protocol for metadata exchange. All social artifacts like issues and discussions are stored in Git and signed with public-key cryptography, ensuring authenticity and authorship verification. The system is designed to be local-first, meaning it functions without internet access and allows users to own their data for easy migration and backup. Its modular design includes a CLI, web interface, and TUI backed by a Radicle Node and HTTP Daemon, allowing for extensibility through Collaborative Objects (COBs) that enable developers to build custom collaboration flows.
Radicle's development follows a regular release cycle, with version 1.8.0 being the latest as of March 2026. The project has a history of frequent updates, including recent releases like 1.7.1 and 1.7.0, and the launch of the Radicle Desktop client in mid-2025. The team actively engages with the community through platforms like Zulip, Mastodon, Bluesky, and Twitter, and maintains a blog with posts on topics such as integrating with Jujutsu and using Radicle CI. Feedback is encouraged via Zulip or email, which is automatically posted to a dedicated channel. The project is free and open source under MIT and Apache 2.0 licenses, inviting contributions from the community.
我注意到您可能发错了内容。我是 OWL,一名专业的英中翻译。
如果您有英文新闻需要翻译成中文,请把原文发给我,我会按以下规则翻译:
1. 准确传达原文的事实与语境
2. 所有英文专有名词(人名、地名、术语)保留英文原文
3. 不遗漏信息,翻译完整
4. 将破折号("—")替换为句号(".")或逗号(",")
5. 绝不将名称、地名或术语翻成中文
请提供您需要翻译的英文内容。
Understood. I'm ready to analyze the Hacker News discussion you provide. Please share the bullet points representing the comments, and I'll create a concise summary following your specified format.
2026 年 4 月 23 日,一个纯 OCaml 实现的 CCSDS(Consultative Committee for Space Data Systems)协议栈,代号为 Borealis,在 DPhi Space 的 ClusterGate-2 载荷模块中成功在低地球轨道启动。该项目由 Parsimoni 开发,实现了端到端加密的命令与控制以及后量子密钥轮换,全部用安全的 OCaml 编写。这一里程碑是历经十年工程攻关、为 OCaml 5 带来安全且高性能多线程能力的成果;Parsimoni 团队把曾被戏言"会到达月球"的设想字面化,将协议栈部署到一颗每 90 分钟绕地球一圈的卫星上。 On April 23, 2026, a pure-OCaml implementation of the CCSDS (Consultative Committee for Space Data Systems) protocol stack, codenamed Borealis, successfully booted in low Earth orbit aboard DPhi Space's ClusterGate-2 payload module. Developed by Parsimoni, the project features end-to-end encrypted command and control with post-quantum key rotation, all written in safe OCaml. This milestone follows a decade-long engineering effort to bring safe, performant multi-threading to OCaml 5, which its creators speculated would eventually reach the moon. The team at Parsimoni took that vision literally, deploying the stack on a satellite that circles the Earth every ninety minutes.
2026 年 4 月 23 日,一个纯 OCaml 实现的 CCSDS(Consultative Committee for Space Data Systems)协议栈,代号为 Borealis,在 DPhi Space 的 ClusterGate-2 载荷模块中成功在低地球轨道启动。该项目由 Parsimoni 开发,实现了端到端加密的命令与控制以及后量子密钥轮换,全部用安全的 OCaml 编写。这一里程碑是历经十年工程攻关、为 OCaml 5 带来安全且高性能多线程能力的成果;Parsimoni 团队把曾被戏言"会到达月球"的设想字面化,将协议栈部署到一颗每 90 分钟绕地球一圈的卫星上。
Borealis 作为守护进程运行在 Arm SoC(四核 Cortex-A53 、 4 GB RAM)的托管载荷环境中。由于卫星没有直接的网络连接,系统采用延迟容忍网络模型,命令和遥测被序列化为 BPv7(Bundle Protocol version 7)包并写入文件系统,DPhi Space 的 API 在卫星过境时转发这些文件。为保障共享硬件上的安全——以防像 "Dirty Frag" 或 "Copy Fail" 之类的内核级漏洞破坏租户隔离——每个数据包都被封装在 BPSec(Bundle Protocol Security)扩展块中。这个加密信封对有效载荷进行加密和认证,确保即便底层 Linux 内核被攻破,卫星运营方或其他租户也无法读取、篡改或伪造内容。
系统还实现了 OTAR(Over-The-Air Rekeying)用于后量子签名密钥 ML-DSA-65,设计以覆盖卫星的 10 到 15 年寿命,允许运营方在无需物理重刷硬件的情况下进行密钥轮换。当前飞行循环在接收新密钥时即刻激活,但协议也支持更保守的地面驱动激活步骤,允许运营方在提交前验证安装。值得注意的是,一旦卫星在轨,主密钥并无轮换路径——在缺乏硬件安全元件(如 TPM)的长期任务中,这是一种现实存在的失败模式。
为提升性能,团队正在引入 OxCaml(Jane Street 的 OCaml 编译器分支)。通过使用 `exclave_ stack_` 注解将分配标记为栈绑定,开发者可以在热路径上消除垃圾回收压力。在一项涉及 2500 万个 CCSDS 包调度的基准测试中,该方法将单包 p99.9 延迟从 29 ns 降至 9 ns,并完全消除了 394 次次要 GC 。这种抖动的减少对具有严格调度截止的实时机载调度至关重要——这是欧盟 ORCHIDE Horizon Europe 项目的核心负载之一。
选择 OCaml 源于对数学严谨性与内存安全的需求:在该领域,C/C++ 的内存损坏约占严重 CVE 的 70% 。采用 OCaml 可消除一整类攻击面,例如在现有 C 库(如 NASA CryptoLib)中常见的堆缓冲区溢出。开发流程采用"纵深防御"策略:针对传输格式使用类型化 schema 、用 GADTs(Generalized Algebraic Data Types)在编译时强制有效的协议状态转换,并与参考实现做互操作测试。这遵循 nqsb-TLS 的做法:同一段代码既可作为飞行软件、地面软件,又可作为测试判定器,从而实现跨角色的逐字节比对。
Borealis 协议栈建立在为期十年的 MirageOS 生产级库之上,MirageOS 最初为云 unikernel 设计。尽管当前部署以 Linux 进程形式运行,而非 unikernel,但它展示了这些函数式系统的适用性。 Parsimoni 的下一个挑战是将该方案扩展到卫星编队,重点包括安全部署、签名更新、载荷隔离和认证。随着把硬件送入轨道变得常态化,行业中最有趣的问题正逐步转向软件层面,这与云计算的发展轨迹相呼应——最终,堆栈比服务器本身更重要。
On April 23, 2026, a pure-OCaml implementation of the CCSDS (Consultative Committee for Space Data Systems) protocol stack, codenamed Borealis, successfully booted in low Earth orbit aboard DPhi Space's ClusterGate-2 payload module. Developed by Parsimoni, the project features end-to-end encrypted command and control with post-quantum key rotation, all written in safe OCaml. This milestone follows a decade-long engineering effort to bring safe, performant multi-threading to OCaml 5, which its creators speculated would eventually reach the moon. The team at Parsimoni took that vision literally, deploying the stack on a satellite that circles the Earth every ninety minutes.
Borealis functions as a daemon running on an Arm SoC (four Cortex-A53 cores, 4 GB RAM) within a hosted-payload environment. Because the satellite lacks direct network connectivity, the system uses a delay-tolerant network model where commands and telemetry are serialized into BPv7 (Bundle Protocol version 7) bundles and written to a filesystem. DPhi Space's API then forwards these files during orbital passes. To ensure security on shared hardware where kernel-level vulnerabilities like "Dirty Frag" or "Copy Fail" could break tenant boundaries, every bundle is wrapped in BPSec (Bundle Protocol Security) extension blocks. This cryptographic envelope encrypts and authenticates the payload, ensuring that even if the underlying Linux kernel is compromised, the satellite operator or other tenants cannot read, modify, or forge the contents.
The system also implements OTAR (Over-The-Air Rekeying) for post-quantum signing keys (ML-DSA-65), designed to last the 10-to-15-year lifespan of the satellite. This allows operators to rotate keys without physically re-flashing the hardware. While the current flight loop activates new keys upon receipt, the protocol supports a more cautious ground-driven activation step where operators verify the installation before committing. The master key, however, has no rotation path once the satellite is in orbit, representing an honest failure mode for long missions lacking hardware-backed secure elements like TPMs.
Looking toward performance optimization, the team is integrating OxCaml, Jane Street's compiler branch for OCaml. By using `exclave_ stack_` annotations to mark allocations as stack-bound, developers can eliminate garbage collection pressure on the hot path. In benchmarks involving 25 million CCSDS packet dispatches, this approach reduced p99.9 latency from 29 ns to 9 ns per packet and eliminated 394 minor GCs entirely. This reduction in jitter is critical for real-time on-board dispatch with hard scheduling deadlines, a workload central to the EU's ORCHIDE Horizon Europe project.
The choice of OCaml is driven by the need for mathematical rigor and memory safety in a domain where C/C++ memory corruption accounts for roughly 70% of severe CVEs. By using OCaml, the team removes entire classes of attack surfaces, such as the heap buffer overflows found in incumbent C-based libraries like NASA CryptoLib. The development process relies on a "defense in depth" strategy: typed schemas for wire formats, GADTs (Generalized Algebraic Data Types) to enforce valid protocol state transitions at compile time, and interop testing against reference implementations. This follows the nqsb-TLS approach, where the same code serves as flight software, ground software, and a test oracle, allowing for byte-for-byte comparison across roles.
The Borealis stack is built on a decade of production-tested libraries from MirageOS, originally designed for cloud unikernels. While the current deployment runs as a Linux process rather than a unikernel, it demonstrates the versatility of these functional systems. The next challenge for Parsimoni is scaling this to a fleet of satellites, focusing on safe deployment, signed updates, payload isolation, and attestation. As launching hardware into orbit becomes routine, the industry's most interesting problems are shifting to the software layer, mirroring the evolution of cloud computing where the stack eventually mattered more than the servers.
- OCaml 被用于 2016 年 GHGSat-D 卫星的有效载荷软件:它作为 SystemD 服务通过 D-Bus 运行,使用对称密钥加密,且整个地面处理链也完全用 OCaml 编写,证明了 OCaml 在航天应用中的可行性。
- 在 GHGSat 星座中,16 颗卫星的有效载荷软件仍以 OCaml 为主,尽管较新的组件开始使用 Rust 编写;主要挑战是培训 OCaml 开发人员。
- 常见的困扰是公司声称找不到 OCaml 这样"冷门"语言的人才,但擅长这些语言的人往往难以获得机会,这表明问题更多源于地域、薪资等非技术性限制,而非人才本身短缺。
- OxCaml 在 Rust 和 OCaml 之间提供了一个吸引人的折衷:默认启用 GC,同时可通过栈分配注解在性能关键路径上消除 GC 压力,从而显著降低延迟。
- 在允许使用 Python 的平台上,OCaml 的开发体验通常优于 Rust:OCaml 提供更高效的开发周期,同时仍能保证较强的安全性。
- 只要将垃圾回收(GC)的影响限制在必要的区域,GC 语言就可以接近 C 的性能。 OxCaml 、 .NET 、 Java 等现代实现都表明自动资源管理并不必然导致性能劣势。
- 大型语言模型(LLM)在 Hindley-Milner 类型系统语言(如 OCaml)上的表现令人惊讶,通常能产出优于 Python 或 PHP 的代码,这可能得益于强类型系统作为可验证的"预言机"。
- OxCaml 被视为 Rust 在系统编程领域的有力竞争者:它兼顾安全性和可用性,但因需运行时支持,不适合某些 Rust 擅长的深度嵌入式场景。
- 在卫星软件的选择上,OCaml 被选中而非 Ada 、 Rust 或 Haskell,是因为它在开发速度与可靠性之间取得了良好平衡;OxCaml 的模式系统能在热路径上实现零 GC,同时让其余部分由 GC 管理。
- 卫星软件生态还面临一项挑战:许多 CCSDS 协议需要自行实现,因为缺乏可用的优质开源实现,尤其是 SDLS 安全层。
讨论显示对 OCaml 在航天领域的强烈支持;GHGSat 在 16 颗卫星上的成功部署提供了实证。关键矛盾在于 OCaml 的技术优势与实际招聘难题:与会者指出招聘困难更多来自非技术性限制,而非人才稀缺。 OxCaml 经常被提及为缓解 OCaml 性能问题的演进方案,在保持安全性的同时,可作为许多系统编程任务中 Rust 的可行替代。讨论还涉及语言设计的更广泛趋势:越来越多的 GC 语言采用栈分配等技术以最小化 GC 压力,从而挑战"自动资源管理必然性能低下"的刻板印象。
• OCaml was used for payload software on the GHGSat-D satellite in 2016, running as SystemD services over DBus with symmetric-key encryption, and the entire ground processing chain was also written in OCaml, demonstrating its viability for space applications.
• The GHGSat constellation's payload software remains mostly OCaml across 16 satellites, though newer components are being written in Rust, with the main challenge being developer training in OCaml.
• There's a recurring frustration about companies claiming they can't find talent in "weird" languages like OCaml, while developers skilled in these languages struggle to find opportunities, suggesting the issue is often other constraints like location or pay rather than actual talent scarcity.
• OxCaml offers a compelling middle ground between Rust and OCaml, providing GC by default with the ability to eliminate GC pressure on performance-critical paths through stack allocation annotations, achieving significant latency improvements.
• The development experience with OCaml is often preferred over Rust on platforms where Python is already allowed, as OCaml offers a nicer development cycle while still providing strong safety guarantees.
• GCed languages can achieve near-C performance when garbage is minimized to only necessary areas, with modern approaches in languages like OxCaml, .NET, and Java showing that automatic resource management doesn't have to mean poor performance.
• LLMs show a surprising facility with Hindley-Milner based languages like OCaml, often producing better code in these languages than in more mainstream ones like Python or PHP, likely due to the strong type systems serving as testable oracles.
• OxCaml is positioned as a competitor to Rust for systems programming, offering both safety and ergonomics, though it still requires a runtime making it unsuitable for some deeply embedded applications where Rust excels.
• OCaml was chosen over Ada, Rust, and Haskell for satellite software because it offers a good balance between development speed and trust, with OxCaml's mode system providing zero GC on hot paths while keeping the rest GC-managed.
• The satellite software ecosystem faces challenges with CCSDS protocols requiring custom implementations, as there are no good open-source implementations available, particularly for the SDLS security layer.
The discussion reveals a strong advocacy for OCaml in space applications, with real-world validation from the GHGSat constellation operating successfully across 16 satellites. A key tension emerges between OCaml's technical merits and the practical challenges of developer recruitment, with participants noting that hiring difficulties often stem from non-technical constraints rather than genuine talent shortages. OxCaml is frequently highlighted as an evolution that addresses traditional OCaml performance concerns while maintaining its safety advantages, positioning it as a viable alternative to Rust for many systems programming tasks. The conversation also touches on broader trends in language design, with garbage-collected languages increasingly incorporating stack allocation and other techniques to minimize GC pressure, challenging the assumption that automatic resource management inherently means poor performance.
Sam Smith 创建了一个名为 Geofile Explorer 的项目,通过把真实世界的位置呈现在电脑文件夹中,重新构想数字化探索。该项目仍在开发中,允许用户将地球当作电脑上的一个文件夹来浏览。用户可以拖放图片上传到文件夹,或右键单击添加文字笔记。该项目受多种基于网页的实验和工具启发,这些项目模拟桌面环境或以创造性方式探索数据,例如 Neal.fun 的 Wiki Files 、 Depths of Wikipedia 以及 Readme 文件中列出的其他项目。 Readme 还说明,"Wikipedia"和"Media"部分中的所有文件夹和文件均为 Wikimedia 及其各自所有者所有,并鼓励用户通过编辑 Wikipedia 和 Wikimedia Commons 来帮助完善文件夹结构。界面包含类似 Windows 的常用元素,如 "My Documents"、"Control Panel" 和 "Help and Support",为用户提供熟悉的桌面交互体验。该项目旨在借助文件系统的概念,使信息更易获取且更具互动性。 Sam Smith has created a project called Geofile Explorer, which reimagines digital exploration by presenting real-world locations as folders on a computer. The project is currently in progress and allows users to explore the Earth as a folder on their computer. Users can drag and drop images to upload them to the folder or right-click to write a text notes. The project is inspired by various web-based experiments and tools that simulate desktop environments or explore data in creative ways, such as Neal.fun's Wiki Files, Depths of Wikipedia, and others listed in the Readme file. The Readme also clarifies that all folders and files in the "Wikipedia" and "Media" sections are properties of Wikimedia and their respective owners, encouraging users to help improve the folder structure by editing Wikipedia and Wikimedia Commons. The interface includes standard Windows-like elements such as "My Documents," "Control Panel," and "Help and Support," suggesting a familiar desktop environment for user interaction. The project aims to make information more accessible and interactive by leveraging the concept of a file system.
Sam Smith 创建了一个名为 Geofile Explorer 的项目,通过把真实世界的位置呈现在电脑文件夹中,重新构想数字化探索。该项目仍在开发中,允许用户将地球当作电脑上的一个文件夹来浏览。用户可以拖放图片上传到文件夹,或右键单击添加文字笔记。该项目受多种基于网页的实验和工具启发,这些项目模拟桌面环境或以创造性方式探索数据,例如 Neal.fun 的 Wiki Files 、 Depths of Wikipedia 以及 Readme 文件中列出的其他项目。 Readme 还说明,"Wikipedia"和"Media"部分中的所有文件夹和文件均为 Wikimedia 及其各自所有者所有,并鼓励用户通过编辑 Wikipedia 和 Wikimedia Commons 来帮助完善文件夹结构。界面包含类似 Windows 的常用元素,如 "My Documents"、"Control Panel" 和 "Help and Support",为用户提供熟悉的桌面交互体验。该项目旨在借助文件系统的概念,使信息更易获取且更具互动性。 Sam Smith has created a project called Geofile Explorer, which reimagines digital exploration by presenting real-world locations as folders on a computer. The project is currently in progress and allows users to explore the Earth as a folder on their computer. Users can drag and drop images to upload them to the folder or right-click to write a text notes. The project is inspired by various web-based experiments and tools that simulate desktop environments or explore data in creative ways, such as Neal.fun's Wiki Files, Depths of Wikipedia, and others listed in the Readme file. The Readme also clarifies that all folders and files in the "Wikipedia" and "Media" sections are properties of Wikimedia and their respective owners, encouraging users to help improve the folder structure by editing Wikipedia and Wikimedia Commons. The interface includes standard Windows-like elements such as "My Documents," "Control Panel," and "Help and Support," suggesting a familiar desktop environment for user interaction. The project aims to make information more accessible and interactive by leveraging the concept of a file system.
在 Hacker News 上,用户们围绕新编程语言、开源项目、创业点子和行业趋势等话题展开讨论。有人分享软件开发、系统架构和人工智能方面的经验,也有人对某些技术的实用性及其未来发展提出质疑。总体氛围积极,参与者互相交流观点,共同探索技术创新的可能性。 I'm ready to analyze the Hacker News discussion. Please provide the bullet points representing the comments, and I'll create a concise summary following your specified format.
2026 年初,偏远的 Tristan da Cunha 岛爆发医疗紧急情况:一名从 MV Hondius 下船的岛民疑似感染汉坦病毒。岛上小医院的关键物资如医用氧气迅速告罄,随即向英国政府求援。 Tristan 岛极为孤立,距最近的 St Helena 机场约 1,510 英里且无飞机跑道,常规运输无法实现;国防部遂制定了一项前所未有的空投方案,动用伞兵与货物降落伞进行救援。 In early 2026, the remote island of Tristan da Cunha faced a medical emergency when an islander who had disembarked from the cruise ship MV Hondius fell ill with suspected hantavirus. The island's small hospital quickly began running low on critical supplies like medical oxygen, prompting urgent requests for assistance from the UK Government. Given Tristan's extreme isolation, 1,510 miles from the nearest airport on St Helena and with no airstrip of its own, conventional delivery was impossible. The Ministry of Defence devised an unprecedented plan: a military airdrop operation involving paratroopers and cargo parachutes.
2026 年初,偏远的 Tristan da Cunha 岛爆发医疗紧急情况:一名从 MV Hondius 下船的岛民疑似感染汉坦病毒。岛上小医院的关键物资如医用氧气迅速告罄,随即向英国政府求援。 Tristan 岛极为孤立,距最近的 St Helena 机场约 1,510 英里且无飞机跑道,常规运输无法实现;国防部遂制定了一项前所未有的空投方案,动用伞兵与货物降落伞进行救援。
任务在后勤上极为复杂,需周密策划。英国皇家空军的 A400M 运输机被选中执行,伴随一架 Voyager 空中加油机以应对长距离航程。物资和人员先在 RAF Brize Norton 集结,随后飞越约 4,200 英里抵达 Ascension Island,作为最后一段的出发点。 5 月 9 日凌晨,条件符合,代号 Flight RRR4989 的 A400M 自 Ascension 起飞;空中加油后飞往 Tristan,但受强风影响,抵达时间从原定的下午 3:30 推迟到约下午 5 点。
行动本身既精准又勇敢。来自 British Army Pathfinder 排的一队伞兵与一名顾问医生和一名 ICU 护士分两组跳伞入岛。首组伞兵从 7,000 英尺跳下,尽管风力强劲且多变,仍在 Back Fence 与高尔夫球场附近着陆,随即在 Patches 设立指引站,指挥后续物资投放;医务人员随后以双人伞降落,安全落在高尔夫球场。共计 3.3 吨医疗物资在 Patches 上空进行了三次低空投放,飞机最低飞行高度仅 175 英尺。
这是一场与冬日余晖竞速的救援。绝大多数物资当晚由岛民收集并运送到定居点,最后一批则在次日早晨取回。军事队伍受到社区热烈接待,住进当地宾馆,并在 Prince Philip Hall 设立临时基地。到 5 月 10 日星期日,所有物资已送达 Camogli Hospital,抵达的医务人员开始为人手吃紧的本地医护提供关键支持;病人被报告为情况稳定。
岛上对救援行动既感激又惊讶。行政长官 Philip Kendall 称赞了英国武装部队与政府的"惊人合力"。对居民而言,看到固定翼飞机低飞掠过定居点、降落伞缓缓降下,是一次既历史性又近乎超现实的经历,暂时掩盖了事件本身的危机感。社区与世界各地的支持者纷纷表达谢意;岛上警员 Barry Thacker 用诗歌纪念此事,向从伞兵和飞行员到当地厨师与通信员在内的所有参与者致敬。军事队伍将继续留岛执行医疗任务,任务完成后再乘船离开。
In early 2026, the remote island of Tristan da Cunha faced a medical emergency when an islander who had disembarked from the cruise ship MV Hondius fell ill with suspected hantavirus. The island's small hospital quickly began running low on critical supplies like medical oxygen, prompting urgent requests for assistance from the UK Government. Given Tristan's extreme isolation, 1,510 miles from the nearest airport on St Helena and with no airstrip of its own, conventional delivery was impossible. The Ministry of Defence devised an unprecedented plan: a military airdrop operation involving paratroopers and cargo parachutes.
The mission was logistically complex and required meticulous planning. An RAF Airbus A400M transport aircraft was chosen for the task, supported by a Voyager air-to-air refuelling tanker due to the vast distances involved. Supplies and personnel were first assembled at RAF Brize Norton in England, then flown over 4,200 miles to Ascension Island, the staging point for the final leg. Early on May 9th, conditions were deemed suitable, and the A400M, designated Flight RRR4989, departed Ascension. After refuelling mid-flight, it headed toward Tristan, though adverse winds delayed its arrival until around 5:00 PM, later than the initially announced 3:30 PM.
The operation itself was a remarkable feat of precision and bravery. A team from the British Army's Pathfinder Platoon, along with a consultant doctor and an ICU nurse, parachuted onto the island in two groups. The first group of paratroopers jumped from 7,000 feet, landing near the Back Fence and the golf course despite strong, unpredictable winds. They immediately set up a guidance station at the Patches to direct subsequent cargo drops. The medics followed on tandem parachutes, landing safely on the golf course. In total, 3.3 tonnes of medical supplies were successfully dropped in three low-altitude passes over the Patches, with the aircraft flying as low as 175 feet.
The operation was a race against the fading winter daylight. While most cargo was collected and transported to the settlement by islanders that evening, the final load had to be retrieved the following morning. The military team was warmly welcomed into the community, housed in local guest houses, and set up a base in Prince Philip Hall. By Sunday, May 10th, all supplies had been delivered to Camogli Hospital, where the arriving medical personnel began providing crucial support to the overstretched local staff. The patient was reported to be stable.
The island's reaction was one of profound gratitude and astonishment. Administrator Philip Kendall praised the "amazing combined effort" from the UK armed forces and government. For the residents, the sight of a fixed-wing aircraft flying low over the settlement and parachutes descending was a historic and almost surreal event, momentarily overshadowing the crisis that prompted it. The community, along with supporters worldwide, expressed deep thanks for the support. The event was poetically commemorated by island policeman Barry Thacker, who wrote a verse honoring all involved, from the paratroopers and pilots to the local cooks and communicators. The military team was set to remain on the island to continue their medical mission until their work was complete, at which point they would depart by ship.
Tristan da Cunha 的经济主要靠出口 langustas(小龙虾),并辅以邮票和手工制品(如针织袜子)的销售、政府工作以及有限的旅游业。岛上居民还种植马铃薯以自给自足。英国为这座约 250 人口的岛建了一座小龙虾加工厂,为当地提供了重要收入来源。现在已有 Tristan da Cunha 的 Street View 图像,可见主定居点以南的农田、绵羊、牛和驴。曾有记者到访并在 Reddit 上做过 AMA,提供了关于当地日常生活的第一手见闻。
像 Tristan da Cunha 这样的偏远岛屿,政府维持其存在很大程度上是为了在周边海域宣示政治控制,居民在实际上因此获得补贴。相比之下,Orkney 自古就有人居住,且距英国本土只有约 20 英里,两者并不可直接类比。有人认为设置海军基地本身就是一种出于控制附近海域愿望的补贴形式,但也有人反驳称,位于现有领海范围内的岛屿并不能有效扩大主张。
RAF 对 Tristan da Cunha 的医疗救援激发了广泛的自豪感和欣慰,这是一个罕见的、超越意识形态的正面故事。社交媒体常放大敌意和极端言论,但这些并不反映现实生活中的态度——许多最恶劣的内容是伪装成英国人的账户发出的,而非真正居民的声音。关于 Tristan da Cunha 是否算作殖民地存在争议:该岛在英国定居前无人居住,英国对海外领地的义务究竟出于关怀还是战略自利,观点不一。为偏远领土提供服务成本高昂,但公众总体支持维持对这些海外同胞的责任。
有人还指出,RAF 的任务既具有人道意义,也展示了能力——表明英国能迅速应对偏远领土的危机,或对他国控制争议岛屿起到威慑作用。医疗人员的双人串联跳伞在晚秋的强风和直到最后一刻能见度才好转的条件下尤为惊人。当地网站故意保持怀旧、简单的设计,部分原因是过去卫星互联网受限;即便现在接入了 Starlink,他们仍选择保留这种风格。一首当地的颂诗表达了对 RAF 救援的感激与戏剧性。医疗团队很可能来自 144 Parachute Medical Squadron,该部队训练有素,擅长此类行动;而双人跳伞除了服从指令与保持冷静外,对先前经验的要求并不像想象中那么高。有读者指出一个讽刺点:被救助的人很可能是 Tristan da Cunha 的居民,对他们来说岛屿是家,而非旅游目的地。讨论中还提到了其他有趣的地名,如靠近 Tristan da Cunha 的 Inaccessible Island 、 Unnecessary Mountain 以及名为 Disappointment 和 Desolation 的岛屿。
总体而言,讨论反映出人们对维持偏远岛屿领土后勤与政治问题的浓厚兴趣,特别聚焦于 Tristan da Cunha 独特的经济模式和战略意义。多数人对 RAF 的医疗救援表示赞赏,这在通常两极分化的网络话语中成为一个团结的正面故事。围绕殖民主义的问题则存在分歧:参与者对无人居住领土被英国人定居是否构成殖民,以及维持这些定居点是否出于真正关怀或纯粹战略考量看法不同。讨论同时提醒人们社交媒体如何扭曲公众态度,许多人指出网络上的敌意并不反映现实生活体验。贯穿始终的是对救援行动技术水平和人道目的的强烈自豪感,读者在这个超越政治分歧的故事中找到了慰藉。
• Tristan da Cunha's economy relies on exporting langustas (crayfish), supplemented by selling stamps, handmade crafts like knitted socks, government jobs, and some tourism. Residents also grow potatoes for self-sufficiency.
• The UK built a crayfish processing facility to provide income for the island, which has a population of around 250 people.
• There are Street View images available of Tristan da Cunha, showing agricultural plots, sheep, cattle, and donkeys southwest of the main settlement.
• A journalist who visited the island did an AMA on Reddit, offering firsthand insights into daily life there.
• Remote islands like Tristan da Cunha are often maintained by governments primarily to assert political control over surrounding waters, with their populations effectively subsidized for this strategic purpose.
• Orkney, unlike Tristan da Cunha, has been inhabited since ancient times and is only 20 miles from the UK mainland, making the two cases not directly comparable.
• Some argue that hosting a naval base is itself a form of subsidization driven by the desire to control nearby waters, though others counter that an island within existing territorial waters doesn't meaningfully expand those claims.
• The story of the RAF medical mission to Tristan da Cunha inspired pride and relief in many readers, serving as a rare positive, non-political story that people across ideological lines could celebrate.
• Social media often amplifies hostility and extremism that doesn't reflect real-life attitudes, with much of the nastiest content posted by people masquerading as British rather than actual residents.
• There's debate over whether Tristan da Cunha qualifies as a colony, given it was uninhabited before British settlement, and whether the UK's obligations to its overseas territories represent genuine care or strategic self-interest.
• The cost of providing services to remote territories is high, but there's broad public support for maintaining these obligations to overseas compatriots.
• Some suggest the RAF mission also served as a demonstration of capability, showing that the UK could respond quickly to crises in remote territories, potentially deterring other nations from attempting to take control of disputed islands.
• The tandem parachute jump by medical personnel was an impressive feat of skill, especially given the challenging conditions of late autumn winds and limited visibility until the final moments.
• Tristan da Cunha's website has a deliberately simple, throwback design due to previously limited satellite internet, though they now have Starlink but have chosen to maintain the basic aesthetic.
• A local poem celebrated the RAF mission, capturing the community's gratitude and the dramatic nature of the rescue operation.
• The medical team likely came from 144 Parachute Medical Squadron, which has specialists trained for such operations, though tandem jumps require minimal prior experience beyond following instructions and staying calm.
• Some readers noted the irony that the person who fell ill was likely a resident of Tristan da Cunha, for whom the island's remoteness is simply home rather than a travel destination.
• The discussion touched on other amusingly named locations, including Inaccessible Island (near Tristan da Cunha), Unnecessary Mountain, and islands called Disappointment and Desolation.
The discussion revealed a community fascinated by the logistics and politics of maintaining remote island territories, with particular attention to Tristan da Cunha's unique economic model and strategic significance. There was broad appreciation for the RAF medical mission, which served as a unifying positive story amid typically polarized online discourse. Debates emerged around colonialism, with participants disagreeing about whether uninhabited territories settled by British citizens constitute colonies and whether maintaining such settlements represents genuine care or strategic calculation. The conversation also highlighted how social media distorts perceptions of public attitudes, with many noting that the hostility prevalent online doesn't reflect their real-life experiences. Throughout, there was a strong undercurrent of pride in the technical skill and humanitarian purpose of the rescue operation, with readers finding relief in a story that transcended political divisions.
Mullvad VPN 在每台服务器上使用多个出口 IP,并根据用户的 WireGuard 密钥以确定性方式分配这些 IP;密钥会在 1 到 30 天内轮换一次。虽然这种设计有助于将用户分散到不同 IP 以避免被封锁,但也带来了指纹识别的风险。对 9 台服务器的测试表明,出口 IP 并非随机分配,而是遵循可预测的模式。每台服务器的 IP 池按比例划分,用户在不同服务器上获得的 IP 会始终位于各自池中的同一百分位;例如,有的用户在每台服务器上总是落在大约第 81 百分位。 Mullvad VPN uses multiple exit IPs per server, assigning them deterministically based on a user's WireGuard key, which rotates every 1 to 30 days. While this design helps distribute users across IPs to avoid blocks, it introduces a fingerprinting risk. Testing 9 servers revealed that exit IPs are not randomly assigned but follow a predictable pattern. Each server's IP pool is divided proportionally, so a user's IP across different servers consistently lands in the same percentile of its pool. For example, one user might always get an IP around the 81st percentile of each server's range.
Mullvad VPN 在每台服务器上使用多个出口 IP,并根据用户的 WireGuard 密钥以确定性方式分配这些 IP;密钥会在 1 到 30 天内轮换一次。虽然这种设计有助于将用户分散到不同 IP 以避免被封锁,但也带来了指纹识别的风险。对 9 台服务器的测试表明,出口 IP 并非随机分配,而是遵循可预测的模式。每台服务器的 IP 池按比例划分,用户在不同服务器上获得的 IP 会始终位于各自池中的同一百分位;例如,有的用户在每台服务器上总是落在大约第 81 百分位。
这种现象源自 Mullvad 在 Rust 中使用基于种子的随机数生成器(RNG)。对于同一种子,RNG 会产生一致的浮点值,再按服务器 IP 池的大小进行缩放。因此即便理论上存在数万亿种 IP 组合,实际上用户只落入观测到的 284 种组合之一。池大小相同的服务器(如 Chile 和 South Africa)会共享相同的 IP 索引,进一步证实了 RNG 的确定性行为。这可能是 Rust 中 random_range 的比例缩放方式导致的意外后果,许多开发者(包括 Mullvad 的)可能未曾预料到这一点。
组合数量受限使得关联攻击成为可能。研究者开发了一个工具来估算一组 IP 对应的浮点区间,结果显示约 0.34% 的用户会共享相同组合。按约 100,000 名活跃 Mullvad 用户估算,约有 340 人可能在不同服务器间被关联。例如,当论坛上两个账户的 IP 日志显示重叠的浮点区间时,很大概率它们属于同一人。该漏洞在数据泄露或法务索取的 IP 日志中同样可被利用,从而可能去匿名化 VPN 背后的用户。
缓解建议:尽量不要在同一 WireGuard 密钥周期内频繁切换服务器,最好每个密钥只切换一次;若需强制轮换密钥,可退出 Mullvad 客户端重新登录。这样可以降低跨会话被关联的概率。此问题凸显了负载均衡与隐私之间的权衡:确定性分配虽有助于扩展和负载均衡,但也会为每个用户留下独特的指纹。
Mullvad VPN uses multiple exit IPs per server, assigning them deterministically based on a user's WireGuard key, which rotates every 1 to 30 days. While this design helps distribute users across IPs to avoid blocks, it introduces a fingerprinting risk. Testing 9 servers revealed that exit IPs are not randomly assigned but follow a predictable pattern. Each server's IP pool is divided proportionally, so a user's IP across different servers consistently lands in the same percentile of its pool. For example, one user might always get an IP around the 81st percentile of each server's range.
This behavior stems from Mullvad's use of a seed-based random number generator (RNG) in Rust. The RNG produces a consistent float value for a given seed, which is then scaled to the server's IP pool size. This means that even with trillions of possible IP combinations, users end up with one of only 284 observed combinations. Servers with identical pool sizes, like those in Chile and South Africa, share the same IP indexes, confirming the RNG's deterministic nature. This might be an unintended consequence of how Rust's `random_range` function works, as many developers, including Mullvad's, may not have anticipated this proportional scaling.
The limited number of combinations allows for correlation attacks. A tool was created to estimate the float range for a set of IPs, showing that about 0.34% of users share the same combination. With an estimated 100,000 active Mullvad users, this means around 340 people could be linked across different servers. For instance, if two accounts on a forum show overlapping float ranges in their IP logs, there's a high probability they belong to the same person. This vulnerability extends to data breaches or legal IP logs, potentially deanonymizing users behind the VPN.
To mitigate this, users should avoid switching servers more than once per WireGuard key and force rotate their key by logging out of the Mullvad app. These steps reduce the chance of being tracked across sessions. The issue highlights a trade-off between load balancing and privacy, where the deterministic IP assignment, while practical for scaling, creates a unique fingerprint for each user.
• Mullvad 的一位联合创始人承认,部分被描述的 IP 关联行为是出于用户体验的考虑(例如在某台服务器上保持稳定的 IP);其他行为并非有意,目前已有针对意外行为的补丁在测试中。他强调了隐私与用户体验之间的权衡,并请求研究人员在公布研究结果前通知厂商。
• Mullvad 默认的 WireGuard 密钥轮换间隔为 72 小时,这被视为缓解 IP 关联问题的一种措施。一些用户认为,更小的 IP 池反而能增加每个出口 IP 的用户数量,从而在结合 DAITA 和多跳等功能时加强隐私。
• 基于用户 WireGuard 密钥的确定性出口 IP 分配意味着,即便用户连接到不同的 Mullvad 服务器,也可能由于重叠的 IP 范围在这些服务器间被关联,形成跨服务器的伪静态标识,从而削弱匿名性。
• 有评论者怀疑考虑到这种关联漏洞,Mullvad 是否可能是情报机构的幌子。反驳者则指出,如果是蜜罐,机构会直接记录所有数据,而不会依赖这种微妙的统计关联;此外,Mullvad 的长期记录、第三方审计以及在法庭案件中证明的无日志政策,都支持其合法性。
• 讨论强调,VPN 主要保护用户免受 ISP 级别的监控和商业追踪,而不是用来对抗有能力的国家级对手或像浏览器指纹这类复杂的去匿名化技术。用户不应期望 VPN 达到 Tor 那样的匿名效果。
• Mullvad 的确定性 IP 分配被辩护为一种无状态且用户友好的设计,避免维护 NAT 表并允许 SSH 等服务保持稳定连接。然而,这种便利是以隐私为代价,可能需要重新评估。
• 博客中声称的 ">99% 的概率" 跨服务器识别用户受到了质疑,有人认为相关数学计算过于简化。但在用户数量很少的小型论坛中,这种关联仍可能构成强有力的证据。
• 一些用户指出,Mullvad 的出口 IP 广为人知,常被银行和由 Cloudflare 保护的网站等服务封锁,要求用户在访问时禁用 VPN——这是任何 VPN 供应商常见的权衡。
• 关于 VPN 与 ISP 的可信度辩论集中在司法管辖区、透明度和可验证的无日志政策上。 Mullvad 接受匿名支付、客户端开源,以及在法庭上得到证明的无日志政策,被认为比典型 ISP 更值得信赖,后者通常会将用户数据货币化。
• 建议那些需要避免 VPN 被列入黑名单的用户考虑使用住宅或移动代理,尽管这些服务可能更昂贵并且可能依赖可疑来源(例如被恶意软件感染的设备)。在更高安全需求下,也有人讨论使用 VPN 链和其他高级技术。
讨论显示了对该问题局限性的细致理解:大多数参与者承认 Mullvad 的 IP 关联问题确实是一个真实的隐私隐患,但并非恶意的证据。共识倾向于认为 Mullvad 是一家值得信赖的供应商,应修复跨服务器关联的缺陷,可能通过在 IP 分配中引入服务器特定的随机性来解决。关于 VPN 与 ISP 的比较、 VPN 对抗国家级对手的有效性以及将 VPN 作为万能隐私工具的宣传,引发了对商业隐私工具的普遍怀疑,同时也认可了它们在特定威胁模型下的实用价值。
• A Mullvad co-founder acknowledged that some of the described IP correlation behavior was intended (for user experience, like maintaining stable IPs on a given server) while other aspects were not, and that a patch for the unintended behavior is already being tested. He emphasized the trade-offs between privacy and UX, and requested that researchers notify vendors before publishing findings.
• Mullvad's default WireGuard key rotation interval is 72 hours, which serves as a mitigation for the IP correlation issue. Some users argue that a smaller IP space actually enhances privacy by increasing the number of users sharing each exit IP, especially when combined with features like DAITA and multi-hop.
• The deterministic assignment of exit IPs based on a user's WireGuard key means that even when connecting to different Mullvad servers, a user can be correlated across those servers via overlapping IP ranges, creating a pseudo-static identifier that undermines anonymity across services.
• Several commenters questioned whether Mullvad could be an intelligence agency front, given the correlation vulnerability. Others countered that if it were a honeypot, the agency would simply log everything rather than rely on such subtle statistical correlations, and that Mullvad's long track record, third-party audits, and proven no-log policy in court cases support its legitimacy.
• The discussion highlighted that VPNs primarily protect against ISP-level surveillance and commercial tracking, not against determined state actors or sophisticated deanonymization techniques like browser fingerprinting. Users should not expect VPNs to provide Tor-level anonymity.
• Mullvad's design choice to assign IPs deterministically was defended as a stateless, user-friendly approach that avoids maintaining NAT tables and allows stable connections for services like SSH. However, this convenience comes at a privacy cost that may need to be reconsidered.
• The blog post's claim of ">99% chance" of identifying a user across servers was questioned, with some arguing the math was oversimplified. However, for small forums with few VPN users, the correlation could still be strong evidence of sockpuppetry.
• Some users noted that Mullvad's exit IPs are widely known and often blocked by services like banks and Cloudflare-protected sites, requiring users to disable the VPN for access. This is a common trade-off with any VPN provider.
• The broader debate around VPN trustworthiness compared to ISPs centered on jurisdiction, transparency, and verifiable no-log policies. Mullvad's acceptance of anonymous payments, open-source clients, and court-proven lack of logs were cited as reasons to trust it more than typical ISPs, which often monetize user data.
• Residential and mobile proxies were suggested as alternatives for users needing to avoid VPN blacklists, though these services can be more expensive and may rely on questionable sources like malware-infected devices. VPN chaining and other advanced techniques were also discussed for higher-security use cases.
The discussion revealed a nuanced understanding of VPN limitations, with most participants acknowledging that Mullvad's IP correlation issue is a genuine privacy concern but not evidence of malicious intent. The consensus leaned toward Mullvad being a trustworthy provider that should fix the cross-server correlation flaw, likely by incorporating server-specific randomness into IP assignment. Debates about VPNs versus ISPs, the effectiveness of VPNs against state actors, and the marketing of VPNs as privacy panaceas reflected broader skepticism about commercial privacy tools while still valuing their utility for specific threat models.
英国政府通过用内部团队开发的自研系统取代用于管理 Homes for Ukraine 难民项目的 Palantir IT 系统,节省了数百万英镑。 MHCLG 表示,新系统更灵活、符合更高的安全标准,同时大幅降低了运行成本,已于 2025 年 9 月投入使用。 The UK government has saved millions of pounds by replacing a Palantir IT system used to manage the Homes for Ukraine refugee scheme with an in-house solution built by its own experts. The Ministry of Housing, Communities and Local Government (MHCLG) said the new system is more flexible and meets high security standards, while significantly reducing running costs. The replacement system became operational by September 2025.
英国政府通过用内部团队开发的自研系统取代用于管理 Homes for Ukraine 难民项目的 Palantir IT 系统,节省了数百万英镑。 MHCLG 表示,新系统更灵活、符合更高的安全标准,同时大幅降低了运行成本,已于 2025 年 9 月投入使用。
Homes for Ukraine 项目在 2022 年 3 月俄国全面入侵后不久启动,旨在将难民与提供免费住宿的人匹配。 Palantir 最初免费提供其 Foundry 平台六个月以便迅速搭建系统,但据 National Audit Office 的报告,随后签订了两份为期 12 个月的合同,金额分别为 450 万英镑和 550 万英镑。报告指出,政府首席商务官对 Palantir 以零成本或名义成本的初始报价换取商业立足点表示担忧,认为这与要求公开竞争的公共采购原则相悖。
该项目高级数字负责人 Coco Chan 表示,部门希望以更灵活的技术方案取代商业平台,以节省开支并掌控数据与代码。她称,内部替代系统每年已为 MHCLG 节省数百万英镑的运行成本,这一做法为减少对外部供应商依赖、发展所谓"主权技术"树立了先例。
此举正值外界对 Palantir 在英国公共服务领域合同的广泛批评之际,涉及的机构包括 NHS 、 Ministry of Defence 、 Financial Conduct Authority 以及 11 个警察部门。批评者指出,Palantir 参与美国移民执法和与以色列军方的合作,加上其几位知名创始人的立场,使其并非合适的合作伙伴;人们也担心英国对大型美国科技供应商的依赖。
但也有人认为,外部专家能带来宝贵经验并能迅速部署大规模团队,这对紧急国家项目至关重要。 Palantir 为其工作辩护,称很自豪能支持该项目,并在短短 9 天内搭建出解决方案,使超过 157,000 名难民得以安全安置;该公司还表示,系统更换证明客户不会被锁定在其技术平台上。
The UK government has saved millions of pounds by replacing a Palantir IT system used to manage the Homes for Ukraine refugee scheme with an in-house solution built by its own experts. The Ministry of Housing, Communities and Local Government (MHCLG) said the new system is more flexible and meets high security standards, while significantly reducing running costs. The replacement system became operational by September 2025.
The Homes for Ukraine scheme was launched in March 2022, shortly after Russia's full-scale invasion, to match refugees with people offering free accommodation. Palantir initially provided its Foundry platform for free for six months to help set up the system quickly. However, subsequent 12-month contracts were awarded, one worth £4.5 million and another £5.5 million, according to a National Audit Office report. The report noted concerns from the Government's chief commercial officer about Palantir's practice of offering zero or nominal-cost initial offers to gain a commercial foothold, which he argued was contrary to public procurement principles requiring open competition.
Coco Chan, a senior digital leader on the project, said the department wanted to replace the commercial platform with a more flexible technology solution to save costs and control data and code. She said the in-house replacement was already saving MHCLG millions of pounds a year in running costs. The move sets a precedent for reducing reliance on external suppliers and developing what some call "sovereign technology."
The shift comes amid broader criticism of Palantir's contracts across UK public services, including with the NHS, Ministry of Defence, Financial Conduct Authority, and 11 police forces. Critics argue the firm's involvement with US immigration enforcement and Israel's military, as well as the beliefs of its prominent founders, make it an unsuitable partner. There are also concerns about the UK's reliance on large US tech suppliers.
However, others note that external specialists can bring valuable experience and the ability to deploy large teams quickly, which is important for urgent national programmes. Palantir defended its record, saying it was proud to have supported the scheme and stood up a solution in just nine days, enabling the safe resettlement of more than 157,000 refugees. The firm also said the change to a new system showed there was no risk of firms being locked into using its technology.
- 一家英国公司曾以出让股权换取对 NHS 数据的访问权限,数据并未离开该组织,但最终合同却落到了 Palantir 名下。这一过程引发了对公共合同授予程序的质疑——即便存在符合伦理的替代方案,也未被采纳。
- 政府与科技公司之间存在明显的"旋转门"现象:高级 NHS 官员把合同授予像 AWS 这样的公司,随后又进入这些公司任职,激起了对利益冲突和腐败的担忧。与此同时,政府限制公务员薪酬等级,使直接雇用熟练程序员变得不可能,部门只好以更高成本把工作外包给咨询公司,既低效又加深了对外部供应商的依赖。
- 缺乏竞争压力导致支出没有自然上限,合同规模膨胀,决策更偏向昂贵的外部方案而非培养内部能力。公共部门技术岗位薪酬远低于市场水平,难以吸引和留住人才,这迫使政府依赖成本高且产出常常不佳的承包商。
- Palantir 在赢得政府合同时,被广泛归因于游说、人脉和"旋转门"影响,而非其方案的质量或性价比。该公司采用以高利润、咨询密集型为主的商业模式,虽提供 Foundry 等强大工具,但长期费用通常高于建立并激励内部能力。官僚体系也倾向于选择 Palantir 或 IBM 等昂贵供应商,因为若项目失败,责任更易归咎于外部供应商而非内部决策者,从而降低了个人风险。
- "乌克兰难民住房计划"最初为求快速部署而使用 Palantir,但现已转向本土平台以降低成本并减少长期开支。 Palantir 在 NHS 中处理敏感健康数据、承揽数亿英镑合同的做法,引发公众信任危机以及对数据隐私和主权的担忧。
总体讨论显示,公众和从业者普遍对 Palantir 在英国公共部门合同中占主导地位持深度怀疑态度,认为其成功更多依赖游说、关系网和激励错位,而非技术优势。大家普遍认为,应发展具有数据主权和问责机制的内部解决方案,以实现更高的成本效益和数据安全;同时也对公共部门管理不善、供应商锁定及将敏感数据交由与美国情报和军事行动有关联的公司处理的伦理问题表示担忧。
• A UK company offering NHS trusts equity in exchange for data access, with data never leaving the organization, lost a contract to Palantir, highlighting concerns about how public contracts are awarded despite ethical alternatives being available.
• The revolving door between government and tech firms is evident, with senior NHS officials awarding contracts to companies like AWS and then joining those companies, raising questions about conflicts of interest and corruption.
• UK government policy restricts civil service pay scales, making it impossible to hire skilled programmers directly, so departments outsource to consultancies at much higher costs, creating inefficiency and dependency on external vendors.
• The lack of competitive pressure in government means there's no natural cap on spending, leading to bloated contracts and a preference for expensive external solutions over building internal expertise.
• Public sector salaries for tech roles are far below market rates, making it difficult to attract and retain talent, which forces reliance on costly contractors who often deliver subpar results.
• Palantir's success in winning government contracts is attributed to lobbying, personal connections, and the "revolving door" phenomenon, rather than the quality or cost-effectiveness of their solutions.
• Palantir operates on a consulting-heavy model with high margins, offering powerful tools like Foundry, but the long-term cost is often higher than building in-house capabilities with aligned incentives.
• Government bureaucrats often choose expensive vendors like Palantir or IBM because it reduces personal risk, as failure can be blamed on the vendor rather than internal decisions.
• The Homes for Ukraine refugee scheme initially used Palantir for rapid deployment but is now transitioning to a home-grown platform to reduce costs and bring down long-term expenses.
• Palantir's role in the NHS involves sensitive health data, with contracts worth hundreds of millions of pounds, despite public distrust and concerns about data privacy and sovereignty.
The discussion reveals deep skepticism toward Palantir's dominance in UK public sector contracts, with many attributing its success to lobbying, corruption, and misaligned incentives rather than technical superiority. There is widespread frustration with the government's inability to build internal tech capacity due to restrictive pay scales and bureaucratic inefficiencies, leading to costly outsourcing. While some acknowledge Palantir's powerful tools, the consensus leans toward the need for sovereign, in-house solutions to ensure accountability, cost-effectiveness, and data security. The conversation also touches on broader issues of public sector mismanagement, vendor lock-in, and the ethical implications of entrusting sensitive data to a company with ties to US intelligence and military operations.
专家:超过一半的美国正遭遇数十年来最严重的干旱 ## Expert: More than half of U.S. faces worst drought in decades
专家:超过一半的美国正遭遇数十年来最严重的干旱
目前美国有超过 60% 的地区处于干旱状态,其中超过 20% 被评为极端干旱。 Virginia Tech 的气候学家 Andrew Ellis 表示,因强度和覆盖范围罕见,这次干旱可谓数十年来最严重。他解释了成因、受影响最严重的地区以及可能的缓解前景。
干旱的主要原因是一次非典型的 La Niña,即西赤道太平洋异常冷却。过去的秋冬季里,这一现象在美国南部带来了持续干燥。虽然在 La Niña 年份里,西部、南部大平原和东南部常见干旱,但 Ellis 指出此次不同寻常的一点是太平洋西北部也异常干燥。 La Niña 时风暴通道通常向北移至美加边境附近,导致美国南部缺乏带来降水的风暴动力。另外,气候变暖也在加剧干旱:气温上升会通过蒸散作用增加土壤失水。
最令人担忧的两个地区是 Colorado 和东南部,尤其是 Georgia 和 Florida,这些地方广泛出现极端和严重干旱。更大范围来看,从 deep South 到 mid-Atlantic 的美国东南象限正经历严重干旱,central Rocky Mountains 和高海拔的 Great Plains 地区也在受影响。从 New Jersey 到 Arkansas 的诸州在 La Niña 年份特别容易在秋冬出现干燥,因为它们依赖来自墨西哥湾和东南海岸的水汽——而这一水源在过去六到八个月基本被切断。相对而言,Ohio Valley 在 La Niña 年份通常更湿润,今年也基本没有出现干旱。
在暖季要实现显著的干旱缓解很困难。最常见的缓解往往来自夏末或初秋的热带系统,但这些系统伴随强风和短时强降雨的风险。对于 Rocky Mountains 和高海拔 Great Plains 来说,夏季缓解尤其困难,因为这些地区高度依赖冬季积雪和大尺度冬季风暴系统。东南部和 mid-Atlantic 虽然可能出现由墨西哥湾和大西洋水汽驱动的湿润夏季,但这类降水通常不够持久,难以彻底消除深层干旱。展望秋冬,Ellis 提到有可能出现一次历史性的 El Niño,理论上这可能带来与去年 La Niña 相反的气候格局。
Andrew Ellis 是 Virginia Tech College of Natural Resources and Environment 下 Department of Geography 的教授,研究领域包括气候科学、气象学、降雪变率、干旱监测以及干旱和半干旱地区淡水资源可持续性的评估。
## Expert: More than half of U.S. faces worst drought in decades
More than 60 percent of the United States is currently experiencing drought conditions, with over 20 percent classified as extreme drought. Andrew Ellis, a climatologist at Virginia Tech, described these conditions as among the worst in decades due to the rare combination of intensity and aerial coverage. He explained the causes, the areas most impacted, and the outlook for relief.
The primary cause of the drought is an atypical La Niña condition, which involves the cooling of the western equatorial Pacific Ocean. This phenomenon brought dryness across the southern tier of the United States during the past fall and winter. While dryness is typical in the West, southern Great Plains, and Southeast during La Niña years, Ellis noted this event was unusual because the Pacific Northwest also remained exceptionally dry. During La Niña, the storm track typically moves north along the U.S.-Canadian border, leaving the southern U.S. without the storm dynamics needed for precipitation. Additionally, climate warming is exacerbating the situation by increasing air temperatures, which leads to greater water loss from the soil through evapotranspiration.
The two areas of greatest concern are Colorado and the Southeast, particularly Georgia and Florida, where extreme and exceptional drought conditions are widespread. More broadly, the southeastern quadrant of the U.S. from the deep South to the mid-Atlantic is experiencing deep drought, along with the central Rocky Mountains and high Great Plains regions. States from New Jersey to Arkansas are especially susceptible to fall and winter dryness during La Niña years because they rely on moisture from the Gulf of Mexico and the Southeast coastline, a source that has been largely cut off for the past six to eight months. Conversely, the Ohio Valley tends to be wetter during La Niña years and has remained largely drought-free this year.
Significant drought relief is difficult to achieve during the warmer months. The most significant relief often comes from late summer or early fall tropical systems, though these carry risks of damaging winds and excessive rainfall in short periods. Relief in the Rocky Mountains and high Great Plains is particularly challenging in summer, as those regions depend heavily on winter snowpack and large-scale winter storm systems. While the Southeast and mid-Atlantic can experience wet summer periods driven by Gulf and Atlantic moisture, these events are rarely persistent enough to eliminate a deep drought. Looking beyond summer, Ellis suggested that a historic El Niño event may occur next fall and winter, which could theoretically produce the opposite conditions to this past year's La Niña.
Andrew Ellis is a professor in the Department of Geography within Virginia Tech's College of Natural Resources and Environment. His expertise includes climate science, meteorology, snowfall variability, drought monitoring, and assessing the sustainability of freshwater resources in arid and semi-arid climates.
当前的干旱图可能具有误导性:预计即将到来的超级厄尔尼诺将在夏末和明年春季为受影响地区带来大量降水,可能消除图中显示的大部分干旱。以 2015–2016 年超级厄尔尼诺为例,当拉尼娜转为厄尔尼诺时,降雨量有可能超过多年平均的两倍以上。
从干旱迅速转为强降雨会带来严重洪水风险。干涸的土壤吸水能力差,容易形成径流,导致受灾区面临更大的水害。实用的防洪建议包括:在秋季来临前检查轮胎花纹深度,车内备好雨具,雨天慢速行驶以防车辆打滑;若发生打滑,应把方向盘朝所需方向并松开油门。此外建议备橡胶靴和手杖,用以探测水深并在流动水中保持平衡。
小麦期货反映出干旱对农业的影响。美国农业部预测,由于平原地区的干旱,美国小麦产量将降至自 1972 年以来的最低水平。随着种植者转向利润更高的作物,小麦种植面积持续减少(下降约 35%),玉米减少约 6%,而大豆种植因对化肥依赖较小而有所增加。
美国西南部正经历至少 1200 年来最严重的长期干旱,但水仍以远低于居民用水价格的水平出售给企业,关键水利基础设施维护却被忽视。西部的水权制度使监管复杂化:水权归属于 150 多年前首次使用它的实体,这一制度加剧了管理难题。
树木减少和城市扩张是干旱的重要且被低估的驱动因素。在北卡罗来纳州罗利附近,过去十年间树冠覆盖率下降了 15% 以上。历史案例(如玛雅文明崩溃)也表明,砍伐森林会导致水资源短缺并最终危及社会稳定。
水循环的中断意味着一些地区年总降水量看似充足,但降水集中在短期内而非全年分布。例如在明尼苏达州,过去常持续到六月或七月的积雪如今反复融化再冻结,无法累积,尽管年降水总量可接受,但夏季仍然干旱。
数据中心的用水量日益令人担忧,尤其是在水权与土地所有权捆绑且难以监管的西部州。部分设施采用闭环冷却系统,但其用水总量相当于小城镇,若含水层消耗速度超过补给速度,就会带来长期可持续性问题。
个人节水措施(如餐厅不主动上水)相比工业和农业用水而言只是分散注意力:无论消除所有个人和数据中心用水,和农业与工业的耗水量相比几乎微不足道。与此相应,讨论指出需要的是基础设施和政策上的变革,而不是象征性的举措。
干旱监测地图虽有用,但也存在局限:包含主观评估成分、对降水事件时点的把握可能不准确,并且不能反映高于平均水平的情况。该地图结合了客观数据与专家解读,因此带有主观性,尽管目前尚无比它更客观的替代方案。
讨论揭示了短期天气事件与长期气候趋势之间的紧张关系,参与者围绕当前干旱究竟是正常气候变动还是人为气候变化展开辩论。通过小麦减产和作物结构变化,农业影响已有明确记录;与此同时,过时的水权制度以及像数据中心这样的新兴行业不断增长的需求,进一步加剧了水资源管理的挑战。对话还强调了干旱测量工具的局限性,并提醒应关注降水的持续时间和分布,而不仅仅是年总量。
• The current drought map may be misleading because a predicted super El Nino is expected to bring heavy precipitation to affected areas by late summer and into next spring, potentially eliminating much of the drought shown. Historical precedent from the 2015-2016 super El Nino shows rainfall can more than double annual averages when La Nina transitions to El Nino.
• Rapid transitions from drought to heavy rainfall create significant flood risks because dried-out soil cannot absorb water effectively, leading to runoff and potential water damage in affected regions.
• Practical flood preparedness advice includes checking tire tread depth before autumn, carrying rain gear in vehicles, driving slowly to avoid hydroplaning, and understanding that if hydroplaning occurs, one should keep wheels pointed in the desired direction and ease off the accelerator. Adding rubber boots and a walking stick for checking water depth and maintaining footing in flowing water is also recommended.
• Wheat futures reflect agricultural impacts of drought, with USDA projecting the smallest US wheat harvest since 1972 due to Plains drought. Wheat acreage continues declining as producers shift to more lucrative crops, with wheat down 35% and corn down 6%, though soybeans appear up due to lesser fertilizer reliance.
• The US Southwest is experiencing its longest period of severe drought in at least 1200 years, yet water continues to be sold to corporations at fractions of what residential rates are, while critical water infrastructure maintenance is neglected. Water rights systems in the West complicate regulation because water belongs to the first entity to have used it over 150 years ago.
• Tree loss and urban sprawl are significant but underappreciated drivers of drought conditions. Near Raleigh, NC, over 15% of tree canopy has been lost in the past decade, and historical examples like the Mayan civilization collapse show how deforestation can lead to water scarcity and civilizational decline.
• Water cycle disruption means some areas receive adequate annual precipitation but in concentrated bursts rather than distributed throughout the year. In Minnesota, snow that once persisted through June or July now melts and refreezes repeatedly without building up, leaving summers dry despite acceptable yearly averages.
• Data center water usage is a growing concern, particularly in western states where water rights are tied to land ownership and difficult to regulate. Some facilities use closed-loop cooling systems, but the scale of water consumption equivalent to small cities raises long-term sustainability questions, especially when aquifers are being depleted faster than they regenerate.
• Individual water conservation measures like restaurants not automatically serving water are distractions from the much larger industrial and agricultural water usage problems. Removing all individual and data center water usage would barely make a dent compared to agricultural and industrial consumption.
• The Drought Monitor map, while useful, has limitations including subjective assessment components, potential inaccuracies in timing precipitation events, and failure to indicate above-average conditions. The map combines objective data with expert interpretation, making it more subjective than fully objective measures, though no more objective alternative exists.
The discussion reveals a tension between short-term weather events and long-term climate trends, with participants debating whether current drought conditions represent normal variability or anthropogenic climate change. Agricultural impacts are clearly documented through declining wheat harvests and shifting crop patterns, while water management challenges are exacerbated by outdated rights systems and growing demand from new industries like data centers. Several commenters emphasize that individual conservation efforts are insignificant compared to industrial and agricultural usage, and that infrastructure and policy changes are needed rather than symbolic gestures. The conversation also touches on the limitations of drought measurement tools and the importance of considering duration and distribution of precipitation rather than just annual totals.
240 comments • Comments Link
• 移动设备上的 AI 功能在用户打开消息前就对消息媒体进行解码,从而扩大了"0-click"攻击面,带来了新的安全风险。
• Google 在 90 天内修复了一个 Android 驱动漏洞,这一速度明显快于其他 Android 厂商和 Apple,引发了人们对其他厂商补丁速度的质疑。
• 由于设备制造商对 Android UI 的分叉导致碎片化,Android 厂商更新缓慢,补丁难以迁移。
• Apple 对安全漏洞的历史响应时间大约为 6 个月,尽管有报告称近年来有所改善。
• Apple 设备上的 Lockdown 模式被视为记者等高风险人群的重要工具,但由于缺乏证据以及零点击漏洞的高价值,其对国家级攻击者的有效性仍受质疑。
• 已发布的 CVE 数量显著上升,翻倍周期已从 4–4.5 年缩短到大约两年,尽管这些 CVE 的质量和合法性存在争议。
• AI 一方面通过引入带有安全漏洞的新功能扩大了攻击面,另一方面又为安全研究人员提供了更高效的漏洞发现工具。
• 关于开发者对安全漏洞的责任存在争论,一些人认为追究编写不安全代码的个人责任能够提高软件安全性。
• Rust 提供了整数溢出的检测选项:在调试构建中默认开启,在发布构建中可选择开启,这可以防止某些类型的漏洞。
• 安全社区对 KASLR 等缓解措施的有效性存在分歧,一些人认为由于信息泄露普遍,这类措施只提供有限的边际收益。
• GrapheneOS 因其减少攻击面和加强加固而受到认可,但也有人认为其缓解措施表面化,需要更实质性的改进。
• 讨论强调了新增功能与维护安全性之间的紧张关系:有人认为移除功能是提升安全性的简单方法,但这会以牺牲功能性为代价。
• 呼吁将驱动更好地上游合并到 Linux 内核,以提升所有 Android 设备的安全性,而不仅仅是那些有开源 BSP 的设备。
总体讨论揭示了移动安全的复杂局面:AI 功能的快速整合正在创造新漏洞,而现有安全措施的有效性常被质疑。尽管在补丁速度和安全研究方面有所进展,但攻击面总体扩大以及许多厂商响应缓慢仍是重大问题。 AI 在制造与缓解安全问题方面的双重作用反复出现:它既可能引入新的漏洞,也能帮助更快地发现漏洞。关于开发者责任、 Lockdown 模式和 KASLR 等防护手段有效性的争论,凸显了在安全性、可用性与创新之间寻求平衡的持续挑战。 • AI-powered features on mobile devices are increasing the "0-click" attack surface by requiring message media to be decoded before the user opens the message, creating new security vulnerabilities.
• Google patched an Android driver bug within 90 days, which is notably fast and raises questions about the patching speed of other Android vendors and Apple.
• Android vendors have been slow to provide updates due to the fragmentation caused by manufacturers forking the Android UI, making it difficult to migrate updates.
• Apple's response time for security bugs has historically been around 6 months, though there are reports of improvement in recent years.
• Lockdown mode on Apple devices is seen as a necessary tool for high-risk individuals like journalists, but its effectiveness against state-level actors is debated due to a lack of evidence and the high value of zero-click exploits.
• The rate of published CVEs has increased significantly, with a doubling interval that has decreased from 4-4.5 years to approximately two years, though the quality and legitimacy of these CVEs are questioned.
• AI is both increasing the attack surface by introducing new features with security holes and providing security researchers with tools to find vulnerabilities more efficiently.
• There is a debate around the responsibility of developers for security vulnerabilities, with some suggesting that personal liability for writing insecure code could improve software security.
• Rust programming language offers choices regarding integer overflow checks, with default checks in debug builds and optional checks in release builds, which can prevent certain types of vulnerabilities.
• The security community is divided on the effectiveness of mitigations like KASLR, with some arguing that they provide only marginal utility due to the prevalence of info leaks.
• GrapheneOS is recognized for its attack surface reduction and security hardening, though some argue that its mitigations are superficial and that more significant improvements are needed.
• The discussion highlights the tension between adding new features and maintaining security, with some suggesting that removing features is an easy way to improve security but at the cost of functionality.
• There is a call for better upstreaming of drivers into the Linux kernel to improve security across all Android devices, not just those with open-source BSPs.
The discussion reveals a complex landscape of mobile security, where the rapid integration of AI features is creating new vulnerabilities, and the effectiveness of security measures is often debated. While some progress is made in patching speeds and security research, the overall increase in attack surfaces and the slow response times of many vendors remain significant concerns. The role of AI in both creating and mitigating security issues is a recurring theme, with its potential to both introduce new vulnerabilities and aid in their discovery. The debate around developer liability and the effectiveness of security mitigations like Lockdown mode and KASLR underscores the ongoing challenges in balancing security with usability and innovation.