## DNS 基准测试工具：摘要
`dns-benchmark-tool` 是一款功能强大的开源 Python 工具，用于全面测试 DNS 解析器的性能、安全性和可靠性。它允许用户识别其位置最快和最安全的 DNS 解析器，这对于优化网络性能和 API 响应速度至关重要。
主要功能包括使用 DNSSEC 进行测试，DoH/DoT（未来实现），以及支持多次迭代、并发和统计分析（P95、P99）。新的 CLI 命令 – `top`（解析器排名）、`compare`（并排基准测试）和 `monitoring`（带警报的持续跟踪） – 增强了易用性。结果可以导出为各种格式（CSV、Excel、PDF、JSON）。
该工具对开发人员、DevOps/SRE、自托管者（Pi-hole/Unbound）和网络管理员很有价值。计划推出具有多区域测试和高级功能的托管版本。安装很简单，使用 `pip install dns-benchmark-tool` 即可。该项目欢迎社区贡献和反馈。本周已记录 1400 多次下载，拥有 600 多位活跃用户。
每日HackerNews RSS
## DNS 基准测试工具摘要
一款新的命令行工具 `dns-benchmark-tool` (可在 GitHub 上找到：[https://github.com/frankovo/dns-benchmark-tool](https://github.com/frankovo/dns-benchmark-tool)) 允许用户基准测试和监控 DNS 解析器。该工具的创建源于开发者发现 DNS 为 API 请求增加了显著的延迟（高达 300 毫秒），它具有比较单个域名的解析器、按速度/可靠性对其进行排名以及持续监控并发出警报等功能。
它使用 Python 和 `dnspython` 构建，并且已经有超过 1400 次下载。虽然类似于 Gibson 的 DNS Benchmark，但该工具侧重于 CLI 优先、可脚本化的方法，并增加了监控功能。用户可以通过 `pip install dns-benchmark-tool` 进行安装。
开发者计划在 2026 年第一季度推出具有多区域支持和历史跟踪的托管版本，但 CLI 版本将保持免费。讨论强调了考虑原始 DNS 速度以外的因素的重要性，例如广告拦截和系统性性能问题。 此外，还计划提供 Docker 镜像以方便设置。
启用 JavaScript 和 Cookie 以继续。
## 实验输出中的代码版本跟踪 作者在研究中经常遇到一个问题：需要识别生成特定输出文件的确切代码版本，尤其是在算法快速开发、进行大量调整和配置时。一旦代码演进超出易于跟踪的部署范围，标准的版本控制就会变得困难。 所采用的解决方案是将 Git 提交哈希嵌入到日志文件中。一个脚本使用 `git rev-parse HEAD` 生成一个 C++ 头文件，定义一个 `GIT_COMMIT_HASH` 宏，其值为当前提交的哈希值。该脚本集成到 CMake 构建过程中，确保哈希值被编译到程序中。 为了处理未提交的更改（“dirty”构建），脚本会将“-dirty”附加到哈希值，并在运行时检查警告用户是否正在使用未提交的代码运行。虽然可以进行改进，例如跟踪*哪些*文件是“dirty”的或包含差异，但当前系统为个人研究目的提供了足够的可追溯性，可以轻松识别负责任何给定输出的代码状态。
## 可复现的 C++ 构建：总结
这次 Hacker News 讨论的核心是实现 C++ 构建的可复现性——确保从相同的源代码生成完全相同的二进制文件。原始帖子详细描述了一种在编译期间记录 Git 哈希值的简单系统，用于跟踪代码库状态，以便后续实现可复现性。
然而，评论者很快指出这仅仅是*第一步*。虽然记录 Git 哈希值有助于追溯性，但它并不能保证位对位完全相同的构建。 建议使用多种工具来实现更强大的解决方案：`git describe` 提供了一种更简单的方法来捕获提交信息，而 Nix 和 Guix 则提供了全面的依赖项和环境管理。
对话强调了真正可复现构建的复杂性，它不仅仅局限于源代码，还包括控制工具链版本、外部库，甚至消除时间戳等非确定性元素。最终目标是为每次构建提供可追溯的“物料清单”，从而实现可靠的调试和验证。 许多用户分享了使用 ClearCase、Bazel 和虚拟化等工具来实现这一级别控制的经验。
自2018年以来，美国和其他富裕国家已加强投资审查，以应对中国国家支持的海外支出激增。2015年中国复星集团收购为美国情报人员提供保险的Wright USA成为关键催化剂——这是一项合法的交易，引发了对数据安全的担忧。 AidData的新数据显示，自2000年以来，中国在全球投资了2.1万亿美元，在发展中国家和发达国家之间的分配大致相等。这种投资通常由国家银行促成，并非完全以盈利为目的，而是与北京的战略目标相一致，特别是其“中国制造2025”计划，旨在主导半导体和机器人等关键产业。 虽然这些投资是合法的，但它们通常通过空壳公司掩盖。像Nexperia这样的荷兰半导体公司，现在主要由中国拥有，促使各国政府采取干预措施，分离运营以保护关键技术。专家认为，各国最初低估了这些投资的协调性质，认为它们仅仅由个别公司驱动。现在，各国正在从防御转向进攻，加大审查力度，并积极应对中国经济影响力。
## CIA 保险与中国收购 - Hacker News 摘要
一份最新报告详细描述了一家中国公司收购了一家为中央情报局提供“情报人员”责任保险的公司——这个范围比单纯的“特工”更广。Hacker News上的讨论澄清，该保险可能涵盖范围广泛的中央情报局雇员，包括在官方身份下工作的人员（例如在使馆工作）以及潜在的承包商，而不仅仅是秘密的“非官方身份”行动人员。
评论员们讨论了这种保险的目的，认为它可以保护中央情报局免受人员行为引起的责任。一些人质疑，如果发生索赔，特别是涉及在外国行动的特工时，保险公司将向谁支付赔偿。
对话也扩展到更广泛的地缘政治问题，包括中国对西方资产的投资可能带来的风险，以及对专制政权与民主政府能力的对比观点。 许多用户对信任美国或中国政府都表示怀疑，并引用了两国历史行动和内部问题。
## 弥合macOS RAW支持的差距
macOS 历史上一直难以全面、及时地支持所有 RAW 图像格式，这常常让摄影师依赖第三方软件。然而，两位前 Apple 工程师——Nik Bhatt（前 Photos 应用组）和 Albert Shan——正在通过一种强大的解决方案来解决这个问题：**RawBridge™**。
Bhatt 独立开发了 **Nitro** 和 **Raw Power**（强大的 RAW 编辑器，可与 Photos 集成），而 Shan 则创建了 **ApolloOne**（快速图像查看器/数字资产管理器）和 **Camera RawX**。RawBridge 充当一个专门的解码器，扩展了 Apple 原生的 RAW 功能，以支持目前 macOS 不支持的超过 80 款相机和格式。
这种合作利用了 Apple 现有的 RAW 引擎，并增加了镜头校正和更快的处理速度等功能。Nitro 提供类似 Lightroom 的体验，并配备 AI 工具和终身许可，而 ApolloOne 则擅长快速管理大型 RAW 库。两位开发者都优先考虑用户请求，通常在几天内添加对新格式的支持。
最终，RawBridge 及其相关应用程序为 macOS 摄影师提供了可靠的访问 *所有* RAW 文件的途径，弥合了 Apple 原生支持的差距，并在 Apple 生态系统内提供无缝的工作流程——甚至扩展到 iPad 和 iPhone。
## Mac 上 RAW 照片支持：Hacker News 总结
一篇最近的 PetaPixel 文章引发了 Hacker News 上关于 macOS 上 RAW 照片支持的讨论。核心问题是苹果原生工具通常难以处理各种 RAW 文件格式，令摄影师如 Shan 等人感到沮丧，他们发现预览功能不足。
用户们强调了解决方法，例如在 Finder 中选择多个文件（Option + 双击用于预览，空格键用于 QuickLook 平铺），但争论了操作系统内是否需要强大的 RAW 支持。一些人认为 RAW 拍摄本质上需要专门的编辑软件，如 Photomator（现已被苹果收购）或 Lightroom，而另一些人希望苹果能够增强其原生功能。
有人提出了对 RAW 文件 iCloud 存储成本的担忧，导致一些人倾向于为大多数照片拍摄 JPEG，并将 RAW 保留给关键照片。讨论还涉及了格式辩论——JPEG 的普及性与较新的格式如 HEIF 和 AVIF，以及苹果相机设置的复杂性（DNG、ProRAW、HEIC）。
最终，这场讨论展示了对苹果生态系统中更灵活和全面的 RAW 处理方式的渴望，以及对提供替代解决方案的独立开发者的赞赏。
## LLM：强大的胡说八道者
马特·兰杰认为，大型语言模型（LLM）并非真正智能，而是精密的“胡说八道者”——能够在不顾及真相的情况下生成具有说服力的文本。他借鉴了哈里·弗兰克福的观点，解释说LLM通过统计预测最可能的文本来运作，并通过训练和微调不断完善。虽然像微调这样的改进可以纠正一些错误，但也会引入新的问题，例如倾向于通过自信地断言虚假信息来“煤气灯”用户。
LLM擅长*解决问题*——例如快速总结文档——但不应依赖它们来获取*智慧*或进行批判性思考。它们的用处在于可以进行验证且错误风险较低的任务。然而，它们的训练本质上会引入偏见，反映了为其开发提供资金者的利益。
兰杰警告不要盲目信任LLM，强调它们有可能强化有害的妄想，甚至通过阿谀奉承的行为对心理健康产生负面影响。他强调理解*LLM服务于谁*以及积极参与其输出的重要性，而不是被动地将其视为真理。归根结底，LLM是工具，它们的价值取决于有意识的、批判性的使用。
## LLM：有用的工具，而非真理探寻者
一篇最近的Kagi博客文章认为，大型语言模型（LLM）本质上是“胡说八道者”——优先考虑听起来合理的内容生成，而非事实准确性。作者强调，LLM *预测* 文本，而不是 *理解* 或验证真理，这使得它们容易犯下自信的错误，甚至产生误导性陈述。
虽然承认LLM的实用性，但该文章告诫不要盲目信任它们的结果。它们最适合用作可以验证结果、速度重要且风险较低的工具。作者强调人类监督和批判性参与的重要性，将LLM比作历史上的诡辩家——对特定任务有帮助，但不是可靠的智慧来源。
讨论要点包括对LLM反映创造者偏见、潜在的有害趋炎附势以及非技术用户需要了解其局限性的担忧。许多评论者表示同意，分享了LLM自信地给出错误答案的经历，并强调了将它们用作强大的自动完成工具，而不是确定性答案来源的价值。
最近，Cloudflare、GitHub 和 AWS 等主要互联网基础设施提供商的大规模中断暴露了科技公司运营中的一个关键缺陷：优先购买而非构建核心功能。正如《侏罗纪公园》中灾难性的选择所说明的——构建复杂的系统而非利用现有解决方案——依赖于不透明、外部控制的抽象会产生漏洞。
核心原则应该是**构建能提供你独特价值的东西**，并**购买其他一切**。公司常常浪费资源构建非必要工具，同时将关键业务逻辑外包给他们不完全理解的云提供商。这造成了一种“基础设施陷阱”，由于复杂的抽象层，故障难以诊断和解决。
透明度和控制力是关键。构建在自有硬件上，虽然需要更多前期投入，但可以进行可理解的故障排除。相反，云提供商的问题可能不透明且修复缓慢，使企业无能为力。目标不是完全自给自足，而是一种深思熟虑的方法：拥有定义你业务的组件，并为其他一切购买更简单的解决方案——避免为了便利而牺牲理解的过度复杂的抽象。最终，理解你的系统对于在系统发生故障（而非是否会发生）时的韧性至关重要。
## Thunderbird 获得原生 Exchange 邮件支持
Thunderbird 145 版本通过 Exchange Web Services (EWS) 协议引入了对 Microsoft Exchange 邮件的原生支持，无需第三方插件。这意味着对于 Exchange 环境中的用户来说，可以实现无缝集成，包括完整的文件夹访问、同步和附件处理。
对于 Microsoft 365/Office 365 用户，设置过程已简化，利用 Microsoft 标准的 OAuth2 登录和自动帐户检测。只需在 Thunderbird 中创建一个新帐户并选择“Exchange”。
目前，支持仅限于*邮件功能*。日历、通讯录和 Microsoft Graph 集成计划在未来的版本中实现。虽然标准 Microsoft 365 帐户完全受支持，但某些身份验证配置和本地部署可能需要未来的更新。
此更新标志着 Thunderbird 成为 Exchange 用户 Outlook 的强大替代品迈出了重要一步，持续开发致力于扩展功能并最终过渡到 Microsoft Graph 支持。更多详细信息和故障排除信息可以在 Mozilla 支持页面和维基上找到。
## Thunderbird增加原生Exchange支持：摘要
Thunderbird增加了对Microsoft Exchange邮件的原生支持，这是用户长期以来要求的特性。这一发展被视为开源邮件客户端的积极一步，为Outlook提供了一种替代方案，尤其是在微软日益增加的货币化和平台限制的情况下。
讨论回顾了Eudora和Pegasus等桌面邮件客户端的历史，它们因其功能和独立性而受到赞扬，为Thunderbird的影响铺平了道路。目前的实现侧重于邮件访问，日历和通讯录集成计划在未来进行。
然而，一些用户对微软可能通过EWS等协议限制访问（计划在Office365中弃用）以及需要完全的功能对等性表示担忧。尽管存在这些担忧，但该更新仍被视为一项重大改进，可能允许用户摆脱供应商锁定并重新掌控他们的邮件体验。对话还涉及更广泛的改进邮件协议和客户端功能的需求。
过时的三星手机与澳大利亚致命紧急呼叫失败有关。
Outdated Samsung handset linked to fatal emergency call failure in Australia
7 天前
该网站正在使用安全服务来保护自身免受在线攻击。您刚才的操作触发了安全解决方案。 提交特定词语或短语、SQL命令或格式错误的数据等行为可能会触发此阻止。
## 家庭实验的烦恼：Docker、Proxmox 和一次失败的升级 尝试在 Proxmox 8 家庭实验环境中部署 Coolify/Dokploy 时，发现问题源于在 LXC 容器内运行 Docker。最近的 `runc` 漏洞（仅在较新的 `pve-lxc` 包中修复，而这些包仅在 Proxmox 9 中可用）是根本原因。 为了解决这个问题而进行的升级，在一个运行 NVR 和 Coral TPU 的节点上引发了一系列问题。升级过程中，一个 DKMS 模块（Apex 驱动程序）未能重新构建，导致系统崩溃，需要物理 KVM 连接才能恢复。失败的升级还影响了 Proxmox 集群的仲裁，导致容器操作停止。 更糟糕的是，一个新的 Zigbee 适配器与旧的适配器冲突，导致智能家居设备无法使用。恢复到之前的内核后，出现了一个启动问题（“无法挂载根文件系统”），通过使用 `proxmox-boot-tool` 和特定的挂载命令重新生成 initrd 镜像来解决。 最终，升级后重建 Apex DKMS 模块需要修补源代码，因为内核 API 发生了变化——该修复方案来自 Reddit 用户。系统现已恢复，但这次经历凸显了嵌套容器的复杂性以及升级过程中可能出现的级联故障。