## macOS 26.3.1 DNS 漏洞总结 macOS 26.3.1 (Darwin 25.3.0) 中最近发现的一个漏洞破坏了标准 `/etc/resolver/` 针对自定义或私有顶级域名 (TLD) – 例如 `.internal`、`.test` 或 `.home.arpa` – 的域名 DNS 配置。 以前，macOS 可靠地使用这些文件将特定域名的 DNS 查询路由到指定名称服务器（例如本地 dnsmasq 实例）。 现在，`mDNSResponder` 错误地拦截了这些未在 IANA 注册的 TLD 的查询，将其视为多播 DNS (mDNS) 请求，而不是将其转发到指定的单播名称服务器。 这导致依赖这些自定义域名的应用程序无法解析域名，影响本地开发工作流程、Docker 容器 DNS 以及 Vagrant 和 Kubernetes 等工具。 虽然像 `google.com` 这样的标准 TLD 仍然不受影响，但此漏洞会导致解析静默失败，`scutil --dns` 显示配置的解析器，但实际 DNS 流量并未发送到目标服务器。 一种解决方法是手动将条目添加到 `/etc/hosts`，但这对于动态环境来说是不切实际的。 已经向 Apple 提交了错误报告：[https://feedbackassistant.apple.com/feedback/22280434](https://feedbackassistant.apple.com/feedback/22280434)。
每日HackerNews RSS
## Coalton 0.2：重大进展 Coalton 是一种静态类型函数式编程语言，嵌入在 Common Lisp 中，其发展基于工业应用中的经验。即将发布的 0.2 版本侧重于解决生产使用中发现的限制，显著影响代码清晰度、效率和类型安全性。 最大的变化是采用**固定参数函数**，取代了之前的 Haskell 风格的柯里化。这使得关键字参数、改进的类型错误消息以及更高效的编译成为可能。虽然柯里化仍然可以实现，但需要更明确的代码。 进一步的改进包括**多值返回**的本机支持（取代了复杂的元组解包系统）、**作用域类型变量**以获得更简洁的代码，以及使用方括号和推导式的新语法来处理**集合和关联**。一个新的标准库模块 **`coalton/xmath`** 引入了对**实代数数**的支持，从而为诸如验证几何相等性之类的计算提供精确算术。 在底层，类型系统已被加强，以解决与可变运算符相关的 unsoundness 问题。标准库已更名以提高清晰度，并且 Coalton 现在将正式进行版本控制，0.2 版本计划于 2026 年 3 月 23 日发布。未来的开发可能会探索线性类型和资源管理。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 Coalton 0.2 预览 (coalton-lang.github.io)
49 分，作者 varjag，1 天前 | 隐藏 | 过去 | 收藏 | 2 条评论 帮助
arn3n 1 天前 | 下一个 [–]
我喜欢他们关于柯里化的讨论。柯里化在理论上非常酷，但我同意它确实会导致一些错误，而且并不常用。大多数函数式编译器自动柯里化我的函数并提供部分应用，这很棒，但我更希望它们强制提供所有参数，并在必要时显式地创建部分函数。回复
a-french-anon 1 天前 | 父评论 | 下一个 [–]
强烈同意，这完全属于我不喜欢的“自动魔法”范畴；简洁的 lambda 语法已经使其变得不必要。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 不等式的几何直觉
受圆形可视化的启发，作者探索了用几何方式表示代数不等式，并创建动画以建立直觉。核心重点是可视化著名的算术-几何平均值不等式——算术平均值总是大于或等于几何平均值。
这是通过几种几何作图实现的：比较相交圆形成的直角三角形的半径和直角边，分析半圆内的线段，以及检查立方体与长方体体积的关系。这些视觉效果展示了如何对称性（等边）最大化面积/体积，直接说明了不等式。
进一步的探索包括使用维维安尼定理和等边三角形可视化内斯比特不等式，揭示了中心平衡如何最小化表达式。作者得出结论，虽然许多不等式不易转化为基本的几何图形，但尝试可以更深入地理解数学背后的物理原理以及对称性的重要性。最终，这些可视化旨在表明对称性不仅仅是关于美学，而是数学本身中的一项基本原则。
## 不等式的形态 - 摘要
一个Hacker News的讨论围绕着对数学不等式的可视化探索，特别是算术平均数 (AM)、几何平均数 (GM) 和调和平均数 (HM) 之间的关系。核心思想是，迭代地将这些平均数应用于一对数字会收敛到一个极限——从HM和GM开始时收敛到几何-调和平均数，而从“极端”的AM和HM开始时，令人惊讶地收敛到GM。
对话延伸到相关的数学概念，如算术-几何平均数 (AGM) 及其与计算Pi的联系、延森不等式和广义幂平均数不等式。用户指出，这些材料通常介于高中和大学水平的数学之间，并讨论了它们与数学竞赛以及更广泛的数学教育的相关性。
原作者Andrei积极参与反馈，承认并修复了伴随这些概念的动画中的错误。 许多评论者推荐了相关的资源，如Terry Tao的博客和《当更少即是更多》这本书。
## Gluon：扩展 Triton 用于 GPU 内核编程 Gluon 是一种新的 GPU 内核编程方法，建立在 Triton 语言和编译器之上。与平衡可移植性和性能的 Triton 不同，Gluon 通过直接暴露 Triton GPU (ttg) 中间表示 (IR) 来优先考虑开发人员的控制，以实现潜在的更高性能。这意味着开发人员管理编译器先前处理的优化，例如软件流水线和显式共享内存管理。 Gluon 的关键特性包括对 GPU 布局、架构特定功能和 warp 级别编程的显式控制——允许进行更细粒度的优化，以利用不断发展的 GPU 硬件，如张量核心。虽然这提高了性能潜力，但与 Triton 相比，牺牲了可移植性。 作者将通用编译器（优先考虑可移植性）与特定领域编译器（如 Triton 和 Gluon，优先考虑性能）进行了对比。他们认为，强大的 LLM 的兴起正在改变格局，可能有利于定制的、特定领域的解决方案。Gluon 以及类似语言可以充当 LLM 生成代码的“契约”和“验证器”，确保在定义域内的安全性和可理解性。最终，Gluon 代表着在智能体 AI 开发时代，在控制、性能和易用性之间取得新的平衡迈出的重要一步。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Gluon: 明确的性能 (lei.chat)
22点 由 matt_d 1天前 | 隐藏 | 过去 | 收藏 | 讨论 帮助
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
这个解释用投票类比来可视化共识的核心概念——在群体中达成一致。它首先说明了简单的多数投票，强调了它在分裂投票时可能陷入僵局的潜力。为了克服这个问题，指定一个领导者来做决定，其他人批准。然而，领导者失效需要一个更强大的系统。
提出的解决方案是系列并发投票，并轮换领导者，可视化为一个二维棋盘。虽然这允许即使部分成员不可用也能取得进展，但可能会导致不同“列”（投票系列）之间出现相互冲突的多数。为了解决这个问题，系统要求任何达成多数的列之间达成一致。
关键见解是，参与者可以专注于防止与他们左侧做出的决定发生冲突，假设其他人遵循相同的规则。这是通过在某些列中策略性地让多数人弃权来实现的，从而保证不会出现相互冲突的多数。最终，共识是通过遵循第一列达成稳定多数来实现的，因为知道其他颜色随后无法达成多数。这个抽象模型构成了更复杂的分布式系统的基础，在这些系统中，通信是不完美的，知识是延迟的。
## OpenBSD PF 数据包过滤器的带宽限制已移除 OpenBSD 的 PF 数据包过滤器最近的补丁移除了长期存在的带宽配置限制。 之前，HFSC 调度器中的 32 位整数上限会静默地将队列带宽限制在约 4.29 Gbps，导致与现代 10G、25G 和 100G 网络接口出现问题。 该更新将带宽字段扩展到 64 位整数，允许精确配置高达 999G。 这解决了较高速度下的不可预测的调度行为，并修复了 `pftop(1)` 中一个显示错误，该错误之前错误地表示超过 4Gbps 的带宽值。 使用低于 4G 带宽的现有配置不受影响。 此更改确保 PF 队列带宽配置能够与当前和未来的高速网络硬件按预期工作。 该补丁计划于 2026 年 3 月 20 日提交。
## OpenBSD PF 过滤更新
OpenBSD 的数据包过滤器 PF 收到更新，去除了一个 32 位限制，该限制将带宽值限制在约 4.29 Gbps。 此限制之前导致尝试使用 10G 或更高速度的网络接口时，带宽配置发生静默环绕，从而导致不可预测的行为。
此次更新将内核 HFSC 调度器中的带宽字段扩展为 64 位整数，现在支持高达约 1 Tbps 的值。 尽管 OpenBSD 传统上不侧重于原始性能，但更快的网络硬件和内核改进的日益普及促成了这一变化。
讨论强调了对 OpenBSD 历史上优先考虑安全而非速度的担忧，有时难以理解的错误报告，以及与 FreeBSD 和 Linux 相比的驱动程序支持。 一些用户质疑在如此高的速度下整形流量的必要性，而另一些用户则强调其在数据中心管理各种网络流量方面的重要性。 此更新解决了瓶颈，但关于 OpenBSD 在高带宽环境中的作用，更广泛的问题仍然存在。
下次关于面部识别使用的争论可能发生在超市。
The next fight over the use of facial recognition could be in the supermarkets
49 天前
启用 JavaScript 和 Cookie 以继续。
## 面部识别扩展到超市 – Hacker News 摘要
最近一篇《政治报》的文章讨论了面部识别和身份扫描在超市中日益普及的问题，引发了 Hacker News 的讨论。最初的帖子强调了一名 Target 员工扫描顾客的驾照以购买非处方止咳糖浆，尽管顾客的年龄远超过了年龄限制。
讨论迅速集中在扫描身份证明的*原因*上——除了简单的年龄验证之外。许多人认为零售商正在追踪特定药物的购买情况（例如含有伪麻黄碱的药物），以监测潜在的非法药物制造。人们对数据隐私表示担忧，质疑扫描与仅仅*查看*身份证明的必要性，以及收集的信息可能被滥用的可能性。
几位评论员分享了类似的经历，包括药店将购买记录在州数据库中，以及使用 Flock 等“安全”摄像头，引发了对更广泛监控和对日常生活潜在影响的担忧。一个反复出现的主题是对零售商声称的原因持怀疑态度（例如防止盗窃），认为数据收集和价格操纵是主要动机。最终，这场对话凸显了对数据实践日益增长的不信任感，以及在日常交易中失去隐私的感觉。
启用 JavaScript 和 Cookie 以继续。
## OpenAI 收购 Astral：开源 Python 生态系统面临担忧
OpenAI 收购了 Astral，该公司是流行的 Python 工具（如 `uv` 和 `ruff`）的开发者，这在开发者社区引发了争论。虽然一些人认为这可能带来好处，但许多人对这些开源项目的未来表示担忧。
一个主要担忧是开源开发对风险投资的依赖，这可能导致大型公司收购，而这些公司具有不同的优先事项。一些人认为 Astral 的风险投资使其退出成为必然，而由基金会支持的模式可能提供更稳定的保障。另一些人指出，Astral 在其开源工作之外，还在构建一个盈利的企业包托管系统。
尽管 OpenAI 和 Astral 保证开发将继续进行，但开发者担心“劣质化”——工具可能被锁定或商业化。有一种观点认为，在 Anthropic 收购 Bun 之后，这次收购标志着人工智能公司收购有价值的开发者工具的趋势。人们仍然希望社区可以在必要时分叉项目，但对 Python 生态系统和更广泛的开源格局的长期影响仍然感到担忧。
Ticketmaster和LiveNation在活动入场处对人脸识别技术的投资，出现了一个意想不到的弱点：Juggalo妆容。Insane Clown Posse的粉丝，以其独特的面部彩绘而闻名，无意中扰乱了这项技术。 大多数人脸识别软件依赖于识别对比鲜明的特征，如眼睛、鼻子和下巴。Juggalo妆容，其突出的黑色条纹遮盖了嘴巴和下巴，通过改变关键面部标志物和错误读取下颌线，扰乱了这些系统。 然而，这种解决方法并非万无一失。苹果的Face ID，利用深度感知而非表面对比，*仍然*可以识别化着Juggalo妆容的人。尽管有此限制，这种独特的审美为许多常见的人脸识别程序提供了一种意想不到的防御，可能允许Juggalos绕过LiveNation的新安全措施。
## Juggalo妆容与面部识别：黑客新闻讨论
一篇2019年的文章引发了黑客新闻的讨论，内容关于Juggalo妆容——嘻哈组合Insane Clown Posse的粉丝所佩戴的独特面部彩绘——扰乱面部识别技术的能力。最初的帖子将其强调为一种潜在的、非常规的规避监控的方法。
讨论迅速演变成一场关于技术对抗措施与系统性解决方案（如限制监控的宪法修正案）有效性的更广泛辩论。许多评论者认为，法律框架至关重要，因为技术不断发展，形成军备竞赛。
几位用户指出，仅仅依靠视觉干扰的局限性，并注意到步态分析和其他生物识别追踪方法正在兴起。其他人建议采取替代方法，例如反识别服装，甚至通过佩戴口罩等方式拥抱匿名性。一个反复出现的主题是监控的日益普遍——从Ring摄像头到手机应用程序——以及扭转这种趋势的难度。
最终，该帖子反映了对数字时代隐私侵蚀的犬儒、幽默和真切担忧的混合，并伴随着令人惊讶的大量对ICP和Faygo的怀旧参考。
Astral 公司，即 Ruff、uv 和 ty 等热门 Python 工具的开发者（月下载量达数亿），将加入 OpenAI 的 Codex 团队。这一举措源于 Astral 的核心使命：大幅提升编程效率。 创始人认为，人工智能，特别是通过 Codex，代表着实现这一目标的下一个前沿，提供的杠杆作用甚至大于仅仅改进现有的 Python 生态系统。重要的是，OpenAI 承诺将*继续*支持 Astral 的开源工具，并保持以社区为中心的发展方式。 该团队将专注于将他们的工具与 Codex 集成，并探索软件开发的未来，同时坚持他们的原始使命。创始人对 Astral 团队、投资者和用户表示感谢，感谢他们的支持和信任，并承诺继续致力于构建有影响力的工具。
## OpenAI 收购 Astral，Python 工具创建者
OpenAI 收购了 Astral 团队，该团队开发了流行的 Python 工具，如 `uv`、`ruff`、`ty` 和 `pyright`。此举引发了技术社区的讨论，人们对这些开源项目在公司所有权下的未来表示担忧。
许多评论员认为这是 OpenAI 在 Python 生态系统中获取“影响力”并增强其“代理开发”能力的战略举措，可能会将这些工具与 Codex 集成。一些人担心此次收购遵循了大型人工智能公司收购有前景工具的模式，可能导致“劣化”或停滞。
尽管存在担忧，但也有人持乐观态度，希望此次收购能够为这些项目提供资金和长期的可持续性，即使必要时通过分叉也能继续维护和开发。 还有关于 OpenAI 更广泛的策略，即控制软件开发生命周期以及对开源可持续性的影响的讨论。 尽管未来仍不确定，但此次收购凸显了人工智能行业权力日益集中以及对更广泛开发者格局的影响。