为了持续打击非法机器人电话，美国联邦通信委员会（FCC）已将超过1200家语音服务提供商从美国电话网络中断开连接。此举由执法局采取，原因是这些提供商未能遵守FCC关于机器人电话缓解和在机器人电话缓解数据库中进行准确认证的规定。 FCC要求提供商实施STIR/SHAKEN技术——一种来电显示身份验证系统——并提交积极打击机器人电话的计划。这1200家提供商此前已收到警告，并于8月初进行了最初的185家移除。他们未能履行这些义务。 FCC主席布伦丹·卡尔强调了该机构保护消费者的承诺，表示不合规的提供商“在我们的网络中没有立足之地”。被移除的提供商只有在获得FCC明确批准后才能重新获得访问权限。此举是更广泛努力的一部分，包括51个州总检察长最近发起的“机器人电话围剿”，旨在打击不合规的语音提供商。
每日HackerNews RSS
启用 JavaScript 和 Cookie 以继续。
## 理解 MLS 与科学传播的挑战 有效的技术沟通依赖于了解你的受众，这在科学和工程领域尤其重要。消息层安全协议 (MLS) (RFC 9420) – 专为加密消息中的群密钥协商而设计 – 最近因其安全模型而受到批评。一篇博文认为 MLS 需要对服务提供商的固有信任，这与端到端加密原则相矛盾。 然而，这种批评源于对 MLS 范围的误解。MLS *专门* 解决密钥交换问题，有意将身份验证 – 验证用户身份 – 留给一个单独的“身份验证服务”。RFC 明确警告如果此服务受到损害的风险，这是一个被误解为根本缺陷的警告措施。 核心问题不是 MLS 本身存在弱点，而是未能清楚地传达其局限性。MLS 不是一个完整的加密解决方案；它是一个构建块。成功的实施需要在身份验证方面做出谨慎的架构决策，这是 RFC 在其安全注意事项中强调的。虽然对受损的身份验证服务存在担忧是有效的，但密钥透明度等解决方案正在出现。 最终，这场争议凸显了沟通复杂技术细节的困难以及精确命名的重要性 – “消息层安全” 对于群密钥协商协议来说是一个具有误导性的名称。这一事件为密码学社区提供了一个学习机会，以提高清晰度并避免未来的误解。
这个Hacker News讨论围绕着MLS（消息层安全）协议及其认证方法。核心论点是MLS有意避免在技术上*解决*认证问题，认识到这本质上是一个**信任问题**，而非技术问题。
MLS的“认证服务”（AS）被设计为灵活的——它可以是受信任公司内部系统（如Keycloak），透明度服务，甚至完全手动、非频道的密钥交换。对AS的信任程度由用户决定，取决于通信的上下文。
虽然承认对MLS可能存在的批评，评论员们认为其AS抽象是一个经过深思熟虑的设计选择。一位IETF贡献者指出，编写对*所有*读者都清晰的技术规范是一个持续的挑战。
## 佛特加兰水危机使居民无水可用
科罗拉多州科斯蒂亚县，特别是桑格雷德克里斯托牧场地区的居民，在佛特加兰水与卫生区突然停止向依赖蓄水池的人们出售散装水后，正面临一场水危机——在干旱地区，这是一种常见做法。数百人依赖从佛特加兰取水，这是一项代价高昂且耗时的日常工作，因为钻井通常不成功且费用高昂。
这一举措由一个分裂的董事会未经公众通知就实施，源于佛特加兰的泵故障以及对城镇用水量的担忧。这一决定让许多人措手不及，不得不寻找替代方案，长途跋涉寻找水源，依赖邻居（非法），或考虑离开家园。
这一情况凸显了干旱肆虐的西部地区水资源获取的脆弱性，并引发了愤怒，指责管理不善和缺乏同情心。科斯蒂亚县专员正在探索解决方案，包括潜在的县立供水站，但可行的解决方案还需要几个月的时间。这场危机凸显了长期居民和新来者之间日益紧张的关系，并引发了关于水权和资源管理在气候变化中的问题。
## 同步需求与系统弹性 同步需求是指大量用户同时请求服务，可能超出其容量。即使有可用余量（容量减去背景负载），对齐的请求也可能创建队列、超时和级联故障。这种对齐源于共享时钟、默认设置、状态转换（如部署）或外部事件（如DDoS攻击）。 缓解措施侧重于防止峰值或安全地释放现有负载。一个关键原则是在时间上分散需求——引入“抖动”，用增加延迟来换取降低峰值负载。最佳策略需要在服务级别目标和资源限制（连接池、CPU）等因素的考虑下，平衡这种权衡。 计算合适的抖动涉及确定一个时间窗口 (`W`)，该窗口足够大以处理负载 (`M`)，同时尊重余量 (`H`)。运营考虑包括考虑统计波动（泊松分布）和服务器提供的提示（Retry-After、速率限制）。 最终，主动方法包括随机化计时器、错开周期性任务以及根据实时容量估计进行节流。通过监控峰值比率、延迟和释放时间来验证这些策略，对于完善这些策略并确保系统弹性至关重要。
## 黑客新闻讨论摘要：放慢速度以求更快
一篇 gojiberries.io 的文章引发了黑客新闻的讨论，探讨了一个反直觉的想法：故意引入延迟可以*提高*系统性能。核心概念在于避免“同步需求”——大量请求同时冲击系统，超出其容量的情况。
讨论中提到了几个相关的悖论，包括**布拉斯悖论**（增加容量反而会恶化流量）和**杰文斯悖论**（提高效率反而会导致消费增加）。讨论强调了**排队、时间转移和流水线**等技术，作为管理负载和优化容量的方法，并与 Facebook 和任务队列系统的方法相提并论。
许多评论者将这一原理与现实世界的场景联系起来，从音乐练习（“慢即是顺，顺即是快”）和体育训练到组织工作流程。其想法是，有意的节奏和管理瓶颈最终可以提高吞吐量和效率，即使这看起来违反直觉。最终，讨论强调了理解系统限制的重要性，并策略性地引入延迟以避免过载并最大限度地提高性能。
像素与颜色 / 什么是色彩空间？6207字 | Dan Hollick 什么是色彩空间？ 我们将解答你关于数字色彩的所有问题，甚至你从未想过的问题。
该网站正在使用安全服务来保护自身免受在线攻击。您刚才的操作触发了安全解决方案。 提交特定词语或短语、SQL命令或格式错误的数据等行为可能会触发此阻止。
使用Base的模式检查器管理您的数据库结构，轻松了解您的表。一览即可查看表模式、列类型、约束和关系。无需深入SQL即可理解您的表设计。
## Base v3：macOS原生SQLite编辑器
Base，一款macOS SQLite数据库编辑器，在历经15年开发后，最近发布了其第三版。开发者旨在提供舒适、原生的GUI体验，专注于SQLite，避免全功能IDE的复杂性。主要功能包括完整的表结构修改能力、详细的列约束显示，以及对数据库附加的支持——由于沙盒机制，这在macOS上是一个棘手的问题。
开发者指出该应用并非全新创建，而是经过多年“实战考验”。虽然它并非重要的收入来源，但开发者希望通过销售来维持开发。定价为40美元，可通过官网、Mac App Store和Setapp购买。用户称赞其原生体验和长期稳定性，与臃肿的替代品形成对比。macOS 15是最低系统要求，但开发者计划支持当前和之前的macOS版本。
该项目体现了一种专注的、“工匠式”软件开发方法，优先考虑质量和特定用户体验，而非广泛的功能集。
## Decode-Kit：零依赖TypeScript验证 Decode-kit是一个轻量级、零依赖的TypeScript库，用于验证运行时数据，*无需*数据转换。它不是返回解析后的值，而是**就地断言类型**，直接细化原始变量的TypeScript类型——通过避免克隆或复制数据，从而提供显著的性能优势。 验证是基于断言的；`validate(input, schema)` 在运行时检查数据，并在失败时抛出`DecoderError`，提供详细的错误消息，包括失败路径和预期的模式。成功后，`input`的类型会根据模式进行收窄。 Decode-kit支持验证基本类型（字符串、数字、布尔值、null、undefined）、字面量、ISO 8601日期时间、数组和对象。它还允许使用`or`函数创建联合类型。一个关键特性是`InferOutputOf`工具，用于提取验证后的类型。 其快速失败的方法和最小的开销使其非常适合对性能要求严格的应用，在这些应用中，内存效率和速度至关重要。API的设计灵感来自Decoders等库。
## Decode-Kit：注重性能的TypeScript验证库
Decode-kit是一个新的TypeScript运行时数据验证库，专为高吞吐量应用设计。与Zod等流行的库不同，它避免在验证过程中深度克隆数据，而是采用**基于断言的方法**，直接验证和收窄TypeScript类型。 这旨在提高内存效率和速度。
该库具有清晰的API和结构化的错误系统，并提供详细路径以精确定位验证失败。 它采用**快速失败**策略，在首次出现验证问题时立即抛出错误。
讨论主要集中在与现有库（Zod、Valibot、Arktype）的性能比较上，并要求提供基准测试来证实其速度提升的说法。 有人担心`try/catch`块可能带来的性能开销，但作者澄清这些主要用于错误报告，并且不会影响有效数据的性能。 作者计划提供基准测试，并欢迎反馈。
[https://github.com/nimeshnayaju/decode-kit](https://github.com/nimeshnayaju/decode-kit)
## PEP：一种新的像素艺术压缩格式
PEP 是一种实验性的图像压缩格式，专门为低色彩像素艺术（最多 256 色）设计，旨在实现比 GIF、PNG 和 QOI 更小的文件尺寸。它利用“基于部分匹配的预测，2 阶”压缩，优先考虑尺寸而非速度。
虽然比成熟的格式如 GIF/PNG/QOI 慢 2-10 倍，但 PEP 通常能实现比 GIF/PNG 更好的 20-50% 压缩率，并且在尺寸上显著优于 QOI。它的压缩效果介于 GIF 和 WEBP 之间。
PEP 输出一种对游戏开发有用的结构，提供对像素数据的直接访问。它需要现有的颜色字节数据，并提供压缩 (`pep_compress`)、解压缩 (`pep_decompress`)、序列化/反序列化以及文件 I/O (`pep_save`, `pep_load`) 函数。
该库正在积极寻求贡献，以成为像素艺术领域的领先格式。基准测试表明，在有限的颜色调色板下，尺寸缩减显著。
一种名为预测编码像素 (PEP) 的新图像格式在 Hacker News 上分享，引发了关于其潜在优势和劣势的讨论。虽然 PEP 在小尺寸、颜色有限的图像方面表现出色，并提供无损压缩，但对于较大的图像，它在文件大小方面并不总是优于成熟的有损格式，如 lossy-PNG、lossy-WEBP 或 mozcjpeg。
主要问题在于解压缩速度。初步测试表明，PEP 的速度可能比优化的 PNG 慢，但性能因图像而异。作者澄清 PEP 专为特定用例设计，并非通用替代品。
macOS 的 CLI 实现可在 GitHub 上找到 ([https://github.com/gingerbeardman/pepr](https://github.com/gingerbeardman/pepr))，并在 Twitter 上分享了基准测试结果。一位开发者已经将 PEP 支持集成到他们的像素艺术应用程序 Dottie 中，尽管存在局限性，但认为它值得探索。