本研究论文首次对专有的苹果 AirDrop 和安卓 Quick Share 文件传输协议进行了全面的安全性分析。鉴于这些服务在全球拥有超过五十亿台设备，且均支持零点击访问，它们构成了重大的攻击面。 作者进行了一项广泛的跨平台研究，通过逆向工程剖析了 AirDrop 复杂的七层状态机，并开发了名为“AIRFUZZ”的协议感知型模糊测试工具，旨在对压缩前的数据进行变异测试。调查发现，在各种实现方案中存在六个关键漏洞（V1–V6）： * **苹果 AirDrop：** 三个预认证缺陷，包括拒绝服务 (DoS) 和内存损坏问题。 * **三星 Quick Share：** 两个协议层缺陷，包括一个安全加密绕过漏洞。 * **谷歌 Quick Share (Windows版)：** 一个堆释放后使用 (use-after-free) 漏洞。 研究人员已向相关厂商负责任地披露了这些发现。苹果、三星和谷歌均已确认报告，其中谷歌还为在其 Windows 实现中发现的漏洞提供了赏金奖励。这项工作凸显了对未公开且具备高权限的近场通信协议进行安全性审查的迫切需要。
每日HackerNews RSS
协议窥探：AirDrop 与 Quick Share 中的漏洞研究 Protocol Prying: Vulnerability Research in AirDrop and Quick Share
17 天前
对 2026 年 2 月至 6 月期间 Codex 遥测数据的分析显示，GPT-5.5 的响应元数据存在显著异常：推理标记（reasoning-token）数量不成比例地集中在 516、1034 和 1552 个标记上。 尽管 GPT-5.5 的响应仅占总响应量的 19.3%，但它贡献了 82% 的“刚好 516 个标记”事件。这种模式在其他模型变体中并不存在，且与整体推理标记强度呈负相关——尽管此类聚集事件有所增加，但整体推理强度却在下降。这种行为表明，这更像是模型特有的阈值设置、截断或预算约束，而非任务复杂度的自然变异。 这种聚集现象与报告中提到的 Codex 复杂任务性能下降情况相吻合。数据显示，GPT-5.5 响应达到 516 个标记这一阈值的概率，是非 GPT-5.5 模型基准的 33 倍。 现请求 Codex 团队调查这些固定的标记峰值是源于有意设置的内部阈值、路由异常，还是系统级的截断。建议的验证方案包括：对比“刚好 516 个标记”任务与可变推理长度任务的性能表现，并审计 GPT-5.5 的调度逻辑。
Hacker News 的用户报告称，OpenAI GPT-5.5 Codex 模型出现了严重的性能退化，其特征表现为一个“自适应思维”错误。
研究人员和用户发现，该模型在执行推理任务时经常会“短路”，在消耗恰好 516 个 token 后便返回错误结果。相反，当模型成功完成任务时，通常会使用 6,000 到 8,000 个推理 token。测试证实，在使用 Codex CLI 进行的重复试验中，有近一半出现了这种行为，导致依赖该模型进行编程任务的资深用户感到非常沮丧。
尽管有些人将此问题归因于“享乐适应”或用户的主观偏见，但许多开发人员分享了可复现的测试案例，证实了在 516 个 token 处会出现峰值，这表明 OpenAI 的推理引擎在集群或批处理推理预算方面可能存在缺陷。
此次讨论引发了关于专有“黑盒”模型与本地开源替代方案之间可靠性的广泛辩论。许多用户现在正通过外部仪表板积极跟踪模型性能，或考虑转向 Claude 等竞争对手，理由是 OpenAI 最近的模型更新缺乏一致性和透明度。
在南非姆波波梅尼（Mpophomeni），非营利组织“Funda Nenja”（祖鲁语意为“与狗共学”）开办了一所独特的“狗狗学校”，旨在改善当地儿童及其宠物的生活。该项目由阿德里安·奥利维尔（Adrienne Olivier）于2009年创立，每周提供免费的训练课程，让孩子们学习如何照顾、训练狗狗并与它们建立深厚的感情。
除了关注动物福利，Funda Nenja还是该地区重要的社区中心，助力当地缓解贫困和失业问题。通过教授训犬技能和培养同理心，该项目激发了孩子们的成就感、领导力与自信心。此外，该组织还通过提供兽医护理、入户走访、心理咨询和食物援助等方式，为社区提供全方位的支持。
这一倡议形成了一个良性循环：当孩子们学会善待宠物时，他们也能从中获得回报与关爱，进而改善自身的情绪健康。对于许多参与者，包括那些如今在组织内工作的前学员来说，“狗狗学校”为他们指明了人生目标，照亮了未来的道路。通过专注于人与动物之间的纽带，Funda Nenja营造了一个充满关怀的环境，让孩子们感受到被重视与信任，并赋予他们照顾身边生命的能力。
像 Opus 4.8 和 Sonnet 5 这样较新的 Anthropic 模型出现了一种退化问题：它们经常在工具调用中注入“幻觉”键（如 `type`、`id`、`matchCase`），导致调用无法通过验证。虽然旧版本模型能妥善处理自定义工具模式，但最新版本却表现得力不从心——讽刺的是，它们在遵循非标准模式方面反而“变差”了。 作者推测，这是 Anthropic 内部闭源工具“Claude Code”进行强化学习（RLHF）所产生的副作用。由于 Claude Code 具有极高的容错性——能够静默修复格式错误的工具调用、过滤未知键并支持别名——模型被训练得预期处于一个“对错误宽容”的环境中。因此，这些模型对 Claude Code 所使用的特定编辑模式形成了强烈的固定偏见，导致它们难以适应其他定义严格的模式。 这表明工具模式已不再是“中立”的协议，而是受到模型训练后环境隐藏偏见的影响。作者总结认为，开发者可能需要依赖严格的语法约束解码来确保可靠性，因为现代模型正日益针对某种特定的、未公开的工具生态进行优化。
这篇 Hacker News 的讨论凸显了先进大语言模型（LLM）与其交互“工具/代理”（harnesses）之间日益紧张的关系。
核心问题在于，模型在调用工具时往往难以处理语法，频繁插入“冗余内容”或虚构字段。用户提出了三种主要的应对策略：
* **稳健的错误处理：** 开发者不应让系统静默失败，而应提供清晰、可操作的错误提示，引导代理在下一次尝试时纠正特定错误。
* **确定性钩子（Deterministic Hooks）：** 许多参与者主张用“钩子”代替传统的技能调用。通过将逻辑卸载到 LLM 之外确定性运行的代码中，开发者可以确保可靠性、降低成本并强制执行护栏（例如在提交更改前运行测试）。
* **系统性担忧：** 许多评论者怀疑，前沿模型正针对专用环境（如 Claude Code）进行专门的强化学习调整，这导致它们在独立或自定义环境中使用时表现得“草率”。
归根结底，大家的共识是：开发者必须停止将代理视为万无一失的黑盒。相反，应将工具交互视为一个标准的 UI/UX 设计问题，优先考虑清晰的反馈和确定性的约束，以弥合模型“智能”与可靠输出之间的鸿沟。
**.splat4d** 格式是一种高性能、可流式传输的动态 4D 高斯溅射（Gaussian Splatting）容器，其压缩率比原始文件高出 16–58 倍。通过将静态背景与动态运动分离，并采用 H.265 风格的“闭合 GOP”数据块，它支持通过 HTTP Range 请求直接从标准对象存储（如 S3/GCS）进行即时跳转和低延迟播放。 主要技术特性包括： * **误差界限量化（Error-Bounded Quantization）：** 保证点对点的确定性精度（例如位置误差在 ±2mm 以内），确保 Rust 和 JavaScript 解码器在重建时位一致。 * **高效流式传输：** 元数据头允许客户端仅获取必要数据，在约 150 毫秒内渲染关键帧。 * **优化：** 使用 Morton 排序、时间死区跟踪和 Zstd 压缩，以实现接近最优的熵压缩。 * **原生 Web 支持：** 由 WebGPU 渲染器驱动，支持在浏览器中以 60fps 流畅播放复杂的动态场景。 该格式专为易用性设计，无需服务器端逻辑或复杂的清单文件，仅需静态托管即可。它非常适合需要极高压缩率和快速随机访问流式传输的高保真交互式 4D 内容。
抱歉。
在用 Rust 重构其 JavaScript 引擎解析器时，作者发现了一个罕见的编译器错误：Rust 编译器（`rustc`）中一个“p-critical, i-miscompile”级别的错误。 问题出现在作者优化 `consume_test` 方法时，他将标准的条件分支比较改为了 `bool as u32` 强制类型转换并随后进行加法运算。解析器随即无法处理简单的 for 循环。在检查了生成的汇编代码后，作者发现编译器实质上“吞掉”了一个必要的增量操作，违背了代码逻辑。 由于怀疑是真正的编译错误而非用户代码问题，作者创建了一个最小复现用例并提交了错误报告。Rust 社区反应迅速，该问题被确认为关键错误，团队成员在 18 小时内编写并合并了修复程序。这次经历凸显了一个罕见的事实：即使在内存安全的语言中，编译器错误也可能破坏程序员与语言之间的契约。最终，作者成功指出了编译器的一个缺陷，证明了有时候，“真的是编译器的问题”。
威克洛酒店取消了彼得·蒂尔（Peter Thiel）的“秘密”团体会议。 Wicklow hotel cancels 'secretive' Peter Thiel group conference
17 天前
位于威克洛郡的波斯考特酒店取消了一场由美国科技亿万富翁彼得·蒂尔共同创立的受邀制团体“对话”所举办的备受瞩目的“秘密”会议。据报道，该活动原计划讨论核能及“第三次世界大战”准备工作等议题，但因涉及帕兰泰尔公司而遭到强烈抵制，该公司因与以色列军方的战略伙伴关系而备受批评。 此次取消是在亲巴勒斯坦活动人士、反对派政客以及波斯考特庄园本身的巨大压力下做出的，庄园方面对这一决定表示宽慰。以“放弃对话”为旗号组织抗议活动的运动人士称赞此举是“人民力量”和直接行动的胜利。 尽管该活动将不再在波斯考特举行，但活动人士警告称，他们将密切关注该会议是否有意转移至爱尔兰的其他场地。他们向其他酒店发出了明确警告，要求避免接待该团体，倡导者们强调，此类集会与爱尔兰社会在声援巴勒斯坦问题上的强烈民意相悖。
抱歉。
人工智能从根本上改变了软件开发，它并没有减少代码的总量，而是将编程从一种专门的职业转变为一项通用能力。 尽管软件行业的整体就业人数保持稳定，但“初级”程序员——即那些受雇按规范编写代码的人——的市场已经崩溃。数据显示，22至25岁人群的入门级招聘和就业人数急剧下降。相反，数以百万计的非工程师正在利用人工智能开发软件，这导致了代码仓库创建数量破纪录，以及 App Store 提交应用数量的激增。 传统的软件工程师“晋升阶梯”已经断裂：由于人工智能现在可以处理初级任务，过去用于培养未来高级开发人员的学徒模式已经消失。尽管一些公司正在尝试新的初级岗位，但整个行业仍面临严峻挑战。随着编程从一个具体的职位演变为一种通用技能（类似于打字），行业必须建立一种培养高级判断力的新方法。如果不能为人才创造新的“入门通道”，当前软件创作的繁荣将因缺乏经验丰富的专业人员来监督所生成的代码，从而在未来面临不稳定的风险。
关于人工智能是否已经“摧毁”了初级程序员就业市场的 Hacker News 讨论揭示了行业内巨大的分歧。许多专业人士证实，初级职位的招聘已显著放缓甚至完全停止，因为企业现在更倾向于雇佣能够利用 AI 工具替代整个初级团队产出的资深开发人员。
反对“唯 AI 论”的观点则认为，由于市场调整以及 2021 年至 2024 年招聘热潮中涌入的大量不合格候选人，初级就业市场早已处于衰退之中。一些招聘经理表示，应聘者技术能力不足，且对软件工程缺乏真正的热情，这让他们感到沮丧。
另一方面，一些参与者认为这种转变是编程的“平民化”，非开发人员现在也可以为各自的领域构建工具。然而，经验丰富的工程师们普遍持悲观态度：他们认为，如果没有入门级岗位，培养未来资深人才的渠道就会被切断。尽管有人建议 AI 可以加速初级人员的学习，但大多数专业人士坚持认为，实践经验和指导是早期职业生涯中无可替代的部分。
Zig：所有包管理功能已从编译器移至构建系统 Zig: All Package Management Functionality Moved from Compiler to Build System
17 天前
以下是上述内容的中文翻译： 此摘要涵盖了 2026 年上半年 Zig 语言的主要进展： **编译器架构与构建系统** 最重要的变化是将 `zig build` 过程拆分为“配置器”（用户脚本）和“构建器”（构建系统）。这实现了构建配置的缓存，显著提升了性能，并允许构建系统在优化模式下运行。包管理现已移至构建器进程中，简化了依赖项处理。此外，全新的原生 ELF 链接器实现了快速的增量构建。 **语言与工具链增强** * **SPIR-V：** 后端进行了重大改进，包括新增 `@SpirvType` 内置函数、多线程代码生成以及更好的链接器集成。 * **@bitCast：** 重新定义了基于逻辑的语义，提高了跨平台的一致性，并支持了性能优化。 * **类型解析：** 内部经过重构，提升了编译器性能，并优化了错误提示（特别是在处理循环依赖时）。 * **Windows：** Zig 正逐步增加对原生 `ntdll` API 的支持，以替代 `kernel32`，旨在减少冗余并提高可靠性。 * **Libc：** 该项目持续使用原生 Zig 实现替换现有的 C 代码，从而提高了编译速度并减小了二进制文件大小。 * **I/O：** 基于用户态栈切换（“纤程/fibers”）的实验性 `std.Io.Evented` 支持正在开发中。
Zig 最近将所有的包管理功能从编译器中剥离，并整合进其构建系统中。这一设计变更在 Hacker News 上引发了热烈讨论。
支持者认为，将包管理与编译器解耦提升了架构清晰度，并符合该语言的长期目标。然而，一些用户对由此产生的复杂性表示不满，将其比作“从油箱里抽出冷却液”——并质疑这些功能当初为何会被耦合在一起。
讨论的很大一部分集中在使用 WebAssembly (WASM) 来沙盒化构建脚本的可能性上。支持者认为这将提供一种安全且可审计的方式来处理第三方依赖，但怀疑论者认为，只要构建系统最终需要与外部工具交互，真正的安全性就难以实现。
讨论还触及了编程语言开发的宏观哲学，用户赞扬了 Zig 相比于人工智能生成的替代方案，其“健康”且以人为本的方法。归根结底，这一讨论反映了业界在集中式包管理、构建系统安全性以及构建高效跨平台工具的持续挑战之间，所存在的广泛分歧。
该项目为 Apple Silicon Mac、iPhone 和 iPad 带来了《命令与征服：将军 – 零点行动》的原生性能。通过将 2003 年原始引擎源码编译为 ARM64 架构，并利用转换层（DXVK/MoltenVK），游戏无需模拟即可运行。它还针对移动端优化了触控操作，包括框选和双指缩放功能。
此版本基于 EA 开源的源码，并在 *GeneralsX* 移植的基础上增加了对 iOS/iPadOS 的支持以及关键的引擎修复。请注意，**不包含游戏资源文件**；用户必须拥有正版副本（例如通过 Steam），才能下载必要的数据。
该项目提供了适用于 macOS 和 iOS 的完整构建脚本，需要 Xcode 和特定的开发工具。尽管该移植版功能完善，但仍处于持续开发中，已知在 iOS 长时间运行期间存在内存管理方面的局限性。详细文档（包括技术“移植指南”和 AI 辅助开发过程的完整工程日志）可在仓库中查阅。
**核心资源：**
* **源码：** [GitHub - Generals-Mac-iOS-iPad](https://github.com/ammaarreshi/Generals-Mac-iOS-iPad.git)
* **需求：** 原始游戏资源（需拥有 Steam 版）。
* **鸣谢：** 由 Ammaar Reshi 使用 Claude Code 工程化开发。
一位开发者近期宣布将《命令与征服：将军（零点行动）》原生移植到了 iOS 和 iPadOS 平台。尽管该项目被标榜为利用 Claude “Fable” 进行 AI 辅助开发的成功范例，但社区对此反应不一。
**讨论要点：**
* **项目范围：** 该项目依赖于 EA 根据 GPL v3 协议发布的源代码以及现有的 *GeneralsX* 分支。后者此前已经完成了将游戏移植到 Linux 和 macOS 的大部分“重活”。AI 辅助贡献主要集中在添加 iOS/iPadOS 支持、触摸控制以及一些细微的引擎修复上。
* **“氛围编程”与现实：** 许多评论者批评标题有标题党之嫌，指出 AI 并非从零开始移植了整个游戏。批评者认为，AI 的作用被夸大了，旨在为 Anthropic 的工具制造炒作热度。
* **软件的未来：** 该帖子引发了关于“AI 代理”工作流程的更广泛讨论。支持者认为，大语言模型（LLM）使独立开发者能够复活被废弃的软件并更新老旧的代码库，有效地将经典的开源问题——“谁来维护这个项目？”——的答案从“一个团队”改写为“我和我的 AI 助手”。
* **担忧：** 持怀疑态度者仍对“劣质代码”（指难以理解的机器生成代码）、移植版本的高内存占用，以及当开发者不再完全掌握底层实现时可能导致的长期可维护性丧失表示担忧。