每日HackerNews RSS
## Nvidia Shield TV：十年的支持与持续的需求
最近的Hacker News讨论强调了英伟达对Shield TV的长期承诺，这是一款基于Android的流媒体设备。用户报告称仍然积极使用几年前购买的原始型号，赞扬其持续的软件更新、与Jellyfin和Moonlight游戏流媒体等服务的可靠性能以及出色的图像升级能力。
尽管已经过时，Shield TV仍然受欢迎，因为它没有计划过时——在流媒体设备市场中这非常罕见。然而，用户也指出了一些限制，例如缺乏对较新编解码器（如AV1）的硬件支持，以及在较新版本中，Android TV启动器中广告越来越多。
许多人表达了对更新型号的渴望，该型号具有改进的硬件、现代连接性（USB-C）、更好的安全性（WPA3）以及对持续支持的保证，但质疑鉴于原始型号的持续功能，刷新后的产品能带来哪些重大改进。 讨论表明，尽管Shield TV具有持久的吸引力，但英伟达目前的重点在于其他方面。
Meta正面临指控，源于最近的诉讼和美国调查报告，称其能够访问用户的加密WhatsApp聊天记录——尽管该平台声称实现了端到端加密。该诉讼由Quinn Emanuel Urquhart & Sullivan提起，基于匿名举报人的说法，声称Meta可以访问“几乎所有”用户通信。 Meta强烈否认这些指控，称其“绝对不属实”，并暗示该诉讼是为了支持NSO Group，一家最近在WhatsApp提起的案件中败诉的间谍软件公司。Meta正在寻求对Quinn Emanuel的制裁，指控其进行宣传噱头。 专家对此表示怀疑，指出在大型公司内部掩盖此类漏洞的难度。虽然WhatsApp会收集用户元数据，但访问消息*内容*的核心说法存在争议。美国商务部的调查尚未得到证实。Meta坚持WhatsApp的加密是安全的，并承诺捍卫用户隐私。
## WhatsApp 加密疑虑 - 摘要
一份报告称，美国当局正在调查 Meta 可能读取 WhatsApp 加密消息的指控。Hacker News 的讨论反映了人们对大型公司（尤其是美国公司）拥有的平台端到端加密的安全性普遍持怀疑态度，原因在于政府的访问请求。
许多评论者认为后门是不可避免的，指出即使有加密，受损的终端或访问备份也会破坏安全性。人们对 WhatsApp 的备份加密（或缺乏加密）以及 Meta 潜在的密钥访问权表示担忧。
几位用户强调了闭源系统的固有不可信性，认为如果没有可验证的开放协议，就很难验证安全声明。其他人建议使用安全飞 enclave 进行解密等缓解策略，但承认客户端受到损害仍然是一个重大漏洞。讨论还涉及绕过聊天加密等安全措施（如短 PIN 码）的容易程度。
## htmx Server-Sent Events (SSE) 扩展总结 htmx-ext-sse 扩展通过连接到服务器发送事件 (SSE) 流，实现网页的实时更新。SSE 是 WebSockets 的一种轻量级替代方案，通过标准的 HTTP 连接运行 – 使其防火墙友好。与 WebSockets 不同，SSE 是**单向的**（仅服务器到客户端）。 **主要特性与属性：** * **`hx-ext="sse"`**: 在 HTML 元素上启用扩展。 * **`sse-connect="<url>"`**: 指定 SSE 服务器的 URL。 * **`sse-swap="<message-name>"`**: 定义哪个服务器消息更新元素的内容。 * **`hx-trigger="sse:<message-name>"`**: 基于 SSE 消息触发 HTTP 回调。 * **`sse-close=<message-name>`**: 收到特定消息时，优雅地关闭连接。 **安装：** 可以通过 CDN 或 npm 轻松添加，确保在加载扩展*之前*加载 `htmx.org`。 **接收事件：** SSE 消息包括事件名称和数据。使用 `sse-swap="message"` 处理未命名的事件，并使 `sse-swap` 值与服务器的事件名称匹配以处理命名的事件。 可以在同一元素或子元素上监听多个事件。 该扩展还包括自动重连逻辑以提高可靠性，并分发自定义事件以进行生命周期管理（连接打开、错误、消息、关闭）。 提供了一个演示服务器用于测试。 此扩展取代了旧的 `hx-sse` 属性，现有用户需要迁移。
## htmx SSE 扩展与讨论总结
一个新的 htmx 服务器发送事件 (SSE) 扩展正在讨论中，但很快将集成到核心库中，随下一次发布 (v4) 一起提供。这允许服务器向客户端流式传输更新，而无需完全页面重新加载，从而简化后端开发和测试。
评论者赞赏 htmx 在无需复杂前端框架的情况下处理许多用例的能力，这符合“渐进式复杂性”的概念。一些用户还探索了类似 DataStar 的库，该库已经包含 SSE 支持，并提供轻量级的客户端交互原语。
讨论要点包括将 SSE 与传统的 EventSource 和 WebSockets 进行比较，以及强调 htmx 的功能超越简单的 `innerHTML` 替换。有人担心增加的复杂性可能会影响重视 htmx 简单性的用户，并提出了一个功能请求，即更容易在 hx- 属性中解析 JSON 数据。
## 常春藤：从消遣到高精度数学 出于对一个有趣项目的需求，作者用Go语言创建了常春藤，一种伪APL语言，它意外地演变成了一个用于高级数学计算的工具。尽管最初比其他APL衍生语言弱，但常春藤采用精确算术（大整数和有理数）被证明出奇有用，甚至被用于移动应用程序。 Go语言库中高精度浮点数的出现带来了新的挑战，促使作者深入研究如何以扩展精度计算超越函数，如正弦和余弦。现有的算法不足以满足需求，作者不得不重新审视和完善数学概念。 常春藤的实现利用了泰勒级数和参数归约等技术，最终采用了Spouge近似（由Causley改进）来计算Gamma函数。这涉及到复杂的系数计算，由常春藤的基于数组的结构高效地处理。尽管承认存在不完美之处以及优化参数方面仍然存在疑问，作者还是取得了令人印象深刻的精度——Gamma函数超过48位小数——展示了常春藤进行高精度数学运算的能力。这个项目源于对有趣编码练习的渴望，最终推动了语言所能达到的极限。
一个 Hacker News 的讨论围绕着一篇博客文章，详细介绍了在名为“Ivy”的系统中实现超越函数的方法。用户很快指出，这与现有的 Emacs 包“Ivy”存在命名冲突。
对话随后转移到准确计算反正切函数等函数的挑战。一位评论者强调了一种比标准泰勒级数更高效的反正切级数，并引用了计算 Pi 的资源，并将该方法的发明归功于牛顿（由欧拉普及）。
进一步的讨论涉及了*实现*与*逼近*超越函数的哲学问题，一些人认为由于其无限性，真正的实现是不可能的，而另一些人则指出计算机代数系统成功地利用了它们。有人怀旧地提到了 Blogspot 的持续存在及其不太理想的移动端渲染。
## 使用被动安全 API 迁移到微服务 迁移到微服务架构需要构建“被动安全”的 API——设计成能够优雅地处理故障，而不会造成数据损坏或重复。这意味着确保请求要么精确一次完成，要么进入清晰可见的可恢复状态。 作者通过实现一个用于处理订单的端点来应对这一挑战，最初面临外部 API 调用、重试和潜在中断的问题。解决方案涉及几个关键步骤： 1. **异步处理：** 使用消息代理将非关键任务（如通知）卸载到后台工作进程。 2. **事务性分阶段作业（消息输出箱）：** 通过在事务*内*将消息插入数据库表来保证消息传递，然后由单独的工作进程可靠地发布它们。 3. **幂等性：** 使用客户端提供的唯一“幂等性密钥”来确保可以安全地重试请求，而不会产生意想不到的副作用。这涉及跟踪请求阶段和恢复点。 4. **消息收件箱：** 使用单独的表跟踪已处理的消息 ID，以去重消息。 这种方法确保在数据库事务中不会发生外部副作用，至少一次传递消息，并安全地处理重试。最终，这种设计创建了一个健壮、有弹性的 API，能够在分布式微服务环境中处理故障并保持数据一致性。为长期可维护性，清理旧的幂等性密钥和处理废弃的请求也至关重要。
## API可靠性设计：摘要
最近的Hacker News讨论集中在设计“被动安全”的API上——这些系统能够抵御崩溃、超时和重试等故障，而不会造成重复工作或不可恢复的状态。核心思想，如链接文章所述，是优先构建能够固有处理这些问题的API，而不是在问题发生后才做出反应。
对话强调了“被动安全”（目标）与“幂等性”（实现它的关键方法）之间的关系。虽然幂等性确保重复操作产生与一次操作相同的效果，但被动安全包含更广泛的概念，例如原子性——确保操作完全完成或根本不发生。
一些评论者建议利用“持久执行”框架，如Temporal、Restate和DBOS来简化实现。另一些人则争论这种努力是否值得，一些人认为这对于扩展和防止客户问题至关重要，而另一些人则警告不要过度设计。一个关键的收获是，主动设计以应对故障的重要性，承认异步行为是计算的内在属性，并使“安全路径”成为最容易的选择。
欧洲核子研究组织接受10亿美元私人捐款用于未来环形对撞机。
CERN accepts $1B in private cash towards Future Circular Collider
13 小时前
启用 JavaScript 和 Cookie 以继续。
## 欧洲核子研究中心为未来环形对撞机获得10亿美元资金
欧洲核子研究中心（CERN）为其雄心勃勃的未来环形对撞机（FCC）项目获得了10亿美元的私人资金。 这引发了Hacker News上关于基础物理研究的实际应用问题的讨论。
尽管一些人质疑鉴于该项目巨大的成本，其价值如何，但许多人强调了CERN在具有影响力的衍生技术方面的历史。 这些包括万维网、分布式计算方面的进展（如LHC计算网格）、医学成像技术（Medipix/Timepix）、癌症疗法（PIMMS、MEDICIS），甚至对工业超冷却技术的贡献。
争论的中心在于，像希格斯玻色子这样的*具体*发现是否能转化为日常应用，以及为实现这些发现*所需*的技术进步。 一些人认为，该对撞机的主要好处是培养STEM职业和推动工程边界，无论是否有立竿见影的科学突破。 另一些人则表示怀疑，指出过去一些项目对现实世界的影响有限。 还有人担心可能会“追溯性地”调整理论模型，以证明对撞机的能量范围。
Please provide the content you want me to translate. I need the text to be able to translate it to Chinese.
Archyl是一个新的C4模型文档平台，旨在可视化系统、从代码中发现架构并保持同步。它在Hacker News上发布后，立即被拿来与IcePanel比较，并呼吁该领域需要更多竞争。
最初的担忧集中在潜在的厂商锁定上，因为该平台目前不兼容“代码即图”方式，并且依赖于专有格式。用户质疑数据的可移植性和安全性，特别是关于访问敏感代码信息的问题。
Archyl团队回应说，计划增加导出选项和基于文本的表示形式。他们强调目前对Git集成的只读方式，优先考虑确定性和可审计性，并表示Archyl并非旨在成为“真实数据的唯一来源”，而是用于派生元数据和可视化。
尽管有这些澄清，一位关键用户强调了与CI/CD流水线同步对于采用的必要性，而这是目前缺乏的功能。虽然Archyl承认这种哲学上的紧张关系，但它旨在建立信任，并为使架构思维更易于理解做出贡献。
经过十年的 Linux 使用和广泛的“发行版跳跃”——从 Mint 到 Arch，Gentoo（以及随之而来的倦怠！），Fedora，最后是 NixOS——作者开始探索声明式发行版的世界。 最初，作者曾认为 Nix 只是一个 DevOps 工具，但随着项目依赖管理和系统软件包漂移带来的挫败感日益增加，作者改变了想法。 Nix 能够创建隔离的、按项目划分的环境（解决了 Ruby 版本问题），并且其声明式方法——通过配置文件定义*期望*的系统状态，而不是查询当前状态——被证明极具吸引力。 这促使作者对 Guix 产生了兴趣，Guix 是一个使用 Guile Scheme 进行配置的 Nix 分支。 尽管之前因稳定性问题而犹豫不决，但 Guix 1.5.0 的改进，特别是对 KDE 的一流支持，促使作者尝试使用它，并记录了安装和初步体验。 声明式系统所提供的控制、可重复性和版本控制是其核心吸引力所在。
## Guix 系统 初次印象 (来自 Nix 用户)
一位用户分享了从 NixOS 切换到 Guix 的初步体验，Guix 是一个 GNU 发行版，提供类似声明式包管理的方法。主要吸引力在于避免 Nix 语言，转而选择 Guile Scheme。
作者发现 Guix 在优势上与 NixOS 很大程度上可比——可重现的构建、声明式配置——但指出 Scheme 最初的学习曲线更陡峭。评论区的讨论强调了 Guix 对桌面高级用户的潜力，同时也承认 NixOS 更侧重于服务器和嵌入式系统。
提出的担忧包括软件包可用性（Nix 拥有更多选择）和 ZFS 支持。使用 Guix 进行服务器部署是可行的，但不如 NixOS 成熟。评论者讨论了各种服务器管理和密钥处理方法，提到了 `guix deploy`、`nixos-anywhere`、`deploy-rs`、`sops-nix` 和 `clan.nix` 等工具。
一些用户争论 Nix 与 Scheme 的优劣，有些人欣赏 Scheme 的灵活性，而另一些人则认为 Nix 更易于管理。一个反复出现的主题是，希望在两种语言的复杂性之外，有更简单的配置选项。
这个轶事突显了与遗留系统合作的令人沮丧的现实，以及向后兼容性的令人惊讶的怪癖。作者的任务是在IBM System 370的黑白调试器中添加颜色，于是开始寻找相关的文档——在一堆文档中找到一本实体文件夹。
搜索揭示了一种囤积信息的职场文化（特别是同事马修对手册的保护态度），这种文化源于害怕成为找不到所需资源的人。最终，文档被找到，显示`WRTERM`宏*确实*支持颜色，但只有黑色（默认）或红色——而且仅当终端配备了罕见的“双色带”时。
这个故事说明，看似简单的改进可能会受到几十年来的设计选择和早期计算硬件的限制，同时还要应对在互联网时代之前获取信息的实际挑战。
这次黑客新闻的讨论集中在计算领域令人惊讶且常常令人沮丧的**向后兼容性**影响。一个链接中的轶事（plover.com）引发了关于为支持*旧*技术而做出的决策如何持续影响现代系统。
用户分享了例子：Fortran 77 的六个字母函数名限制（为了支持古老的编译器）至今仍在 NumPy 等库中回响，而 Windows 使用“CR LF”作为换行符源于打字机机制。IBM 大型机因运行着数十年历史的代码而受到赞扬，而 Windows 也承载着遗留负担——一些对话框自 Windows 3.1 以来就没有更新过，以避免破坏功能。
核心观点是，看似武断的、出于历史原因做出的选择可能会变得根深蒂固，从而在当前软件和硬件中产生怪癖和限制。虽然令人沮丧，但这种对向后兼容性的承诺确保了关键系统的持续功能。