九个美国州联合推动热泵普及

九个州签署了一份谅解备忘录，旨在加速从燃气供暖向电动热泵的过渡。根据协议，到2030年，热泵在住宅供暖、空调和热水系统出货量中的占比应至少达到65%；到2040年，这一比例将进一步提升至90%。签署方包括加利福尼亚、科罗拉多、缅因、马里兰、马萨诸塞、新泽西、纽约、俄勒冈和罗得岛州。

工作原理与优势
热泵通过将室外空气中的热量转移到室内来供暖，反向运行则可制冷，兼具供暖与空调功能。由于其依赖电力驱动，可逐步转向由风能、太阳能等可再生能源供电的电网。即使使用化石燃料发电，热泵的能效也远高于燃气炉，因为它转移热量而非产生热量。据估算，热泵平均每年可为美国一个家庭节省超过550美元，且在低温环境下仍能有效运行。

政策与合作
该联盟由东北州协调空气使用管理协会（NESCAUM）促成，各州将共同争取联邦资金、制定热泵部署标准，并制定住宅电气化的优先行动计划。此举旨在向市场传递明确信号，鼓励制造商扩大生产以满足需求。马里兰州环境部长强调，需让消费者认识到热泵是清洁供暖的理想选择，尤其是在更换旧设备时。

联邦支持
联邦政府已通过《通胀削减法案》拨款1.69亿美元支持热泵国内生产，并为家庭提供数千美元的退税或税收抵免，以激励热泵安装。

供应链协调
联盟将与制造商合作跟踪销售数据，推动供应链上下游（包括承包商）制定长期规划。通过协调各州政策与法规，降低市场不确定性，为其他州提供可参考的标准化方案。建筑脱碳联盟的Matt Casale指出，各州采取一致策略有助于缓解市场过渡压力，为行业参与者提供清晰的规划依据。

这一合作标志着美国在住宅建筑零排放转型中迈出重要一步，通过政策协同与产业联动，推动热泵成为主流供暖解决方案。

Ollama 兼容 OpenAI API 摘要

核心功能

Ollama 现已内置对 OpenAI Chat Completions API 的兼容性，支持用户在本地使用更多工具和应用与 Ollama 交互。

基础设置

• 下载并安装 Ollama。
• 拉取所需模型，例如 Llama 2 或 Mistral：ollama pull llama2。

使用方法

Ollama 的兼容 API 端点为 http://localhost:11434/v1/chat/completions，支持标准的 OpenAI 请求格式。

常见调用方式

1. cURL：通过命令行直接发送 JSON 请求。
2. OpenAI Python 库：将 base_url 设置为本地 Ollama 地址，api_key 可为任意值（如 'ollama'）。
3. OpenAI JavaScript 库：配置 baseURL 和 apiKey 后，按标准方式调用。

应用示例

1. Vercel AI SDK

• 使用 create-next-app 克隆示例项目。
• 在 app/api/chat/route.ts 文件中，将 OpenAI 客户端配置指向本地 Ollama。
• 运行应用并在浏览器中访问 http://localhost:3000 查看示例界面。

2. Autogen

• 拉取模型：ollama pull codellama。
• 安装 Autogen：pip install pyautogen。
• 编写 Python 脚本，配置 Autogen 的 AssistantAgent 使用本地 Ollama 端点。
• 运行脚本，让助手代理执行任务（例如绘制股票价格图表）。

未来计划

当前支持为实验性功能，未来计划增加对以下 API 和功能的支持：

• Embeddings API
• 函数调用
• 视觉支持
• Logprobs

欢迎通过 GitHub 提交 issue 以反馈问题或建议。

SSH端口22的历史由来

SSH（Secure Shell）的默认端口为22，这一选择并非偶然。1995年，Tatu Ylonen开发了初始版本的SSH，旨在替代当时广泛使用的telnet（端口23）和ftp（端口21）。端口22恰好位于这两个端口之间，且当时未被分配。作者认为使用此端口能增加协议的可信度，于是在发布前通过电子邮件向IANA（互联网号码分配机构）申请分配端口22。IANA的Jon Postel和Joyce K. Reynolds迅速批准了该申请，次日即确认端口22分配给SSH。1995年7月12日，SSH-1.0正式发布。

更改SSH端口的方法

SSH服务器默认运行在端口22，但有时需要更改，例如用于测试、运行多配置或非特权环境（端口≥1024）。更改方式包括：

• 修改配置文件/etc/ssh/sshd_config中的Port 22指令。
• 使用命令行选项：服务器端通过sshd -p <port>，客户端（如ssh、sftp）通过ssh -p <port>或sftp -P <port>（注意大小写）。命令行设置会覆盖配置文件。

SSH与防火墙配置

SSH常被允许通过防火墙，但需注意安全风险：

• 出站SSH：通常只需允许TCP端口22出站即可。但无限制的出站SSH可能带来风险，如反向隧道（SSH隧道）可绕过防火墙控制，违反安全策略（如PCI、HIPAA），并可能被用于建立后门。
• 入站SSH：可通过以下方式配置：
  1. 端口转发：将防火墙的端口22连接转发到内部网络或DMZ的特定IP。
  2. 多端口分配：使用不同端口访问不同服务器。
  3. VPN要求：仅允许通过VPN（如IPsec）登录后访问SSH。

使用iptables启用SSH访问

在Linux中，iptables作为主机防火墙，需显式允许端口访问。启用SSH的命令如下（以root身份运行）：

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

若要永久保存规则，可使用service iptables save命令（系统支持时）。

这篇文章记录了作者偶然参与Blender视频序列编辑器（VSE）开发并为其贡献性能优化代码的经历。

作者原本对视频编辑一无所知，因访问Blender总部被邀请而意外开始了贡献工作。在大约两个月的兼职开发中，他专注于对VSE进行性能优化，主要改进了以下方面：

1. 时间线绘制性能：通过优化图形API调用方式，将包含约3000个片段的大型时间线的滚动和缩放帧率从约15 FPS提升至60 FPS以上。同时，音频波形显示默认开启。

2. 示波器改进：优化了直方图、波形监视器和矢量示波器的绘制质量与速度。直方图绘制为更清晰的多边形并添加网格；波形监视器通过多线程加速了15倍；矢量示波器更新了外观设计。此外，“显示过曝区域”功能也加速了2-3倍。

3. FFmpeg多线程处理：通过调整代码以正确使用libswscale库的多线程功能，显著加速了电影文件读写过程中的RGB与YUV色彩空间转换。

4. 音频重采样优化：为Audaspace音频引擎新增了一个“中等”质量重采样算法，在保持与高质量渲染几乎相同音质的同时，将计算速度提升了约3倍，从而缩短了视频渲染时间。

5. 图像变换与滤波：

   • 修复了图像缩放和旋转过程中出现的“半像素偏移”等误差。
   • 解决了双线性滤波在图像边缘混合透明度的问题，并改为在目标图像边缘应用抗锯齿。
   • 新增了“双三次（Mitchell）”滤波选项，为上采样提供了更多选择。
   • 将下采样使用的“3x3子采样”滤波器改为可变尺寸的盒式滤波器，效果更佳。
   • 新增了“自动”滤波选项作为默认值，它能根据变换参数（如缩放比例）自动选择最合适的滤波方法。
   • 通过消除虚函数、使用SIMD指令和优化数学计算，提升了各类滤波的处理速度。

6. VSE特效优化：通过引入多线程等技术，大幅提升了多种特效的处理速度，例如发光效果加速6-10倍，擦拭效果加速6-20倍，伽马交叉效果加速4倍，高斯模糊效果加速1.5倍。

综合以上改进，在作者使用的测试项目上，VSE的视频渲染时间缩短了约一半。

最后，作者分享了在开源项目中进行贡献的工作感受，认为在无公司流程约束的环境下，开发效率和完成度可能更高，并希望Blender能避免陷入低效的官僚流程。作者计划继续对VSE进行探索性优化。

文章分析探讨了React的发展及其带来的影响。作者认为，React已经超出了最初的定位，现今带来的负面影响大于正面价值。主要观点包括：

• React最初作为UI库，目标是简化组件化开发，但如今其生态不断膨胀，涵盖状态管理、路由、服务端渲染等，使开发复杂度上升。
• 随着React普及，许多开发者默认选择React而不评估真正需求，导致其被滥用于简单项目或非合适场景，浪费资源。
• React的抽象层给初学者带来学习门槛，影响新手工程师成长，不利于Web标准普及和底层技能培养。
• 生态繁荣导致依赖多、工具链复杂、升级和维护成本高，反而阻碍开发效率提升。
• 作者建议在许多现代项目中可以用原生Web技术（如Web Components）或轻量级库替代React，获得更高效、低耦合的开发体验。

总结认为，React已经背离了初衷，成为Web开发中负重前行的工具，应当审慎选用而非盲目依赖。

规则共识之难：从“公园禁车”到平台内容审核

本文通过“公园禁车辆”这一简单例子，论证了大型平台在制定内容审核、垃圾信息、欺诈及色情内容等政策时，几乎不可能获得用户的一致同意。

核心论证

1. 简单规则下的共识困境

作者引用David Turner设计的“公园禁车”调查游戏作为例证。该游戏仅要求参与者根据一条简单规则（禁止车辆进入公园）判断各种实体（如自行车、救护车、太空站、退役坦克等）是否违反规定。尽管规则看似明确，但参与者的答案分歧巨大。

2. 数据揭示的惊人分歧

• 调查显示，共有36,902人参与，产生了9,432种不同的答案组合。
• 最主流的观点组合仅获得**11.7%**参与者的认同，远非“明显多数”。
• 第二、第三流行的观点组合分别只有8.5%和6.5%的支持率。
• 平均而言，每种独特观点仅约3.9人持有，用户之间的平均共识率低至约0.01%。
• 数据表明，即使在最主流的答案组合中，也没有一种能获得多数人（超过50%）的同意。

3. “显而易见”的错觉

文章指出，许多参与者（如文中引用的热门评论者）认为自己的答案“清晰明了”，但数据揭示这是一种普遍的认知偏差——人们往往高估他人与自己观点一致的程度。实际上，在简单规则下，不同人对规则的理解和应用就已存在根本性差异。

从抽象例子到现实复杂议题

作者进一步将此现象延伸至更复杂、更具情感色彩的现实议题：

• 体育领域：以NBA球员德雷蒙德·格林的“脏动作”为例。尽管非勇士队球迷普遍认为他是“最脏”球员，但勇士队球迷却能为其所有行为辩护。即使是“踩踏对手胸膛并借力跳跃”这类看似无可争议的行为，也存在强烈的意见分歧。
• 政治与社会议题：在人们情感投入更深的领域（如政治），分歧会加剧且变得更加“分形化”——即使观点极为接近的人群之间，也可能因微小差异而产生激烈冲突。文章以1976年女权主义者Jo Freeman的经历以及近年来视频创作者Natalie Wynn的遭遇为例，说明即使意见差异细微到需要数千字才能解释，也可能引发要求“平台封禁”甚至人身攻击的激烈反应。

结论：平台审核的根本性难题

文章最终指出：

1. 不可能满足所有用户：由于用户对何种内容应被审核、何种内容应被保留存在根本性且广泛的意见分歧，没有任何大型平台能够制定出令所有用户满意的规则。
2. 规模加剧矛盾：平台规模越大，用户群体越多样，这种基于主观解释的规则共识问题就越难以解决，甚至可能变得不可能。
3. 现实意义：这解释了为什么内容审核政策总是伴随着争议——问题不在于平台“做得不够好”，而在于获得广泛共识在人性层面就是极其困难的，即使面对最简单的规则。

（注：摘要严格依据原文内容与数据，未添加个人意见或外部信息。）

2024年对精简软件的呼吁

背景与现状

本文致敬已故计算先驱Niklaus Wirth，他于1995年发表《对精简软件的呼吁》。作者在近30年后更新其观点，指出当代软件存在严重臃肿化问题：简单应用（如车库门控制器）可能依赖数百万行代码和1600多个外部库，导致安全风险剧增。

软件安全危机

当前软件安全形势严峻，近年来Ivanti、MOVEit、Outlook等主流软件均爆出严重漏洞。即便是苹果、谷歌等巨头也出现低级错误。软件的不安全性导致行业建议用户不要自行运行软件，而是转向“X即服务”或云平台。然而，云服务本身也不安全（如微软邮件系统多次被入侵、Okta遭全面攻破）。欧盟已通过NIS2、《网络弹性法案》等立法试图改善这一状况。

代码臃肿的根源

1. 激励机制失衡：开发更安全的软件耗时耗力，而安全漏洞往往不影响公司利润，导致企业优先追求上市速度。
2. 代码数量过多：攻击面与代码量成正比。苹果iMessage因支持过多图像格式（包括含嵌入编程语言的PDF）而长期被利用，暴露了数百万行代码中的漏洞。
3. 依赖管理失控：现代应用常基于Electron等框架，内置浏览器引擎和Node.js，轻松引入数千万行代码和大量依赖包。依赖项来源不透明，且常被恶意接管。

精简开发的可行性

作者以Trifecta项目为例证明精简软件的可行性：这是一款独立的图片共享工具，仅用1600行新代码和5个关键依赖，总代码量仅3MB。相比之下，类似项目常占用数百MB的Docker镜像或包含数百万行代码。

未来展望

• 监管推动：欧盟立法要求厂商最小化攻击面，可能迫使行业重视代码精简。
• 开发者责任：Wirth曾指出“复杂不等于强大”，软件膨胀并非自然法则，而是工程选择。开发者应抵制“复杂即高级”的误区，在压力下保持质量标准。
• 平衡之道：既要提升代码质量（如使用内存安全语言、模糊测试），更需通过减少代码量来缩小攻击面。精简软件虽可能延长开发周期，但能从根本上增强安全性。

Trader Joe's 每日价格追踪摘要

这是一个提供 Trader Joe's（缺德舅）超市商品每日价格 的追踪工具或列表。其核心功能是让用户能够方便地查看该超市数百种商品的最新售价。

核心内容

• 服务性质：旨在每日更新和展示 Trader Joe's 的商品价格信息。
• 数据格式：以 “商品名称 + 价格” 的列表形式呈现，清晰直观。
• 覆盖范围：列表极其详尽，涵盖了 Trader Joe's 超市中绝大多数品类的数千种商品，包括但不限于：
  • 食品饮料：从咖啡、茶饮、果汁、奶制品、肉类、海鲜、冷冻食品、面包烘焙、调味品、零食到酒水等。
  • 特色商品：包括大量 Trader Joe's 的自有品牌产品、季节性限定商品、以及各种口味的特色奶酪、意大利面、酱料等。
  • 其他品类：亦包含少量个人护理、家居清洁及宠物用品。

价格特点

从列出的价格示例来看，商品价格跨度较大，但多以个位数美元为主，符合 Trader Joe's 作为平价优质超市的定位。例如：

• 基础食品如香蕉、谷物等价格较低。
• 特色奶酪、优质肉类、酒类及部分进口商品价格相对较高。
• 存在不同包装规格导致同一商品有不同价格的情况。

总结

该工具的本质是一个 Trader Joe's 商品价格数据库或每日快报，主要价值在于为消费者提供透明、及时的价格信息，帮助其做出购物决策、跟踪价格变动或了解该超市的产品结构与定价范围。

PostgreSQL 16 查询规划器的10项新改进

PostgreSQL 16 对查询规划器进行了多项优化，显著提升了众多 SQL 查询的执行速度。以下是对文中提到的10项关键改进的概要总结，每项改进均附有 PG15 与 PG16 执行计划对比的示例说明。

1. 允许在更多场景（包括 DISTINCT 查询）中使用增量排序

• 改进内容：PG16 的查询规划器现在会为 SELECT DISTINCT 查询考虑使用增量排序。该排序方式可利用已按某些前导列排序的数据，仅对剩余列进行分组排序，从而比全排序更高效。
• 效果对比：在示例查询中，PG16 使用了索引扫描结合增量排序，执行时间比 PG15 的哈希聚合快 63%，且内存使用大幅减少。

2. 允许包含 ORDER BY 或 DISTINCT 的聚合函数利用预排序数据

• 改进内容：PG16 的规划器会尝试生成能为聚合节点提供已正确排序输入的计划。执行器在检测到输入已排序时，可跳过内部排序步骤。
• 效果对比：示例查询中，PG16 避免了隐式排序溢出到磁盘的操作，执行时间缩短了一半以上。

3. 允许在 UNION ALL 查询上方使用 Memoize 节点

• 改进内容：当参数化嵌套循环的内侧是 UNION ALL 查询时，PG16 会考虑使用 Memoize 节点。该节点缓存查询结果，对于重复的查找值可直接返回缓存，避免重复执行。
• 效果对比：示例查询中，Memoize 节点显著减少了内侧循环的执行次数，使查询速度提升了约6倍。

4. 允许非可空输入作为内部关系执行反连接

• 改进内容：PG16 引入了右反连接支持。规划器现在可以在执行 NOT EXISTS 子查询产生的反连接时，选择对两表中较小的一个构建哈希表，而不是固定将 NOT EXISTS 中的表作为内部关系。
• 效果对比：示例查询中，PG16 为小表构建哈希表，内存使用和执行时间均大幅降低。

5. 允许对 FULL 和 RIGHT 外部哈希连接进行并行化

• 改进内容：PG16 扩展了并行哈希连接的支持范围，现在 FULL JOIN 和 RIGHT JOIN 类型也可以使用并行执行。多个工作进程可以共同构建单个哈希表。
• 效果对比：示例的 FULL JOIN 查询在 PG16 中成功并行执行，执行时间显著缩短。

6. 当 RANGE 模式不必要时，允许窗口函数使用更快的 ROWS 模式

• 改进内容：对于 row_number(), rank() 等在 ROWS 和 RANGE 窗口模式下行为相同的窗口函数，PG16 的执行器可以跳过检查“对等行”的额外开销，直接使用更高效的 ROWS 模式逻辑。
• 效果对比：在使用 row_number() 限制结果的查询中，PG16 执行器能提前终止索引扫描（仅读取11行 vs 50410行），查询速度提升超过500倍。

7. 优化始终递增的窗口函数 ntile(), cume_dist() 和 percent_rank()

• 改进内容：PG16 将“提前终止”窗口函数执行的优化扩展到了 ntile(), cume_dist() 和 percent_rank() 函数。当 WHERE 子句中的过滤条件对这些单调递增函数变为假后，可立即停止处理。
• 效果对比：示例查询中，PG16 将过滤条件作为“运行条件”，避免了处理全部50000行，执行时间减少超过4倍。

8. 允许在分区表上进行左连接移除和唯一连接优化

• 改进内容：PG16 现在支持在分区表上移除不必要的 LEFT JOIN。规划器能够证明连接不会产生重复行且未使用被连接表的列时，可完全消除该连接。
• 效果对比：示例查询中，PG16 的执行计划完全消除了对分区表的连接和扫描，仅需扫描普通表。

9. 在可能时，使用 Limit 而非 Unique 来实现 DISTINCT

• 改进内容：当规划器能确定所有结果行在 DISTINCT 列上的值都相同时（例如 WHERE 子句已对这些列设定了相等条件），PG16 会使用 Limit 1 来简单获取一行结果，而不是对可能的所有行进行去重。
• 效果对比：示例查询中，PG16 避免了并行扫描和去重操作，执行时间比 PG15 快超过1200倍。

10. 放宽 select_outer_pathkeys_for_merge() 中过于严格的规则

• 改进内容：在考虑合并连接的顺序时，PG16 的规则从“必须完全匹配上层操作所需排序”放宽为“至少有一个前导列已正确排序”。这使得规划器可以在合并连接后使用增量排序来满足上层的排序要求。
• 效果对比：示例查询中，PG16 使用了增量排序替代全排序，执行时间略有减少，且排序操作的内存使用大幅降低。

Sudo for Windows

发布概述
微软在 Windows 11 Insider Preview Build 26052 中发布了 Sudo for Windows。它允许用户在未提升权限的控制台会话中直接运行需管理员权限的命令，无需预先打开新的管理员窗口，提供更符合用户习惯的体验。该项目已在 GitHub 开源，并计划未来扩展文档和功能。用户如需更多高级功能，可考虑第三方工具 gsudo。

启用方式

• 在 Windows 设置中，导航至“设置 > 开发者”，启用“启用 Sudo”选项。
• 或在管理员命令提示符中运行命令：sudo config --enable <configuration_option>。

配置选项
Sudo for Windows 提供三种配置模式，可通过设置界面或命令行切换：

1. 在新窗口中 (forceNewWindow)

   • 默认模式。命令在新开的管理员窗口中运行，新窗口继承原窗口的工作目录和环境变量。
   • 工作流程类似传统 runas 命令。

2. 关闭输入 (disableInput)

   • 在当前窗口运行提权进程，但关闭其标准输入（stdin）。适用于无需用户进一步交互的命令。
   • 安全性较高，因进程无法读取用户输入。

3. 内联 (normal)

   • 类似 Linux/macOS 的 sudo 行为。提权进程的标准输入、输出和错误流均连接到当前窗口，支持交互式操作。
   • 需注意安全风险：中等完整性进程可能操控高权限进程。

工作原理

• 运行 sudo 命令时，会弹出 UAC 对话框请求提权确认。
• 根据配置模式，sudo.exe 会启动提权进程：
  • 新窗口模式：直接新开管理员窗口执行命令。
  • 关闭输入/内联模式：通过 RPC 连接，将当前控制台句柄传递给提权进程。内联模式下提权进程可读写原窗口，而关闭输入模式则无法读取输入。
• 进程层级关系：未提权的 sudo.exe 与提权的 sudo.exe 建立连接，以实现数据转发。

安全提示

• 在内联配置下，需警惕中等级别进程对提权进程的控制风险。
• 关闭输入模式因阻断输入，安全性相对较高。

未来计划

• 微软将继续完善 Sudo for Windows 的文档，特别是内联配置的安全细节。
• 项目已开源，用户可在 GitHub 仓库提交反馈。

产品概述
CueCam Presenter 是一款专为Mac设计的应用程序，旨在提升在线会议的专业性和互动性。它兼容macOS 14+，并与Zoom、Microsoft Teams、Google Meet、Webex、OBS和Stream Deck等主流工具无缝集成。该工具通过简化技术操作，让用户专注于内容呈现，避免“能看到我的屏幕吗？”等常见问题。

主要功能

• 实时素描：在共享的幻灯片、网站、照片或空白板上直接绘图，增强观众参与度。
• 一键共享：将视频、图像或窗口保存到编号槽位，通过键盘数字键快速切换，无需手动操作屏幕共享。
• 虚拟绿幕摄像头：保持用户面部清晰可见，展示反应，而非仅显示幻灯片。
• 内置提词器：在查看摄像头的同时阅读脚本，并自动触发视觉内容，提升演讲流畅度。
• iPad集成：通过伴侣应用Video Pencil支持在iPad上绘图，扩展创作灵活性。

工作原理
设置过程分为三步：

1. 打开CueCam：在Zoom、Teams或Meet中将CueCam选为摄像头，无需插件。
2. 拖放内容：将视频、图像或窗口拖入槽位，使用编号键即时调用。
3. 绘图与演讲：实时在共享内容上绘图，让观众跟随想法演示，增强记忆点。

用户评价
多位教练、创作者和教育者反馈积极：

• 橄榄球教练Quincy Avery表示，该应用通过视频绘图提升了观众互动和观看量。
• 主持人和教练Neil Farrimond赞赏内置提词器功能，节省时间并保持演讲连贯。
• 培训师John Doorbar强调其易用性，相比OBS或Ecamm更专注于内容而非技术操作。
• 创作者Max J Miller喜欢屏幕绘图功能，使演示更即时有趣。
  此外，Video Pencil应用曾被知名足球运动员Harry Kane使用，体现了工具的高品质可靠性。

定价与可用性
CueCam采用租购模式，提供免费试用，并分三个层级：

• Connect（免费）：基础功能，如即时屏幕共享、iPhone作为摄像头和iPad绘图，但脚本带有水印。
• Essentials（$59.88/年，30%折扣）：包含Connect所有无水印功能，支持构建演示文稿、iPhone作为提词器、视频录制等。
• Suite（$119.88/年）：高级功能，如直播到YouTube/Twitch、Stream Deck插件、绿幕、多音频支持和开发者个人支持。
  学生和教师凭.edu/.ac邮箱可享70%折扣，团队有批量优惠。

兼容性与集成
除主流视频会议平台外，该工具还支持与OBS、Stream Deck等专业软件集成，并通过Video Pencil for iPad扩展绘图能力，适用于在线演示、教学和内容创作场景。

将 PostgreSQL 用作消息队列

核心优势

• 简化基础设施：避免了 Terraform 配置、多容器测试等复杂环节，降低了风险与维护成本。
• 减少技术依赖：仅需 Python 和 PostgreSQL 专业知识，无需引入额外的消息中间件（如 SNS、PubSub、Kafka）。
• 避免复杂机制：无需设计重试、死信队列等机制，也无需考虑数据序列化传输问题。
• 代码可读性高：在单体代码库中使用 ORM，避免了微服务架构中常见的代码跳转（CMD-clickability）问题。

对性能质疑的回应

• 主要反对意见：担心会增加数据库负载和行更新频率。
• 场景分析：文章以能源行业为例，模拟处理“客户提交电表读数”任务。对比传统消息队列与 PostgreSQL 队列的数据库操作耗时：
  • 传统方式：总耗时约 6.3ms（查询 + 更新 + ACK）。
  • PostgreSQL 队列方式：总耗时约 7.8ms（轮询状态更新 + 查询 + 更新 + ACK）。
• 结论：在许多场景下，额外开销很小。建议通过性能分析（profiling）实际评估，极端高并发场景需谨慎。

实现方案

• 表结构：事件表包含 id（UUID）、status（状态）、updated_at（时间戳），并为 (status, updated_at) 创建索引。每类队列使用独立表。
• 并发控制：使用 FOR UPDATE SKIP LOCKED 实现原子锁，避免多 worker 冲突。
• 轮询逻辑：
  1. Worker 循环查询待处理事件（status = TO_PROCESS），若无则休眠。
  2. 获取事件后更新状态为 PROCESSING。
  3. 执行任务，成功则更新为 PROCESSED，失败则更新为 ERRORED。
• 关键 SQL：

  WITH ids AS MATERIALIZED (
      SELECT id FROM event_queue
      WHERE status = 0  -- 待处理状态
      ORDER BY updated_at
      LIMIT 1
      FOR UPDATE SKIP LOCKED
  )
  UPDATE event_queue
  SET status = 1, updated_at = NOW()  -- 更新为处理中
  WHERE id = ANY(SELECT id FROM ids)
  RETURNING id;
  

  使用 MATERIALIZED 强制 CTE 提前执行，确保原子性。

附加功能

• 重试机制：定期扫描状态异常或超时的任务并重试。
• 延迟处理：增加 ignore_before 列，支持定时任务（如超时检测）或批量处理。
• 数据清理：通过定时任务删除历史队列数据。
• 优雅关闭：附录提供 ShutdownHandler 工具类，处理信号中断并设置超时自动终止。

总结

通过 PostgreSQL 实现消息队列能大幅简化技术栈，适用于中小型规模且数据库操作已占主导的场景。实现时需注意并发锁机制和状态管理，但整体复杂度远低于专用消息中间件。

LLRT: AWS低延迟JavaScript运行时

LLRT (Low Latency Runtime) 是AWS推出的轻量级JavaScript运行时，专为快速高效的无服务器(Serverless)应用设计。相较于运行在AWS Lambda上的其他JavaScript运行时，它能提供超过10倍的启动速度提升以及高达2倍的整体成本降低。

核心特点

• 构建与引擎: 使用 Rust 语言构建，底层采用 QuickJS 作为JavaScript引擎，确保高效的内存使用和快速的启动。
• 状态: 实验性软件包，仅用于评估，未来可能发生变更。
• 设计目标: 专为短生命周期的Serverless函数优化，不包含JIT(即时编译)编译器，从而减少启动时的计算和内存开销。

在AWS Lambda中的使用

提供了多种配置方式：

1. 自定义运行时 (推荐): 在Amazon Linux 2023上选择自定义运行时，将LLRT引导程序二进制文件与JS代码一起打包。
2. 使用Lambda层: 上传LLRT二进制zip文件作为层并添加到函数。
3. 打包到容器镜像: 在Dockerfile中包含LLRT二进制文件。
4. 通过AWS SAM或CDK部署: 提供了相应的构造库和示例。

兼容性与限制

• 非Node.js完全替代品: 虽然支持ES2023，但仅实现了部分Node.js API。许多模块仅部分支持或完全不支持（如cluster, http2, vm等）。
• 专有API: 提供了一些LLRT特有的API（如llrt:codec, llrt:xml）。
• 依赖管理: 强烈建议在部署前对依赖项进行打包、压缩和树摇(tree-shaking)。配置指南涵盖了ESBuild、Rollup和Webpack等工具。
• AWS SDK: 内置了优化过的AWS SDK v3客户端（针对性能进行了原生转换）。支持三种捆绑包类型：no-sdk、std-sdk和full-sdk，分别包含不同范围的SDK客户端。
• TypeScript: 必须预先编译为ES2023 JavaScript，运行时不会进行编译。

测试与验证

建议使用内置的测试运行器（支持类似Jest的API和Jest/Chai断言）来确保兼容性。测试类型包括：

• 单元测试: 隔离验证特定模块和函数。
• 端到端测试: 验证与AWS SDK和WinterTC规范的总体兼容性。
• Web平台测试: 验证与标准化浏览器API的兼容性。

构建与技术细节

• 从源码构建: 详细步骤包括克隆仓库、安装依赖（Rust、构建工具等）、使用make命令针对不同架构和捆绑包类型进行构建。
• 加密与TLS后端: 支持通过Cargo特性配置不同的加密（如RustCrypto, Ring, OpenSSL）和TLS后端。
• 环境变量: 提供了多个配置项，用于控制内存阈值(LLRT_GC_THRESHOLD_MB)、HTTP版本(LLRT_HTTP_VERSION)、日志级别(LLRT_LOG)、网络连接(LLRT_NET_ALLOW/DENY)、TLS版本(LLRT_TLS_VERSION)等。

设计理念与局限性

• 引入理由: 专为无服务器环境设计，避免了JIT的复杂性和开销，专注于降低启动延迟和资源消耗。
• 局限性: 在处理大量数据、模拟等需要数百万次迭代的任务时，性能可能不如基于JIT的运行时。它最适合数据转换、实时处理、AWS服务集成等小型无服务器函数。

基准测试方法

强调测量往返请求时间比仅使用Lambda报告的Init Duration更能全面反映面向用户的冷启动延迟。

许可与安全

• 根据 Apache-2.0 许可发布。
• 详细的安全信息请参阅项目贡献指南。

索尼关闭 Funimation 数字媒体库事件总结

事件背景

索尼旗下的动画流媒体平台 Funimation 宣布，其应用和网站将于 4 月 2 日关闭，并与同属索尼的 Crunchyroll 平台合并。届时，Funimation 账户将转为 Crunchyroll 账户，且大部分内容目录已迁移至 Crunchyroll。

核心问题：承诺的“永久”数字库失效

Funimation 曾发行附带数字兑换码的实体光盘（DVD/蓝光），用户将兑换码添加到平台后即可在线观看。Funimation 此前曾承诺，用户可“永远”保留并访问这些数字副本。

然而，Funimation 在公告中明确指出，Crunchyroll 目前不支持 Funimation 的数字副本。因此，平台合并后，这些曾承诺“永久可用”的数字副本将不再受支持，用户的数字媒体库将被清除。

对用户的影响

此举导致许多用户面临无法访问已购内容的困境。部分用户基于“永久访问”的承诺，可能已经处理了实体光盘，或缺乏相应的物理播放设备。随着数字库的关闭，他们将彻底失去这些媒体内容的访问权。

官方回应与退款政策

• 内容引导：Funimation 表示正持续提升内容服务，并鼓励用户转向探索 Crunchyroll 的动画库。
• 退款说明：对于退款问题，官方仅引导用户联系客服以根据支付方式查看可用选项，但并未提及是否会针对实体光盘（DVD/蓝光）的购买费用提供退款。

文章摘要：《为数学家准备的物理学——引言》

本文作者是一名数学家，记录了自己为理解量子场论和粒子物理标准模型所做努力的经历。系列文章旨在面向具有类似数学背景的读者，填补传统物理教材中因侧重物理问题求解而对数学背景读者造成的理解障碍。作者明确区分“纯数学”与“物理实质”的阐述，旨在帮助数学背景读者更清晰地把握物理内涵，同时避免将物理仅作为探讨数学的借口。

核心要点：

1. 目标与定位：面向有扎实数学基础但初涉理论物理的读者，强调理解物理学本质而非单纯解决问题。
2. 方法论：
   • 复用读者已有的高阶数学工具（如微分几何、泛函分析等），避免传统物理教材中常见的数学简化。
   • 清晰区分数学框架与物理假设/现象的对应关系。
3. 避免的误区：不流于仅展示有趣的数学形式，始终以阐明物理图像为目标。
4. 系列内容规划：涵盖从经典力学到现代理论物理的核心主题，结构递进：
   • 基础理论：哈密顿/拉格朗日力学、量子力学基础。
   • 数学工具专题：联络、G-丛、曲率与完整度等。
   • 经典物理重构：电磁学作为规范理论。
   • 统计物理：热力学与统计力学（附玩具模型）。
   • 量子理论进阶：路径积分表述、量子场论（自由场、相互作用场、散射、微扰论、费曼图、重整化）。
   • 引力理论：广义相对论及其拉格朗日表述。

系列文章目录：

1. 哈密顿与拉格朗日力学
2. 量子力学 I - 基础
3. 连接速成（附：G-丛、完整度与曲率）
4. 作为规范理论的电磁学
5. 热力学与统计力学（附：热力学行为的玩具模型）
6. 量子力学 II - 路径积分
7. 量子场论 I - 自由场
8. 量子场论 II - 相互作用场与散射
9. 广义相对论（附：广义相对论的拉格朗日方法）
10. 量子场论 III - 微扰论与费曼图
11. 量子场论 IV - 重整化

该系列致力于为数学背景读者架起通往现代物理理论的理解桥梁，通过重构物理概念的数学表述，凸显物理思想的本质。

J.G. Ballard：塑造我想象力的书籍

英国作家J.G. Ballard在其职业生涯晚期回顾了文学如何塑造其一生想象力的历程。

• 童年阅读的持久烙印：随着年龄增长，童年读物（如《金银岛》和《鲁滨逊漂流记》）的记忆变得异常鲜活，带来的情感冲击远超过近期阅读。这些故事已脱离书本，在其脑海中获得第二次生命。
• 青少年时期的密集阅读：在战后英国灰暗的氛围中，Ballard于十几岁时贪婪地阅读了从塞万提斯到卡夫卡、奥斯汀到加缪的大量经典作品，有时一天一本。这为其想象力奠定了基础，但他现在反思，这种在缺乏成人经验（如恋爱、谋生）时进行的密集阅读，可能实际上阻碍了他的成熟成长。他观察到，自己的子女更晚（大学后）才深入阅读经典，这让他们能以更成熟的心态去理解和欣赏。
• 上海童年与文化混合：Ballard的童年阅读深受其出生地上海这个多元文化大都会的影响。他同时接触《爱丽丝梦游仙境》等英国经典、《特里与海盗》等美国漫画以及《纽约客》等杂志，这些混合元素共同塑造了他最初的心理图景。
• 学校教育与恐惧的基调：学校的正规教育以枯燥的拉丁文为主。放学后，阅读替代了电视、电影等现代娱乐。他读了大量内容，但后来意识到其中缺失了对英国社会大多数人的描写。童年读物大多笼罩着一种令人恐惧或道德说教的氛围（如《水孩子》），但他认为正是这种怪异而非史蒂文森的冒险故事，更深刻地塑造了他的想象力。
• 集中营阅读与写作生涯：二战期间被日军拘押的经历，让他通过营中流通的流行小说接触了成人文学，并学会了“纯粹讲故事”的重要性。战后回到英国，他广泛阅读19至20世纪文学，与好莱坞电影、精神分析及超现实主义共同影响了他早期的短篇小说创作和决定学医的抉择。他坦言，大学时读《尤利西斯》曾让他困惑，可能延误了他的写作起步。
• 职业生涯与“隐形文学”：职业生涯开始后，他几乎停止了阅读，长期消化青少年时期的积累。晚年，他重新大量阅读，尤其是19-20世纪经典，并热衷于阅读科学期刊、技术手册、公司报告等“隐形文学”，认为这些是为想象力提供养分的沃土。
• 最爱的十本书（例举）：Ballard列出的最爱书籍并非公认的文学巨著，而是他近年重读最多的书，包括：
  • 纳撒尼尔·韦斯特的《蝗虫之日》
  • 海明威的《短篇小说全集》
  • 柯勒律治的《古舟子咏》
  • 马丁·加德纳注释的《爱丽丝漫游奇境记》
  • 帕特里克·特雷弗-罗珀的《通过模糊视力看世界》
  • 威廉·巴勒斯的《裸体午餐》
  • 马尔科姆·麦克弗森编的《黑匣子》
  • 《洛杉矶黄页》
  • 让·鲍德里亚的《美国》
  • 达利的《达利的秘密生活》

微型四旋翼无人机18秒学会飞行

核心突破：纽约大学敏捷机器人与感知实验室（ARPL）与技术创新研究院（TII）合作，开发了一种能在模拟器中仅用18秒就将四旋翼无人机从零训练至稳定飞行的系统。该训练过程甚至比将固件烧录到实体无人机的时间更短。

关键技术：

1. 高效的课程学习策略：研究人员设计了一个逐步调整强化学习奖励函数的“课程”。初期奖励较为宽松，随后逐渐增加惩罚以强调鲁棒性和可靠性，从而优化训练效率。
2. 软硬件优化：采用了高效的深度强化学习算法，并充分利用了苹果M系列处理器的硬件加速能力。模拟器的高效率与课程学习带来的样本效率相结合，共同实现了极速训练。

训练成果：

• 无人机不仅能够稳定悬停，还能抵抗外力干扰（如戳动、风力）。
• 能够执行特定的飞行轨迹。

适用性与开放性：

• 该方法不限于小型无人机，理论上适用于几乎所有无人机，包括大型或自定义机型。
• 所有相关代码（GitHub）和论文（ArXiv）均已开源，用户可自行构建无人机并应用此系统进行训练。

未来展望：

• 研究人员正在将系统与PX4开源自动驾驶仪集成。
• 长期目标是开发一个能够适应不同环境条件和不同飞行器配置的通用策略，使其可应用于各种飞行机器人。

气候科学家迈克尔·曼在持续12年的诽谤诉讼中胜诉，陪审团裁定两名保守派作家赔偿其100万美元。曼因其1998年在《自然》期刊发表的“曲棍球杆”图表（直观展示全球变暖趋势）而闻名，但其工作长期受到质疑。2012年，竞争企业研究所的兰德·西姆伯格在博客中将曼的数据分析比作宾州州立大学性侵案罪犯杰里·桑达斯基，另一作家马克·斯泰恩在《国家评论》转载该观点，称曼的研究为“欺诈”。

陪审团认定西姆伯格和斯泰恩作出虚假陈述且带有恶意，判处每人1美元补偿性赔偿，西姆伯格另付1000美元惩罚性赔偿，斯泰恩则需支付100万美元惩罚性赔偿。斯泰恩方面表示将上诉，认为赔偿金额需经正当程序审查；西姆伯格律师亦对判决表示失望。曼曾因文章失去研究资助，但辩方声称其并未遭受实际损失。

曼呼吁此案能遏制针对科学家的诽谤，并计划对2021年另一项未认定《国家评论》及竞争企业研究所侵权的判决提起上诉。此案反映了气候变化议题在美国的高度政治化分歧，学者与环保组织希望该判决能推动基于事实的公共讨论。法官在审理中强调，陪审团职责不包括判断全球变暖是否存在。

哈希表的最优时空平衡

70年前，IBM工程师Hans Peter Luhn提出哈希表这一数据结构，彻底改变了计算机科学。哈希表通过键值对存储信息，能以近乎恒定的时间快速查询、插入或删除数据，被广泛应用于各类计算系统。

核心矛盾 哈希表存在固有且不可避免的权衡：速度与空间的矛盾。更快的访问速度通常需要更多的内存（“浪费的比特”），而追求更小的空间占用则会降低操作速度。自1957年W. Wesley Peterson明确指出这一挑战以来，找到两者之间的最佳平衡一直是计算机科学的长期难题。

理论突破 2022年，以Michael Bender为首的团队在论文中首次提出了一种理论上极其高效的哈希表设计方案。其关键创新在于，它由一个主数据结构（存储物品本身，无任何浪费比特）和一个辅助数据结构（用于快速定位物品）构成。团队发现，通过不断将物品移动到其在主结构中更优（更偏好的）存储位置，可以大幅减少辅助结构所需的内存，而无需增加查询时间。这建立了一个前所未有的高效上界。

证明最优 2023年，以普林斯顿大学Huacheng Yu领导的团队，试图改进Bender方案但未能成功。他们转而从理论上证明，任何空间高效的哈希表都存在一个操作速度的下界。他们运用通信复杂性理论等工具，从第一性原理推导出数据结构在每次操作中必须访问内存的最少次数。计算结果表明，这个下界与Bender哈希表的性能完全吻合。这意味着Bender方案不仅是已知最佳，而且是理论上可能达到的极限，任何数据结构都无法超越。

意义与应用 这项历时数十年的研究终于给出了Peterson问题的终极答案，具有重大理论意义。其证明的通用性极强，适用于所有现存和未来可能被发明的数据结构。尽管该理论构造过于复杂，目前难以直接投入实际应用（理论常数在现实中至关重要），但它为工程实践指明了绝对上限。例如，受此启发的新型哈希表IcebergHT已实现速度与空间的显著改进。研究者们将此视为一个里程碑，使他们能将精力转向理论计算机科学中的其他新问题。

事件感知是认知过程，负责将连续的意识流划分为离散、有意义的事件单元。事件模型在工作记忆中表示当前事件，用于预测未来环境状态，从而支持行为规划。事件分割理论指出，当事件模型的预测与感官输入出现显著偏差时，会触发模型更新，形成事件边界，这标志着新事件的开始。

事件边界对记忆有双重影响。一方面，边界处的信息因注意力增强而记忆更牢；另一方面，门口效应表明，当人们穿过门口或改变环境时，容易忘记之前的想法或任务，这是因为事件边界导致工作记忆更新，前一事件的信息被丢弃。事件地平线模型解释了这种矛盾：边界通过因果网络促进记忆检索，但也会因竞争干扰导致遗忘。

事件记忆具有层次结构，从基本事件（如“准备早餐”）到更高级事件（如“晨间例行”）。记忆中的时间感知在边界处扭曲，跨事件的时间间隔被感知为更长。个体差异如衰老会影响事件感知，因为工作记忆和注意力下降，导致事件分割能力减弱，进而影响情节记忆。

总之，事件感知是动态过程，通过事件模型和边界塑造我们对世界的理解和记忆，门口效应是其典型例证。

斯宾诺莎与危险时代的思考艺术

时代背景与冲突

1668年，荷兰医生阿德里安·库尔巴赫因出版异端书籍，主张上帝非三位一体、耶稣仅为凡人、圣经非神圣经典等观点，被当局以亵渎罪判处十年监禁。他于一年后死于狱中。随后，巴鲁赫·斯宾诺莎匿名出版《神学政治论》，倡导思想自由与宗教宽容，尽管其真实身份很快被识破。该书在1674年被荷兰当局查禁，但斯宾诺莎本人因谨慎行事，避免了类似库尔巴赫的厄运。

斯宾诺莎的生平与思想核心

• 早年经历：1632年生于阿姆斯特丹犹太社区，后因异端观点于1656年被公开驱逐出犹太教。他选择过世俗生活，以磨镜片为生，形成了一套完整的哲学体系。
• 核心思想：
  • 泛神论：认为上帝是无限的实体，即自然本身（"上帝即自然"），否定传统宗教中超越自然的人格神。
  • 决定论：宇宙万物皆依自然法则运行，不存在脱离自然的自由意志。
  • 思想自由：强调“哲学自由”（libertas philosophandi），认为理性探索是通往幸福与正确理解上帝的途径。
  • 民主政体：在《神学政治论》中倡导民主制度，因其最能保障思想自由，引导人类以理性生活。

当代意义与思考策略

• 当代启示：作者伊恩·布鲁玛在《斯宾诺莎：自由的弥赛亚》中指出，斯宾诺莎对思想自由的坚持在当今意识形态对立、社交媒体施压的时代尤为重要。
• 谨慎与 boldness 的结合：斯宾诺莎以拉丁文写作（面向知识精英），避免直接挑衅公众；出版作品后即停止公开出版，将主要著作留待死后发表。其戒指刻有"Caute"（谨慎），体现了在危险时代中保护自身以延续思想的智慧。

结论

斯宾诺莎的思想奠定了“激进启蒙运动”的基础，影响了现代民主与世俗观念。他既勇于提出颠覆性观点，又善于通过谨慎策略避免迫害，为当代思考者在面对思想压制时提供了借鉴：在坚守理性与自由的同时，需注重自我保护，以持久地推动思想进步。

Elixir：2024年构建自助启动B2B SaaS的最佳语言

为什么Elixir能简化Web应用技术栈

传统全栈开发需要掌握过多技术（HTML、CSS、前端框架、后端语言、数据库、消息队列等），对单人团队不现实。Elixir通过三种方式大幅简化技术栈：

1. 移除技术层：Phoenix LiveView允许仅用后端代码构建类似SPA的前端交互，无需编写JavaScript或构建REST API，仅需少量代码实现实时更新和页面过渡。
2. 内置功能到平台：Erlang的BEAM虚拟机和OTP框架提供进程隔离、监督树（容错）、ETS内存缓存（替代Redis）、Phoenix PubSub（消息队列）等，减少外部依赖。
3. 利用已知工具：作业队列Oban基于PostgreSQL而非Redis，减少新技术学习；垂直扩展简单，避免分布式系统复杂性；测试可直接用ExUnit进行前端交互测试，无需浏览器自动化。

技术栈压缩对比

传统全栈需掌握约23项技术，Elixir方案仅需：

• Elixir（含容错、并发、缓存）
• Phoenix（含LiveView、PubSub）
• Oban（后台作业）
• PostgreSQL
• PaaS部署平台（如Dokku、Render）
• HTML、CSS、Tailwind

其他SaaS启动加速工具

1. Petal Pro框架：提供Stripe订阅集成、组织管理、管理后台、用户模拟等预制功能，节省约200小时开发时间。
2. OpenAPI规范生成器：可深度定制自动生成代码，优雅集成大型第三方API（如GitHub）。
3. 生态系统稳定性：Elixir和Phoenix版本升级平滑，维护成本低，多数用户使用近一年内版本。

适用场景

Elixir特别适合B2B SaaS的典型形态（管理后台、CRUD应用、电商平台），能以更少技术、更快开发速度构建可扩展应用。单人团队可借此聚焦业务开发，而非技术栈管理。

该文章标题为“雷克雅内斯半岛喷发”，但提供的实际内容仅为冰岛国家广播公司（Ríkisútvarpið ohf.）的机构信息，包括：

• 机构名称：Ríkisútvarpið ohf.
• 机构编号：600307-0450
• 地址：Efstaleiti 1, 103 Reykjavík
• 电话：515-3000（服务时间：周一至周五 8:30-14:00）

总结：
所提供的文本未包含任何与“雷克雅内斯半岛火山喷发”事件直接相关的内容，仅列出了冰岛国家广播公司的基本联系信息。因此，无法从当前内容中提取关于火山喷发的事件详情、时间、影响或相关报道。如需了解事件信息，需参考其他来源。

《山鹰报》：永不沉寂的新闻自由之声

核心事件：纵火与坚守

1974年8月1日深夜，位于肯塔基州怀茨堡的《山鹰报》办公室遭纵火焚毁。创始人汤姆·吉什和帕特·吉什在得知火灾后，尽管办公场所尽毁、珍贵的历史照片档案付之一炬，仍决心不缺席任何一期出版。汤姆含泪对员工承诺：“即便只剩一台打字机，也要在下周出版。”他们在废墟中发现了煤油浸染的信封，怀疑这是一场针对报社的报复性纵火。

报纸的创立与使命

汤姆和帕特于1956年接手《山鹰报》，将这份原本只刊登讣告和会议消息的社区小报，转变为深入揭露阿巴拉契亚地区问题的调查性媒体。他们扎根怀茨堡，全家投入办报工作。报纸重点关注当地经济支柱——煤矿业带来的问题，如露天开采对环境的破坏、矿工黑肺病、普遍贫困以及地方政府与煤矿公司的利益勾结。他们的报道引起了全国关注，甚至促使约翰·F·肯尼迪总统下令对贫困山区实施紧急援助。

对抗权势与威胁

吉什夫妇的报道触怒了当地由煤矿公司主导的权势集团。报社因此遭到广告抵制，被试图剥夺官方出版物的地位。1967年，一名拍摄山区贫困的纪录片导演因遭到地主反对而被枪杀，凸显了当地对外界审视的敌意。1970年代初，报纸因揭露县政府与煤矿公司秘密放宽卡车重量限制的协议，以及批评警方骚扰青少年（包括吉什夫妇的儿子本）而与当地警方关系紧张。在一次会议上，有人公开威胁要“烧毁《山鹰报》大楼”。

纵火案调查与审判

纵火案发生后，调查逐渐指向怀茨堡市警察约翰尼·考迪尔。两名受雇的年轻人承认，考迪尔付钱给他们去报社纵火。1975年，考迪尔受审并被陪审团定罪。然而，法官——本人拥有煤矿资产——仅判处其一年缓刑，考迪尔几乎未受实质惩罚。汤姆在下一头条写道：“猎杀《山鹰报》的季节到了。”外界认为，煤矿公司创造的敌意环境为此次袭击提供了土壤。

精神的传承与延续

纵火未能击垮《山鹰报》。汤姆和帕特于2004年获得职业记者协会终身成就奖。2005年，肯塔基大学设立“吉什奖”，以表彰他们在农村新闻事业中的勇气与正直。汤姆于2008年、帕特于2016年先后去世，他们的儿子本·吉什继承了主编职位，继续报道贫困、洪水和就业流失等问题。

现状与象征意义

如今，《山鹰报》仍在出版，但怀茨堡的煤矿经济早已衰落。2022年，当年的纵火犯约翰尼·考迪尔提交文件竞选怀茨堡市长。《山鹰报》如实报道：“考迪尔在1975年因纵火焚毁《山鹰报》办公室而被定罪。”随后，考迪尔默默退出了竞选。这一插曲印证了吉什家族的信念：告知新闻、服务社区、坚守正直——这正是《山鹰报》代代相传、永不沉寂的呐喊。

苹果已从App Store下架一款伪装成密码管理器LastPass的虚假应用。该应用由个人开发者“Parvati Patel”发布，复制了LastPass的品牌标识和用户界面，旨在迷惑用户。除发布者非LastPass所有者LogMeIn外，应用还存在多处拼写错误等欺诈迹象。

此事件引发对苹果App审核流程的质疑，因苹果曾以保障用户安全为由反对欧盟《数字市场法案》（DMA）等法规，称第三方应用商店可能带来欺诈与恶意软件风险。然而，此次威胁却出现在App Store内部。

应用情报提供商Appfigures的数据显示，该假冒应用于1月21日上架，存在约两周。虽然它利用关键词“LastPass”在搜索中排至第7位，但未进入任何排行榜，表明下载量有限。用户评论均为欺诈警告，许多消费者已察觉异常。

LastPass通过威胁情报、法律和工程团队协调应对，并公开发布博客警告用户。公司表示正与苹果沟通，了解该应用如何通过审核，并确认其图标、描述等均刻意模仿LastPass以针对其用户。

苹果在媒体曝光后下架了该应用，并禁止开发者参与苹果开发者计划，依据审核指南中关于“模仿应用”的条款处理。尽管影响范围有限，但LastPass指出，此类明显欺诈应用本不应通过审核。事件凸显了应用商店审核机制存在的漏洞。

文章标题：微控制器常用无线链路延迟基准测试

本文旨在通过实验评估各种常用微控制器无线模块和协议的延迟性能，以弥补现有资料在用户体验量化方面的不足。作者认为，除带宽、距离和功耗外，延迟是影响用户体验（如实时控制、传感器数据流）的关键指标。

测试聚焦于单向通信的响应性，采用“基准测试”方法，在半受控环境中使用逻辑分析仪（采样率100MS/s）精确测量从发送触发信号到接收端确认收到数据包的端到端延迟。测试涵盖了三种典型数据包大小（12字节、128字节、1024字节）。

在开始无线测试前，作者首先验证了软硬件配置对测量结果的影响：

• 软件影响：在STM32F429上测试显示，编译优化等级（-Os vs -O3）和框架选择（LL vs Arduino）会导致微秒级差异，但远小于通信传输时间。
• 硬件外设配置：以UART为例，对比了轮询、中断（IRQ）和DMA三种模式。DMA虽利于低功耗，但因需等待线路空闲检测，在短包低波特率测试中反而引入额外延迟（例如12字节@115200波特，理论耗时1041µs，实测1050µs）。这凸显了实现细节的重要性，尽管其影响通常被数据传输时间所主导。

无线测试结果摘要如下：

1. SiK (透明串口， FHSS)：实际延迟范围8ms至130ms，远高于理论计算。原因是其频率跳变（每120ms一次）与发送时隙（TDM）结合，数据包需缓存至下一个发送窗口。通过同步测试信号至发送窗口可获得9-15ms稳定延迟，但这非正常工作模式。
2. LoRa (长距离低功耗)：
   • 高速模式（250 kHz， SF7）：128字节实测延迟~100ms，与理论空中时间一致。
   • 长距离模式（64.5 kHz， SF11）：128字节实测延迟高达~5.4秒。结果高度可预测，体现了数据传输量对延迟的巨大影响。
3. nRF24 (2.4 GHz)：表现出色，延迟稳定且低。
   • 2 Mbps模式：12字节最低延迟~300µs，1024字节约23ms。
   • 256 kbps长距离模式：延迟增加约3-4倍，但增幅小于速率下降比例。
4. ESP-NOW (ESP32， 2.4 GHz)：单包传输稳定在5ms。发送1024字节（分5包）需24ms。启用长距离模式会略增延迟。
5. IEEE 802.15.4 (ESP32-C6， 2.4 GHz)：性能与nRF24的256kbps模式相当。12字节最低延迟~2.5ms，128字节约4.5ms。启用ACK对延迟影响微小。
6. 蓝牙经典串口 (SPP)：
   • HC-05模块：默认9600波特率延迟高。提高波特率至460800可改善，但存在~20ms固定开销和突发传输。
   • ESP32实现：性能优于HC-05，单包延迟更低（如12字节约9.5ms），大数据包差距更大。数据分块发送时，小块会导致更多拥塞和更高延迟。
7. 蓝牙低功耗 (BLE)：
   • ESP32 Bluedroid栈：单包延迟约9ms（服务端通知）或14ms（客户端写入）。结果分布与最小连接间隔（7.5ms）相关。NimBLE栈默认性能较差，需额外配置才能接近Bluedroid表现。
   • nRF52 (Nordic)：性能最佳，12字节最低延迟~3ms，1024字节约12ms。结果呈现与连接间隔相关的簇状分布。
8. WiFi (ESP32)：
   • 原始TCP/UDP套接字：经优化后（禁用Nagle算法、电源管理等），延迟可低至~3ms。
   • WebSockets：引入额外~6ms开销，但更易于应用层集成。
   • 高吞吐量使得数据包大小对延迟影响甚微。

关键结论与建议：

• 延迟表现：现代无线技术能实现优异的低延迟通信。nRF24在小包测试中延迟最低；BLE和WiFi能提供接近10ms以内的稳定延迟；长距离技术（LoRa, SiK）延迟较高是其设计权衡的结果。
• 选择依据：不能仅凭延迟选择模块，需综合权衡功耗、吞吐量、网络拓扑、开发难度等因素。默认配置通常偏保守。
• 开发体验：ESP32-C6（支持多协议）和Nordic nRF系列在易用性和文档方面受推荐。透明串口模块（如SiK, HC-05）是低功耗场景的简单选择。NimBLE（ESP32）的配置过程较为繁琐。
• 通用建议：若追求最低延迟和可控性，可考虑专用无线协议栈。软件优化（如禁用Nagle、调整连接参数）很重要，但硬件能力（如MTU大小、空中速率）是基础。务必使用示波器或抓包工具进行实际验证。

测试表明，为项目选择“最佳”无线模块是一个涉及多维度的工程决策，延迟是其中一个可被精确量化的重要参数。

假LastPass密码管理器惊现Apple App Store

LastPass近日发出警告，提醒用户注意一个冒充其正版应用的假应用正在Apple App Store上分发。该应用极有可能被用作钓鱼软件，旨在窃取用户的凭证信息。

这个假应用在设计和命名上极力模仿正版：

• 名称：使用“LassPass”而非“LastPass”，仅有一个字母之差。
• 界面：采用与正版品牌相似的红色主题界面和图标。
• 发布者：显示为“Parvati Patel”，而非法人实体。
• 评分与评论：仅获得1个评分和4条评论，且评论中明确警告其为假冒应用（正版LastPass拥有超过5.2万条评分）。

由于LastPass用于存储极为敏感的认证信息（如用户名、邮箱和密码），此应用很可能是一个旨在窃取这些凭证的钓鱼工具。目前，媒体尚未测试该应用的具体运作机制。

LastPass的应对措施 正版LastPass已在其官方网站发布警报，提醒用户注意数据丢失风险。公司表示正在积极采取行动，争取尽快将该欺诈应用下架，并将持续监控针对其应用的仿冒行为。

苹果的处理与罕见漏洞 虽然Apple App Store拥有包括自动检查和人工审核在内的严格审查流程，以确保应用符合高标准的隐私、安全和内容规范，但此类明显的欺诈应用能通过审核实属罕见。尽管苹果通常会在发现违规应用后迅速将其下架并禁止开发者，但在该报道发布时，该假LastPass应用仍可供下载。

事件后续

• 该开发者账户中存在另一款看似合法的应用，因此其账户可能已被恶意行为者劫持。
• 苹果公司随后确认，该欺诈应用因违反其《审查指南》中关于“山寨应用”的条款已被下架，该应用开发者也已从苹果开发者计划中移除。
• 苹果同时表示，他们收到了来自LastPass的商标争议，并重申了其为开发者设立的内容争议处理流程。

给用户的建议

• 立即行动：如果已安装了这款假应用，请立即删除。
• 更改密码：立即登录 lastpass.com 更改您的主密码。
• 重置所有密码：建议您重置所有存储在LastPass密码库中的密码，以确保绝对安全。

基础设施决策回顾与总结

本文作者回顾了其在一家快速扩张的初创公司负责基础设施四年间做出的关键决策，并评估了这些决策的成效。

云服务商与核心AWS服务

• 选择AWS而非Google Cloud 🟩 推荐：主要因AWS客户支持更佳、服务稳定性好，且API变更向后兼容性好。GCP在Kubernetes集成上的早期优势已减弱。
• 使用EKS管理Kubernetes集群 🟩 推荐：避免自行管理控制平面，且Kubernetes生态（如external-dns）已能良好集成AWS服务。
• EKS托管插件 🟧 后悔：因需频繁定制配置（如CPU请求、镜像标签），后改用Helm图表管理，更契合GitOps流程。
• 使用RDS托管数据库 🟩 推荐：数据至关重要，托管服务的溢价是值得的。
• 使用Redis ElastiCache 🟩 推荐：Redis作为缓存和通用快速数据工具表现优异、文档完善。
• 使用ECR容器镜像仓库 🟩 推荐：从quay.io迁移后稳定性提升，且与EKS等权限集成更深。
• 使用AWS VPN 🟩 推荐：与Okta集成，设置简单，满足安全访问需求。
• AWS高级支持 🟧 后悔：成本高昂，相当于一名工程师的薪资，若内部AWS知识不足则可能值得。
• 使用Control Tower账户工厂（AFT） 🟩 推荐：简化了账户创建自动化和标签标准化。
• 不使用Terraform Cloud 🟩 无悔：成本难以 justify，改用Atlantis及自定义CI/CD自动化作为补充。

流程与运营

• 用Slack机器人自动化事后复盘流程 🟩 推荐：以机器方式推动流程，减轻人力督促压力。
• 使用Notion作为文档中心 🟩 推荐：其数据库概念便于组织文档，优于传统Wiki或Google Docs。
• 使用Slack作为默认沟通工具 🟩 推荐：并建议善用线程、设定响应预期、鼓励使用公共频道。
• 从JIRA迁移至Linear 🟩 推荐：Linear更轻量、直观，功能满足需求。
• 每月成本跟踪会议 🟩 推荐：联合财务与工程团队定期审视所有SaaS账单，按标签、账户等维度分析成本动因。
• 未更多采用函数即服务（FaaS） 🟩 后悔：除GPU负载外，许多CPU工作负载适合FaaS。Lambda在成本追踪精度和避免过度配置方面有优势。
• GitOps作为基础设施管理范式 🟩 推荐：灵活性高，虽需额外工具辅助状态查询，但仍强烈推荐。
• 优先保证团队效率，而非一味响应外部需求 🟩 推荐：投资自动化和文档化，以提升长期效率。
• 多个应用共享数据库 🟩 后悔：会导致所有权不清、清理困难、性能问题调试复杂，最终成为无人妥善维护的基础设施问题。
• 未早期采用身份平台 🟩 后悔：初期使用Google Workspace群组管理权限灵活性不足，应尽早引入Okta等专用身份解决方案。
• 使用PagerDuty进行告警管理 🟩 推荐：性价比高。并建立了分级告警（关键/非关键）和定期告警审查会议制度。

软件与工具选型

• 使用Diff进行数据库Schema迁移 🟧 部分推荐：将完整Schema存入Git并生成同步SQL，虽属“可怕”方案中较满意的一种。
• 开发服务器使用Ubuntu 🟩 推荐：避免为与生产环境一致而强行使用EKS基础OS，Ubuntu支持好、软件丰富。
• 使用AppSmith构建内部工具 🟩 推荐：自托管方案，为工程师提供简单UI以执行内部操作脚本，性价比高。
• 使用Helm（v3） 🟩 推荐：作为打包和部署Kubernetes对象的工具尚可，模板语言强大但调试较难。
• 将Helm图表存储在ECR（OCI格式） 🟩 推荐：替代了需安装插件的S3存储方式，更简洁。
• 使用Bazel 🟧 不确定：对于Go服务可能过于复杂，学习曲线陡峭。
• 未早期采用OpenTelemetry 🟩 后悔：初期直接使用Datadog API埋点，后期难以替换。建议从开始就采用OpenTelemetry进行可观测性数据收集。
• 选择Renovatebot而非Dependabot 🟩 推荐：自定义灵活性强，但设置和调试非常复杂。
• 使用Kubernetes 🟩 推荐：用于托管长期运行服务，社区与AWS集成良好。但系统灵活性高，也易用错。
• 购买自有IP地址段 🟩 推荐：便于向外部合作伙伴提供固定的IP白名单范围。
• 为Kubernetes GitOps选择Flux 🟩 无悔：从v1用到v2，运行良好。听说ArgoCD也不错。
• 使用Karpenter进行节点管理 🟩 推荐：比其他自动扩缩器（如Kubernetes默认自动扩缩器、SpotInst）更可靠、更经济。
• 使用SealedSecrets管理K8s秘钥 🟩 后悔：对开发者复杂，且失去了AWS原生的秘钥轮换等自动化功能。
• 使用ExternalSecrets管理K8s秘钥 🟩 推荐：同步AWS秘钥到Kubernetes，流程简单，利于利用Terraform和AWS控制台。
• 使用ExternalDNS 🟩 推荐：同步Kubernetes服务到Route53 DNS记录，稳定可靠。
• 使用cert-manager管理SSL证书 🟩 推荐：配置直观，与Let’s Encrypt配合良好。
• EKS节点使用Bottlerocket OS 🟩 后悔：遇到网络CSI问题且调试困难，后改用EKS优化AMI。
• 选择Terraform而非CloudFormation 🟩 推荐：作为基础设施即代码工具，Terraform易扩展、语法更清晰。
• 不使用Pulumi等代码化IaC方案 🟩 无悔：认为Terraform的声明式语言（HCL）的局限性反而是优点，降低了复杂性。
• 不使用服务网格（如Istio/Linkerd） 🟩 无悔：认为其复杂度被低估，坚持“少即是多”的原则。
• EKS入口使用Nginx负载均衡器 🟩 无悔：经典、稳定、久经考验。
• 使用Homebrew分发公司脚本 🟩 推荐：便于向macOS和Linux工程师分发脚本和二进制文件。
• 服务端语言选择Go 🟩 推荐：易于新手工程师上手，是网络IO密集型非GPU服务的理想默认选择。

富人付费插队服务正从机场安检、滑雪场缆车延伸到约会软件等各类场景，打破了传统排队伦理。借助移动支付等新技术，商家将“插队权”转化为盈利产品：Clear会员（189美元/年）可被护送至机场安检队列前端；Tinder推出499美元/月会员以优先展示用户资料；Snowbird等滑雪场提供额外收费的快速通道；环球影城和迪士尼等主题公园也推出109美元起的快速通行证。

这种趋势背后是商业对消费分层的追逐。疫情期间，富人甚至通过高价优先接种新冠疫苗。传统VIP服务（如头等舱）曾侧重体验差异，而如今付费插队直接影响核心服务效率——付费滑雪者可能多滑数趟，付费游客可免去88分钟排队等待。

然而该模式引发广泛争议。一万三千人联名反对滑雪场“为富人合法插队”，美国参议员罗恩·怀登指出这会加剧公共资源获取的公平问题。宾夕法尼亚大学教授加德·阿隆指出，目睹他人插队会加重普通顾客的 frustration，而将高付费用户从队伍中移除后，企业缺乏动力改善大众服务——这些原本最有议价能力的客户不再能推动整体服务提升。

加拿大政府召开打击汽车盗窃全国峰会，多部门协同推出综合性应对措施。

主要机构行动：

• 加拿大边境服务局：增加投资2800万加元，用于扩大被盗车辆调查与检查能力，加强国内外情报共享与合作，并探索人工智能等高级检测技术。
• 皇家加拿大骑警：负责协调联邦、省、市警察间的刑事情报共享与分析，利用边境执法能力识别跨境威胁，并与国际执法机构保持紧密合作。
• 司法部：将与省、领土协商，审查《刑法典》中有关汽车盗窃的现有罪行和处罚，考虑修订以强化法律框架。
• 交通部：将更新《加拿大机动车安全标准》，以纳入技术进步来防盗；对港口设施进行安全评估以识别货运漏洞，并制定改进方案。
• 创新科学和经济发展部：将与汽车业界合作开发防盗和车辆寻回的新方案；重点是，将采取一切途径禁止用于通过复制无钥匙进入系统信号来盗车的设备（如Flipper Zero），并与执法部门合作将此类设备清除出加拿大市场。

核心目标： 通过加强边境执法、情报共享、法律审查、标准更新和行业合作，全面提升对汽车盗窃，特别是其与有组织犯罪关联的打击能力，并明确从技术源头禁用盗窃工具。

关于OpenPOWER关注度的讨论

文章基于Hacker News的提问帖，探讨了为何OpenPOWER平台在技术层面具备显著优势却未获得类似RISC-V的广泛社区关注。

核心观点

1. 技术优势与现状

   • OpenPOWER在理论上提供完全开放的固件控制（包括CPU微代码），允许深度安全审计和定制。
   • 以Raptor Computing的Talos II工作站为例，其拥有高性能且完全开放的计算平台。
   • 相比之下，RISC-V虽引起广泛讨论，但其实际高端硬件实现较少。

2. 不受欢迎的可能原因

   • 成本高昂：OpenPOWER硬件（如Talos系统）价格远高于主流x86或ARM设备，限制了普通用户和开发者采用。
   • 生态系统薄弱：软件兼容性、驱动支持和开发工具链远不如x86或RISC-V成熟。
   • 市场定位狭窄：主要面向企业服务器和特定专业领域，缺乏消费级应用和推广。
   • 社区活跃度低：相比RISC-V的开源社区和大量业余项目，OpenPOWER的爱好者群体较小。
   • 架构差异：Power架构历史悠久，虽在IBM服务器领域成功，但未向低功耗或嵌入式领域有效扩展。

3. 与RISC-V的对比

   • RISC-V的模块化设计和免费许可降低了入门门槛，吸引了大量学术研究和初创企业。
   • OpenPOWER虽开放，但背后仍由IBM等大公司主导，社区自主权感知较低。

总结

讨论指出，OpenPOWER在技术开放性和性能上确有优势，但其市场渗透受限于成本、生态系统不完善以及缺乏广泛的社区推动。当前关注点更多集中在RISC-V和ARM等更具可及性和活力的开放架构上。

热泵销量在2023年超越燃气炉

背景与现状

• 美国住宅是主要污染源：若将全美住宅视为一个国家，其温室气体排放量将位居全球第六，每年排放约十亿吨温室气体，超过伊朗、德国和韩国的总排放量。
• 要实现家庭脱碳，未来几十年内需将6600万台化石燃料供暖系统替换为热泵。

销售数据与趋势

• 根据暖通空调（HVAC）行业主要贸易组织的数据，热泵销量已连续两年超过燃气炉，2023年领先幅度达27%。
• 过去两年间，热泵的安装量比燃气炉多出100万台。
• 尽管受高利率、通胀和供应链问题影响，2023年HVAC设备总销量下降，但热泵与燃气炉之间的销量差距持续扩大。这一差距越大，家庭碳排放下降的速度就越快。

热泵销量增长的原因

文章指出，热泵销量超越燃气炉是多种因素共同作用的结果，主要包括五个相互关联的驱动因素，这些因素正在改变美国家庭供暖和制冷的方式。

（注：摘要严格基于原文内容，未包含原文中未详细展开的五个具体原因的细节。）

《置换城市》是格雷格·伊根创作的一部科幻小说。其核心内容简介如下：主人公保罗·达勒姆不断创建自身的软件副本（即模拟其大脑和身体的“副本”），并将其置于虚拟现实中运行，但运行速度比真实世界慢17倍。他希望通过这些副本进行关于人工智能、时间和因果关系本质的实验，然而副本们却常常改变主意并自行关闭。玛丽亚·德卢卡则沉迷于一个名为“自动宇宙”的细胞自动机虚拟世界，它遵循一套简单的数学规则作为其“物理定律”。尽管玛丽亚失业且经济拮据，她仍无法停止在这个虚拟世界中投入时间。保罗向她提供了一个奇特的提议：设计一个能够在“自动宇宙”中存在、并能生长繁衍的整个虚拟生物圈的种子，该生物圈的建模需深入到分子层面。这份工作报酬丰厚，也能满足玛丽亚的痴迷。但其中暗含一个难题：这样的种子若没有一个足够庞大的“自动宇宙”模拟环境来支持生物圈的生长，将毫无用处——而所需模拟规模远远超出了全世界所有计算机的能力。

小说的出版历史十分丰富，自1994年首次由英国Orion/Millennium出版社出版以来，已被翻译成德、法、意、西、日、捷克、波兰、俄、中等多种语言，并在多个国家以不同版本出版，包括精装本、平装本及电子书。中文版计划于2024年由Dook出版社出版。

本文揭露了风投公司a16z通过关联企业批量购买其合伙人Chris Dixon的新书《Read Write Own》，从而将其推上《纽约时报》非虚构类畅销书榜单第9位的操作。

文章指出，《纽约时报》畅销书榜单并非纯粹依据销量，其算法不透明，且长期存在通过批量订购来“操纵”排名的漏洞。Dixon的新书榜单位置旁标有“†”符号，表明其销量统计中包含了批量购买。

具体操作涉及a16z的关联公司。a16z投资的加密公司Syndicate公开表示为其团队购买了该书；加密投资公司Electric Capital则购买了1401册用于赠书，其创始人称这是对Dixon贡献的感谢。a16z自身也向员工分发了该书，但其发言人声称这些员工用书可能未被《纽约时报》计入销量。

《纽约时报》发言人表示，榜单编辑有权根据内部审计标准决定是否将批量购买纳入统计。文章同时提及，此类操纵榜单的行为在政治等领域亦有先例。《纽约时报》曾因批量购买问题直接取消书籍上榜资格，但此次Dixon的书未被取消，并引发了对于榜单公正性的质疑。

这篇文章介绍了将 DPS8M Multics 模拟器成功移植到 IBM i (原AS/400) 平台，通过 IBM PASE for i 环境运行，实现了在IBM Power Systems硬件上同时运行多个Multics实例与关键任务AIX及IBM i工作负载。

背景与历史

• IBM i 平台源自1969年的IBM System/3，经历System/32、System/34、System/38和System/36等型号，于1988年整合为 AS/400。其采用独特的分层架构（TIMI），实现了软件与硬件的隔离，保障了应用程序的长期兼容性。
• 平台后续演变为iSeries、System i，并最终更名为 IBM i，运行于现代的 IBM Power Systems (如POWER10) 硬件上，以高可靠性著称。

移植技术与实现

• 移植基于 IBM PASE for i，这是一个支持AIX应用程序二进制接口（ABI）的运行时环境，允许大多数AIX二进制文件在IBM i上直接运行，并能获得接近原生的性能。
• 开发者最初评估了使用 ILE C/C++ 进行本地移植的方案，但考虑到PASE与AIX的高度兼容性、移植的便捷性以及性能因素，最终选择了PASE方案。
• 移植主要工作包括适配DPS8M源码和构建流程，以应对PASE与AIX在底层操作系统功能（如线程、文件系统、内存管理）上的差异。因此，需要专门为IBM i构建二进制文件，而非提供一个通用的AIX/IBM i二进制包。
• 依赖库处理：
  • libuv：通过IBM提供的RPM包安装，已成功支持。
  • decNumber：高度可移植，PASE环境已内置。
  • libsir：需要进行修改，相关代码已在当前版本中。
  • libbacktrace：在PASE环境下目前无法工作，但非关键问题。

开发体验与平台印象

• 在PASE环境中的开发与调试体验总体良好，提供AIX风格的dbx和gdb调试器，以及基于Java的IBM i专用调试工具。
• 经典的 5250 终端界面 提供了高效的实时调试工具（如查看调用栈、线程状态）和基础的文本编辑器（EDTF），在连接不佳时仍能保持响应。
• 作者对IBM i平台表达了积极的看法，认为其不仅稳定可靠，并且通过PASE为开源软件（如DPS8M）提供了良好的支持。

总结与展望

• 该移植成果展示了DPS8M模拟器的良好兼容性与IBM PASE for i环境的强大能力。
• 提供了实验性构建版本的下载（针对IBM i 7.5和POWER9处理器）。
• 此举使得在同时运行业务关键的IBM i工作负载的现代IBM Power服务器上运行历史性的Multics操作系统成为可能。

• 首次突破关键阈值：欧盟哥白尼气候变化服务局（C3S）数据显示，2023年2月至2024年1月的12个月内，全球平均气温比1850-1900年工业化前平均水平高1.52°C，这是有记录以来首次全年超过1.5°C的长期气候目标阈值。
• 近期持续创纪录：2024年1月成为有记录以来最热的1月，平均地表温度达13.14°C，比1991-2020年平均值高0.7°C。此前2023年已被确认为史上最热年份，且2024年1月之前的连续七个月均打破同期高温纪录。
• 与《巴黎协定》的关系：该数据不直接违反《巴黎协定》，因协定针对的是20-30年长期平均温度，而非单一年份。但科学家强调，这凸显了人类减少温室气体排放的窗口期正在迅速缩小。
• 气候风险警示：超过1.5°C阈值会增加触发“临界点”的风险，可能导致地球系统发生重大且不可逆的变化。联合国指出，全球已升温约1.1°C，加剧了全球极端天气事件。
• 科学界呼吁行动：研究人员称此结果为“重要里程碑”，并警告这凸显了迅速减少温室气体排放的紧迫性，以避免更严重的气候危机。