美国参议院通过了《外国情报监视法》第702条的再授权，该关键监控项目在午夜截止日前几小时获得延期。

• 立法紧迫性：参议院在60-34的两党支持下批准了该法案，将702条款延长两年。总统拜登随后签署，使其成为法律。此举发生在截止日期前约15分钟，避免了该法案的失效。
• 项目重要性：美国官员强调，702条款自2008年首次授权以来，对于阻止恐怖袭击、网络入侵和外国间谍活动至关重要。该法案授权美国政府无需搜查令即可收集位于美国境外的非美国公民的通讯，以获取外国情报。
• 主要争议点：立法过程因隐私倡导者和国家安全强硬派之间的长期冲突而陷入困境。核心争议在于是否应限制FBI使用该项目搜索美国人的数据。虽然该项目仅针对境外外国人，但也会收集与这些外国人联系的美国人通讯。
• 改革尝试与结果：一些两党议员要求修正法案，包括要求执法部门在访问美国人通讯前必须获得搜查令。参议院多数党领袖舒默最终达成协议，允许就六项修正案进行投票以换取加快立法进程。然而，这些旨在加强公民自由保障的修正案均未获足够支持，最终未能纳入法案。
• 反对与支持观点：支持者认为，要求搜查令会阻碍情报机构快速应对迫在眉睫的国家安全威胁。反对者则引用了过去一年中FBI分析师不当查询美国人信息（包括国会议员和抗议活动参与者）的案例，主张需要更严格的隐私保护。
• 背景情况：尽管法案到期，拜登政府曾表示，基于外国情报监视法庭的意见，其收集情报的授权在至少一年内仍可运作。但官员警告，缺乏国会授权可能导致通信公司停止配合政府。据报道，在截止日期前，已有两家主要美国通信供应商表示将停止遵守相关命令。

Quill v2 富文本编辑器概要

面向开发者的特性

• 精细的API控制：通过简洁的API，开发者可以对编辑器的内容、更改和事件进行精细的访问和操作。
• JSON数据驱动：支持以JSON格式作为统一的输入和输出，确保编辑器的行为具有确定性和一致性。

跨平台支持

• 广泛的浏览器兼容性：在桌面端、平板电脑和手机的现代浏览器上均能流畅运行。
• 一致的体验与输出：无论在何种平台上，都能提供一致的用户体验，并生成相同的HTML代码。

• 帖子目的：鼓励Hacker News用户申请Y Combinator (YC)，特别是针对S24批次，强调申请过程简单且可能改变人生。
• 关键反驳点：
  • 错误想法1：可能不够好或不会被录取：许多人因冒名顶替综合症或缺乏资历而犹豫，但YC评估的是潜力而非当前表象；申请者无需担心资历，应专注于展现真实自我。
  • 错误想法2：太早了：YC寻找有潜力的创始人，无论项目阶段如何；他们提供培训，帮助申请人学习创业技能，因此任何时间都可以申请。
• 额外鼓励：YC的成功案例常来自临时申请或不同初始想法，类似于“Snakes and Ladders”游戏中的“梯子”，增加成功机会。
• 申请细节：截止日期为太平洋时间2024年4月22日晚上8点前，申请链接为 https://apply.ycombinator.com，目标是在5月29日前获得决定。

《猴岛的诅咒》是LucasArts经典“猴岛”系列的第三部作品，延续前作《猴岛2：勒查克的复仇》离奇结局。上部结尾，主角Guybrush三木（Guybrush Threepwood）陷入幻觉，认为自己只是游乐园里玩角色扮演的小孩。新作由Larry Ahern和Jonathan Ackley两位内部员工首次担任主设计师，他们参考了前作风格，加入更强动画与视觉表现，并利用升级版SCUMM引擎实现640x480分辨率，比以往更细腻多彩。

故事设定上，Guybrush在海上漂流，偶遇Elaine与僵尸海盗勒查克（LeChuck）的激战，被俘又逃脱，结果向Elaine求婚却用上了含有巫毒诅咒的钻石戒指。Elaine变成金像后被海盗盗走，Guybrush必须集齐船只、船员和地图，前往“血岛”（Blood Island）寻找解除诅咒的第二枚钻戒。冒险中，他与各种角色互动，包括理发师、餐厅老板、沙滩服务生等，途中遭遇海战、风暴，最终在血岛与各路奇人进行解谜与任务。勒查克苏醒并派手下追捕Guybrush。最终，Guybrush解开诅咒却与Elaine双双被勒查克抓到“猴岛的魔鬼嘉年华”，Guybrush被变成孩童，机智逃脱并与Elaine走向幸福结局。

游戏特色：

• 强化视觉：采用更高分辨率的像素画面，灵感参考迪士尼与Tim Burton动画，角色夸张但讨喜，动画水平堪比主流动画片。
• 首次全程配音：Guybrush配音（Dominic Armato）成为系列标志，后续以及原作重制均由其参与。
• 幽默与温情：摒弃二代部分尖刻风格，延续一代的包容与善意，笑点普遍易懂，适合各年龄层，包涵大量业界、流行文化和自家游戏的彩蛋（如《星际迷航》、《星球大战》、《海盗们！》等）。
• 创新谜题设计：继承二代双难度模式，“Mega-Monkey”难度谜题更多层次。谜题遍布各处且有丰富互动，适合多次游玩体验更完整笑点与细节。
• 互动设计亮点：包括船战+侮辱剑斗模式，重现Sid Meier的“海盗们！”但更幽默包容；还包含原创互动歌唱片段，遗憾未能国际化移植。
• 内容丰富：主岛“Plunder Island”篇章长度接近首作全篇，血岛与嘉年华结局部分也内容充实，整体体量大、玩法多、探索丰富。

产业背景：

• LucasArts在90年代后半期冒险游戏市场趋于萎缩，为保障投入，依赖品牌效应推出本作。
• 彼时3D游戏、射击与即时战略类崛起，传统像素冒险渐成小众。LucasArts仍坚持高质量动画与定制内容投入，制作周期18个月，团队规模最高达50人。
• 本作是LucasArts使用SCUMM引擎及像素美术的最后一部作品，之后公司转向3D建模及更低成本的设计方法。
• 商业上本作表现佳，销售数十万份，是最后一部取得商业成功的LucasArts冒险游戏。后续第四作无论艺术还是业绩均明显逊色。
• 冒险游戏高昂成本与有限受众群导致LucasArts最终放弃AAA冒险开发，本作亦被赋予“告别之作”意义。

简述剧情流程（漫画式梗概）：

1. Guybrush于海上漂流，思念Elaine，意外卷入勒查克与Elaine战斗。
2. 逃脱后向Elaine求婚，因咒戒导致Elaine变成金像并被盗。
3. Guybrush求助巫毒女士，踏上集船、船员和地图之旅，邂逅多名角色。
4. 海战与风暴后抵达血岛，解谜盗取钻石终成功解咒。
5. 二人被抓至猴岛嘉年华，Guybrush智斗勒查克，救出Elaine，与其成婚。

《猴岛的诅咒》以幽默、艺术和丰富玩法，成为90年代末冒险游戏巅峰，也是SCUMM引擎与像素画时代的绝唱。

Multipath TCP for Linux (2022) 摘要

Multipath TCP (MPTCP) 是标准 TCP 的扩展（RFC 8684），允许设备通过单一 MPTCP 连接同时利用多个网络接口收发数据包。其主要目标是通过路径聚合提升吞吐量、选择最低延迟路径，以及在一条路径失效时实现无缝故障切换，将流量转移到其他可用路径。

核心概念与工作机制

1. 子流与连接：当使用 IPPROTO_MPTCP 协议创建套接字时，会建立一个初始子流。子流本质上是一个常规的 TCP 连接，通过特定网络接口传输数据。主机之间可后续协商建立额外的子流。
2. 协商与降级：MPTCP 在底层 TCP 子流的 TCP 选项字段中通过 MP_CAPABLE 选项向对端主机发出信号。如果对端主机或中间网络设备（middlebox）不支持 MPTCP，连接将自动降级为普通 TCP，继续使用单路径。
3. 内部组件：
   • 路径管理器：负责子流的整个生命周期（创建、删除）以及地址公告。客户端通常发起子流，服务器则通过 ADD_ADDR/REMOVE_ADDR 选项公告额外地址。在 Linux v5.19 中，有两种类型：类型0（内核内置，通过 ip mptcp 配置，对所有连接应用统一规则）和类型1（用户空间，由守护进程 mptcpd 控制，可对每个连接应用不同规则）。
   • 数据包调度器：负责决定将下一个数据包发送到哪个可用的子流上。其策略可根据配置目标为最大化带宽、选择最低延迟等。截至 Linux v6.8，仅有一种数据包调度器，通过 net.mptcp 下的 sysctl 旋钮配置。

应用场景

• 无缝切换：在保持连接的同时切换路径（如从蜂窝网络切换到Wi-Fi），Apple 自2013年起主要为此在智能手机上使用 MPTCP。
• 最优网络选择：根据延迟、丢包、成本、带宽等条件选择“最佳”路径。
• 带宽聚合：同时使用多条路径以获得更高吞吐量（如聚合固定和移动网络以快速传输文件）。

Linux 内核主要特性（截至 v6.10）

• 支持在 socket() 系统调用中使用 IPPROTO_MPTCP 协议。
• 当对端或中间件不支持时，从 MPTCP 回退到 TCP。
• 支持内核内置或用户空间路径管理。
• 支持 TCP 套接字的常用套接字选项。
• 提供调试功能，包括 MIB 计数器、diag 支持（ss 命令使用）和跟踪点。

生态系统与项目

• 核心项目：
  • 内核开发：托管在 GitHub，有持续集成测试和问题跟踪器。
  • Multipath TCP Daemon (mptcpd)：可执行完整的用户空间路径管理或控制内核路径管理器，并包含 mptcpize 工具使传统 TCP 程序也能使用 MPTCP。
  • 带 MPTCP 支持的 Packetdrill：测试工具。
• 增强项目：
  • iproute2（用于 ip mptcp 命令）。
  • Network Manager（自 v1.40 开始包含 MPTCP 特性）。
  • Multipath TCP applications：协调流行 TCP 应用的 MPTCP 更新项目。
• 社区沟通：邮件列表 mptcp@lists.linux.dev，IRC 频道 #mptcp on libera.chat，定期举行在线会议。

文章作者测试了Meta基于Llama 3构建的AI助手“meta.ai”。作者以自己（Tim Bray）为测试对象，询问助手关于他对谷歌的看法。助手在两次查询中均给出了详细回答，但存在大量事实错误。

主要错误包括：

• 错误称作者为计算机科学家。
• 错误描述作者在谷歌的职位（从未担任副总裁或拥有“工程师”头衔）。
• 虚构了作者的博客文章内容（如提及并不存在的文章《Goodbye, Google》），并错误概括了其观点和批评。
• 将作者的观点描述为“复杂多面”，而作者自认观点主流。

作者强调，尽管这些回答事实错误，但表述上显得极其合理且自信，这令人不安。他指出，助手虚构的许多行为和观点（如批评谷歌的决策过程、赞扬其开源活动）虽然可能发生，但并非事实。

作者认为，这反映了大型语言模型（LLM）的一个普遍问题：擅长生成听起来合理但实际上错误的叙述。他提到，科学图表通常会标注“误差范围”以显示数据的可信度，但当前的AI产品缺乏这种透明度，因此在没有不确定性提示的情况下依赖此类技术可能存在风险。

作者最后表示，虽然meta.ai的用户界面设计出色，但基于此次体验，他对该产品的可靠性持保留态度，并指出类似问题在其他通用问题中也重复出现。

协程与效应系统

文章探讨了协程与效应系统的关联与差异，并从类型检查和作用域两个维度分析了它们的优劣。

核心概念

• 协程：一种可以在执行中暂停并向调用者yield控制权的函数。调用者可保存其状态并在未来恢复执行。它可以用于建模多种效应，如异步IO（yield Pending）、迭代（逐个yield值）、异常（yield异常值）。Rust使用协程处理异步和迭代。
• 效应系统（如Koka）：表达式除了类型，还拥有“效应”这一额外属性。函数继承其体部的效应。对于可处理的效应，当其发生时，控制权会传递给最近的效应处理器，处理器可能交还控制权，也可能不交还。同样可用于建模IO、迭代、异常。

关键区别

核心区别在于控制权转移的目标不同：

• 协程：将控制权交还给调用者。
• 效应系统：将控制权交给最近的处理器。

这导致了透明性的差异：

• 使用协程时，调用点需要显式的语法（如Rust的.await或?）来转发或处理协程可能产生的效应（如Pending或异常）。
• 使用效应系统时，效应的传播是隐式的，函数体内的任何函数调用都可能触发效应。

作用域分析

作者将设计空间分为三个象限，以异常和IO为例：

• 效应处理器 属于“静态类型 & 动态作用域”：它们要求函数标注其效应，但在函数体内，无需在每个调用点标注效应即可发生，这给局部推理（理解控制流在哪里可能发生跳跃）带来了挑战。
• 协程 属于“静态类型 & 词法作用域”：效应（如Pending）通过类型标注，在调用点有显式的语法（如await）来标识控制流可能转移的位置，有利于局部推理。

共同优势：无层级性

协程和效应系统相比Monad的一个共同优势是它们是无层级的。例如，所有能yield Pending和Exception的协程都具有相同类型，无需区分像IO<Result<T, E>>和Result<IO<T>, E>>这样的嵌套顺序。

总结观点

作者认为，协程是处理许多效应函数更有前景的方式，因为它处于一个理想的设计位置：静态类型、词法作用域且无层级。尽管有栈协程（可递归）可能更优，但无栈协程（如Rust的async）已满足需求。

JEP 草案：在 switch 中处理异常

摘要

此提案旨在增强 Java 的 switch 结构，允许在 switch 代码块内处理选择器表达式（即 switch (e) ... 中的 e）所抛出的异常。结合此前对 null 选择器的处理支持，这将使 switch 在模式匹配中更加强大和实用。这是一项预览语言特性。

主要目标

1. 提高可读性与可维护性：允许 switch 语句简洁地处理选择器表达式求值的所有可能结果（包括成功、为 null 或抛出异常）。
2. 简化抛出检查异常的 API 使用：当 switch 的选择器表达式调用了可能抛出检查异常的方法时，可以更便捷地处理。

非目标

• 不处理 switch 代码块内部（例如 case 或 default 子句）抛出的异常。
• 不引入匹配异常的新模式。
• 不改变检查异常与非检查异常的基本模型。

动机

传统的 switch 语句对 null 值和异常不友好。若选择器表达式为 null，会抛出 NullPointerException；若选择器抛出异常，则该异常会直接抛出。这迫使开发者在 switch 之外单独处理 null 和异常（通常需用 try-catch 包裹 switch），导致代码冗余且易出错。

近年来，switch 已支持处理 null（通过 case null）。为了进一步提升其在模式匹配中的效用，提案引入 case throws 语法，使开发者能在 switch 内部处理选择器抛出的异常，就像处理 null 一样简洁。

描述

switch 语句和表达式支持一种新的 switch 标签：异常 case，其语法为 case throws <异常类型> <变量名> [when <守卫条件>]。

关键规则

• 编译时错误：如果 case throws 指定的异常类型不可能被选择器抛出，或者类型不是 Throwable 的子类。
• 代码块分区：一个 switch 代码块被逻辑分为两部分：普通 case（包含常量、模式、null、default）和 异常 case。
  • 若选择器求值成功，仅执行普通 case；异常 case 永远不会执行。
  • 若选择器求值抛出异常，仅执行异常 case；普通 case（包括 default）不会执行。
• 主导规则：异常 case 之间的顺序规则类似于 catch 子句：更具体的异常必须在更一般的异常之前处理，否则会产生编译错误。
• 穷尽性要求：选择器可能抛出的每个检查异常都必须被满足以下条件之一：1）被 switch 中的 case throws 处理；2）被外部 try-catch 捕获；3）在所在方法的 throws 子句中声明。
• 匹配多个异常：可以使用无名模式变量（_）在一个 case throws 中匹配多种异常类型，例如 case throws CancellationException _, ExecutionException _ -> ...。
• 精确重新抛出：从异常 case 中重新抛出异常时，异常类型会像 Java 7 的 try-catch 那样保持精确。
• 处理异常 vs 匹配异常值：需区分“选择器抛出异常”（由 case throws 处理）和“选择器返回一个异常对象”（由普通 case 和模式匹配处理）。

示例

Future<Box> f = ...;
switch (f.get()) {
    case Box(String s) when isGoodString(s) -> score(100);
    case Box(String s)                      -> score(50);
    case null                               -> score(0);
    case throws CancellationException ce    -> handleCancel(ce);
    case throws ExecutionException ee       -> handleExecError(ee);
    case throws InterruptedException ie     -> handleInterrupt(ie);
}

运行时行为

在执行 switch 时，首先求值选择器表达式。

• 如果求值成功，控制流进入匹配的普通 case。
• 如果求值抛出异常，且 switch 代码块中存在一个能够处理该异常的异常 case，则控制流转向第一个匹配的异常 case。如果没有匹配的异常 case，则 switch 语句或表达式会以相同的异常突然完成。

其他要点

• 用例：简化静态字段初始化：此特性可方便地在禁止抛出检查异常的位置（如静态初始化器）内联处理异常。
• 预览特性：需要在编译和运行时使用 --enable-preview 选项启用。
• 备选方案：提案探讨了其他语法（如 case catch）并说明了选择 case throws 的原因，以保持 switch 语义的清晰性（即基于选择器的结果进行分支）。同时指出，使用辅助方法（如将结果包装在 Optional 中）是一种变通方法，但并未从根本上解决问题。

文章主要论述了“单一厂商开源”（single-vendor Open Source）本质上是一种伪装的专有软件，一种“新型专有软件”，并对当下软件行业关于开源、专有以及再许可的趋势进行了反思和批判。文章结构及要点如下：

背景梳理

• 起初，计算机软件由使用者共享开发，硬件才是商品。
• 80年代PC兴起后，软件变得有价值，微软等公司推动专有软件模式，使用限制性许可，获取全部价值。
• 90年代，为反击专有模式，开放协作的开源席卷业界，极大降低创新门槛，促进软件革命，开源组件普及度极高。
• 软件厂商也大规模拥抱开源，以便利创新，但逐渐转向通过“单一厂商开源软件”或SaaS模式变现。
• 公有云厂商利用开源软件，SaaS企业感受到竞争压力，认为纯粹的开源对业务不友好，开始采用“非竞争性许可”（non-compete licenses）及再许可，甚至承诺几年后开放，但现在采用限制性许可以保护自身利益。

三大误区解构

1. 免费即等同于开源好处：
   • 实际上开源的核心是“无需许可的自由创新”，而不是“免费”。
   • 非竞争性许可终结了开源的无障碍创新基础。
2. 单一厂商开源是一种理性商业开源方式：
   • 这些厂商实质上将软件视为自有资产，凭借集中的著作权/宽松许可，随时可以变更许可本质，仍然是专有做法。
   • 单厂商开源是暂时披上开源外衣的专有软件，一旦时机合适就会再切换回限制许可。
3. 专有软件是“邪恶”的：
   • 实际“专有”与“开源”并非善恶对立。部分厂商利用开源并不真正背离专有，只是战术手段，本质未变。
   • 真正的问题在于“开源漂洗”（Openwashing）和名义上的开源，但实际只是假意开放、随意变更许可。

当前趋势与警示

• 越来越多的厂商摒弃真正的开源许可，回归限制性规则，同时借用“开放”名义维持影响力和争取口碑。
• 真正的风险在于，如果这类再许可/非开放做法主导行业，软件发展将回到80年代，创新受限，开发者需反复求助法务，无法便捷自由地用和造新工具。

号召行动

• 开源带来的无许可创新是由OSI定义的完整开放许可保障的，不能视为理所当然。
• 应警惕将许可控制集中到单一厂商手中的模式（如带有厂商持有的CLA），它实际上是伪装的专有开发模式，并非真正的开源。
• 只有在开放协作社区中发展软件才是真正的开源，其他发展模式都是“再许可定时炸弹”。
• 呼吁回归并捍卫真正的开源自由，防止名义上的伪开源消解开源精神和行业创新活力。

简要总结

• 单一厂商持有的所谓开源软件，只是临时穿着开源外衣的专有软件，终将回归限制本源。本质上的开源必须是开放、无许可、社区共治。警惕任何有条件或隐藏限制的“伪开源”，积极维护真正开源社区和创新生态。

App Store 编辑精选内容概要

本文主要展示了 App Store 编辑推荐的各类应用程序和游戏，内容涵盖多个主题板块。

主要推荐板块

游戏类推荐：

• 足球游戏：包括《最佳球会-世界杯版本》、《FC足球世界-Next》等足球主题游戏
• 热门手游：如《王者荣耀》S43赛季、《和平精英》7周年、《三角洲行动》、《蛋仔派对》、《崩坏：星穹铁道》等
• 独立游戏：如《迷失岛4小屋实验》、《火山的女儿：再度重逢》等小团队制作的精品
• 经典游戏：如《保卫萝卜4》、《模拟城市：我是市长》、《植物大战僵尸2》等

应用类推荐：

• 效率工具：Microsoft Teams（沟通协作）、Microsoft To Do（任务管理）
• 摄影学习：CapWords（AI拍照学单词）
• 天文观测：星空（观星指南应用）

特色专题

1. 世界杯专题：为2026年世界杯准备的观赛指南和相关应用
2. 编辑挚爱：编辑精心挑选的各类应用和游戏
3. 今日游戏/App：每日更新的精选推荐
4. 独立游戏专题：展示小团队开发的创意游戏
5. 纸牌游戏专题：各类卡牌和棋牌游戏合集
6. 天文探索专题：为天文爱好者精选的观星应用

推荐内容特点

• 覆盖面广：从休闲游戏到专业工具，从儿童教育到效率办公
• 更新及时：包含最新版本和季节活动（如各游戏周年庆）
• 质量筛选：通过“编辑挚爱”、“今日推荐”等形式突出精品内容
• 用户体验导向：注重应用的设计美学和使用体验

整体而言，这是一份App Store当前精选内容的综合展示，反映了平台推荐的多样性和编辑团队的筛选标准。

GitHub评论功能遭滥用：通过微软仓库URL传播恶意软件

漏洞原理

GitHub的文件上传功能存在设计缺陷。用户在提交评论时可附加文件（如压缩包、文档），系统会自动生成以下格式的下载链接：
https://github.com/{用户}/{仓库名}/files/{文件ID}/{文件名}
关键问题：

• 链接在评论保存前即自动生成，攻击者无需发布评论即可获取恶意文件链接
• 文件上传至GitHub CDN后，即使评论从未发布或已删除，链接永久有效
• 链接包含知名仓库名称（如微软、NVIDIA），极具误导性

恶意活动实例

1. 微软仓库被利用

   • 恶意软件伪装成《Cheat Lab》《Cheater Pro》等作弊工具，通过微软的 vcpkg 和 STL 仓库分发
   • 链接示例：
     https://github.com/microsoft/vcpkg/files/14125503/Cheat.Lab.2.7.2.zip
   • 实际文件与仓库源代码无关，仅为评论附件

2. 其他高危仓库可被滥用

   • 攻击者可在 NVIDIA驱动安装仓库 上传伪装为显卡驱动的恶意文件
   • 或在 Chromium源代码仓库 上传伪装为浏览器测试版的恶意文件
   • 链接均显示为官方仓库地址，欺骗性极强

恶意软件特征

• 传播载体：以作弊工具为诱饵，实际为 LUA恶意加载器（SmartLoader）
• 关联恶意软件：常与 RedLine信息窃取程序 等其他恶意负载捆绑安装
• 活动时间：自2024年2月起持续活跃，3月出现类似变种

平台限制与应对措施

• GitHub现有防护不足：
  • 无法管理项目关联的附件文件
  • 唯一缓解方案：临时禁用仓库评论（最长6个月），但严重影响项目开发
• 微软仓库处理结果：
  • 截至报道更新时，GitHub已删除微软仓库中的恶意文件链接
  • 但 httprouter、Aimmy 等其他仓库的恶意链接仍可访问

安全风险总结

该漏洞允许攻击者利用任意公开仓库的信誉分发恶意软件，且仓库所有者无法主动检测或清理恶意附件。用户对来自知名开源项目的链接可能产生虚假信任，显著增加感染风险。GitHub尚未公开回应此漏洞或提供长期解决方案。

比特币区块 840000

项目名称： Mempool 开源项目®

主要内容：
这是一个用于全面探索比特币生态系统的开源项目平台。其主要功能是让用户能够查看交易的实时状态、获取网络信息以及更多相关数据。

核心功能：

• 交易状态追踪： 提供比特币网络上交易的实时监控。
• 网络信息展示： 展示比特币网络的运行状态和相关数据。
• 生态系统浏览： 帮助用户深入了解和探索整个比特币生态系统。