经过一年尝试向OpenJDK贡献补丁，开发者xtex（张炳武）因Oracle贡献者协议（OCA）审核停滞而放弃努力。尽管在数月内多次跟进邮件，OCA仍未获得批准，回复仅表示道歉并请求另一方进一步审核。 xtex居住在中国大陆，但声明与任何受限制的实体无关，他希望如果存在疑虑，能够明确拒绝，而不是无限期延迟。由于对流程感到沮丧，且没有时间继续“维护”这些PR，xtex发布这些补丁供他人采用。 这些补丁包括修复了损坏的`llvm-config`检查以及JDK 24零变体中的堆栈溢出问题，以及最初计划用于龙芯JDK分叉的多个补丁。xtex鼓励任何感兴趣的人以原创作品的形式重写这些补丁，以避免OCA要求。相关提交和拉取请求的链接已提供。
每日HackerNews RSS
## 开源贡献的挫败感与公司管控
一位开发者分享了他们尝试一年向OpenJDK贡献补丁的经历，最终因缺乏审查和优先级而放弃。 这引发了Hacker News上关于为大型开源项目贡献代码的挑战的讨论，特别是像Oracle这样有公司支持的项目。
许多评论者表示有类似经历——提交的补丁被忽略，难以从维护者那里得到回复，以及贡献除非来自大型公司（Google、Red Hat）的员工，否则不被重视的感觉。 一些长期参与开源的人员哀叹从协作精神转变为期望被接受，而另一些人则指出贡献不是理所当然的权利。
一个关键问题是维护者的负担，他们通常是志愿者，时间有限。 许多人指出，虽然琐碎的补丁对新手入门有好处，但也可能让维护者不堪重负。 讨论还涉及公司贡献者许可协议（CLA）以及对公司控制表面上开放的项目的问题。 几位评论员认为，目前的系统偏向于已建立的贡献者，并阻止了新人的加入。 最终，该讨论强调了在大型开源生态系统中导航的困难，以及对更好贡献者入职和审查流程的需求。
## 播客广告的十字路口 (2024 总结) 播客广告是一个24.3亿美元的市场，但面临一个关键挑战：广告数量增加正在导致听众流失。虽然每周有1.58亿美国人收听播客，但自2020年以来，广告时长增加了39%，现在平均在45分钟的节目中接近5分钟。这导致30%的听众*仅仅*因为广告过多而放弃节目。 研究表明存在“10%阈值”——超过这个广告时长会显著降低广告效果（转化率下降25-40%）。一些类型，如犯罪纪实，远远超过了这个阈值，达到34%的广告占比。 尽管存在风险，广告商仍在继续投入资金，因为播客通过主持人朗读广告建立了独特的亲密感和信任感。然而，数据表明每集2-3个广告（6-10%的运行时长）是平衡收入和听众留存的最佳点。近50%的听众可以容忍*合理的*广告，但26%的听众会因过度打断而离开。 播客的未来取决于优先考虑听众忠诚度，而不是最大化短期广告收入。
## 播客广告现状与听众沮丧
最近在Hacker News上出现了一场讨论，主要围绕播客中广告数量增加的问题，以及这些广告最终是否会损害这种媒介。核心观点是，过多的广告会驱赶听众，从长远来看可能会损害播客创作者的利益。
许多评论者分享了减少广告干扰的方法——使用应用程序自动跳过片头广告，利用快进按钮，或在可能的情况下选择无广告订阅。甚至有人表示会*购买*播客中宣传的产品。然而，人们也对播客的经济模式表示担忧，一些人认为目前的系统令人费解地可持续。
人们探讨了替代广告支持模式的方法，包括通过Patreon等平台进行直接听众支持，甚至使用BitTorrent等去中心化分发方式。YouTube作为播客平台的兴起也受到了关注，一些创作者在那里提供无广告版本，并使用Sponsorblock等广告拦截插件。
最终，这场讨论凸显了支持创作者和保持积极聆听体验之间的紧张关系，许多人认为动态插入的、重复的广告尤其令人沮丧。
## CPython-Internals：深入剖析Python的实现
“CPython-Internals”仓库是对CPython解释器源代码的详细探索，旨在阐释其内部运作机制。它基于CPython 3.8.0a0版本构建，面向有兴趣了解Python底层*如何*运作的Python程序员。
该仓库分为几个部分，涵盖核心Python **对象**（如字典、列表和类）、**模块**（包括`io`、`pickle`、`re`和`asyncio`）、**解释器**本身（GIL、垃圾回收、异常处理和导入机制），以及**扩展**的可能性（C API、Cython和C++集成）。它还涉及从语法到字节码的编译过程。
除了代码相关的文档外，该仓库还提供了一份精选的**学习资料**清单——书籍、博客和视频，供进一步学习。欢迎贡献，包括知识共享、更正和翻译的拉取请求，以及建议和问题的提交。
该资源拥有超过4.4k星标和458个fork，对于那些寻求更深入理解Python实现的人来说，它是一个宝贵的资源。
## CPython 内部原理与 Python 实现讨论
最近 Hacker News 上的一条链接（github.com/zpoint）引发了关于 CPython 实现细节的讨论。 许多评论者分享了深入研究 C 代码的经验，指出其混合了现代和较旧的风格，并且由于缺乏易于“Google 搜索”的细节，导致查找信息具有挑战性。 一些人发现基于代理的编码工具对架构问题有帮助，而另一些人则强调了人工智能在处理复杂方面（例如广泛使用实用宏）时会遇到的困难。
对话还涉及 Python 及其实现（CPython、PyPy 等）之间的关系，并争论是否在讨论 Python 时应始终指定“CPython”。 许多人认为，只有在与替代实现进行对比时才需要这样做。 讨论还包括 Python 和 JavaScript (V8) 之间的性能差异，声称 Python 中的技术债务阻碍了优化，以及 Python 3.13/3.14 中最近添加的实验性 JIT 编译器。 分享了有关 CPython 内部原理的更多探索资源，包括文档链接。
## Nvidia Shield TV：十年的支持与独特方法
一篇Ars Technica的文章引发了Hacker News上关于英伟达对Shield TV持续更新十年承诺的讨论，这种做法在Android TV领域几乎是无与伦比的。用户认为这种长寿归功于英伟达的**垂直整合**——控制着硬件和软件，从而能够绕过像高通这样的公司施加的典型SoC（系统级芯片）支持限制。
虽然良好的文档*可以*实现长期支持，但讨论强调，如果芯片制造商放弃平台，仅仅依靠制造商的意愿是不够的。据报道，英伟达的首席执行官优先考虑继续更新Shield TV，并为此投入了大量预算。
许多用户赞扬Shield即使在十年后仍能持续运行，并对缺乏有竞争力的替代品感到遗憾。一些人建议探索Apple TV或Ugoos设备等选项，但承认存在权衡。对话还涉及了Android TV令人沮丧的现状，竞争产品充斥着广告和过时的硬件。
最终，Shield TV成为一款获得持续支持的罕见设备，引发了人们的疑问：为什么英伟达会继续这项努力，同时大力关注人工智能市场。
Meta正面临指控，源于最近的诉讼和美国调查报告，称其能够访问用户的加密WhatsApp聊天记录——尽管该平台声称实现了端到端加密。该诉讼由Quinn Emanuel Urquhart & Sullivan提起，基于匿名举报人的说法，声称Meta可以访问“几乎所有”用户通信。 Meta强烈否认这些指控，称其“绝对不属实”，并暗示该诉讼是为了支持NSO Group，一家最近在WhatsApp提起的案件中败诉的间谍软件公司。Meta正在寻求对Quinn Emanuel的制裁，指控其进行宣传噱头。 专家对此表示怀疑，指出在大型公司内部掩盖此类漏洞的难度。虽然WhatsApp会收集用户元数据，但访问消息*内容*的核心说法存在争议。美国商务部的调查尚未得到证实。Meta坚持WhatsApp的加密是安全的，并承诺捍卫用户隐私。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
美国据报正在调查指控，称Meta可以读取加密的WhatsApp消息 (theguardian.com)
174点 由 echelon_musk 1天前 | 隐藏 | 过去 | 收藏 | 1条评论
dang 1天前 [–]
评论已移动至 https://news.ycombinator.com/item?id=46838635，其中包含原始来源。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## 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 更新与替代方案：摘要
一则黑客新闻讨论集中在 HTMX 库的近期和潜在变化上，该工具使用 HTML 属性构建服务器驱动的 UI。即将到来的 HTMX v4 最初将包含服务器发送事件 (SSE) 作为核心功能，但开发者正在考虑将其移回扩展，原因是重新设计的 WebSocket 扩展 – 旨在避免偏袒某种流式传输方法。核心扩展（SSE、WebSocket 等）将一起发布，以便更轻松地组合。
对话还强调了替代方案，如 **Datastar**，它提供类似的功能并包含 SSE 支持，具有客户端变量管理等功能，以简化状态处理。 许多用户正在构建自己的框架，灵感来自 Datastar，例如 **Hyperstar**，以实现更像 SPA 的语法。
讨论涉及 HTMX 为寻求简洁性的后端工程师带来的好处，并承认 HTMX 功能强大，但存在局限性 – Datastar 在处理大型数据集的虚拟滚动方面表现出色。最终，用户赞赏 HTMX 减少前端复杂性的能力，但一些人担心更改会破坏现有的简单设置。
## 常春藤：从消遣到高精度数学 出于对一个有趣项目的需求，作者用Go语言创建了常春藤，一种伪APL语言，它意外地演变成了一个用于高级数学计算的工具。尽管最初比其他APL衍生语言弱，但常春藤采用精确算术（大整数和有理数）被证明出奇有用，甚至被用于移动应用程序。 Go语言库中高精度浮点数的出现带来了新的挑战，促使作者深入研究如何以扩展精度计算超越函数，如正弦和余弦。现有的算法不足以满足需求，作者不得不重新审视和完善数学概念。 常春藤的实现利用了泰勒级数和参数归约等技术，最终采用了Spouge近似（由Causley改进）来计算Gamma函数。这涉及到复杂的系数计算，由常春藤的基于数组的结构高效地处理。尽管承认存在不完美之处以及优化参数方面仍然存在疑问，作者还是取得了令人印象深刻的精度——Gamma函数超过48位小数——展示了常春藤进行高精度数学运算的能力。这个项目源于对有趣编码练习的渴望，最终推动了语言所能达到的极限。
一篇最近的博客文章详细介绍了 Ivy 编程语言中超越函数（位于 commandcenter.blogspot.com）的实现，并在 Hacker News 上引发了讨论。一个关键的挑战是准确计算反正切等函数。
评论者指出，存在比标准泰勒级数更高效的反正切级数，并引用了关于加速级数和 Pi 计算方法的资源。 还有一些轻松的争论关于“Ivy”这个名字与现有的 Emacs 包冲突。
关于超越函数是否能真正被*实现*还是仅仅被*近似*，引发了一场哲学讨论，一些人认为精确计算需要无限的时间。 另一些人反驳说，计算机代数系统成功地实现了这些函数，尽管精度有限。 该帖子还提到了 Blogspot 平台的怀旧简单性。
## 使用被动安全 API 迁移到微服务 迁移到微服务架构需要构建“被动安全”的 API——设计成能够优雅地处理故障，而不会造成数据损坏或重复。这意味着确保请求要么精确一次完成，要么进入清晰可见的可恢复状态。 作者通过实现一个用于处理订单的端点来应对这一挑战，最初面临外部 API 调用、重试和潜在中断的问题。解决方案涉及几个关键步骤： 1. **异步处理：** 使用消息代理将非关键任务（如通知）卸载到后台工作进程。 2. **事务性分阶段作业（消息输出箱）：** 通过在事务*内*将消息插入数据库表来保证消息传递，然后由单独的工作进程可靠地发布它们。 3. **幂等性：** 使用客户端提供的唯一“幂等性密钥”来确保可以安全地重试请求，而不会产生意想不到的副作用。这涉及跟踪请求阶段和恢复点。 4. **消息收件箱：** 使用单独的表跟踪已处理的消息 ID，以去重消息。 这种方法确保在数据库事务中不会发生外部副作用，至少一次传递消息，并安全地处理重试。最终，这种设计创建了一个健壮、有弹性的 API，能够在分布式微服务环境中处理故障并保持数据一致性。为长期可维护性，清理旧的幂等性密钥和处理废弃的请求也至关重要。
## 被动安全API设计：摘要
这次Hacker News讨论的核心是构建具有韧性的API，能够在处理失败（崩溃、超时、重试）时，避免数据损坏或重复工作——实现“被动安全”。其核心思想是确保失败不会导致意外副作用或不可恢复的状态。
虽然**幂等性**（多次执行操作的效果与执行一次相同）是实现这一目标的关键*方法*，但被动安全是*原因*。 许多评论员强调了**持久化执行框架**，如Temporal、Restate和DBOS，它们是预构建的解决方案，提供幂等性和恢复等功能。 然而，关于“精确一次”处理的争论浮出水面——框架通常保证“至少一次”，并依赖于幂等操作。
讨论还涉及**事务性输出邮箱模式**，作为一种更轻量级的替代方案，尤其是在使用消息队列时有用。一个关键的收获是，主动解决潜在的故障模式不是“过度工程”，而是必要的工程实践。 最后，有人提出了一个哲学观点：真正同步的操作在计算中很少见，理解异步行为对于构建健壮的系统至关重要。
欧洲核子研究组织接受10亿美元私人捐款用于未来环形对撞机。
CERN accepts $1B in private cash towards Future Circular Collider
9 天前
启用 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模型文档平台
Archyl是一个新的平台，旨在可视化系统架构，使用C4模型，从代码中发现架构，并保持文档同步。它最近在Hacker News上发布，引发了对其方法和潜在缺点的讨论。
虽然其精美设计受到赞扬，但人们也担心它是一个专有解决方案，可能导致“锁定”，与Structurizer和PlantUML等开源的、将图表作为代码的替代方案形成对比。开发者澄清说，Archyl并非旨在*取代*这些方法，而是通过自动发现和同步功能来补充它们，并计划提供导出选项。
目前，Archyl的Git集成是只读的，以确保数据完整性。用户还讨论了将文档与实时代码库同步的挑战，以及需要一个支持更广泛生态系统而不是创建孤岛的平台。 许多评论者分享了使用现有工具（如Structurizer和IcePanel）的经验，强调了可扩展性和可移植性的重要性。 此外，还报告了一个与GitHub注册相关的问题。