## 针对性随机测试发现安全漏洞 最近一案例表明，基于属性的测试 (PBT) 发现了一段由人工智能为聊天应用程序的 API 密钥存储系统生成的代码中一个微妙的安全缺陷。尽管实现看似稳健，并且通过了传统的单元测试，但 PBT 揭示了一个与 JavaScript 原型相关的漏洞。 团队使用了规范驱动开发 (SDD)，定义了一个“往返”属性：保存并检索 API 密钥应该返回原始值。在测试期间，PBT 随机生成输入字符串，并在第 75 次迭代时，当使用 "__proto__" 作为提供者名称时失败。这暴露了一个潜在问题，恶意输入可能会操纵对象原型，但由于当前代码的限制，目前尚不可利用。 修复措施包括实施防御措施：使用 `Object.create(null)` 进行安全存储（移除原型链）并验证检索。这突出了 PBT 在系统地探索输入空间和发现人类直觉和传统测试遗漏的边缘情况方面的优势。 这个例子强调了自动化测试的重要性，即使对于人工智能生成的代码，也要主动识别和解决潜在的安全风险，然后再进行部署。PBT 提供可执行的规范、紧密的反馈循环以及对常见错误模式的机构知识，最终带来更健壮和安全的软件。
每日HackerNews RSS
基于属性的测试发现了一个我永远不会发现的安全漏洞。
Property-Based Testing Caught a Security Bug I Never Would Have Found
3 天前
## Hacker News 讨论总结：基于属性的测试与 JavaScript 安全
一篇近期博客文章 (kiro.dev) 强调了基于属性的测试 (PBT) 如何捕获了 JavaScript 代码中的一个微妙错误——具体来说，通过 `__proto__` 字符串可能造成的原型污染。虽然由于 JSON.stringify 的处理方式，该错误无法直接利用，但它表明了意外输入如何轻易引入漏洞。
讨论的重点在于超越“正常流程”场景进行全面测试的重要性。一些人认为传统的测试驱动开发 (TDD) *应该* 覆盖边缘情况，而另一些人则强调 PBT 生成问题输入（如 `__proto__`）的能力，这些输入是开发者可能无法预料到的。
一个反复出现的主题是 JavaScript 的独特漏洞，一些人认为像 Rust 这样的语言可以防止此类问题。然而，其他人指出类似的问题也可能发生在其他语言中，例如 Ruby。对话还涉及过度依赖 LLM 以及对严格工程实践的需求，对 AI 生成的营销材料持怀疑态度。最终的结论是使用成熟的测试库而不是自行编写的价值，以及了解 JavaScript 的具体特性。
## HP Zbook G1a (AI Max+ 395) – 性能总结
使用一个月后，HP Zbook G1a (128GB 内存) 证明了其作为移动工作站的强大竞争力，尤其是在矩阵运算和 FDTD 模拟等内存密集型任务中。AI Max+ 395 APU 在满载时（CPU 或 GPU）初始功耗约为 80W，随后稳定在约 70W，并略微降低时钟频率后降至约 45W。
在 FDTD 计算中——一种受内存带宽限制的工作负载——Zbook 凭借其快速的 256 位 LPDDR5x 8000 MHz 内存，实现了与高端 Threadripper 工作站 80% 的性能。运行本地 LLM (Phi4 推理加 Q8)，上下文窗口为 24k，展现了超过 80% 的峰值内存带宽（约 205 GB/s），甚至成功加载了 70B 模型，仅使用了 32GB 专用 GPU 内存。COMSOL 基准测试显示了具有竞争力的性能，峰值读取带宽约为 72GB/s。
然而，Windows 电源管理目前限制了对所有 16 个线程的充分利用；第二个 CPU CCD 除非完全加载，否则将保持非激活状态，需要像 Process Lasso 这样的解决方法。BIOS 中缺少 SMT 禁用选项是这款工作站级设备的一个显著遗漏。
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 工作 | 提交 登录
我对HP Zbook Ultra G1a的初步印象：Ryzen AI Max+ 395，Strix Halo 128GB (level1techs.com)
19 分，由 teleforce 1天前发布 | 隐藏 | 过去的 | 收藏 | 2 条评论
rubatuga 1天前 | 下一个 [–]
SMT可以在Linux引导加载程序中禁用 -nosmt 回复
cranberryturkey 1天前 | 上一个 [还有2条]
[已标记]
Morthor 1天前 | 父级 [–]
这条评论对对话没有贡献。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
Google Sans字体被广泛应用于谷歌产品，是庞大协作努力的成果。数百名设计师和贡献者——包括个人和Dalton Maag、Colophon Foundry等字库公司——参与了它的创建和持续开发。 这份名单代表了来自世界各地的多元化人才团队，包括字体设计师、插画家和研究人员。Akaki Razmadze和Aleksandra Samulenkova等关键人物因其贡献而受到认可。 除了核心设计团队外，Sarah Daily和Susanna Zaraysky提供了额外的报道，而Arthur Ribeiro Vergani创作了配套的插图和动态图形。Google Sans真正体现了一种集体精神，展示了设计中开放协作的力量。
## Google Sans Flex字体发布 - Hacker News 总结
最近 Hacker News 的讨论集中在谷歌发布的新可变字体 Google Sans Flex。文章详细介绍了字体的设计和开发，包括解决非拉丁文字符集的问题，但讨论很快偏离了主题。
许多评论者关注的重点不是字体本身，而是发布页面的谷歌网页设计选择，批评了迟缓、变形的鼠标光标和性能问题，尤其是在移动设备上。 几位用户报告感到头晕或反应迟钝。
除了页面设计之外，该帖子还引发了关于苹果手机设计（特别是手机摇晃和摄像头凸起）的争论，以及美观性和可用性之间的权衡，以及网站越来越需要大量带宽的趋势。 用户还分享了他们最喜欢的字体，并抱怨很难找到“完美”的字体，尤其是在编码时。
最终，讨论强调了一个共同的主题：对那些优先考虑新颖性而非实用用户体验的设计选择感到沮丧。
《从零到QED》是一个学习系列，旨在从基础开始教授Lean 4，这是一种功能强大但目前文档不足的形式化语言。该资源力求弥补现有学习材料的不足，采用实用、非正式的方法。 该系列分为两部分：第一部分是Lean作为一种编程语言，涵盖语法、类型以及单子和IO等编程概念；第二部分是Lean作为定理证明器，深入探讨证明写作、类型论和策略。 值得注意的是，整个系列*本身*就是一个Lean项目——所有代码和证明都经过机器验证，并可在GitHub上获取（github.com/sdiehl/zero-to-qed）。无需先前的定理证明经验，但熟悉函数式编程会有所帮助。该系列以探讨形式化方法在人工智能时代日益增长的相关性作为结尾。它是一个实用的入门点，与更严谨的学术资源形成对比。
## 从零到QED：LLM与数学证明的未来
一项新资源（[sdiehl.github.io/zero-to-qed/](https://sdiehl.github.io/zero-to-qed/)）介绍了使用Lean 4进行形式化数学证明，引发了Hacker News上的讨论。对话的中心是大型语言模型（LLM）可能如何影响该领域，特别是随着证明变得越来越复杂——可能超过人类验证的能力。
一个关键的担忧是，数学家是否能够自信地验证由LLM生成的数百万行代码的证明。虽然Lean编译器确保了*形式化*的正确性，但信任可能会从人类理解转移到对工具链本身的依赖。一些人认为，证明的核心价值不仅在于真理，还在于在过程中发展理解和新的数学思想。
另一些人指出，Lean的受信任内核足够小，可以供人类审查，并强调模块化、"美观"证明的重要性，这些证明仍然易于理解。一个主要的争论点在于形式化是阻碍还是增强了数学探索，一些数学家对采用额外的工作犹豫不决。然而，像Kevin Buzzard这样的倡导者展示了对证明助手日益增长的参与度。
经过多年的努力，为庆祝《Commander Keen 1-3》游戏35周年，其完整源代码已公开发布。这包括从最早的1990年beta版本到鲜为人知的1.34版本，允许使用原始编译器（Turbo C++ 1.00/1.01和Turbo Assembler）创建逐位相同的可执行文件。
重建工作充满挑战，主要原因是需要特定的编译器版本。一个关键的障碍是精确地排列BSS段中的未初始化变量，这需要使用策略性命名的变量来影响编译器的输出。
有趣的是，此次发布揭示了《Keen》团队重用了他们之前在Softdisk公司的工作代码，特别是《The Catacomb》和《Hovertank》中发现的例程，这可能导致版权问题。证据表明，《Dangerous Dave》的代码也被利用。
现在，源代码可供爱好者探索和修改，为这款经典DOS游戏的起源提供了一个引人入胜的视角。
## Commander Keen 源代码重建与法律讨论
Commander Keen 1-3 的源代码重建版已发布 (pckf.com)，引发了 Hacker News 的讨论。该项目是“匹配反编译”——它不包含原始资源，但重建了代码，并需要用户现有的游戏文件。
一个关键的争论围绕着发布反编译代码的合法性，特别是关于版权和原始权利人（如 id Software/Apogee）可能发起的删除请求。一些人认为反编译是一个法律灰色地带，而另一些人则指出版权法，认为这类似于缺乏足够创意投入的翻译。 历史背景也被提及，指出 id Software 早期代码重用的做法（可能源于他们 Softdisk 时期）以及游走在法律边缘的行为。
讨论还涉及了人们对知识产权态度的演变，从破解游戏以解放的“自由软件”精神，到目前对所有权的高度关注。 最后，用户指出该项目可能使相关项目（如 Commander Genius）受益，并与 Mister AO486 核心兼容。
Apple Search Ads 将于 2026 年扩展，为广告商在 App Store 搜索结果中提供更高的曝光率——几乎 65% 的应用下载都源自此处。目前广告显示在搜索结果的顶部，现在也将出现在结果页面的更下方。 现有广告系列将自动符合新展示位置的条件，无需更改。广告将保持相同的形式（使用产品页面和可选的深度链接），计费方式也相同（按点击或安装付费）。 Apple Ads 利用关键词——由广告商选择或由 Apple 建议——将广告与相关的用户搜索匹配，顶级广告的转化率超过 60%。广告展示位置并非仅基于竞价；**与搜索查询的相关性至关重要**。Apple 优先向用户展示与搜索真正相关的应用，即使竞价更高，也能确保积极的用户体验。
要启用SMB Direct，一种使用RDMA的高性能SMB传输协议，需要几个步骤。首先，安装兼容的RDMA设备——硬件（InfiniBand、RoCE、iWARP）或软件模拟器（soft RoCE、soft iWARP），确保内核驱动程序支持。 接下来，需要内核版本5.15或更高版本，以及用于挂载SMB共享的`cifs-utils`软件包。至关重要的是，内核在编译期间*必须*配置为启用RDMA支持，具体而言是Infiniband/iWARP适配器支持和IP-over-InfiniBand（如果适用），或者软RDMA模块。 使用`iproute2`和`rdma link add`创建RDMA接口（例如`siw0`）。最后，在内核配置中启用SMB Direct支持，分别在服务器端（网络文件系统 -> SMB3服务器支持）和客户端（网络文件系统 -> SMB3和CIFS支持）中。重建并安装内核，以激活`cifs.ko`和`ksmbd.ko`模块中的SMB Direct功能。
## SMB Direct & 内核支持总结
最近的 kernel.org 更新为 Linux 内核（5.15 版本及更高版本）添加了对 SMB Direct 的支持——SMB3 over RDMA。这使得应用程序无需 Microsoft 软件即可访问 SMB 共享，从而为更快速、更低延迟的网络存储打开了可能性。
讨论的重点在于潜在的应用场景，例如在 Mac 之间编辑视频文件，或利用 SMB 传输大型文件，如 LLM 模型权重。用户对与传统 SMB 相比的性能提升，以及该实现是否充分利用 RDMA 功能感到好奇。
此次更新似乎源自三星，一些人推测这是由 Tuxera 推动，以提高其 Fusion SMB 的性能。对话还涉及 SMB 总体上出人意料的强大性能，尽管存在一些看法，以及微软长期以来对网络存储优化的关注——以及安全问题。最后，一些评论员指出文件管理器（Windows 和 macOS）中潜在的效率低下，这可能会影响感知性能，而与底层协议无关。
## 理解LLM提示词缓存 提示词缓存通过重用先前计算的数据，可以大幅降低LLM成本（高达10倍）和延迟（可能高达85%）。它*并非*仅仅是重新提供缓存的响应；相反，提供商存储来自处理输入提示的中间结果——具体来说是LLM的transformer架构中的“attention”机制期间生成的“K”和“V”矩阵。 LLM通过将文本转换为数字token，然后将这些token嵌入到表示其含义的高维空间中来工作。然后，transformer使用“attention”来衡量每个token相对于其他token的重要性。这个过程涉及大量的计算，而K和V矩阵代表了该计算的关键部分。 缓存这些矩阵允许后续使用相同（或相似）提示的请求跳过重新计算它们，从而显著加快处理速度。像OpenAI这样的提供商会自动管理缓存，而Anthropic则提供更多的控制权。重要的是，像温度这样的参数不会影响缓存的有效性，因为它们是在“attention”机制*之后*应用的。 最终，理解提示词缓存揭示了LLM运作方式以及如何优化其使用以实现成本和性能的更深层洞察。随着LLM越来越集成到各种应用程序中，这种知识至关重要。
## LLM 提示词缓存解释
一篇最近在Hacker News上的帖子详细介绍了大型语言模型 (LLM) 中提示词缓存的工作原理以及为什么它对成本效益至关重要。作者 samwho 来自 ngrok，最初打算做一个简单的解释，但最终创建了一份关于 LLM 内部机制的综合指南。
核心思想是 LLM 可以重复利用相同提示词前缀的计算结果，从而显著减少 token 的使用量和成本。这种“KV 缓存”存储了处理初始 token 的结果，避免了重复工作。然而，缓存并非普遍存在；像 OpenAI 这样的提供商出于安全和合规原因，会按组织或用户隔离缓存，并且通常要求提示词至少有 1024 个 token 才能符合条件。
讨论的重点在于，考虑到表达相同问题的多种方式以及上下文的影响，缓存是否真正可行。它在具有一致前缀（如系统提示词）或在历史上下文保持不变的聊天场景中效果最佳。人们对潜在的信息泄露表示担忧，但专家澄清说，缓存不会影响模型的概率分布。这篇帖子引发了人们对 LLM 组件（如前馈和输出层）的进一步探索的兴趣。
用户尝试在其戴尔Precision T3610工作站（运行Proxmox）中将CPU从Intel Xeon E5-1650 v2升级到更强大的Xeon E7-8890 v4，两者均使用FCLGA2011接口。尽管Intel列出这两个CPU与同一接口兼容，但升级失败，原因是物理不兼容——E7-8890 v4有额外的触点和不同的键位。 问题源于FCLGA2011接口家族内的差异。T3610使用R接口（LGA2011-0），而E7-8890 v4需要R2接口（LGA2011-1）。Intel不一致的命名和规格页面导致了这种混淆，经常将所有LGA2011变体归类在单个“FCLGA2011”标签下。 用户现在有一个无法使用的CPU，因为退货运费超过了最初的购买价格。这次经历强调了在升级CPU时，验证*特定*接口修订版的重要性，而不仅仅是通用的接口类型。
## Rust 在 Linux 内核中：实验宣告成功
最近在 2025 年维护者峰会上确认，Rust 已成功集成到 Linux 内核中，最初作为一项实验引入。数百万设备现在已搭载使用 Rust 编写的内核代码，尤其是在 Android 16 中的 ashmem 模块。采用正在迅速增长——过去一年 Rust 代码量增加了五倍，Debian 现在已将其包含在内核构建中。
人们正在努力推进基于 GCC 的 Rust 编译 (gccrs)，旨在进一步简化开发。内核计划跟踪与 Debian 稳定版本绑定的 Rust 版本，目前目标是 1.85。
开发人员一致认为，是时候取消“实验”标签了，理由是安全性提高以及新开发人员和维护人员的涌入。虽然对所有架构的支持尚未普及（s390 和 PowerPC 仍在进行中），但 x86、Arm 和 RISC-V 等核心架构都得到了良好支持。DRM 子系统甚至预计在一年内将要求新驱动程序使用 Rust。
Linus Torvalds 和 Greg Kroah-Hartman 倡导结束实验阶段，强调了编译器支持以及 Rust 代码中没有关键漏洞（CVE）。该项目的成功也激励了增加文档编写的努力。