2019年，猎人布拉德·凯普和菲尔·尤曼斯在怀俄明州的“棋盘格”地带寻找麋鹿时，遇到了一项独特的土地所有权挑战——这种棋盘格图案是由19世纪铁路土地赠与产生的，由公共和私人的一平方英里地块交替组成。进入该系统内的公共土地受到一位不愿允许他人穿越其私人土地的牧场主阻碍。
猎人们尝试了“角点穿越”，这是一种仅在棋盘格的角落触摸公共土地，避免任何非法侵入的技术。尽管最初成功，但他们还是面临牧场主提起的非法侵入指控，并由此引发了为期五年的法律诉讼。
案件的核心问题在于角点穿越是否合法，以及最终谁控制着数百万英亩公共土地的进入权。此案引起了全国关注，最终提交至美国第十巡回上诉法院，法院裁定猎人胜诉，确认了公众进入权。虽然该裁决目前适用于六个西部州，且美国最高法院拒绝审理此案，但争取公共土地进入权的斗争仍在继续，而布拉德和菲尔已准备好重返麋鹿山。
每日HackerNews RSS
棋盘
The Checkerboard
3 小时前
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
棋盘格 (99percentinvisible.org)
10 分，thread_id 1小时前 | 隐藏 | 过去 | 收藏 | 1 条评论
rtkwe 10分钟前 [–]
我很高兴法院的判决是合理的，你不能通过购买一半的土地（随着你购买的土地越来越多）来控制整个封闭区域，这显然是那些地主们想要达到的目的。我想知道他们现在会真的购买这些封闭区域吗？回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 便携式 Go Agent 的探索：经验教训 团队旨在利用 Go 的编译和并发优势，创建一个单一、便携的服务器监控 Agent (simob)。目标是构建一个轻量级二进制文件，从源代码构建，可部署到任何 Linux 发行版，而无需复杂的流水线。 最初，Go 使用诸如 `gopsutil` 之类的库来实现核心功能，用于系统指标。然而，添加 systemd journal 日志收集带来了挑战。通过 Go 封装器利用 systemd C API 需要在运行时动态链接到 `libsystemd`，导致在非 systemd 系统（如 macOS）上构建失败，并需要特定架构的构建。 `glibc` 标准 C 库也带来了进一步的复杂性。启用 CGO 进行 C API 调用意味着二进制文件链接到 `libc`，在像 Alpine Linux 这样使用 `musl` 的发行版上会失败。这需要为 glibc 和非 glibc 系统分别构建。 虽然 Go 的功能符合预期，但团队意识到真正的可移植性并非易事。他们最初的“随处构建”愿景演变成了一个使用 GitHub Actions 的 CI/CD 流水线，并为每个架构配备了专用 runner。尽管复杂性增加，他们仍然保持了核心目标：小型、自包含的二进制文件。
一个 Hacker News 的讨论强调了 Go 语言可移植性方面的一个细微之处。虽然 Go 经常被宣传为可移植，但使用 CGO（从 Go 调用 C 代码）会降低其可移植性。使用 CGO 会导致动态链接的二进制文件，从而失去静态编译的优势，并需要针对目标系统架构进行特定构建。
即使是看似标准的库函数，如 `os.UserHomeDir`，也可能在不知情的情况下触发 CGO 依赖。禁用 CGO 可以强制静态链接，但会阻止使用 CGO 功能，例如 SQLite。
评论者争论这是否是语言问题还是工具/组织问题，并指出使用 `musl libc` 也会出现类似的复杂情况。 也有人担心措辞暗示 Go 在*没有*动态链接的情况下才具有独特的便携性，因为其他语言也面临类似的架构特定限制。最终，使用 Go 和 CGO 实现真正的跨编译可移植性需要仔细考虑链接和架构特定的构建。
## 正式验证 50 年进展 (1975-2025) 最近关于科学停滞的说法忽视了计算机领域的进步，尤其是在正式验证方面——对软件和硬件正确性的严格证明。虽然早期的计算进步受益于工业研究，但基础工作源于学术界和政府资助。本文重点介绍过去 50 年证明助手的发展，从 1975 年的爱丁堡 LCF 开始，该系统通过严格的推理规则确保定理生成。 剑桥 LCF 紧随其后，为 HOL 系统家族铺平了道路。Isabelle 于 1986 年出现，支持构造类型理论并能够进行复杂的形式化。20 世纪 90 年代的一个转折点是 John Harrison 对浮点算术的验证，展示了这些工具在严肃数学方面的强大功能。 21 世纪见证了越来越多的采用。里程碑式的成就包括 ARM6 处理器的形式化验证、CompCert 编译器以及亚马逊网络服务 (AWS) 的 Nitro 隔离引擎，使用了 26 万行 Isabelle/HOL 代码。数学家越来越多地使用 Lean 等证明助手，例如对主要定理的形式化以及对确认新数学发现的贡献。正式验证正从一个利基领域转变为可靠系统开发的关键组成部分，证明进展*正在*进行。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
50年证明助手 (lawrencecpaulson.github.io)
12点 由 baruchel 1小时前 | 隐藏 | 过去 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## OpenAI 拥抱“技能”概念
OpenAI 正在迅速采用 Anthropic 首创的“技能”机制，使 LLM 能够利用外部工具和知识。这种系统，仅仅是一个包含 Markdown 指令和资源的文件夹，已经悄然出现在 ChatGPT 的代码解释器和 Codex CLI 工具中。
在 ChatGPT 中，技能目前支持电子表格、DOCX 文件和 PDF（渲染为图像以保留布局）。最近的测试表明，ChatGPT 成功创建了一份 PDF，总结了 rimu 树对 kakapo 繁殖的影响，展示了其研究和格式化信息的能力。
Codex CLI 也获得了实验性的技能支持，允许用户安装自定义技能——例如，用于创建 Datasette 插件的一个技能——并相应地执行任务。这使得强大的代码生成和自动化成为可能。
作者认为，技能代表了 LLM 能力的重大进步，超越了多轮提示 (MCP) 的影响。他们建议正式记录技能规范，这可能成为 Agentic AI Foundation 的一个项目。
## OpenAI 为 ChatGPT 和 Codex 添加“技能”
最近一篇 Hacker News 上的帖子指出，OpenAI 悄然推出了“技能”——本质上是自定义功能——在 ChatGPT 和 Codex CLI 中。这使得交互更加精准和实用，超越了通用的语言能力。
讨论的中心在于这些技能的实现方式，一位评论员指出，它们依赖于视觉文档读取，而非光学字符识别 (OCR)。另一些人预测，未来会将预构建的“MCP”资源与自定义技能相结合，提供一个语义层，以便更轻松地集成 API。
使用命令行界面 (CLI) 进行技能操作的便利性也受到称赞，因为它们具有自文档化功能，并且与现有的代理工具兼容。值得注意的是，VS Code Copilot 也宣布了实验性的技能支持，预示着更广泛的行业趋势。最初的帖子也是一个巧妙地分享关于鸮鹦鹉繁殖季节的积极消息的方式！
C64 Maze Chomp.BAS
6 小时前
## 迷宫吞噬：Commodore 64 BASIC 游戏简介 “迷宫吞噬”是一款简单的迷宫游戏，最初发表于1984年的《Input》杂志，旨在教授BASIC编程。游戏目标是使用WASD键在迷宫中导航，并在最短时间内“吃掉”所有的点（用句点表示）。 代码使用Commodore 64 BASIC编写，设置屏幕颜色、边框和背景，然后使用字符代码仔细构建迷宫布局。关键变量管理玩家位置（`p1`, `p2`）和分数（`co`）。一种巧妙的技术使用`POKE`命令直接操作内存地址，以控制屏幕和按键重复功能。 游戏玩法包括移动玩家角色（π）在迷宫中，吃掉点并跟踪经过的时间。程序会检查与迷宫墙壁的碰撞并相应地更新分数。一旦吃掉所有点，游戏将重置，显示达到的最佳时间。原始代码由于基于文本的编辑限制，需要仔细输入字符代码，这突出了早期游戏开发的挑战。
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
C64迷宫吞噬.BAS (basic-code.bearblog.dev)
23点 由 ibobev 6小时前 | 隐藏 | 过去的 | 收藏 | 2评论
predictsoft 4小时前 [–]
我拥有Input的所有4卷。
empressplay 37分钟前 | 父评论 [–]
可悲的是，Commodore 64 BASIC非常糟糕，基本上你必须学习所有关于ROM例程和机器语言才能做任何有用的事情。
指南 | 常见问题 | 列表 | 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中直接控制加湿器，避免依赖专有应用程序和云服务。
一个黑客新闻的讨论集中在将小米加湿器从云端依赖中解放出来，并由此引发了关于加湿器类型的对话。一位评论员警告说，除非使用蒸馏水，否则超声波加湿器会释放PM2.5颗粒，建议使用蒸发式加湿器，并特别提到了 Smartmi 蒸发式加湿器。
然而，另一位用户指出 Smartmi 型号仍然包含“有毒物联网”功能。他们建议 Vornado EV100 蒸发式加湿器作为一种非物联网替代方案，并指出一些小缺点，如滤芯更换、风扇噪音和明亮的 LED 灯。最后，第三位评论员分享了一个 Technology Connections 视频链接，提供了详细的加湿器比较。这场讨论强调了便利性/功能与避免连接设备及潜在健康问题之间的权衡。
## 重新思考特权提升：Capsudo 作者对`sudo`表示不满，认为其设计过于庞大、配置复杂，并且由于SUID二进制文件的特性和对环境权限的依赖，存在固有的安全风险。传统的特权提升工具（如`sudo`）会授予广泛的访问权限，从而造成巨大的攻击面。 受到对象能力模型（authority是明确且局限于特定动作的）的启发，作者开发了`capsudo`。`capsudo`不采用临时成为root的方式，而是通过与持有狭窄范围能力的`capsudod`服务进行交互来运作。 这种方法利用Unix sockets来表示能力，从而实现精确的控制。例如，可以授予服务特定的挂载/卸载权限，或者允许开发者在*无需*广泛的管理权限的情况下更新文件并重启服务。`capsudo`支持权限的分层，能力可以向下委托，但绝不会扩展。 最终，`capsudo`将重点从*谁*被允许执行操作，转移到*权限在哪里*以及*如何流动*，从而提供了一种更安全、更可组合的权限管理方法。它探索了显式委托，并可能为通过资源传递（如文件描述符）实现更细粒度的控制铺平道路。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Capsudo: 使用对象能力重新思考 Sudo (ariadne.space)
19 分，由 fanf2 1小时前发布 | 隐藏 | 过去 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## Bidicalc：双向电子表格
Bidicalc 是一款实验性的电子表格，允许“反向”计算——改变一个单元格的*结果*，并让输入单元格调整以匹配公式。与输入决定输出的传统电子表格不同，bidicalc 在给定期望输出的情况下求解输入。
该电子表格区分**变量**（可变数字）、**常量**（以#为前缀的固定数字）和**公式**（标准计算）。它支持常见的算术运算、指数以及 `sqrt`、`pow`、`pi`、`abs`、`log` 和 `exp` 等函数。
其核心创新在于一个自定义的求根算法，它“逆流”导航电子表格的公式以寻找解决方案。虽然功能强大，但求解器可能难以处理复杂或欠定的问题，可能产生不正确或意外的结果。用户可以通过将变量设置为常量或简化公式来优化解决方案。
Bidicalc 是一个基于 TypeScript 的开源项目（AGPL 许可），旨在作为对数学概念的有趣探索。不建议将其用于关键应用，但它提供了一种独特的电子表格计算方法，并欢迎社区贡献和改进。未来的开发目标包括变量域限制和求解器增强。
一位 Hacker News 的开发者发布了“bidicalc”，这是一款新颖的电子表格工具 (victorpoughon.github.io)，允许用户更新*任何*单元格——输入或输出——并使其他单元格重新计算。 传统的电子表格只允许更新输入。
开发者正在寻求反馈，特别是关于错误和有用的应用。 最初的反应是积极的，一位评论员指出这个概念类似于数据库中的完整性约束。
讨论要点包括质疑非可逆运算（如加法）的反向计算的实用性，以及对 Lotus Improv 等较早电子表格软件的启发，包括命名单元格和公式窗格等功能建议。 另一位用户建议在电子表格中对常量和变量进行视觉区分。
## 将 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 优化策略取得了显著改进。
最近的 Hacker News 讨论集中在使用 Docker 进行*整个*构建过程，还是仅仅用于打包。虽然一篇新文章提倡更快的 Docker 镜像构建，但经验丰富的 Docker 用户，如作者“zerotolerance”，认为容器化构建通常是不必要的复杂性。
核心争论围绕依赖管理。容器擅长为构建提供一致的工具链版本，避免了系统级更新的需求。然而，这可能会导致越来越复杂的 Dockerfile，因为缓存、测试和外部系统集成被添加进来。
许多评论者同意 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 DNS记录的使用——一种更安全的DNS查找方法。虽然在技术上可行，但由于浏览器和DNS提供商的支持不一致，普及率仍然缓慢。
目前，Safari是HTTPS DNS请求的主要推动者，导致最初的预期使用率较高（基于Safari的市场份额，约为14%）。然而，Cloudflare（8.1%的请求）和一个较小的DNS服务器（1.11%）的实际数据显示出明显较低的数字，这可能是由于整体HTTPS采用不完整以及缓存效应造成的。
最近的报告表明Chrome *也* 支持HTTPS DNS，这挑战了Safari是唯一用户的观点。这次讨论强调了需要更清晰的浏览器支持信息以及更强大的回退策略，以便更广泛地实施。