苹果发布 M4 芯片

苹果公司于2024年5月7日宣布推出 M4 芯片。这是一款为全新 iPad Pro 设计的系统级芯片（SoC），旨在提供卓越的性能与能效。

核心技术规格

• 制程工艺：采用第二代 3 纳米技术打造。
• CPU：配备多达 10 核心 的全新中央处理器。
• GPU：搭载 10 核心图形处理器，基于 M3 引入的新一代 GPU 架构，并首次为 iPad 带来了 动态缓存、硬件加速光线追踪和硬件加速网格着色 技术。
• 显示引擎：内置全新显示引擎，用于驱动 iPad Pro 上突破性的 超视网膜 XDR 显示屏，提供精准的色彩与亮度。
• 神经网络引擎：搭载苹果迄今最快的神经网络引擎，运算速度可达每秒 38 万亿次操作，速度超越当前任何 AI PC 的神经网络处理单元。
• 内存与加速器：具备更快的内存带宽，以及 CPU 中的下一代机器学习加速器。

性能与优势

M4 芯片延续了苹果硅的行业领先能效，支撑了 iPad Pro 极致纤薄的设计。结合高性能 GPU 和强大的神经网络引擎，该芯片使新款 iPad Pro 成为处理人工智能任务的强力设备。

注：文中提及的性能对比数据均基于苹果公司在2024年3月至4月进行的测试，使用了特定的预生产设备和行业标准基准。

超声波技术实现3分钟冷萃咖啡

传统冷萃的局限

传统冷萃咖啡口感顺滑、酸度低、苦味轻，但制作需12至24小时的长时间浸泡，无法满足快速获取咖啡因的需求。

新技术原理

新南威尔士大学（UNSW）工程师团队开发了利用声空化加速冷萃过程的方法。他们改装了现有的Breville意式咖啡机，通过螺栓夹紧的换能器连接金属喇叭与滤篮，将标准滤篮转变为超声波反应器。该系统以38.8kHz频率通过多个点向反应器壁注入声波，在反应器内部产生多个声空化区域。

工作原理与效果

• 声空化作用：声波产生的空化气泡在崩溃时会产生微射流，冲击并破碎咖啡粉，显著加速油脂、风味和香气的提取。
• 效率提升：提取时间从12-24小时缩短至不到3分钟。
• 提取率提高：与未经超声处理的样本相比，提取率和咖啡因浓度翻倍。

感官评估结果

昆士兰大学对样本进行了感官分析，比较了：

• 1分钟超声处理样本（室温）
• 3分钟超声处理样本
• 传统24小时冷萃样本（4°C浸泡）

评估结果显示：

• 1分钟样本在风味、余味（包括苦味、酸味、饱满口感）和香气上与24小时冷萃相似，但香气强度和黑巧克力香气略低。
• 3分钟样本的黑巧克力香气和香气强度与24小时冷萃相当，但苦味略高。
• 研究表明，1至3分钟的超声处理时间可制得与24小时冷萃相当的咖啡。

应用前景

• 家用咖啡机：该技术可集成到现有意式咖啡机中，让家庭用户快速制作冷萃。
• 商业场所：咖啡馆和餐厅可按需制作冷萃，无需大型半工业酿造设备及大量冷藏空间。
• 其他领域：超声波技术还可应用于茶饮制作，以及食品工业中的干燥、提取、乳化和结晶等过程。

总结

该技术通过声空化原理，在保持冷萃咖啡口感特征的同时，将制作时间从小时级缩短至分钟级，为家庭和商业咖啡制作提供了高效、便捷的新方案。

Pyspread – 基于Python的非传统电子表格

Pyspread是一款使用Python编程语言编写的非传统电子表格应用，其目标是成为最符合Python风格的电子表格。它的核心特点是单元格内接受Python表达式，从而取代了传统的电子表格专用语言。每个单元格都会返回一个Python对象（如列表、矩阵等），这些对象可以从其他单元格中访问和调用。

Pyspread是免费软件，依据GPL v3许可证发布。最新版本为v2.4.5，要求Python 3.6或更高版本。已停止更新的v1.1.3版本仍兼容Python 2.x。

主要功能

• 单元格支持Python代码并返回Python对象。
• 可在单元格内调用Python模块（如NumPy）。
• 支持导入CSV、SVG、XLSX格式。
• 支持导出CSV、SVG、PDF（通过打印到文件）。
• 单元格可显示文本、标记、图像、日期或图表。
• 支持生成Matplotlib和R图表（通过对话框支持plotnine及R的graphics、lattice、ggplot2等包）。
• 具备拼写检查功能。
• 使用git友好的pysu文件格式保存，并基于blake2b的签名防止外部代码执行。

目标用户群 Pyspread的核心功能要求用户直接在网格中使用Python代码，因此其目标用户是拥有Python经验或希望学习该语言的人群。

• 适合的用户：例如研究工程师Clara，她熟练使用Python进行科学分析，可利用Pyspread快速比较不同参数集的结果，进行初步数据探索。又如商业分析师Peter，他将数据与代码分离，通过Pyspread调用CSV文件和导入专用货币数据类型（如py-moneyed）来避免浮点错误，并导入包含单元测试的分析模块，以提高计算可靠性。

• 不适合的用户：例如希望寻找免费Excel替代品且不懂编程的用户（如Donna），可能会觉得学习曲线陡峭。又如需要进行计算密集型分析、期望电子表格能原生支持并行计算（如集群或云方案）的用户（如Jack），可能会因Pyspread需要手动管理长时间运行任务以避免界面卡顿而感到失望。

支持与参与 用户问题或反馈可通过指定的Delta Chat频道获取。关于贡献、补丁和开发讨论，建议使用Pyspread的问题跟踪器提交议题。

Zed 编辑器 Linux 版本进展

现状概览：Zed 编辑器于今年一月底开源时暂不支持 Linux。三个月后，Linux 版本已可编译运行，并达到可日常使用的稳定度，距离“Alpha 版本”发布已临近。

技术挑战与实现：

• 跨平台架构：Zed 使用 Rust 开发，追求各平台原生体验，因此通过自研框架 GPUI 实现跨平台。GPUI 定义了 Platform trait，为各系统提供统一抽象。
• Linux 适配：核心工作是实现 Linux 的 Platform trait，包括窗口管理、剪贴板、文件对话框等。二月时仍有大量方法未实现（todo! 或 unimplemented!），目前仅余少数待完成。
• 渲染方案：Linux 下通过 Blade 库（基于 Vulkan）与 GPU 通信，替代 macOS 的 Metal。社区贡献者 @kvark 在开源后两周内提交关键 PR，实现了基础渲染。
• 系统兼容性：需同时支持 X11 和 Wayland 显示服务器，以及不同桌面环境（如 GNOME、KDE）。封装方面暂以 .tar.gz 形式分发，暂未深入各发行版专用包格式。

社区贡献： 开源社区推动 Linux 版本快速发展，主要贡献包括：

• @kvark：实现 Blade 渲染集成。
• @witelokk：添加 Wayland 支持。
• @romgrk：实现文件对话框。
• @apricotbucket28 等众多开发者修复滚动、选择等功能。 项目负责人 Mikayla 负责统筹代码审查与管理。

当前状态与未来计划：

• 剩余工作：仍需修复约 86 项待办任务，包括 Wayland 窗口调整、系统对话框实现等。
• Alpha 版本后：需添加音频通话、拖放操作、凭据存储等功能，并持续优化性能与稳定性。
• 长期挑战：Linux 生态碎片化（如包管理、剪贴板机制、桌面环境差异）将持续带来适配工作。

尝试体验：目前可通过编译源代码在 Linux 上运行 Zed，需配置 Rust 环境及依赖项。详细指引见官方说明。

微软关闭多家Bethesda附属游戏工作室

微软（Xbox）宣布关闭其旗下的多家Bethesda游戏工作室，作为其业务“重组”的一部分。具体变动如下：

关闭的工作室：

• Arkane Austin：曾开发《红霞岛》（Redfall）。该工作室关闭，部分成员将加入其他工作室。《红霞岛》将停止所有后续开发，包括已承诺的离线模式和新角色DLC。游戏服务器将保持在线，微软将为购买过“英雄DLC”的玩家提供补偿。
• Tango Gameworks：曾开发《Hi-Fi Rush》和《恶灵附身》系列。该工作室关闭。《Hi-Fi Rush》将保留在现有平台上。
• Alpha Dog Games：曾开发手游《Mighty Doom》。该工作室关闭，游戏将于2024年8月7日停运。

工作室调整：

• Roundhouse Games：将被并入《上古卷轴Online》开发商ZeniMax Online Studios。

未受影响的工作室：

• Arkane Lyon（正在开发《刀锋战士》游戏）
• Bethesda Game Studios（《辐射》、《上古卷轴》、《星空》系列开发商）
• MachineGames（《夺宝奇兵：大圆环》开发商）
• id Software（《毁灭战士》系列开发商）

裁员与官方解释： 微软未透露具体裁员人数，但表示将有大量员工受到影响。Xbox工作室负责人Matt Booty在内部邮件中称，此次变动源于“游戏与资源优先级的重新调整”，旨在专注于高影响力的游戏系列，并加大对Bethesda旗下“巨型IP”的投资。邮件表示，解散团队是为了“腾出能力”以增加对其他产品组合和重点游戏的投资。

行业背景与反应：

• 此次裁员发生在微软于2024年1月宣布裁员1900名游戏部门员工之后，且正值游戏行业大规模裁员浪潮。
• 此举令人意外，尤其是Tango Gameworks在《Hi-Fi Rush》获得广泛好评后仅一年多便被关闭。此前微软曾称赞该游戏是“全方位的成功”。
• Arkane Lyon工作室负责人Dinga Bakaba公开批评了这一决定，称其“绝对糟糕”，并提醒高管，游戏是娱乐/文化产业，公司应照顾好旗下艺术家。他的言论反映了工作室内部对裁员的不满。

总结： 微软以战略重组和聚焦重点IP为由，关闭了数家Bethesda工作室，导致大量裁员，并停止了《红霞岛》的更新。此举是近期游戏行业持续裁员潮的一部分，并引发了开发者社群的批评。

Caniwebview.com 网站摘要

这是一个专为WebView兼容性设计的查询工具，类似于“Can I Use”，旨在帮助开发者比较不同WebView环境对Web功能的支持情况。

核心功能与结构：

• 比较界面：网站的核心是一个交互式表格，允许开发者对比多个主流WebView环境对特定Web功能的支持状态。
• 支持的WebView环境：包括覆盖多个操作系统和平台的引擎，主要有：
  • WKWebView (macOS, iOS)
  • Android WebView (Android)
  • WebView2 (Windows)
  • WPE MiniBrowser (Linux)
  • Servo (Android)
  • Chrome Browser (Android)
  • Safari Browser (macOS, iOS)
• 功能与新闻：
  • 最新功能：网站追踪并列出最新的Web特性支持情况，示例包括Zstandard压缩、zoom、z-index、XSLT、XPath等。
  • 新闻动态：发布与WebView开发相关的更新，例如与webcompat.dev的工具整合、WebView社区组活动回顾、针对Android和iOS的实机测试工具介绍等。
• 基线状态：提供关键WebView的功能支持统计，例如：
  • Android WebView (Android)：支持900/1094个特性。
  • WKWebView (iOS)：支持810/1094个特性。

总结：该网站为跨平台WebView开发提供了集中的兼容性参考工具，通过清晰的比较表格、功能追踪和社区新闻，帮助开发者了解不同WebView引擎的Web能力差异。

文章标题：2014年C++错误爆炸大赛结果

竞赛概述 本次竞赛设有两个主要奖项类别：一是用最少的源代码产生最大的编译错误（通过“错误信息大小/源代码大小”的乘数衡量）；二是具有艺术价值的提交作品。文章展示了多个获奖条目，旨在体现C++编译器错误信息的独特“魅力”。

主要获奖作品

1. 最大错误奖（“任意”类别）：Turtles all the way down

   • 作者：Ed Hanway
   • 乘数：59亿
   • 方法：使用了“双重自包含”模式，通过精心构造的路径反复包含自身文件，从而引发海量错误信息。

2. 最大错误奖（“普通”类别）：y u no backreference?

   • 作者：Chris Hopman
   • 乘数：7.9亿
   • 方法：同样利用了被允许的#include指令，通过包含一个名为set>.cpp的文件来触发错误。

3. 最大错误奖（“徒手”类别）：Const Variadic Templates

   • 作者：Marc Aldorasi
   • 乘数：6.57亿
   • 方法：在禁止使用预处理器的规则下，通过紧凑的递归/可变参数模板构造，在少于一行的代码中引发了递归模板实例化错误。

4. 最佳作弊奖：What's perl?

   • 作者：Chris Hopman
   • 方法：提交的C++代码本身仅为空格，但通过提供的“头文件搜索路径”参数，向编译器命令注入了Perl脚本。该脚本会向标准错误输出无限量字符，从而“炸毁”错误日志。

5. 最意外奖：templates and nested classes are not best practice

   • 作者：Aaron Grothe
   • 特点：代码因缺少分号看似简单，却会触发编译器进入无限模板递归，最终导致Clang编译器段错误，揭示了IDE代码补全引擎需要防范的复杂情况。

6. 最逼真奖：Bjarne's nightmare

   • 作者：Victor Zverovich
   • 特点：模拟了令人望而生畏的“企业级质量”代码，通过大量嵌套模板和函数重载，构造出复杂到令人崩溃的代码，用于测试而非阅读。

7. 最原始技巧奖：whatever

   • 作者：John Regehr
   • 特点：在不使用模板或包含递归的情况下，仅凭基本的结构体和语法错误，也能产生相当可观的错误输出。

结语 大赛组委会感谢了所有参与者。文章最后暗示，如果公众有需求，未来可能会举办第二届比赛。

Temporal Python SDK 核心介绍

Temporal Python SDK 正式发布，为 Python 开发者提供了原生 asyncio 集成的持久化分布式工作流解决方案。

Temporal 基础概念

• 定义：一个允许用代码编写工作流的系统，工作流在 worker 中运行。
• 持久性与重放：工作流代码对应 Temporal 中的事件，采用事件溯源方法，可在不同 worker 上通过事件重放。工作流代码必须是确定性的。
• 交互方式：工作流可调用活动（Activity），客户端可发送信号、查询、取消或终止工作流。

Temporal Python 核心特性：Asyncio 事件循环

Temporal 工作流本质是一个持久化、确定性的 asyncio 事件循环。

• asyncio.sleep 与持久化计时器：在工作流中调用 await asyncio.sleep(10) 会启动一个由 Temporal 支撑的持久化计时器，而非本地阻塞。
• 任务（Tasks）：使用 asyncio.create_task 或 asyncio.TaskGroup 启动的是 Temporal 协程。活动和子工作流句柄可视为 asyncio 任务的扩展。
• 取消（Cancellation）：Python 的 asyncio.CancelledError 机制与 Temporal 的取消请求机制完全兼容，可使用 asyncio.shield 保护操作。
• 同步原语：支持如 asyncio.Queue、asyncio.Event 等确定性的 asyncio 同步原语。
• workflow.wait_condition：提供比标准 asyncio 更高级的等待条件，在事件循环每次迭代时检查回调。

关键优势与限制

• 优势：利用 asyncio 原生构造，开发者能以熟悉的异步编程风格编写持久、容错的工作流。进程崩溃后，工作流可在其他 worker 上无缝恢复。
• 限制：仅实现确定性的 asyncio 构造。不支持子进程、磁盘/网络 IO 等非确定性操作。当前仅支持基于相对时间的功能，call_at 和基于它的 asyncio.timeout 无法使用。

Temporal Python 其他重要特性

• 完全类型化：库全面使用 Python 类型提示，支持类型检查以在编译期捕获错误。
• 多种活动风格：除推荐的 async def 活动外，还支持线程（ThreadPoolExecutor）和多进程（ProcessPoolExecutor）活动。
• 工作流沙箱：默认在沙箱中运行工作流，重新导入工作流文件以避免全局状态污染，并代理已知的非确定性标准库调用。可通过 workflow.unsafe.imports_passed_through() 绕过特定导入。
• Rust 核心：Python SDK 的底层由 Rust 核心实现，通过 PyO3 桥接，确保了性能和可靠性。
• 重放功能：可获取工作流历史记录并在本地工作流代码上重放，用于检测不兼容更改、调试或设置断点。
• 测试环境：提供两种本地测试服务器：基于 SQLite 的全功能 Temporal 服务器，以及支持手动时间跳跃的服务器。

资源与社区

• 开源与许可证：MIT 许可证，欢迎贡献。
• 资源：提供代码库、应用开发指南、示例和 API 文档。
• 社区：可通过 Slack 的 #python-sdk 频道、社区论坛等渠道交流。

该 SDK 使 Python 开发者能够利用 asyncio 编写强大、持久且易于维护的分布式工作流。

德国公共广播机构开源其流媒体平台

德国公共广播机构ARD和ZDF宣布，将共同开发一个名为“Streaming OS”的共享流媒体操作系统。该系统的代码计划作为“德国最大的开源计划之一”向公众开放。

项目目标与潜在影响

ARD主席Kai Gniffke表示，竞争对手也可以使用Streaming OS的代码。他设想这能成为构建一个跨平台的德语流媒体网络的基础，即如果其他媒体公司（包括竞争对手）采用该软件，它可能发展成为大型德语平台的基石。

统一技术基础与开源细节

两家机构将利用这一共享技术基础，全面整合用户数据管理。虽然计划开源，但具体哪些部分会公开尚未完全确定。据悉，共同的流媒体软件可能包括流媒体播放器、登录系统、推荐功能代码以及“设计系统核心”。此举意味着ARD和ZDF在近年来内容已深度融合的基础上，进一步将媒体库置于统一的技术基础之上。

社会责任与合作前景

开源不仅面向私营媒体公司，教育机构也能从中受益。ZDF总监Norbert Himmler表示，此举是“将社会为我们支付的费用回馈给社会”。此外，与欧洲合作伙伴的合作也在考虑之中。

组织与实施计划

ARD和ZDF将设立一个联合办公室来管理Streaming OS项目。技术开发将由ARD管理下的一个商业子公司负责执行。该流媒体操作系统预计将于2025年春季准备就绪。

Dotfiles：GitHub上Dotfiles的非官方指南

这是一个关于在GitHub上管理dotfiles（点文件）的非官方指南网站。

为什么要在GitHub上管理你的Dotfiles？

将你的dotfiles存放在GitHub上有以下主要优势：

• 备份、恢复与同步：保护你工具箱中的偏好设置。你的dotfiles可能是你机器上最重要的文件。
• 向社区学习：为你的工具箱发现新工具，并学习已有工具的新技巧。
• 分享你的知识：与他人分享你所学到的东西。

网站导航指南

网站提供了不同阶段的用户指南：

1. 新手入门：在直接符号链接(~/*)之前，可以先查看一些关于如何组织dotfiles的教程。
2. 工具选择：浏览通用dotfiles工具，找到一个适合管理你的dotfiles的系统。
3. 特定工具框架：一些针对特定工具的框架可以帮助你节省定制特定程序（如Shell）的时间。
4. 快速启动：如果喜欢从一个流行的基础配置开始，可以查看dotfiles启动仓库。
5. 寻求灵感：仅仅想看看别人是怎么做的？可以查看其他GitHub用户的dotfiles或Reddit的 r/dotfiles 子版块。

参与贡献

欢迎提交功能请求、报告问题或提交补丁来帮助完善本指南。

“Conditional Longevity”是工业设计师Charlie Humble-Thomas在英国皇家艺术学院（RCA）设计产品硕士期间完成的项目，核心问题为“物品究竟该持续多久？”。通过对伞这一常被丢弃的物品进行研究，设计了三种类型伞：可回收、可修复、耐用型，并系统评估每种设计及其制造过程，揭示产品设计过程中不可避免的取舍和复杂性。

Humble-Thomas强调，物品寿命受材料、制造工艺、设计以及用户情感关系等多重因素影响，例如咖啡杯盖使用时间仅几秒，但实际寿命可达数百年；而泰迪熊则因儿童的情感依附，会被珍视多年。通过构建“用户情感与物理寿命”的关系图，初步甄选了长寿命对象，还包括凳子、模块化电脑、可重复使用咖啡杯等，最终聚焦于伞，探讨在循环经济和消费者文化转型背景下设计决策的环境代价和社会影响。

三款伞的设计思路如下：

1. 可回收伞：以单一材料（聚丙烯PP）打造，采用无染色塑料和模块化结构（如卡扣连接），方便拆卸和最大化回收价值。伞的全部组装重量为460g，结构强化与能耗、碳排都有显著节约。此设计强调材料统一简化回收工序，并通过结构优化发挥塑料的灵活性。
2. 可修复伞：主张“修复权”，通过编号系统简化用户更换零件、组装，所有部件均可替换，旨在让伞像乐高玩具般轻松维修。组装伞重量为1.11kg。该设计有助减少废弃，推动使用者而非品牌承担维护责任，但也增加生产复杂性和回收难点，因不同材料需机械分离。
3. 耐用型伞：使用碳纤维与不锈钢等高性能材料，并采用CNC精加工，整体结构为超规格打造，伞重1.71kg，设计目标为“终身使用”并赋予情感（手柄刻有使用者姓名及QR码以便寻回）。此伞耐用但制造能耗高，引发对于“少即是好”的反思，提出超耐用设计并非总能实现环保。

该项目对每款伞进行了数据化比较（重量、能耗、碳排放等），以实际使用次数为衡量标准：例如可回收伞若使用4次，则耐用型伞需用25次才在能耗上持平。由此提出“物品影响比”：用资源消耗除以实际使用寿命，建立产品设计的多维评估方法。

调查发现，用户行为与环保信念存在偏差，且以购物袋为例，传统塑料袋虽被批判，但棉布袋需反复使用数十次才在碳排放上“划算”。因此，一个物品应如何延长或缩短寿命需结合材料、环境、用户行为等多方面权衡。

总结项目意义在于发起关于产品寿命的深入讨论，挑战大众对于“应该如何设计物品”的预设观念，推动工业设计师重新审视物品与人、环境的关系，及设计决策背后复杂的生态影响。该项目由Robin & Lucienne Day基金会支持，并于2021年完成。

文章总结

本文通过从头构建一个简化版的 asyncio 来深入解释其工作原理。核心观点是 asyncio 的主要功能建立在 Python 生成器 之上，是一个优秀的层。作者通过循序渐进的方式，重现了 asyncio 的关键组件。

1. 生成器基础回顾

生成器通过 yield 关键字实现函数的暂停和状态保持，使其能够按需生成数据，极大提升了内存效率。yield from 则允许链式调用生成器。生成器的这种“可启动和停止并保持状态”的特性是 asyncio 实现并发的基础。

2. 构建事件循环

事件循环是 asyncio 的核心，负责管理和运行所有任务。在简化版中，可以用一个列表（或队列）来存放任务（即生成器对象）。事件循环通过遍历任务列表并调用 next()（或 .send(None)）来推进每个任务的执行。任务通过 yield 暂停，将控制权交还给事件循环，从而实现任务间的切换。

3. 实现睡眠功能

通过创建一个 sleep 生成器函数，它在指定时间内持续 yield，让出控制权，从而模拟异步等待。任务通过 yield from sleep(seconds) 来暂停自身执行，直到睡眠时间结束。这展示了如何在不阻塞整个程序的情况下实现I/O等待。

4. 从 yield 过渡到 await

await 关键字本质上是 yield from 的语法糖，并带有额外验证。为了使用 await，需要：

• 创建 Task 类：该类需要实现 __await__ 方法。__await__ 方法内部会 yield，直到任务完成。
• 构建任务调度系统：使用队列作为事件循环，实现 create_task 函数将生成器包装为 Task 并加入队列，以及 run 函数来启动和驱动整个循环。
• 改造 sleep 函数：将其拆分为一个内部生成器函数 _sleep 和一个使用 async def 定义的 sleep 协程函数，后者通过 create_task 和 await 来协调等待过程。

5. 对接真正的 asyncio

完成上述简化版实现后，只需将自定义模块（如文中的 jacobio）中的调用替换为标准 asyncio 库的对应函数（如 asyncio.sleep, asyncio.create_task, asyncio.run），即可无缝切换到官方 asyncio 实现。

结论

通过这个从生成器到自定义事件循环，再到 async/await 语法，最后对接官方库的过程，可以清晰地理解 asyncio 的核心运行机制：利用生成器（或协程）的暂停与恢复特性，由一个事件循环来协调多个任务的执行，从而在单线程中高效处理I/O密集型任务。虽然真正的 asyncio 实现更为复杂，但本文的构建过程揭示了其基本原理。

TOTP Authenticator for PalmOS

这是一个为Palm OS设备（及模拟器如Cloudpilot）开发的TOTP（基于时间的一次性密码）身份验证器应用程序。它允许用户在Palm设备上生成两步验证码，功能类似于谷歌身份验证器。相较于旧版应用（如Hotpants），此版本占用空间更小，并支持更广泛的Palm OS版本（2.0及以上）。

主要特点：

• 在Palm设备上生成两步验证码。
• 支持Palm OS 2和3。
• 相较于旧版应用，体积更小。

安装方法：

1. 在真实设备上安装：
   • 使用Palm Desktop时，可直接双击.prc或.pdb文件进行安装。
   • 在Linux系统下，可安装pilot-link工具并使用pilot-xfer命令安装。
2. 在Cloudpilot模拟器上安装：
   • 可以将文件逐一拖放到模拟器屏幕上。
   • 也可以使用模拟器顶部工具栏的“安装”按钮。
   • 重要提示： 如果更新现有应用，在安装前请确保先打开另一个应用程序，仅返回到启动器可能不足以完成更新。

下载与源代码：

• 下载链接：<TOTPAuth-1.1.zip>
• 源代码仓库：palm-totp.git

在线演示： 文中提供了一个在线演示链接，但请注意，在演示中输入的数据不会被保存。如需保存数据，请使用Cloudpilot的主要网站。

NES《俄罗斯方块》游戏内重编程技术解析

黑客发现通过游戏内崩溃机制实现任意代码执行，可在原版硬件上注入新行为。

核心原理：崩溃触发内存跳转

当NES《俄罗斯方块》分数计算超过155级时，帧延迟导致代码执行中断，跳转至RAM起始地址。由于RAM存储随机数据，通常直接崩溃，但玩家可通过Famicom扩展端口控制跳转地址。

漏洞利用步骤

1. 控制器输入操纵：通过Famicom扩展端口连接额外控制器，特定按键组合（第三控制器按“上”，第四控制器同时按左、右、下）可将跳转地址指向高分榜存储区。
2. 高分榜编码机器码：在B-Type高分榜输入特定字符（如“(G”），使游戏将高分榜数据读取为NES CPU指令。受限于43个可用符号，仅能编写简单代码。
3. 验证案例：Displaced Gamers通过高分榜注入代码，将分数寄存器置零，暂时避免崩溃（示例：A型第二名分数8575，名称))"-P)）。

技术限制与突破

• 局限：单次可注入代码长度短，且需手动重复输入高分记录（无电池存档）。
• 进阶方案：玩家HydrantDude提出通过分层引导程序（bootstrapper）获取完整RAM控制权，理论上可彻底修复崩溃漏洞，使游戏突破255级后循环至0级。

潜在应用场景

• 高分玩家可规避致命崩溃，提升游戏连续性；
• 开发者或能在此基础上改造游戏逻辑（如将《俄罗斯方块》转换为其他游戏）。

技术背景

该方法属于“任意代码执行”（ACE）漏洞，此前已见于《超级马力欧世界》等游戏。NES《俄罗斯方块》的公开实现基于2021年以来的逆向工程研究，将理论转化为可复现操作。

SecureDrop Protocol 概要总结

该文章介绍了 SecureDrop 系统下一代端到端加密协议的概念验证版本，旨在为高风险的举报人提供更安全的通信渠道。

核心设计目标与特性

该协议旨在解决现有威胁模型中的关键问题，具备以下四大核心属性：

1. 无账户与认证：源（举报人）和记者均无需创建或管理用户账户，从而最大化源的合理否认性。
2. 无消息流元数据：不同类型的消息无法被区分，且消息之间不可关联。
3. 服务器状态不可观测：外部观察者无法察觉服务器内容的变化。
4. 防密文收集与信息泄露：仅向相关接收者提供其相关的密文，防止“先收集，后解密”的攻击。

协议设计与机制

• 简洁的API：仅包含 send、fetch 和 download 三个端点。源和记者的请求结构完全相同，使恶意服务器或网络对手难以区分二者。
• 密码学基础：使用 libsodium 库中的成熟原语（如 X25519, XSalsa20-Poly1305）实现端到端加密。
• 关键创新——消息检索机制：利用 异步三方Diffie-Hellman密钥协商 的可交换性。接收者匿名向服务器请求“线索”，服务器每次响应都返回一个包含真实线索和诱饵密文的新组合。接收者通过试解密线索发现 message_id，进而获取完整消息。整个过程使得服务器无法获知请求者是否为合法接收者，且每次请求的响应都不同，从而隐藏了服务器状态。
• 加密属性：
  • 单向前向保密：实现了从源到记者的前向保密，但由于源端不能轮换密钥材料（需保持口令稳定），反向保密无法实现。
  • 参与者认证与否认性：对于首次联系，源具有完全的否认性。对于持续对话，可以实现消息级别的否认，但参与对话的否认性仍是一个开放的研究问题。

与其他协议的对比

文章将 SecureDrop Protocol 与几种其他方案进行比较：

• 试用解密：不安全，会泄露服务器状态且允许大规模密文收集。
• Signal 协议：依赖于账户和消息投递的元数据，不符合“无账户”和“无元数据”的目标。
• 不经意消息检测/检索（OMD/OMR）：理论上能隐匿接收者，但技术复杂且尚不成熟，对于 SecureDrop 的小规模场景不实用。SecureDrop 协议在满足所有四个核心属性上取得了更好的平衡。

现状与未来步骤

• 现状：该协议为概念验证代码，不用于生产环境。已发布在 GitHub 上，并完成了由独立密码学家进行的初步安全审计。
• 主要挑战：
  • 后量子安全：当前使用的椭圆曲线 Diffie-Hellman 不具备抗量子计算能力。虽然消息本身可以采用量子安全的加密，但消息检索机制依赖的三方密钥交换的可交换特性，目前尚无成熟的量子安全替代方案。
  • 客户端集成：如何在浏览器等客户端安全地实现该协议是下一步的重点。
• 未来计划：
  • 对协议进行形式化建模并证明其安全属性。
  • 最终确定协议规范以供审计和发布。
  • 特别寻求在后量子密码学领域具有专业知识的人员进行合作。

无限画布，用于代码探索

核心问题

• AI编程代理（如Claude Code）虽能生成代码，但缺乏对产品本身的理解。每次对话都需重新解释用户画像、解决的问题、技术约束等背景信息，导致生成的技术上正确但偏离产品目标的代码。

现有解决方案的不足

• 无结构化：使用自由格式的Markdown文件，代理难以识别关键上下文（如用户画像、约束条件）。
• 过度结构化：采用笨重的方法论（如BMAD），流程官僚化，通常在第一个冲刺后就被废弃。
• 存放在Git中：非技术人员（如产品经理）难以访问和维护。
• 生命周期错误：产品规格说明与代码提交不同步，在功能发布后易过时，随计划变更而脱节。

Territory解决方案

Territory 是一个产品上下文层，旨在帮助AI代理和人类开发者协同构建正确的产品。其核心是：一次性定义，处处使用。

关键特性

1. 定义产品上下文：结构化地捕获产品决策的稳定基础，包括：
   • 产品愿景与使命
   • 用户画像与痛点
   • UX指南与设计模式
   • 技术约束与技术栈
   • 设计原则
2. 规格化功能特性：以足够的结构为代理定义正在构建的功能，使其理解意图而非仅仅是需求，包括：
   • 功能描述与验收标准
   • 关联的用户画像与目标
   • 线框图与模型
   • 技术说明
3. 装备代理：将产品上下文无缝连接到编码工作流。上下文流向代理，实现细节流回Territory。
   • 支持MCP服务器（用于Claude Code）
   • 命令行工具（用于任何工作流）
   • 上下文包导出
   • 从实现中同步回规格

核心优势

• 结构化足够：让AI代理能理解。
• 易于访问：让人类协作者（如产品经理、联合创始人）能参与。
• 与代码库解耦：独立于代码库存在。
• 保持活跃：通过“定义 -> 导出 -> 代理构建 -> 同步回”的循环，确保产品规格说明永远不会过时。

当前状态

Territory 正在开发中，用户可以通过加入等待名单获取早期访问权限。

梯度下降可视化工具

这是一个桌面应用程序，用于可视化机器学习中几种常用的梯度下降方法，包括（原始）梯度下降、动量法、AdaGrad、RMSProp和Adam。旨在通过交互探索，帮助初学者和专家直观理解这些算法的工作原理。

主要功能

• 多样化曲面：提供多种优化曲面供选择。例如，可以观察Adam和RMSProp在处理鞍点时，比简单梯度下降或动量法表现更优。
• 参数调节：允许用户调整学习率等参数。例如，在存在平台的曲面上，调高动量法的学习率可以帮助其穿越平坦区域。
• 逐步动画演示：通过动画卡通逐步展示每种方法的计算过程。
• 视觉元素追踪：使用视觉元素（如箭头、大小可变的方块）追踪并展示梯度、动量、梯度平方和、调整后的梯度以及优化路径等关键量。这有助于直观比较不同方法在调整梯度时的差异（如RMSProp与AdaGrad在梯度平方和规模上的区别）。
• 路径绘制：展示不同方法达到目标点的路径差异。

技术信息

• 开发技术：使用C++和Qt框架（开源许可版本）开发，支持跨平台。
• 获取与构建：
  • 提供适用于macOS和Windows的预编译版本。
  • 可从源代码构建，需安装Qt 5.10或以上版本及Qt数据可视化模块，然后在Qt Creator中构建项目。
• 代码结构：
  • window类：负责UI布局。
  • plot_area类：处理绘图区域内的用户交互。
  • animation类：控制动画逻辑，每种下降方法有其派生类。
  • item类：实现自定义3D项目（如箭头、路径）。
  • GradientDescent类：实现各种下降方法的数学逻辑。

参与贡献

项目欢迎贡献，特别是寻求帮助将其转变为网络应用程序。

漏洞概述： 研究人员发现一种名为“TunnelVision”的新型网络技术，可利用DHCP（动态主机配置协议）的内置功能，绕过基于路由的VPN加密隧道，使用户流量在VPN连接状态下未加密传输，从而被攻击者窥探。该技术不破坏VPN加密协议本身，而是通过DHCP选项121向目标主机的路由表注入更具体的路由规则，劫持流量路径。受影响主机的VPN控制通道通常保持连接，导致用户误认为VPN仍处于有效保护状态。

技术原理：

• 攻击前提：攻击者与目标处于同一局域网，并可控制或伪装DHCP服务器。
• 攻击机制：通过DHCP选项121（类无类静态路由）向目标主机注入特定路由规则（如两个/1路由覆盖默认路由），其优先级高于VPN虚拟接口的路由规则。根据DHCP协议，此类路由将通过与DHCP服务器通信的物理网络接口发送，而非VPN隧道，导致流量绕过VPN加密。
• 隐蔽性：VPN隧道未断开，Kill Switch等安全功能不会触发，用户界面持续显示“已连接”。

影响范围：

• 受影响系统：支持DHCP选项121的操作系统，包括Windows、Linux、iOS和macOS。
• 不受影响系统：Android因未实现DHCP选项121支持而免疫。
• 受影响VPN类型：仅依赖路由规则管理流量的VPN均受影响，与VPN协议（如WireGuard、OpenVPN）或加密强度无关。

缓解与修复方案：

1. 根本修复（Linux系统）：
   • 使用网络命名空间隔离VPN接口与物理接口，彻底防止外部路由干扰。WireGuard文档提供了参考实现。
2. 部分缓解措施：
   • 防火墙规则：VPN客户端可通过防火墙阻止物理接口的非必要通信（需为DHCP和VPN服务器IP开放例外）。但此方法会引入侧信道，攻击者可通过流量分析推测目标通信对象，甚至用于审查或匿名化攻击。
   • 忽略DHCP选项121：可能破坏网络连通性，且攻击者可迫使用户重新启用该选项。
   • 使用移动热点或虚拟机：通过受控网络环境隔离本地网络风险。

风险与责任提示：

• 该技术可能自2002年起即为可行，且已有早期研究（如2015年OpenVPN加固讨论）提及类似风险，但未广泛修复或公开。
• VPN的安全承诺常被误解：VPN主要保护数据传输加密，而非防御本地网络攻击。在不可信网络（如公共Wi-Fi）中，依赖VPN防止本地攻击者存在风险。
• 各方建议：
  • 用户：避免在不可信网络处理敏感事务；选择已实施有效缓解方案的VPN提供商。
  • 企业网络管理员：教育员工公共网络风险；采用移动热点+VPN、虚拟机隔离等方案；启用交换机的DHCP Snooping等二层防护。
  • VPN提供商：在网络命名空间可行的系统（如Linux）上实现隔离；透明披露缓解措施；修正夸大安全性的营销宣传。
  • 操作系统维护者：评估网络命名空间等隔离功能的跨平台可行性。

研究局限性：

• 研究团队因资源有限，无法逐一测试所有VPN产品。因此选择公开披露以扩大影响。
• 攻击仅需局域网访问权限，无需特权账户，但部分接收方曾低估其实现条件。研究者后续将发布“ArcaneTrickster”工具库，进一步演示局域网内邻近主机的攻击可行性。

结论： TunnelVision利用协议设计特性而非实现漏洞，凸显了VPN在不可信网络中的局限性。各方需协同采取修复或缓解措施，并重新审视VPN的安全宣传。

巨型电池正在改变美国用电方式

问题背景与电池的兴起

加州太阳能资源丰富，但存在昼夜发电不均衡问题：白天阳光充足，傍晚用电高峰时太阳能却消失，过去主要依靠燃烧天然气等化石燃料填补缺口。自2020年起，加州大规模安装巨型电池（仅次于中国），用于储存白天多余的太阳能，并在夜间放电以替代部分化石燃料。例如，2024年4月30日晚7点至10点间，电池供电量超过加州总电量的五分之一，瞬时输出相当于七座大型核电站的发电能力。

全美发展现状

过去三年，美国电网电池存储容量增长十倍，达16,000兆瓦，预计2024年将翻倍，增长主要集中在德克萨斯州、加州和亚利桑那州。电池技术多采用锂离子（与电动汽车同源），成本在过去十年下降80%，加之联邦补贴推动，使其在电网中应用日益广泛。

工作原理与应用场景

电池在电网中主要有两种用途：

1. 辅助服务：平滑电力波动（如电厂意外断电），稳定电网。
2. 能源套利：在电价低廉时（如中午太阳能过剩）充电，在电价高昂时（如傍晚需求高峰）放电。

在加州，电池已形成10,000兆瓦的容量，可有效应对傍晚负荷上升、极端高温及山火导致的输电线中断。德克萨斯州则主要用于辅助服务和应对风能波动，但也开始在傍晚需求高峰时发挥作用（如2024年4月28日瞬间提供4%的电力）。

各州发展模式差异

• 加州：由政策推动，监管机构为应对电厂关闭风险，要求公用事业公司快速部署储能项目。目标2045年实现100%无碳电力，计划2035年前将电池容量增至三倍。
• 德州：由市场驱动，电力价格波动大（最高达5,000美元/兆瓦时），电池运营商通过低价充电、高价放电获利。市场机制鼓励在电网拥堵地点部署电池。

其他州（如亚利桑那、佐治亚）也计划安装数千兆瓦电池，以应对数据中心和工厂增长的需求。

对气候变化的作用与局限

电池在加州已开始减少化石燃料使用，2024年4月天然气发电量创七年新低。但在德州，因运营商以盈利为目标，有时仍用煤电或气电为电池充电，反而增加碳排放。专家指出，电池需配合合理激励机制才能有效减排。

主要局限：

1. 技术局限：当前锂离子电池通常仅能供电2-4小时，成本制约其难以替代提供稳定电力的大型燃气电厂。
2. 季节性差异：无法储存跨越数月的电力以平衡夏冬发电差异。
3. 安全与供应链：电池易燃引发社区反对；多数电池产自中国，受贸易争端影响。

未来发展方向

为应对长期无风无光（如加州可能面临长达一周的“能源干旱”）的挑战，业界正探索新技术：

• 长时储能电池：如Flow电池（液态电解质，可供电12小时以上）和铁空气电池（100小时供电）。
• 竞争方案：核能、先进地热、绿氢储能等也可能是选择。

加州监管机构表示，到本世纪中叶可能需要五倍于当前的储能容量，具体技术路径尚在探索中。电池储能仍处于发展初期，但已成为电网可再生能源整合的关键组成部分。

波音星际客机首次载人任务因故推迟

核心事件：波音公司的CST-100“星际客机”飞船的首次载人试飞任务在发射前约两小时被紧急叫停。官方宣布出于“高度谨慎”的原因，新的发射时间将不早于5月17日。推迟的主要原因是负责发射的联合发射联盟（ULA）的“阿特拉斯五号”火箭上面级的一个氧气泄压阀存在问题，需要将火箭运回厂房更换部件。此外，还存在5月7日、10日和11日的备用发射窗口。

任务背景与目标：

• 宇航员与计划：本次任务搭载宇航员布奇·威尔莫尔和苏尼·威廉姆斯。原计划从佛罗里达州卡纳维拉尔角发射，随后与国际空间站对接，宇航员将在空间站停留至少8天，计划不早于5月16日返回地球。
• 历史意义：此次任务是波音公司首次尝试将宇航员送往国际空间站，也是“阿特拉斯五号”火箭首次执行载人任务。该型火箭此前已连续成功执行99次发射。
• 波音的困境：该项目历经多年延误和严重成本超支，波音已累计承担15亿美元损失。波音在2019年首次无人试飞因技术问题失败，2022年才成功完成无人试飞。

与SpaceX的对比：

• 作为NASA商业载人计划的一部分，波音在2014年获得42亿美元合同，而SpaceX同期获得26亿美元合同用于开发“载人龙”飞船。
• SpaceX已于2020年开始常态化执行国际空间站运输任务，已执行十多次载人飞行，并开展了私人太空任务。相比之下，波音的进度严重滞后。
• SpaceX创始人埃隆·马斯克在社交媒体上评论称，波音获得的资金更多，但交付时间却晚了四年，并指出波音非技术人员过多。

安全与前景：

• 安全第一：NASA和波音均强调将宇航员的安全置于首位。NASA副局长表示“机组人员的生命至关重要”。
• 战略意义：若任务成功，波音将能获得载人航天认证，开始履行其合同中的六次载人任务。这将为NASA提供第二个可靠的商业载人运输选项，增强该计划的冗余性和弹性。

任务关键点：此次推迟是一次常规的技术安全处理，波音星际客机能否最终通过考验、为NASA提供第二个常态化载人运输选择，仍有待此次任务完成后的评估。

Google Fit APIs 将于2025年关闭，或影响健身设备

Google 正在逐步淘汰 Google Fit APIs。该平台最初旨在将第三方健身设备的健康数据同步到用户的 Google 账户，但现在其已被列入终止计划。API 的弃用始于2024年5月1日，Google 已停止接受新的 API 注册。官方关闭日期定于2025年6月30日。

Google Fit API 于2014年推出，其目标是成为来自各种应用和服务的健康数据的中央存储库，旨在将步数、体重等不同健康指标集中到一个统一的平台。发布时拥有众多知名合作伙伴，如Nike+、Adidas、Withings、Runtastic 和 RunKeeper 等。

然而，到2024年，Google 未能聚焦于单一解决方案的问题再次显现。目前，Google 同时维护着三个相互竞争的健身 API：Health Connect API、Fitbit Web API 和 Google Fit REST API，Android 开发者网站甚至提供了它们的对比指南。

除了关闭 API 之外，Google Fit 整体产品似乎已被搁置。Google 于2021年完成对 Fitbit 的收购后，Fitbit 成为其主打的健身品牌。新的 Google 产品（如 Pixel Watch 和 Pixel 手机）已将 Fitbit 应用作为内置的健身解决方案，取代了 Google Fit，而 Google Fit 应用也已长期未获得重大更新。

Google 的新健身 API Health Connect 自2022年起在 Play Store 上提供测试版应用，仅适用于 Android 13。在Android 14 中，Health Connect 被集成到操作系统中，作为存储健康数据的开源框架。值得注意的是，Play Store 版的 Health Connect 与 Android 14 内置版并不相同，用户需要经历一个自动的“迁移”弹窗提示并重启设备才能升级到 Android 14 版本。

Google 尚未明确说明对 Android 14 之前版本（或 Android 13？）的兼容性。鉴于 Android 设备更新速度缓慢以及开发者功能采纳率较低，即使到2025年，Health Connect API 的设备支持度也可能面临挑战。

这篇文章讲述了作者在 Google Cloud 的 DNS 研究中，受一篇关于 SSRF 漏洞的文章启发，转而对 toolbox.googleapps.com 网站进行安全研究，最终发现了一个 存储型跨站脚本攻击（XSS） 漏洞的完整过程。

主要发现过程：

1. 研究起点：作者从 toolbox.googleapps.com 的 robots.txt 文件中列出了多个应用路径开始研究。
2. 目标定位：通过搜索发现了一个未在主菜单列出的 恢复应用 (/apps/recovery)，它包含多个子页面（如 recovery/ownership）。
3. 漏洞触发：这些页面接收多个查询字符串参数。其中 continue 参数的值会被直接用作页面中“继续”按钮的链接地址。作者尝试将 continue 参数的值设置为 javascript:alert(document.domain)，成功触发了 XSS。
4. 严重性：该网站没有任何 CSP（内容安全策略）或其它防护，因此攻击者不仅能执行任意 JavaScript，还可以通过构造的脚本从外部站点发送和接收数据（例如窃取用户公共 IP）。

结果与奖励： 作者将漏洞报告给 Google。由于该漏洞属于一个普通 Google 应用上的 XSS，按照 Google 的奖励标准，作者获得了 3133 美元 的奖金。作者将这篇文章命名为“Common”（常见的），是因为该漏洞是一个非常典型的 开放重定向转 XSS 漏洞，通过简单修改 URL 参数即可实现，无需复杂思考。

Patagonia研究揭示摇粒绒夹克是严重污染物

问题起源与早期研究

• 2000年代初：普利茅斯大学海洋生物学教授Richard Thompson在英格兰海滩发现，海洋沉积物中的微塑料主要为纤维状，可能来自服装、绳索或包装。
• 2011年研究：Thompson的学生Mark Browne在15个海滩的沉积物中发现大量聚酯和丙烯酸纤维，浓度在污水处理厂附近最高。他测试了一件摇粒绒夹克，一次洗涤可滤出1900根纤维。Browne寻求服装制造商资助进一步研究，但大多数品牌（包括Patagonia、Columbia）当时拒绝，仅Eileen Fisher提供帮助。
• 后续科学进展：研究表明污水处理厂无法完全过滤合成纤维，且纤维在进入水体时会吸附DDT、PCBs等毒素。小型水生生物会摄入微纤维，鱼类和贝类体内也已发现微纤维，可能对人类健康构成潜在威胁。

Patagonia的委托研究与关键发现

• 背景：2015年初，Patagonia环境策略总监Jill Dumain主导，委托加州大学圣巴巴拉分校（UCSB）布伦环境科学与管理学院开展研究，评估其合成产品对微纤维污染的贡献。
• 主要结果：
  • 纤维脱落量惊人：单件摇粒绒夹克一次洗涤可释放多达250,000根合成纤维，远高于Browne此前记录的1900根。若按全球每年洗涤100,000件Patagonia夹克估算，进入水道的纤维量相当于11,900个塑料袋的塑料含量。
  • 实验方法：测试了五件衣物（三件Patagonia摇粒绒夹克、一件含聚酯绝缘层的尼龙外壳夹克、一件未公开品牌的“平价”摇粒绒），使用前置式和顶置式洗衣机多次洗涤，并通过两级过滤系统收集废水中的纤维。研究人员计算纤维质量而非数量，并借助行业公式估算纤维根数。
  • 影响因素：
    1. 洗衣机类型：在顶置式洗衣机中洗涤时，衣物释放的微纤维数量是前置式洗衣机的5倍。
    2. 衣物老化：通过24小时“强化洗涤”模拟老化后，纤维脱落量平均增加80%。不同衣物受老化影响程度因洗衣机类型而异。
    3. 衣物构造：尼龙外壳夹克在部分测试中释放的纤维量与摇粒绒夹克相当，甚至更多，表明聚酯填充物可能通过接缝或外壳面料渗出。
  • 研究局限性：研究未使用洗涤剂（可能堵塞过滤器），且测试样本有限。Thompson教授认为该研究对Patagonia自身更具参考价值，但肯定了企业主动研究这一环境风险是负责任之举。

行业应对与未来方向

• 污染规模：尽管污水处理厂能去除98%以上的塑料碎片，但每天仍有约6500万件微塑料进入水体。聚酯纤维是通过处理厂的主要塑料类型。
• 全球趋势：随着全球洗衣机使用量预计到2050年将从20亿台增至50亿台，微纤维污染问题可能加剧。
• 行业行动：
  • 技术改进：Patagonia等公司正在研究新的纱线和织物构造以减少纤维脱落。欧洲的“Mermaids”项目发现洗涤剂中的表面活性剂会导致纤维脱落量激增至100万根/件，并正在开发环保的织物涂层以减少纤维流失。
  • 洗涤建议：基于“Mermaids”研究，建议避免使用高pH值洗涤剂、粉末洗涤剂和氧化剂，采用冷水洗涤并软化硬水。
  • 标准化与倡导：Patagonia计划在2016年8月的户外零售商展会上分享研究成果，并希望与户外产业协会合作，将测试协议转变为行业标准。公司也期望如ASTM等国际测试标准组织能采纳该方法。
• 监管与自我规范：目前尚无明确的立法限制微纤维污染，服装制造商倾向于自我监管，以避免未来可能面临更严格的法规。Patagonia将此研究视为第一步，旨在推动整个服装行业进行更多测试和改进。

本文介绍了一种创新方法，将AirPods等具备媒体控制功能的耳机作为摩尔斯电码发射器。

核心原理：利用耳机的媒体控制命令（单按⏸️暂停/播放、双按⏯️下一曲、三按⏮️上一曲）来模拟摩尔斯电码的“点”和“划”。项目提供了一个在线演示页面（etherdream.github.io/headphone-morse-transmitter/），但由于浏览器安全策略，需要用户先点击页面以初始化音频，才能接收耳机命令。

操作与编码规则：

• 按键映射：⏸️ 对应“点”（.），⏯️ 对应“划”（-），⏮️ 用于刷新输入缓冲区或退格（删除最后一个字符）。
• 自动刷新：最后一次按键后，经过设定延迟时间，输入缓冲区会自动刷新并输出结果。
• 支持系统：支持国际摩尔斯电码、日本和文电码、中文电码（依据中国大陆1983年标准），以及一些特殊编码。

特殊功能代码：

• <AA>：换行 (.-.-)
• <HH>：删除最后一行（连续8个点）
• <DO>：切换到和文电码 (-..---)
• <SN>：切回国际电码 (...-.)
• 输入2至4位数字：输出对应的中文电码汉字。
• 私有功能包括切换大小写/平假名片假名、添加空格、以及输入小假名（如っ、ゃ等）。

多种输入方式：

1. 耳机：核心输入设备，适合盲操。
2. 键盘：使用键盘上的媒体控制键（⏮️⏸️⏯️）输入，速度更快。
3. 媒体控制弹窗：通过点击屏幕媒体控制弹窗中的按钮输入。

盲操模式：该程序支持在后台运行，即使浏览器最小化或手机屏幕锁定也能工作，用户可以仅依靠听觉和手指进行摩尔斯码练习，无需注视屏幕。

演示视频均展示了通过耳机或键盘输入并解码的过程，但因声音来自耳机，音量较轻。

麝鼠是一种鲜为人知、半水生且适应力极强的啮齿动物，其数量在原生分布区（从北极圈到美墨边境）正经历显著下降。自20世纪90年代起，北美多州的狩猎数据开始呈现下降趋势，而2017年一项综合研究证实，自1970年代初以来，美国34个州的麝鼠数量至少减少了一半，部分地区跌幅高达90-99%。尽管总体数量仍以百万计，且在某些栖息地密度依然很高，但其整体下降趋势令人深感忧虑。

这一现象的成因复杂且不明朗，可能涉及多种因素的综合影响：

• 栖息地变化与丧失：湿地被人类活动破坏、退化或隔离，阻碍了麝鼠在不同种群间的迁移与定殖。大型水坝建设（如加拿大不列颠哥伦比亚省的WAC Bennett大坝）改变了水文条件，导致干旱期延长、水体消失或变浅，是导致特定区域（如和平-阿萨巴斯卡三角洲）种群崩溃的关键原因。
• 植被结构改变：外来植物芦苇（Phragmites australis）的蔓延挤占了本地植被（尤其是麝鼠的主要食物香蒲），可能对其生存构成挑战，但并非全部解释。
• 疾病与污染：尽管存在多种病原体和农业、工业污染物，但目前缺乏证据表明它们是导致种群规模下降的主因，相关研究极为匮乏。
• 其他潜在因素：包括气候变化、淡水贝类减少、捕食者种群变化等。

麝鼠是重要的“湿地工程师”，其生态作用虽不如海狸显著，却至关重要：

• 营养循环与栖息地塑造：通过取食水生植物和动物（如贝类），它们将营养物质重新分配。其啃食行为能维持湿地的“半沼泽”状态（植被与开阔水面各半），防止沼泽化，并促进植物多样性。
• 为其他物种提供栖息地：它们的巢穴（泥草屋）和觅食平台为超过60种脊椎动物（包括鸟类、爬行动物、两栖动物）提供了筑巢、栖身和觅食的场所，增加了生态系统的异质性和生物多样性。

目前，少数研究者（如罗德岛大学的John Crockett）正致力于调查麝鼠的分布与数量变化，以建立基线数据。新技术（如从水样中检测麝鼠DNA）有望提供更高效、可扩展的监测方法。虽然下降原因尚未完全厘清，且公众关注度很低，但一个积极的信号是：麝鼠在城市和人类改造环境（如受污染的河流、城市湿地）中也能生存良好，表明只要给予基本的湿地栖息地（如池塘或小段河流），它们仍有繁衍生息的潜力。

Parquet 诞生记

本文是作者“构建开源标准的十年”系列博客的第一部分，回顾了列式存储格式 Parquet 的诞生历程与开源项目经验。

早期经历与灵感

作者于 2007-2011 年在 Yahoo! 工作，使用 MapReduce 和 Apache Pig。期间阅读了 Google 的 Dremel 论文，该论文描述了一种用于嵌套数据的列式存储格式和查询引擎，成为其后续工作的重要灵感来源。通过参与 Pig 社区，作者积累了开源项目经验并扩展了行业人脉。

Twitter 时期的技术挑战

2011 年，作者加入 Twitter 数据平台团队。当时平台主要依赖两个工具：

1. Hadoop：可扩展性高、吞吐量大，但延迟高（MapReduce 相当于暴力处理）。
2. Vertica：一种 MPP 数据库，采用列式存储和向量化处理，延迟低但成本高、扩展性有限。

这引出了一个核心问题：如何让 Hadoop 具备 Vertica 的列式存储优势？

列式布局的优势

传统的行式存储将每行数据依次存储，而列式存储将同一列的所有数据连续存储。列式存储的主要优势包括：

• 查询效率高：只需读取所需列的数据，减少磁盘寻址。
• 压缩率高：同一列的数据类型相似，更易压缩。

Red Elm：Parquet 的前身

作者在通勤途中开始原型开发，最初命名为 Red Elm（对 Dremel 的变位词），旨在实现 Dremel 论文中描述的列式分裂算法。他借鉴了 Twitter 使用的 Thrift 和 Pig 上下文以及其他现有格式（TFile、RCFile 等）。

合作与 Parquet 的诞生

作者意识到，要让项目可持续，必须与开源数据生态系统集成，而非仅作为 Twitter 的专有格式。通过推特分享，他联系上了同样在开发列式格式的 Cloudera Impala 团队。

• 互补优势：作者带来 JVM 生态兼容性；Cloudera 带来基于 LLVM 的分布式查询引擎。
• 合并设计：作者实现 Java 部分，Cloudera 实现 Impala 中的原生读取器，共同创建了 Parquet，名称寓意“数据库的底层布局”。

社区发展与行业采用

Parquet 发布后，多家公司迅速参与：

• Criteo 为 Hive 提供支持。
• Netflix 采用 Parquet 并为 Presto 提供支持。
• Apache Drill 将 Parquet 作为基础存储格式。

项目进入 Apache 孵化器，最终成为 Apache 顶级项目。随着 SparkSQL 构建于 Parquet 之上，它迅速达到“逃逸速度”，如今已成为所有主流数据仓库的标准格式。

开源项目的经验总结

作者从 Parquet 的发展中总结了三点关键经验：

1. 每个贡献者都是利益相关者：尤其在定义标准格式的项目中，需确保贡献者拥有发言权和影响力，使其更负责任地参与。
2. 雪球效应：开源项目初期像推石上山，但随着贡献者增加，项目会加速增长，最终达到“逃逸速度”，形成自增长的良性循环。
3. 开源形态多样：开源不仅是代码公开，更涉及许可证、治理和基金会。关键点包括：
   • 许可证：如 Apache 许可证（宽松，保护署名）与 GPL（具有“病毒性”，要求衍生作品同样开源）。
   • 治理：明确决策机制、如何成为贡献者/维护者。加入 Apache 基金会等组织可保证中立性和治理最佳实践。
   • 重要性：无论采用何种形式，关键是要明确使用规则和决策流程，管理好用户预期。

Parquet 的成功源于技术需求、跨公司合作、开源社区动力以及清晰的治理模式。

PeerDB Streams：简易、原生的Postgres变更数据捕获

概述

PeerDB Streams 是一个新发布的开源工具，旨在提供一种简单且原生的方式，将PostgreSQL数据库的实时变更（Change Data Capture，CDC）复制到消息队列系统（如Kafka、Redpanda、Google PubSub等）。该项目基于PostgreSQL的逻辑解码功能实现。

背景与动机

• 项目起源：PeerDB团队在过去7个月中专注于构建从Postgres到数据仓库的数据复制体验，现在将解决方案扩展到消息队列。
• 解决痛点：现有工具（如Debezium）虽然功能全面且广泛使用，但存在显著的学习曲线陡峭、配置复杂等问题。常见挑战包括：CLI交互复杂、需要学习大量最佳实践、数据格式与转换设置繁琐（如需Java项目），以及对非Kafka队列（如Azure Event Hubs）的原生支持和配置灵活性不足。
• 核心目标：PeerDB旨在构建一个简单且全面的Postgres CDC体验，让工程师能在几天内（而非数月）构建生产级的CDC管道，将可用性放在首位。

主要特性与优势

1. 简易的用户界面（UI）：

   • 通过创建“PEER”（数据源/目标连接）和“MIRROR”（复制任务）来设置CDC。
   • 提供监控功能，包括吞吐量、延迟、复制槽增长等指标，并支持基于这些指标向Slack/Email发送警报。

2. 兼容Postgres的SQL CLI：

   • 为偏好命令行的用户提供SQL接口管理CDC，功能与UI对齐，比bash脚本更直观。

3. 灵活的行级数据转换：

   • 支持通过运行时Lua脚本进行行级转换。
   • 可用于加密/脱敏PII数据、支持多种数据格式（JSON、MsgPack、Protobuf等），并提供脚本编辑器和模板。

4. 原生连接器与配置：

   • 为非Kafka目标（如Azure Event Hubs）提供原生连接器和针对性配置选项（例如，支持跨命名空间和订阅分发到主题）。

5. 深度Postgres优化：

   • 专注于Postgres，提供原生指标监控（如复制槽大小、等待事件、连接数等）。
   • 正在开发中的私有测试版功能包括：通过并行快照加快初始加载，以及飞行中事务解码。

当前状态与愿景

• PeerDB的功能集尚未达到Debezium的完整水平，团队承认在发展过程中可能面临类似复杂性挑战，但将可用性置于核心。
• 其长期目标是为PostgreSQL提供最佳的数据迁移（data-movement）体验，PeerDB Streams是朝此方向的重要一步。
• 项目已开源，并提供了快速入门指南和演示，团队积极寻求社区对产品体验、设计理念等方面的反馈。

资源

• GitHub仓库：https://github.com/PeerDB-io/peerdb
• 博客文章：https://blog.peerdb.io/peerdb-streams-simple-native-postgres...
• 快速入门指南：https://docs.peerdb.io/quickstart/streams-quickstart
• UI演示：Loom视频演示
• 示例脚本库：https://github.com/PeerDB-io/examples

Caniemail.com 简介

Caniemail.com 是一个专注于电子邮件客户端兼容性的参考工具，类似于知名的 Can I Use 网站，但专为电子邮件内容设计。该网站帮助开发者和设计师查询特定 CSS 属性、HTML 元素或功能在主流邮件客户端中的支持情况。

主要功能与更新

• 最新特性追踪：网站持续更新并列出邮件客户端对各种 CSS 属性的支持状态，例如：
  • CSS inert
  • CSS font-size-adjust
  • CSS :focus-within
  • CSS :focus-visible
  • CSS animation 这些条目通常附有更新日期（如 2026 年 4 月），表明数据保持最新。
• 新闻与更新：网站定期发布博客文章和更新日志，分享行业动态、新功能发布或技术见解。例如：
  • 纪念网站上线六周年（2025 年 9 月）
  • 月度更新（如 2025 年 8 月、7 月等）
• 赞助商信息：网站展示赞助商内容，当前由 Resend 提供赞助。Resend 是一个面向开发者的邮件服务，专注于提升事务性和营销邮件的送达率。

目标用户

该网站主要面向电子邮件开发者、设计师和营销人员，帮助他们确保邮件内容在不同客户端中的显示一致性和兼容性。通过提供详细的兼容性数据，它简化了邮件模板开发和测试流程。

总结

Caniemail.com 是一个实用且更新及时的工具，专注于解决电子邮件开发中的兼容性难题，通过清晰的兼容性数据和定期新闻更新，支持用户优化邮件内容在各客户端的呈现效果。

Cyperful: Rails 系统测试可视化调试器

Cyperful 是一个为 Ruby Capybara 系统测试设计的插件，旨在为 Rails 应用的端到端测试提供类似 Cypress.io 的优秀开发体验（DX）。

核心功能

• 步骤可视化：在测试运行时，实时查看测试步骤列表并高亮显示当前步骤。
• 交互式暂停：支持在每个测试步骤处暂停，并允许开发者直接与当前页面进行交互。
• 日志监控：在测试步骤之间，可以查看相关的 API 请求和浏览器控制台日志。
• 自动重载：当测试的源代码被修改时，可以自动重启测试。
• 录制回放（实验性）：自动录制测试过程的视频，方便回溯和调试。

框架支持与安装

注意：Cyperful 目前处于 BETA 阶段，可能存在缺陷。仅支持以下环境：Rails 7.1、Ruby 3.2.1、测试框架 Minitest 或 RSpec、Capybara 以及使用 Chrome 浏览器的 Selenium 驱动。

安装步骤

1. 在项目的 Gemfile 中添加 gem（设置 require: false）：

   group :test do
     gem "cyperful", require: false
   end
   

2. 根据所使用的测试框架进行配置：
   • RSpec：在 rails_helper.rb 中添加环境变量判断和配置，确保浏览器驱动设置在 Cyperful 之前。
   • Minitest：在 application_system_test_case.rb 中添加环境变量判断和包含辅助模块。

使用方法

通过设置环境变量 CYPERFUL=1 并运行单个系统测试来启用调试器：

CYPERFUL=1 rails test test/system/my_test.rb:123

重要：目前工具对单次运行单个测试的支持最佳。

配置选项

可以通过 Cyperful.config 对象配置以下选项：

• reload_test_files：源代码修改时是否重置测试。
• auto_run_on_reload：是否在代码修改后自动运行测试（依赖于前一项设置）。
• history_recording：是否录制测试视频。

贡献开发

项目欢迎贡献。开发者可以 Fork 仓库，在本地启动前端开发服务器，并设置环境变量 CYPERFUL_DEV=1 来指向本地开发资产，以进行开发和调试。

Sizewell B 核电站控制室模拟器参观总结

设施与模拟器概况

Sizewell B 是英国目前唯一的压水反应堆（PWR）核电站。其运行培训模拟器是对实际控制室的 1:1 高保真复刻，精准还原了布满开关的控制面板及墙面细节。该站采用西屋 PWR 驱动两台蒸汽轮机，早期的 Sizewell A 已退役，Sizewell C 正在规划中。

控制台与系统功能

• 主控制台：布满带指示灯的开关。系统状态与指令不一致时开关闪烁，操作员按下确认后设备动作，闪烁停止。
• 保护面板：后墙设有带保护盖的红色开关，用于手动触发保护程序。左下角设有紧急停堆（Trip）按钮，按下可使控制棒落入堆芯实现安全停堆。
• 备用控制室：主要用于监控系统状态，交互开关较少。
• 技术架构：模拟器由计算机控制，精准模拟电厂物理与逻辑行为，支持场景演练与教练干预。控制系统自动响应异常，人类主要负责监督，必要时可手动干预（如用操纵杆升降控制棒）。人工干预无需切换“手动模式”，自动保护机制依然生效，体现了良好的人机共生设计。

操作纪律与安全设计

操作受监管机构（ONR）严格规范，所有动作均需遵循详尽手册并接受审查。控制室设有物理防误触设计：

• 安全边界：控制台前设有紫色地毯，未经许可不得踏入，以防跌倒误触开关。
• 准入控制：人员需在红线外等待经理允许方可进入，避免分散操作员注意力。

专业术语与数据记录

• 特定术语：“Reactor trip”（停堆）指控制棒插入使反应堆安全停止，是保护机制正常运作的体现；“Outage”指每 18 个月一次的计划内停机维护与换料，而非意外故障。
• 数据与警报：系统收集海量时间序列数据，可追溯运行以来任意时刻的开关状态。警报声音的音色和频率经精心设计，便于区分同时触发的多种警报。

经验积累与未来展望

现有控制室基于 20 世纪 80 年代技术，凝聚了近半个世纪的安全经验，并吸收了全球核电事故教训（如三里岛事故）。未来的 Sizewell C 计划采用触摸屏替代实体开关，虽易于维护，但会失去部分实体交互的直观优势。