Next.js 的 React 服务器组件 (RSC) 协议存在一个关键的远程代码执行 (RCE) 漏洞 (CVE-2025-66478，源自 CVE-2025-55182)。该漏洞 CVSS 评分为 10.0，攻击者可以通过操纵未修补应用程序的请求在服务器上执行代码。 **受影响版本：** Next.js 15.x 和 16.x，以及使用 App Router 的 Next.js 14.3.0-canary.77 及更高版本 canary 发布版。**不受影响：** Next.js 13.x、14.x 稳定版、Pages Router 应用程序和 Edge Runtime。 **解决方案：** 升级到您发布系列中的最新修补的 Next.js 版本 (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 或 16.0.7)。如果使用 canary 发布版，请还原到最新的 14.x 稳定版。没有替代方案；升级至关重要。 详情有意限制，以防止在修补之前被利用。感谢 Lachlan Davidson 的负责任披露。
每日HackerNews RSS
Next.js 存在潜在安全漏洞正在讨论中，最初在 Hacker News 上被提及。问题似乎与最近的 React 远程代码执行 (RCE) 漏洞 (CVE-2025-55182) 相关，最初的猜测认为 Next.js 是问题的来源。
然而，评论者很快澄清，该漏洞*源于* React 本身的实现，而非 Next.js。有人认为 Vercel 在实现 React 服务器组件 (RSCs) 中的作用*可能*有所贡献，但没有确凿证据支持这一说法。
讨论链接回关于 React RCE 漏洞的更广泛讨论，强调了在讨论安全漏洞时准确归因的重要性。核心问题在于 React，尽管最初的假设是 Next.js 参与其中。
英国《在线安全法》正在实施，旨在追究在线平台对用户安全的责任，解决过去将利润置于保护之上的担忧。初期阶段，包括7月实施的色情网站更严格的年龄验证，已经显示出一定影响——Pornhub报告称英国访问量下降了77%。 然而，人们仍然对该法的有效性表示担忧。批评者认为，目前的罚款不足以阻止大型科技公司，而VPN等易于绕过的措施会破坏年龄检查。此外，关于执法也存在疑问，一些公司注册的地址位于问责制有限的地方。 虽然新的指导方针旨在提高女性和女孩的在线安全，但许多人认为该法需要加强，并需要Ofcom进行更严格的监管，包括积极利用其法律权力以确保合规，并真正破坏有害行为。
## MathML Core：改善网络数学互操作性
目标是使数学符号在所有浏览器中一致显示，从而改善所有人的网络体验。这是通过 **MathML Core** 实现的，它是由主权技术基金资助的复杂 MathML 3 标准的简化子集。虽然存在网络标准，但浏览器实现通常存在差异，从而阻碍了一致的渲染。Interop 项目优先考虑用于统一实现的 key 功能。
最近的工作集中在几个领域。**RTL 对称**（适用于阿拉伯语等从右向左的语言）现在可以正常工作，这归功于跨引擎实现的字形级别对称。对 **`math-shift` 和 `math-depth`** 的改进确保了复杂公式的一致间距和大小。其他进展包括标准化的字体处理 (`font-family: math`) 和变量标识符的改进行为 (`text-transform: math-auto`)。
这些改进需要在 Firefox、WebKit 和 Chromium 之间进行持续的协作和更新。未来的工作包括完善运算符布局、改进间距以及解决 MathML 中的定位问题。这项由敬业的个人和组织（如 W3C 数学工作组）推动的协作努力，有望实现数学公式在任何浏览器上都能可靠且美观地显示。
这个Hacker News讨论围绕着MathML，一种将数学符号表示为代码的语言。一个关键点是区分“内容MathML”——侧重于方程的*结构*（类似于Lisp的S表达式），易于程序化生成——和“展示MathML”——侧重于*布局*以供显示。
用户指出，生成内容MathML然后使用XSLT将其转换为展示MathML以便在浏览器中渲染的优势，因为MathML Core（在链接文章中讨论）是展示MathML的一个子集。
评论者认为MathML有很大机会成为标准，这得益于Firefox的早期支持，尽管有些人更喜欢SVG，但发现它更难可靠地实现。一位用户还表达了对欧盟资助MathML开发的满意。还有一个小提示，关于链接网站的性能延迟。
(Empty input provided. There is nothing to translate.)
## Tunnl.gg：一个简单的本地主机隧道工具
Tunnl.gg 是一项新的免费服务，提供了一种无摩擦的方式将本地主机暴露到互联网上，用于开发和测试。它由一位厌倦了记住 ngrok 授权令牌的开发者创建，无需注册，并利用现有的 SSH 客户端进行 HTTP/TCP/WebSockets 隧道传输。
该服务在 Hacker News 上引起了关注，讨论集中在其简单性与潜在滥用（类似于 serveo.net 等过去的项目）以及可持续性。创建者承认存在恶意使用的风险，并正在考虑开源该项目，可能带有 API 密钥系统。
用户被告知流量并非端到端加密——TLS 终止发生在服务器端——并且该服务不适用于生产环境。ngrok、Cloudflare tunnels 和 Tailscale Funnel 等替代方案也被讨论，并考虑了隐私、安全和成本等因素。创建者正在积极处理反馈，包括澄清隐私政策和更新文档。
甲骨文公司拥有“JavaScript”的商标权，这是其收购Sun Microsystems的遗留问题，尽管该公司已基本停止使用该商标。这导致混淆，并阻碍了开发者社区，阻止了活动和标准直接以该语言命名。 放弃该商标的理由主要基于两点：未使用和通用化。甲骨文从未将任何产品*作为*JavaScript进行过严肃的营销，其有限的使用（例如在工具包和JVM中）并不构成真正的商标使用。与此同时，“JavaScript”已成为该语言的通用名称，独立于甲骨文，并被数百万人自由使用。标准化过程甚至导致该语言正式被称为“ECMAScript”，以避免商标冲突。 作者敦促甲骨文公司将该商标释放到公共领域，认为其在法律上符合在美国专利商标局（USPTO）注销的条件。此前他们曾要求采取此行动但未收到回复，他们已准备提交注销申请，并正在寻求法律支持。他们鼓励社区通过签名和提供公益法律援助来支持这一行动。
您的请求已被阻止，原因是网络策略。请登录或在此处创建帐户以恢复浏览。如果您正在运行脚本或应用程序，请在此处注册或使用您的开发者凭据登录。此外，请确保您的User-Agent不为空，并且是独特且具有描述性的，然后重试。如果您正在提供替代的User-Agent字符串，请尝试改回默认设置，因为这有时会导致阻止。您可以在此处阅读Reddit的服务条款。如果您认为我们错误地阻止了您，或者想讨论更轻松地获取所需数据的方式，请在此处提交工单。联系我们时，请提供您的Reddit帐户以及以下代码：e88cb210-94b7-4bc5-99bd-56ca030c4d57。
## 海象：高性能分布式消息流平台
海象是一个基于高性能日志存储引擎构建的、容错的分布式消息流平台。它通过基于段的分割、由 Raft 共识管理的自动领导者轮换以及基于租约的写屏障来实现可扩展性和可靠性。
主要特性包括自动负载均衡、简单的客户端协议（连接到任何节点）以及通过密封段从任何副本提供历史读取的能力。该系统包括节点控制器、Raft 引擎、集群元数据存储以及基于海象的桶存储。
生产者和消费者连接到任何节点，集群会智能地路由请求。主题被划分为段（约 1M 条目），领导者在轮换时进行切换，确保负载均衡。海象提供了一个简单的基于 TCP 的 CLI 用于交互（创建、生产、消费、状态、指标）。
性能基准测试表明，其写入和读取吞吐量具有竞争力，通常超过 Kafka 和 RocksDB。正式的 TLA+ 规范验证了数据一致性，并且核心存储引擎也作为独立的 Rust 库提供。提供了全面的测试和详细的文档。
## 海象：一种新的基于 Rust 的 Kafka 替代方案
一种名为海象的新分布式日志系统，使用 Rust 编写，作为 Apache Kafka 的轻量级替代方案正受到关注。海象并非旨在*取代* Kafka，而是在特定领域表现出色，它提供更快的 WAL 引擎和现代 I/O (io_uring)，从而降低运营开销并简化设置——无需 JVM 调优或复杂的生态系统管理。
然而，Kafka 在生态系统、连接器和大规模可扩展性方面仍然占据主导地位。其他一些 Kafka 替代方案也存在，包括 Redpanda、Tansu 和 Iggy。讨论强调了推翻 Kafka 的挑战，这归功于其强大的网络效应，以及 Kafka API 兼容性等功能的重要性。
海象的创建者指出，潜在的 S3 后端存储，并承认由于偏移量与基于消息的方法不同，维护与 Kafka 兼容的 API 的复杂性。基准测试正在进行中，计划将海象与 Redpanda 进行比较，并评估超越简单吞吐量的性能，重点关注关键指标，如 P99 延迟。
## IndyCar 与一级方程式：主要区别
IndyCar 和一级方程式都是开放式赛车系列赛，但两者之间存在显著差异。一级方程式优先考虑尖端技术，是一项以推动技术极限为重点的制造商锦标赛，从而造就了速度更快的赛车。相反，IndyCar 强调车手技巧和坚固性，比赛场地包括公路/街道赛道*和*椭圆赛道。
一个主要区别在于下压力：一级方程式赛车产生更多的下压力，有助于在弯道中提高速度，但会产生“脏空气”，阻碍近距离竞速。IndyCar 的设计优先考虑来自赛车底部的下压力，从而促进更紧密的竞争，但牺牲了极致的弯道速度。
在引擎方面，两者都使用涡轮混合动力，但一级方程式拥有更高的马力（800-850 马力对 IndyCar 的 700 马力）和不受限制的涡轮增压。IndyCar 优先考虑引擎的寿命。轮胎也不同，一级方程式的 Pirelli 轮胎提供更多的抓地力，但耐用性不如 IndyCar 的 Firestone 轮胎，后者专为椭圆赛道的可靠性而设计。
最后，一级方程式车队大多自行制造，以最大限度地减轻重量，而 IndyCar 依赖 Dallara 提供坚固但更重的部件。这导致 IndyCar 更耐用，但在传统赛道上整体速度较慢。
## IndyCar 与 F1：快速总结
最近的 Hacker News 讨论强调了 IndyCar 和一级方程式赛车之间的差异。尽管圈速出人意料地接近，但这两个系列在理念和技术上有所不同。
目前，F1 是一项高科技、企业驱动的活动，而 IndyCar 则保持着更“以驾驶员为中心”的感觉。然而，F1 正在发展：2026 年的规则将减少下压力和阻力（更接近 IndyCar），同时引入“主动”空气动力学和更平衡的混合动力引擎（50/50 内燃机/电动）。这种转变可能会在短期内导致不可预测的比赛。
评论员还讨论了发动机技术的未来，包括转向合成燃料，甚至电动连续可变变速器（尽管后者目前由于声音问题被 F1 禁止）。除了赛车本身，讨论还涉及团队与驾驶员的作用、草根赛车吸引力以及交通运输电气化的挑战。最终，这两个系列都为赛车迷提供了独特的吸引力。
× PrintCalendar.top 极简月度任务规划器
一个平静、方便打印的画布，用于规划你的月份，记录笔记，并轻量级地记录重要事项。
保持月份显示，跳转到今天，分享月份链接，选择周一/周日作为一周的开始。
随行笔记：带有内联编辑的月度笔记，本地保存在你的浏览器中。
准备打印：简洁的A4布局，深色/浅色主题，以及一键生成PDF。
## 极简月度计划表 - printcalendar.top
一位Hacker News用户创建了[printcalendar.top](https://printcalendar.top/)，这是一个简单、离线且可打印的月度任务计划表，旨在减少干扰。该工具有意避免账户、同步或仪表盘，专注于简洁的月度视图进行任务管理。
创建者回应了反馈，指出所有数据都存储在浏览器本地，并正在探索通过URL编码导出/导入数据以进行共享和备份的选项。用户建议的功能包括JSON/Base64编码数据、同步选项（考虑隐私问题）以及修复不同浏览器（Safari、Chrome、Firefox）上的打印问题。
多位用户赞扬了该工具的简洁性和实用性，并指出打印布局和响应速度方面存在潜在改进空间。创建者欢迎建议，并计划添加带有许可证和README文件的仓库以供自托管。
## 镜像桥：使用 C++26 反射的自动绑定 镜像桥是一个实验性的头文件库，利用 C++26 反射（需要 Bloomberg 的 clang-p2996）从 C++ 代码自动生成 Python、JavaScript 和 Lua 的绑定——**无需任何样板代码**。它在编译时内省 C++ 类，处理数据成员、方法（包括可变参数和重载）、构造函数、智能指针、嵌套类、容器和异常处理。 **主要特性：** * **零代码绑定：** 无需手动编写包装代码或宏。 * **编译时魔法：** 所有绑定逻辑都在编译期间生成，从而实现零运行时开销。 * **多语言支持：** 生成 Python、JavaScript (Node.js) 和 Lua 的绑定。 * **两种工作流程：** “自动发现”用于快速原型设计，而“配置文件”方法则用于生产级控制。 * **性能：** 在编译和运行时均显示出比 pybind11 显著的性能提升。 **入门：** 该项目提供了一个开发容器以方便设置。绑定使用命令行工具（如 `mirror_bridge_auto` 或 `mirror_bridge_generate`）生成。还提供单头文件发行版，以简化集成。 **状态：** 实验性。需要 C++26 反射，尚未推荐用于生产环境。
## Mirror_bridge: C++ 反射用于 Python 绑定
一种名为 Mirror_bridge 的新工具，由 fthiesen 开发并在 Hacker News 上分享，旨在简化使用 C++ 反射为 C++ 代码创建 Python 绑定。这使得开发者能够更轻松地封装 C++ 方法，减少将 C++ 库与 Python 集成的摩擦。
该项目利用 C++26 反射标准，目前已在 Bloomberg clang 分支中实现，并正在逐步添加到 GCC 中。用户可以测试 GitHub 仓库 ([https://github.com/franciscothiesen](https://github.com/franciscothiesen)) 中提供的预构建镜像。
讨论中对该工具的潜力以及 C++26 的新特性表示兴奋，甚至有一些用户考虑专门学习 C++ 以利用它。一个幽默的交流也解决了常见的（且不正确的）断言，即所有新代码都应该用 Rust 编写，并指出 Rust 目前缺乏强大的反射能力。之前的 HN 帖子也链接在其中。