本文探讨了“竞争的规则论”，通过系统性的计算方法来确定迭代博弈中的制胜策略。作者没有依赖传统的、由人类提出的策略（如“以牙还牙”），而是采用计算方法枚举了所有可能的策略——将其建模为有限状态机、元胞自动机或图灵机——以观察它们在“猜硬币”或“囚徒困境”等重复博弈中的表现。
研究表明，竞争本质上受计算不可约性支配；由于这些程序的行为可能变得复杂且不可预测，通常无法通过定理推导出制胜策略。相反，必须运行程序以观察结果。虽然一些制胜策略利用了“简单的技巧”，但另一些则极为复杂。此外，适应性进化可以成功发现能够利用“不可约计算块”来智取对手的高性能策略。
最终，作者认为，由于简单的程序往往会产生复杂、周期性或不可预测的行为，系统枚举是理解竞争动态的唯一可靠途径。这种方法强调，与其通过静态的博弈论分析，不如通过基础计算过程的视角来审视生物、经济和人工系统中的竞争。
每日HackerNews RSS
这篇 Hacker News 讨论聚焦于斯蒂芬·沃尔夫勒姆（Stephen Wolfram）最近的文章《程序间的博弈：竞争的规则学》（Games Between Programs: The Ruliology of Competition）。
评论者 *quuxplusone* 指出了文中提到的一个引人入胜的特定序列：能够胜过任何 $n$ 状态对手的最小“硬币匹配玩家”确定性有限自动机（DFA）的大小。虽然沃尔夫勒姆给出了 $n=1$ 和 $n=2$ 的值，但 $n=3$ 的值仍不明确。该用户质疑这一序列是否被收录在整数数列在线大全（OEIS）中，并指出这个问题与单纯识别对手策略的问题不同，后者需要更多的状态。
这一简短的讨论串凸显了人们对沃尔夫勒姆作品中计算复杂性方面的兴趣，另一位用户建议回归沃尔夫勒姆的《一种新科学》（A New Kind of Science）来更好地理解讨论的背景。
16位Windows内存管理旨在克服8086/80286硬件缺乏分页功能的局限性。由于系统规模超过了可用内存，Windows通过充当覆盖管理器，使用“新可执行文件”（NE）格式来按需加载、移动或丢弃内存段。 由于这些内存段是可移动的，它们是通过不透明的句柄而非固定地址来标识的。开发者必须使用 `GlobalLock` 将内存段锁定在内存中，并使用 `GlobalUnlock` 释放它们，这一过程需要严格的纪律以避免产生“隐蔽”的错误。该系统依赖于在运行时进行补丁处理的专用函数序言和尾声，以正确管理数据段（`DS`）寄存器和堆栈帧。 尽管OS/2利用286保护模式硬件来自动执行这些任务，但16位Windows要求开发者手动处理导入、导出以及特定的编译器开关（如 `/Gw` 和 `/Aw`）。因此，微软提供了如“Shaker”和“HeapWalk”等压力测试工具，以帮助程序员强制触发内存错误，并识别在内存充足时难以发现的内存段处理故障。归根结底，Windows内存管理是一种基于软件的复杂变通方案，旨在弥补当时硬件尚不支持真正保护模式内存虚拟化的缺陷。
这篇 Hacker News 帖子探讨了 Win16 内存管理的复杂性，开发者当时必须在严重的硬件限制下，通过手动处理段（segments）和偏移量（offsets）来进行编程。
主要内容包括：
* **架构挑战：** 为了保持与早期 CPU 的兼容性，Windows 依赖分段内存（近指针、远指针和巨大指针）。与现代系统不同，Win16 缺乏内存保护，这意味着 DLL 和应用程序通常共享全局内存，因此需要严格的规范以避免冲突。
* **历史背景：** 参与讨论者回顾了那个时代的艰辛，指出开发者不得不“重复造轮子”并深入了解硬件底层，这往往能培养出更好的工程素养。
* **学习曲线：** 虽然有人认为与平面内存模型相比，这些限制是多余的“紧身衣”，但也有人认为克服这些障碍造就了更强大的程序员。
* **现代视角：** 讨论连接了过去与现在，指出一些古老的技术（如段切换或内存映射）在现代语境下（如 CPU-GPU 编程）往往焕发了新生。
总而言之，参与者将 Win16 时代视为一个虽然繁琐但具有塑造性的时期，它要求极高的技术造诣，并与当今抽象的高级开发及碎片化注意力时代形成了鲜明对比。
投机式 KV 编码：将 KV 缓存无损压缩至原来的 1/4 Speculative KV coding: losslessly compressing KV cache by up to ~4×
26 天前
随着大语言模型（LLM）的规模不断扩大，KV缓存的内存需求已成为瓶颈。尽管有损压缩（如降低位宽）可以缓解这一问题，但会带来模型质量下降的风险。“推测式KV编码”（Speculative KV coding）通过提供一种无损压缩方法解决了这一问题，在现有FP8方法的基础上实现了约4倍的额外压缩（总计约8倍）。 其核心思想是利用一个更快的“预测器”模型来估计目标模型的缓存。编码器和解码器并行运行此预测器，为每个缓存值生成统计模型（均值 $\mu$ 和方差 $\sigma^2$）。随后，算术编码器利用这些预测值将实际缓存值压缩为位流。由于双方都能根据提示词确定性地重建相同的 $(\mu, \sigma)$，因此原始缓存可以被精确恢复。 初步结果显示，尤其是在与预量化的FP8缓存结合使用时，该方法在比特率方面有显著提升。这种方法在带宽受限的场景下前景广阔，例如跨数据中心的分离式LLM服务或扩展主机RAM前缀缓存。下一阶段的开发重点将集中在更复杂的残差建模，并利用跨模型预测器，以进一步优化计算开销与内存节省之间的权衡。
这篇 Hacker News 的讨论探讨了“推测性 KV 编码”（Speculative KV Coding），这是一种通过小型辅助模型来预测并仅存储“增量”或误差项（而非完整缓存），从而压缩大语言模型键值（KV）缓存的技术。
支持者认为，这可以大幅降低显存占用，使消费级硬件有望支持超长上下文（例如 256k token）。他们认为，随着模型规模的扩大，“预测器”模型的计算成本相对于内存节省而言微不足道。
然而，批评者对该方案的实用性提出了重大质疑：
* **计算开销：** 许多人认为，在每个解码步骤中重新计算缓存的成本依然过高且缓慢，可能会拖累性能。
* **带宽限制：** 怀疑者指出，GPU 到内存的数据传输速度通常导致重新计算比直接存储完整缓存更慢。
* **可行性：** 一些人认为该方法“并非真正的压缩”，因为主模型最终必须重构完整数据，这使其效率还不如简单的 LRU 缓存或卸载到磁盘。
目前社区观点仍存在分歧，许多人将其视为一种有趣的理论探索，而非应对不断增长的上下文窗口的生产级解决方案。
最近的研究表明，可以直接从冻结的 Llama 模型的内部激活状态中提取算术能力，而无需依赖提示文本。这种被称为“Rune”的框架使用基于激活的读出机制来确定何时触发计算器以及传递哪些参数，从而成功绕过了对自然语言解析的需求。 在对超过 11,000 个案例的审计中，该系统在区分真正的算术请求与“困难负样本”（即看起来像数学问题但不应触发计算的文本）方面表现出极高的有效性。在针对 DeepMind 数学数据集的测试中，该框架的表现比仅使用冻结模型有了显著提升。对于带余除法、最大公约数（GCD）和最小公倍数（LCM）等任务，该路径能够持续绕过模型的内部限制，得出准确答案。研究结果表明，这些算术参数被编码在模型的内部状态中，为工具使用提供了一种既精确又能够抵御对抗性操作的稳健机制。
这份 Hacker News 的讨论探讨了大语言模型（LLM）如何进行算术运算，以及它们对外部工具的依赖暗示了其本质为何。
主要观点如下：
* **原生运算与工具辅助数学：** 虽然模型可以通过内部矩阵运算进行“心算”，但这往往不可靠。使用外部工具（如计算器或 Python）是一种必要的“卸载”策略，正如人类使用计算器来弥补自身认知局限一样。
* **关于“代理”的辩论：** 批评者认为，为 LLM 强行接入确定性插件，说明它们仅仅是复杂的专家系统，而非真正具备自我进化能力的通用人工智能（AGI）。支持者则反驳称，人类智能同样建立在将复杂任务卸载给外部工具和抽象概念的基础上。
* **认知类比：** 数学家在进行数学思考时往往倾向于空间想象而非符号处理。同样，用户也在争论 LLM 的算术运算究竟应被视为“真正的”计算，还是仅仅通过拼凑解决方案实现的“鲁布·戈德堡机械”式的过程。
* **效率问题：** 虽然有人认为原生数学比调用外部进程更快，但另一些人则指出，与运行大模型本身的高昂成本相比，使用 Python 等工具所产生的额外开销微不足道。
该作者的软件开发理念遵循一套明确的优先级层级，其最终的“北极星”目标是为终端用户创造实用且令人喜爱的软件。 这一目标通过以下三大基石来实现： 1. **实用性**：软件必须具备真正的价值并以用户为中心；无论技术质量如何，对用户不友好的项目都是失败的。 2. **正确性**：功能性至关重要，因为缺陷会直接损害软件的宗旨。如果没有稳健的设计流程来确保可靠性，技术安全特性将毫无意义。 3. **效率与可维护性**：软件必须具备高性能，并便于后续开发。如果过度设计的抽象导致性能缓慢或产生阻碍长期发展的技术债务，那么这些抽象是无用的。 虽然作者重视开发者体验，但将其仅视为达成目标的手段。每一项技术决策——从语言选择到架构设计——都完全是为了服务于终端用户。在面对挑战或分歧时，作者始终专注于主要目标：交付人们能够真正享用的高质量、可持续的软件。
这篇 Hacker News 讨论围绕 Zig 软件基金会社区副总裁 Loris Cro 的文章《我的软件北极星》（My Software North Star）展开。该讨论引发了关于软件开发未来的激烈辩论，主要集中在以下三个主题：
* **Zig 与 Rust：** 对话凸显了两个社区之间的紧张关系。一些人认为 Rust 的编译时内存安全性更胜一筹，而 Zig 的支持者则捍卫该语言，称其为更“精巧”、更“优秀的 C 语言”，在无需 Rust 复杂性的前提下提供了手动控制能力。Bun 项目近期从 Zig 迁移至 Rust，成为了这些争论的主要导火索。
* **人工智能的影响：** 用户对“氛围编程”（AI 辅助开发）持不同意见。怀疑论者认为这是一种降低批判性思维和代码质量的捷径。而另一些人则认为 AI 是一种提高生产力的工具，并指出无论代码如何编写，Zig 及其他底层语言依然至关重要。
* **定义“正确性”：** 讨论批评了作者关于“内存安全次于‘为正确性而设计’”的哲学立场。批评者认为这是一种模糊且可能具有误导性的理想；支持者则坚持认为，在一个常被炒作所干扰的行业中，这是构建真正有用软件的必要指导原则。
第29届国际混乱C代码大赛（IOCCC29）已圆满落幕，本届比赛保持了极高的投稿量与卓越的质量。2025年的获奖作品现已在官网公布，用户可查阅源码、作者感言以及各程序的编译与运行指南。 本次更新的亮点包括为每位获奖者增设了“趣味挑战”板块，鼓励社区通过 GitHub 的 Pull Request 功能提交改进方案或技术解读。此外，IOCCC 对规则进行了大幅修订，并优化了内部文档处理流程，使赛事管理更加顺畅。 尽管竞争依然激烈，评委们仍鼓励未获奖的参赛者精进作品，并指出许多本届获奖作品其实都是往届参赛作品的优化版本。第30届 IOCCC 的计划定于 2026 年末举行。在赛后休整及处理完初步贡献后，评委们将继续维护相关代码仓库。欢迎各位参赛者探索获奖作品、在 YouTube 上观看颁奖展示，并为下一届比赛做好准备。
2025年第29届国际C语言混乱代码大赛（IOCCC）已公布获奖名单，引发了Hacker News上的热烈讨论。其中最引人注目的作品之一是rclone作者Nick Craig-Wood制作的一款功能性Game Boy模拟器，其代码被创意性地排版成了Game Boy硬件的外观。
该比赛要求代码极其精简，通常要在严格的字符限制内完成，迫使参赛者挑战C语言语法的极限、利用各种晦涩的漏洞，并采用诸如在Makefile中定义符号等创意手段来实现目标。
讨论的一个核心议题是人工智能的角色。尽管IOCCC的规则明确允许使用AI工具，但参赛者指出，大语言模型目前并不擅长生成真正的“混乱艺术”。虽然它们在代码去混淆方面表现出色，但缺乏创造优雅、诡谲且技术精湛的代码所需的独到匠心。用户得出结论：IOCCC依然是一项独特的人类竞赛，相比单纯的计算复杂性，它更看重审美天赋、创造力以及“人类级别”的问题解决能力。尽管该大赛的网站导航存在挑战，但社区仍将其视为展示非常规编程技巧的重要舞台。
本文审视了一股令人不安的趋势：公众对知名软件开发者的心理健康危机怀有窥私欲，文中所指的案例为泰瑞·A·戴维斯（TempleOS）与肯特·奥弗斯特里特（bcachefs）。 作者认为，尽管戴维斯的操作系统属于小众技术项目，而奥弗斯特里特的文件系统是专业工程，但两人最终都沦为了公众审视的对象。在这些案例中，在线社区——从恶意挑衅者到看似好心的旁观者——通过骚扰、嘲弄以及对他们个人妄想的侵入性审视，将这些人变成了某种“娱乐”来源。 作者指出，这种行为常以将目标贴上“有问题”或“难以相处”的标签来开脱，从而为参与者提供了一种道德正当性，使其得以参与到实质上的现代羞辱仪式中。文章总结道，将这些危机炒作化不仅伤害深重，更强化了污名化的循环。作者主张，与其参与这种“马戏团表演”，不如给予同情与隐私，并尊重那些陷入挣扎者的自主权。若无法提供实质性的帮助，最合乎伦理的选择是转身离开，不去理会，而非助长对他人的痛苦进行公开剥削。
抱歉。
作为 Jane Street 的一名设计师，作者起初对大语言模型（LLM）持怀疑态度，但如今已通过利用人工智能构建功能性原型而非静态模型，彻底改变了自己的工作流程。通过使用 Claude 等工具编写陌生语言（OCaml 和 Bonsai）的代码，作者现在能够直接在代码库中对实时功能进行迭代，从而绕过了 Figma 文件和规格说明文档等传统的“辅助性”设计产物。
这种方法实现了快速、高保真的实验，能够在不占用工程资源的情况下验证可行性并改善用户体验。虽然作者也指出了潜在的挑战——例如确保合作者有权对“成品化”的原型提出批评，以及避免人工智能辅助迭代带来的创造性限制——但这种转变赋予了设计师巨大的赋能。
通过在实际媒介中进行构建，作者重新获得了创建工作概念证明的能力，而这曾是工程师的专属特权。这种演变绕过了复杂的正式设计流程，使作者能够专注于打磨最终产物，并促进了更流畅、更直接的“设计到实现”过程。
简街（Jane Street）最近发表的一篇文章称，利用人工智能（Claude）进行“氛围编程”（vibe coding）已在很大程度上取代了 Figma 的设计工作流，这一观点在 Hacker News 上引发了激烈的争论。
支持者认为，人工智能能够实现快速迭代的原型设计，其交互性和功能性远超静态的 Figma 设计稿。他们将此视为向更高层抽象的转变，开发者无需手动进行布局，而是通过对话即可快速将想法落地并进行优化。一些人认为，这种方式降低了创作门槛，并加速了利益相关者与开发者之间的反馈循环。
然而，批评者表达了强烈担忧。许多人认为人工智能生成的代码往往是“垃圾”——存在技术缺陷，缺乏架构完整性，且难以供工程师审查或维护。持怀疑态度的人警告称，“氛围编程”助长了批判性思维的缺失，绕过了必要的边界条件验证，并造成了运营负债。此外，这种观点也因其来源而遭到质疑；批评者指出，简街是 Anthropic 的投资者，暗示该文章可能带有“人工智能吹捧”的宣传性质。
归根结底，这场讨论反映了行业内更广泛的张力：即追求人工智能驱动的快速迭代，与传统工程对纪律、稳定性和人为设计严谨性的要求之间的博弈。
请提供您想要翻译的内容。
抱歉。
PaceVer 是一种专为应用程序设计的版本控制系统，有别于 SemVer，旨在管理原生二进制更新与空中下载（OTA）补丁之间的交互。 **核心机制：** * **版本构成：** 应用程序在运行时通过 `MARKETING.NATIVE.OTA` 计算其版本。OTA 版本号存储在更新清单中，而 `MARKETING` 和 `NATIVE` 则驻留在二进制文件中。 * **重置：** `NATIVE` 构建总是会将 `OTA` 重置为零。`MARKETING` 的重置是可选的；团队可以选择将 `NATIVE` 和 `OTA` 重置为零（例如从 1.6.2 到 2.0.0），或者保持单调递增（例如 2.6.2）。 * **约束：** `MARKETING` 和 `NATIVE` 的更改需要发布新的商店二进制文件，而 `OTA` 更新则不需要。`NATIVE` 的增量必须在所有平台（iOS/Android）上同步应用，以保持 OTA 谱系的连贯性。 * **适用范围：** PaceVer 严格适用于应用程序。库和 API 应继续使用 SemVer 来管理契约兼容性。 * **采用建议：** 新项目通常从 `0.1.0` 开始。现有应用不应将版本号向下重置以避免被应用商店拒绝；应在现有营销版本历史的基础上采用 PaceVer 语义。