## 正式验证 50 年进展 (1975-2025) 最近关于科学停滞的说法忽视了计算机领域的进步，尤其是在正式验证方面——对软件和硬件正确性的严格证明。虽然早期的计算进步受益于工业研究，但基础工作源于学术界和政府资助。本文重点介绍过去 50 年证明助手的发展，从 1975 年的爱丁堡 LCF 开始，该系统通过严格的推理规则确保定理生成。 剑桥 LCF 紧随其后，为 HOL 系统家族铺平了道路。Isabelle 于 1986 年出现，支持构造类型理论并能够进行复杂的形式化。20 世纪 90 年代的一个转折点是 John Harrison 对浮点算术的验证，展示了这些工具在严肃数学方面的强大功能。 21 世纪见证了越来越多的采用。里程碑式的成就包括 ARM6 处理器的形式化验证、CompCert 编译器以及亚马逊网络服务 (AWS) 的 Nitro 隔离引擎，使用了 26 万行 Isabelle/HOL 代码。数学家越来越多地使用 Lean 等证明助手，例如对主要定理的形式化以及对确认新数学发现的贡献。正式验证正从一个利基领域转变为可靠系统开发的关键组成部分，证明进展*正在*进行。
每日HackerNews RSS
## 证明助手 50 年：Hacker News 摘要
Hacker News 上一篇帖子链接到一篇关于证明助手 50 年进展的文章——这些软件工具用于验证数学证明，并且越来越多地用于验证软件的正确性。讨论强调了一个迷人的渐进式发展故事，与人工智能等领域相比，往往被忽视。
一些评论员注意到基础物理学似乎停滞不前，但在生物学和化学等领域，进展是显而易见的。在符号人工智能领域，包括证明助手，进步是稳定的，但不如神经网络那样引人注目。硬件和软件的改进，特别是 SAT/SMT 求解器，极大地提高了这些工具可以处理的问题规模。
尽管工业用途不断增长，但业务规则引擎等技术仍然出乎意料地边缘化。挑战在于将复杂的、现实世界的意图转化为形式语言，并在上下文变化时保持相关性。最近的进展，如 Lean4、Dafny，以及对费马大定理甚至阿ద్വൈత吠檀多等复杂概念的形式化，展示了持续的创新和不断扩展的应用，表明该领域远未停滞。对话还涉及了进步的“氛围”，指出对人工智能的关注可能会掩盖其他领域的进步。
## OpenAI 拥抱“技能”概念
OpenAI 正在迅速采用 Anthropic 首创的“技能”机制，使 LLM 能够利用外部工具和知识。这种系统，仅仅是一个包含 Markdown 指令和资源的文件夹，已经悄然出现在 ChatGPT 的代码解释器和 Codex CLI 工具中。
在 ChatGPT 中，技能目前支持电子表格、DOCX 文件和 PDF（渲染为图像以保留布局）。最近的测试表明，ChatGPT 成功创建了一份 PDF，总结了 rimu 树对 kakapo 繁殖的影响，展示了其研究和格式化信息的能力。
Codex CLI 也获得了实验性的技能支持，允许用户安装自定义技能——例如，用于创建 Datasette 插件的一个技能——并相应地执行任务。这使得强大的代码生成和自动化成为可能。
作者认为，技能代表了 LLM 能力的重大进步，超越了多轮提示 (MCP) 的影响。他们建议正式记录技能规范，这可能成为 Agentic AI Foundation 的一个项目。
C64 Maze Chomp.BAS
3 天前
## 迷宫吞噬：Commodore 64 BASIC 游戏简介 “迷宫吞噬”是一款简单的迷宫游戏，最初发表于1984年的《Input》杂志，旨在教授BASIC编程。游戏目标是使用WASD键在迷宫中导航，并在最短时间内“吃掉”所有的点（用句点表示）。 代码使用Commodore 64 BASIC编写，设置屏幕颜色、边框和背景，然后使用字符代码仔细构建迷宫布局。关键变量管理玩家位置（`p1`, `p2`）和分数（`co`）。一种巧妙的技术使用`POKE`命令直接操作内存地址，以控制屏幕和按键重复功能。 游戏玩法包括移动玩家角色（π）在迷宫中，吃掉点并跟踪经过的时间。程序会检查与迷宫墙壁的碰撞并相应地更新分数。一旦吃掉所有点，游戏将重置，显示达到的最佳时间。原始代码由于基于文本的编辑限制，需要仔细输入字符代码，这突出了早期游戏开发的挑战。
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 工作 | 提交 登录
C64迷宫吞噬.BAS (basic-code.bearblog.dev)
33点 由 ibobev 1天前 | 隐藏 | 过去的 | 收藏 | 4条评论
FatalLogic 23小时前 | 下一个 [–]
按下ESC键，C64窗口聚焦时停止游戏。之后你可以输入LIST查看代码，然后编辑它，再输入RUN重启。
predictsoft 1天前 | 上一个 [–]
我拥有Input的所有4卷。
empressplay 1天前 | 父级 [–]
可悲的是，Commodore 64 BASIC非常糟糕，你基本上必须学习所有关于ROM例程和机器语言才能做任何有用的事情。
classichasclass 20小时前 | 根 | 父级 [–]
是也不是。它确实在BASIC编程方面很糟糕，但这也意味着你不得不更快地直接驱动硬件，这是充分利用它的最佳方式。
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## 带有Home Assistant的智能加湿器：DIY方法 出于对注重隐私、面向未来的基于Home Assistant的智能家居的渴望，作者着手解决寻找兼容加湿器的问题。对容易过时且依赖云服务的选项不满意，他们选择更换现有智能加湿器的固件。 小米智能抗菌加湿器（型号ZNJSQ01DEM，内部ID deerma.humidifier.jsq）因其ESP8266微控制器而被选中，该控制器可以使用ESPHome轻松编程。现有的固件已过时，促使作者将其重新实现为ESPHome“外部组件”（可在[这里](https://github.com/stv0g/esphome-config/components/xiaomi_deerma_humidifier)找到）。 该过程包括拆卸加湿器、拆焊原始WiFi模块以及焊接电源（3.3V）、地线、RX和TX的连接。刷新新的ESPHome固件需要临时接地GPIO0并使用串行适配器。**至关重要的是，在刷新之前建议备份原始固件。** 这允许在Home Assistant中直接控制加湿器，避免依赖专有应用程序和云服务。
## 解放小米加湿器，摆脱云端依赖
一则Hacker News讨论集中在一个将小米加湿器从云端依赖中解放的项目上。最初的帖子引发了关于超声波与蒸发式加湿器的争论，人们担心超声波型号在使用自来水时会释放PM2.5颗粒。用户分享了空气质量监测器的使用经验，结果各不相同。
对话扩展到“智能”电器需要互联网连接的问题，许多人对购买“非智能”设备日益困难表示沮丧。人们对隐私和远程控制、状态提醒等功能是否必须依赖云连接表示担忧。
讨论的解决方案包括使用蒸馏水、通过Home Assistant进行本地自动化，以及选择更简单、不联网的加湿器。一些用户强调了全屋加湿器的优势，以及使用ESP32模块进行DIY控制，强调了便利性和控制权之间的权衡。最终，该帖子反映了人们希望拥有更多自主权，减少对云端生态系统对日常电器的依赖。
## 重新思考特权提升：Capsudo 作者对`sudo`表示不满，认为其设计过于庞大、配置复杂，并且由于SUID二进制文件的特性和对环境权限的依赖，存在固有的安全风险。传统的特权提升工具（如`sudo`）会授予广泛的访问权限，从而造成巨大的攻击面。 受到对象能力模型（authority是明确且局限于特定动作的）的启发，作者开发了`capsudo`。`capsudo`不采用临时成为root的方式，而是通过与持有狭窄范围能力的`capsudod`服务进行交互来运作。 这种方法利用Unix sockets来表示能力，从而实现精确的控制。例如，可以授予服务特定的挂载/卸载权限，或者允许开发者在*无需*广泛的管理权限的情况下更新文件并重启服务。`capsudo`支持权限的分层，能力可以向下委托，但绝不会扩展。 最终，`capsudo`将重点从*谁*被允许执行操作，转移到*权限在哪里*以及*如何流动*，从而提供了一种更安全、更可组合的权限管理方法。它探索了显式委托，并可能为通过资源传递（如文件描述符）实现更细粒度的控制铺平道路。
## Capsudo：用对象能力重新思考 `sudo` - 摘要
这个Hacker News讨论围绕着Capsudo项目，该项目旨在利用对象能力重新实现`sudo`，以实现更细粒度的权限控制。核心思想是摆脱对仅依赖文件系统权限和用户/组分配的依赖，转向一个通过Unix域套接字显式授予权限的系统。
用户分享了管理`sudo`配置的复杂经历，特别是系统更新覆盖自定义设置的问题。 许多评论员指出了现有的解决方案，如overlayfs和systemd的能力安全特性。
讨论深入探讨了能力委托的好处——仅在需要时才允许有限的权限提升——与传统的ACL模型相比。虽然有些人认为Capsudo是一种潜在的更安全、更可审计的方法，但另一些人认为它本质上是在增加复杂性的前提下复制现有功能。人们对Capsudo守护进程本身可能成为“上帝对象”以及以C语言安全地实现这样一个系统所带来的挑战表示担忧。
最终，这场对话凸显了可用性、安全性和管理复杂操作系统中权限固有的困难之间的持续紧张关系。
## Bidicalc：双向电子表格
Bidicalc 是一款实验性的电子表格，允许“反向”计算——改变一个单元格的*结果*，并让输入单元格调整以匹配公式。与输入决定输出的传统电子表格不同，bidicalc 在给定期望输出的情况下求解输入。
该电子表格区分**变量**（可变数字）、**常量**（以#为前缀的固定数字）和**公式**（标准计算）。它支持常见的算术运算、指数以及 `sqrt`、`pow`、`pi`、`abs`、`log` 和 `exp` 等函数。
其核心创新在于一个自定义的求根算法，它“逆流”导航电子表格的公式以寻找解决方案。虽然功能强大，但求解器可能难以处理复杂或欠定的问题，可能产生不正确或意外的结果。用户可以通过将变量设置为常量或简化公式来优化解决方案。
Bidicalc 是一个基于 TypeScript 的开源项目（AGPL 许可），旨在作为对数学概念的有趣探索。不建议将其用于关键应用，但它提供了一种独特的电子表格计算方法，并欢迎社区贡献和改进。未来的开发目标包括变量域限制和求解器增强。
## Bidicalc：一种反向更新的电子表格
Victor Poughon 发布了“bidicalc”，这是一种新颖的电子表格，其公式可以双向更新——与仅允许输入更新的传统电子表格不同。这创造了一个双向计算器，本质上将电子表格变成了一个约束系统。
用户正在试验这个工具，并注意到它在简单计算之外的潜力，包括金融建模、物理学和日程安排等应用。然而，缺乏明确的约束可能导致意外的结果和一种“混乱”的感觉。
关键讨论点包括：需要一种“锁定”或固定某些变量的方法，可视化自由度，以及求解器内部机制。创建者承认用户体验需要改进才能成为一个严肃的产品，但有意强调了这个项目的实验性质。该项目与约束传播、Prolog，甚至像瑞士信贷的“Paradise”系统这样现有（但复杂）的解决方案相呼应。
你可以在这里试用它：[https://victorpoughon.github.io/bidicalc/](https://victorpoughon.github.io/bidicalc/)
## 将 Go 带入 Python 世界 & 优化 Docker 构建
作者的任务是在主要使用 Python 的公司环境中构建第一个 Go 服务。选择 Go 是因为它速度快、易于使用，并且是 Rust 或 Nix 的舒适替代方案。该项目涉及一个远程代码执行 (RCE) 服务，Go 的安全特性是关键考虑因素。
最初，作者尝试使用 Nix 进行镜像构建，但由于团队已经熟悉，最终回到了 Docker 和 Docker Compose，尽管承认他们当前的 Docker 工作流程效率低下。文章详细介绍了优化 Docker 镜像大小和构建时间的努力。
关键技术包括使用 `scratch` 或 `alpine` 基本镜像进行多阶段构建，利用构建参数 (`CGO_ENABLED=0`) 进行静态编译，以及使用绑定/缓存挂载以加快依赖管理。`.dockerignore` 文件对于排除构建上下文中的不必要文件至关重要。还优化了图层顺序以最大化缓存。最终，作者实现了仅 15.9MB 的最终镜像大小，证明了通过这些 Docker 优化策略取得了显著改进。
## 更快的 Docker 镜像：一则 Hacker News 讨论
最近 Hacker News 上进行了一场关于构建更小、更快的 Docker 镜像的讨论。核心争论在于*在哪里*执行构建过程——在容器内部还是在传统的构建机器上。
许多开发者承认对多阶段构建等技术缺乏了解，导致容器不必要地变大。虽然 Docker 在*打包*方面表现出色，但一些人认为将整个构建过程容器化会带来性能开销。
讨论中的替代方案包括利用基于主机的构建（例如，使用 `ko-build` 构建 Go 项目）或将主机目录挂载到 Docker 中以访问工具链。另一些人则提倡使用 Bazel 或 Nix 等构建系统，它们提供更高的稳定性和缓存能力。
一个关键点是缓存的重要性——无论是通过 Docker 层、特定语言的系统，还是持久的 CI worker 缓存。 许多评论者强调了构建速度、可重复性和依赖管理之间的权衡。最终，讨论强调优化构建管道需要仔细考虑和注重性能的文化。`nspawn` 和 `stagex.tools` 等工具也被提及，作为构建和打包 Docker 的潜在替代方案。
## 浏览器对SVCB和HTTPS记录的支持 (2025年12月) 尽管RFC9460定义了SVCB和HTTPS DNS记录于2023年发布，但两年后浏览器支持仍然不一致。该RFC引入了各种`SvcParamKeys`（如ALPN、ECH、IP Hints和Port），浏览器对它们的实现程度和行为存在差异。当前资源如Caniuse.com缺乏关于此支持的全面信息。 最近的测试集中于Chrome、Firefox和Safari，揭示了不同的能力。**AliasMode/TargetName**用于根域名别名通常按预期工作，通过SNI引导连接。**ALPN**用于协议协商（如QUIC/H3）显示出部分支持。**ECH**用于加密客户端问候也经过测试。**IP Hints**被证明不可靠，浏览器可能会忽略它们或与其他DNS记录发生冲突。**Port**用于非标准TLS端口的指定按预期工作。 值得注意的是，Chrome需要默认解析器，而Firefox需要启用DNS over HTTPS (DoH)才能执行这些查找。作者强调了这些记录的优化实现仍然存在歧义，尤其是在缓存和冲突解决方面。
## HTTPS RR：有限的采用和浏览器支持
一则Hacker News讨论集中在使用HTTPS资源记录（RRs）进行安全的DNS查找。虽然相比传统方法有所改进，但由于DNS提供商的支持不一致以及缺乏明确的浏览器兼容性信息——甚至CanIUse.com也缺乏细节——导致采用率仍然缓慢。
初步观察显示，Safari的HTTPS DNS请求率（预计基于市场份额约为14%）与DNS服务器实际看到的请求之间存在显著差异（约为1-8%）。这归因于非HTTPS网站的使用、缓存以及超出浏览器范围使用DNS的更广泛的设备/应用程序等因素。
值得注意的是，用户纠正了Safari是*唯一*支持HTTPS DNS的浏览器的说法，并引用了Firefox和Chromium中启用的加密客户端问候（ECH）的证据。这次讨论强调了需要更好地了解浏览器支持以及更广泛实施的明确回退策略。
Please provide the content you want me to translate. I need the text to be able to translate it to Chinese. Just paste it here, and I will give you the Chinese translation.
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Wine 11.0 RC2 – 在 Linux, BSD, Solaris 和 macOS 上运行 Windows 应用程序 (winehq.org)
57 分，由 neustradamus 1 天前发布 | 隐藏 | 过去 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 快速中值滤波：总结 本文详细介绍了中值滤波器的优化过程，这是一种常见的图像处理技术。中值滤波器的核心思想是用周围窗口内的中值替换每个像素。 初始实现（V1）涉及对每个像素的窗口内的所有像素进行排序，速度慢且无法很好地扩展到更大的内核尺寸。优化V2用快速选择算法取代排序，实现了4.2倍的速度提升。V3通过引入多线程，进一步提高了性能，通过在多个核心上并行处理，实现了16倍的速度提升。 最显著的改进来自V4，它利用了*序数变换*——用像素的等级代替原始值——以及基于位集的窗口表示。这允许高效的更新和中值查找，实现了惊人的420倍速度提升。通过使用之字形扫描模式，进一步减少了冗余计算。 性能提升主要归功于降低了查找中值的计算复杂度，并利用了现代CPU的功能，如SIMD指令和多线程。虽然描述的优化侧重于通用数据类型，但当限制为特定类型（如uint8）时，通过使用基于直方图的方法和 wavelet 变换等技术，可以实现更大的速度提升。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
快速中值滤波，适用于任意数据类型 (martianlantern.github.io)
35 分，martianlantern 发表于 1 天前 | 隐藏 | 过去 | 收藏 | 2 条评论
ncruces 发表于 1 天前 | 下一个 [–]
由于文章提到了中位数的中位数，我想指出“九位数的中位数”：https://erdani.org/research/sea2017.pdf
我能够使用它在 Go 中实现实用的确定性线性时间中位数选择：
https://github.com/ncruces/sort/blob/main/quick/quick.go
munro 发表于 1 天前 | 上一个 [–]
非常酷，我刚刚对偶数桶上的任意键数据类型进行了类似的分位数处理（仍然需要排序）
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：