Ruby on Rails 8 主要更新摘要

Rails 8 的首个测试版已发布，它在 Rails 7.2 的基础上引入了一系列新特性、错误修复和改进，旨在提升开发效率和体验。

核心亮点

1. 简化部署：Kamal 2 与 Thruster

• Kamal 2 允许开发者在几分钟内将应用部署到云虚拟机、物理服务器或 VPS 环境，减少了对托管云服务和 PaaS 的依赖。仅需 kamal setup 一个命令即可完成生产环境配置。
• 它与专为 Rails 构建的代理 Thruster 集成，支持零停机部署、HTTP/2、自动 SSL 证书、Gzip 压缩及单服务器托管多应用。
• 开发者可通过 --skip-kamal 选项跳过 Kamal，保持原有部署流程。

2. 轻量化部署与 Solid 适配器

Rails 8 通过三个新的数据库后端适配器，显著减少了对额外服务（如 Redis）的依赖，仅用 SQLite 即可处理常见的 Web 应用需求。

• Solid Cable：取代 Redis 成为新的默认 Action Cable 生产适配器，通过 SQLite 实现发布/订阅功能。
• Solid Cache：利用磁盘存储替代内存缓存，支持更大、更持久且更经济的缓存方案，并具备加密和数据保留策略。
• Solid Queue：取代 Redis 用于 Active Job 后台任务处理，通过 FOR UPDATE SKIP LOCKED 机制高效管理任务，包含并发控制、重试和定时任务等功能。

这些适配器的设计理念是利用现代高速 SSD/NVMe 硬盘的性能，从而不再强制要求内存数据库。

3. SQLite 正式可用于生产环境

得益于对 SQLite 适配器和 Ruby 驱动程序的大量改进，SQLite 现在可以可靠地用于生产环境。

• 支持全文搜索和虚拟表。
• 支持批量插入 fixtures 以提升数据填充性能。
• 事务默认为 IMMEDIATE 模式以提高并发性。
• 改进了错误处理，将 SQLite3::BusyException 转换为 ActiveRecord::StatementTimeout。

4. 新的资产管道：Propshaft

Propshaft 取代了长期使用的 Sprockets，成为新的默认资产管道。它采用更简洁的现代设计，专注于提供清晰的资产路径和缓存摘要戳。复杂的 JavaScript 处理则交由 Esbuild 或 Vite 等专业工具完成。

5. 内置认证系统

Rails 8 整合了多年来积累的认证组件（如 has_secure_password、generates_token_for 等），提供了一个简单的起点。通过运行一个命令，即可生成基于数据库会话和密码重置功能的认证系统所需模型、控制器、邮件和视图文件。

6. 新的脚本目录与生成器

引入了新的 script 目录用于存放一次性或通用脚本（如数据迁移、清理任务）。并提供了脚本生成器，方便创建和执行这些脚本，使项目结构更清晰。

7. ActiveRecord 的多项改进

• 在 PostgreSQL 中区分 float4 和 float8。
• drop_table 支持一次删除多张表。
• 在 PostgreSQL 中创建表时支持继承和分区等高级选项。
• 支持批量插入 fixtures。
• 新数据库迁移前会先加载数据库模式（schema）。
• create_schema 和 drop_schema 操作变为可逆。
• 因支持 datetime 精度等特性，要求 MySQL 5.6.4 或更高版本。
• 在开发环境中默认启用查询日志标签，便于将 SQL 语句追溯到应用代码。

这篇文章详细介绍了作者David Buchanan如何使用一个简单的压电打火机，通过电磁故障注入（EMFI）技术，在笔记本电脑上实现从普通用户到root的权限提升。

核心原理与硬件设置

作者选择了一台老旧的三星笔记本电脑作为目标，其物理上最容易受攻击的部分是连接内存的DDR总线。他将一根电线焊接到内存模块的DQ26数据引脚上（实际错误可能出现在第29位），电线充当天线，接收附近的电磁干扰并将其直接注入数据总线。点击压电打火机即可在天线附近可靠地诱发内存错误，导致数据位翻转。

漏洞利用过程

1. CPython沙箱逃逸（概念验证）：

   • 作者首先在CPython上测试了位翻转利用。核心策略是：创建一个bytes对象，其中内嵌一个精心构造的伪造bytearray结构。
   • 通过反复读取指向该bytes对象的指针（通过大型数组填满CPU缓存，强制从内存读取），并利用打火机触发故障，使指针值翻转第7位（加减128字节），从而使其指向伪造的bytearray对象，获得任意内存读写原语。

2. Linux本地权限提升（最终目标）：

   • 利用memfd和mmap系统调用，将物理内存的50%用0级页表（用于虚拟地址到物理地址转换的最终映射）进行“喷射”。
   • 以绕过TLB的方式循环访问大量映射，迫使CPU在每次访问时进行页表遍历。在此过程中，利用打火机触发故障，希望使某个0级页表项（PTE）读取时发生位翻转。
   • 如果成功，翻转的位会改变PTE指向的物理地址，使其指向之前喷射的另一个0级页表，从而让用户程序获得对页表本身的读写权限。
   • 获得对页表的读写权后，便获得了对所有物理内存的访问权限。作者扫描物理内存，找到setuid的su程序的第一个内存页（该页存在于页面缓存中），并用自定义的、会启动root shell的小型ELF程序替换它。
   • 下次执行su时，系统将使用被污染的页面缓存，从而启动root shell。执行后，程序会刷新页面缓存以恢复正常。

关键技术与挑战

• 缓存绕过：通过创建大于CPU缓存的大型数据结构，并强制循环访问，确保内存读写操作直接到达DRAM总线，从而在总线上注入故障。
• 虚拟内存与页表：攻击利用了现代操作系统虚拟内存管理的核心机制——多级页表。通过喷射和篡改页表项，打破了进程间的内存隔离。
• 可靠性：成功率受多种因素影响（如图形界面活动、后台服务），且故障可能导致系统崩溃。在简单的图形环境下，成功率约为20%；在无图形界面的环境下约为50%。

意义与展望

• 证明了利用极其廉价和简单的工具（打火机）实现高级硬件故障注入攻击的可行性。
• 该技术可能应用于对抗基于TPM的反作弊系统（如Windows游戏或Android的Play Integrity检查），通过故障注入绕过其完整性验证。
• 作者提出了多项开放问题，包括该技术在DDR4/DDR5、ARM架构、带ECC内存的系统上的适用性，以及能否用于虚拟机逃逸或浏览器（如Webkit）漏洞利用。

总结

作者通过将电磁故障注入与对操作系统内存管理机制的深刻理解相结合，成功利用一个打火机实现了从普通用户到root的完整权限提升攻击。这项工作不仅展示了低级硬件漏洞的严重性，也揭示了传统安全边界在物理攻击面下的脆弱性。

Google AI内容操控实验总结

实验概述

作者测试了Google的NotebookLM工具，该工具可根据网页或文档生成播客内容。作者通过技术手段，使同一网页对人类访问者显示正常内容，而对Google的AI爬虫（GoogleOther用户代理）显示虚假的“制作人笔记”——一个关于骑自行车带气瓶飞向月球的虚构故事。NotebookLM完全按照虚假信息生成了播客内容，证明了其可被轻易操控。

核心发现

1. AI易受定向内容影响：NotebookLM能高度准确地按照提供的虚假“制作人笔记”生成对应播客，无需额外编辑。
2. 潜在网络操纵风险：攻击者可针对高排名网页植入“仅AI可见”的隐藏内容，专门操纵大型语言模型（LLM）的认知。当AI搜索网络辅助回答时，可能摄入这些“武器化的谎言”，导致输出被污染。
3. 用户需警惕：即使AI引用了看似合理的来源，其答案仍可能受此类操纵影响。

技术细节

• 引导LLM方法：通过向NotebookLM提供虚假的“制作人笔记”可控制其生成内容结构。
• 欺骗爬虫技术：使用如isai等工具检测AI用户代理（如GoogleOther），仅向AI提供定制化虚假内容，而向人类用户展示正常网页。但作者提醒，此类行为可能波及其他Google服务，需谨慎使用。

关键警示

此类针对AI的内容操纵可能已广泛存在，用户应对AI基于网络生成的答案保持审慎态度。

自动化流程的深层挑战

核心观点

自动化远比许多人想象的困难。难点不在于处理常规任务，而在于应对例外情况和不完整、不确定的输入。随着时间的推移，大多数系统实际上是在处理异常流程，而非标准流程。

主要挑战

1. 例外驱动的复杂性
   自动化的难度源于处理例外情况。例如，库存系统需要应对客户自提、货到付款、佣金变动或运费计算方式变化等不断出现的例外情况，导致系统逻辑变得复杂且脆弱。

2. 输入的不确定性
   许多流程（如旅行规划、医疗诊断）的输入本身就不确定或模糊。例如，医疗诊断中患者的症状可能不完整或存在多种解释（肩痛可能是运动损伤，也可能是癌症转移），这使得自动化决策风险极高。

3. 规则与上下文的复杂性
   即使看似简单的任务（如会议安排），也涉及多方偏好、时间协调和不断变化的日程，没有标准化的流程。许多自动化尝试只是将复杂性转移，而非真正解决。

现实案例

• 商业系统：作者早期开发的库存系统因不断出现的业务例外（如客户自提、现金支付等）而逐渐变得复杂。
• 医疗诊断：自动化诊断工具可能基于不完整信息或实验室数据的微小偏差做出最坏情况推断，导致过度医疗或误诊。
• 会议安排：尽管有日历工具，但实际协调仍需人工干预，因为涉及个人偏好、突发变更和组织动态。

对自动化的反思

• 自动化不是替代，而是增强：真正的突破可能像产品管理一样，需投入大量精力定义系统输入和处理例外的方式。
• AI作为工具：AI应被视为辅助工具，其责任由部署者承担，而非工具本身。这类似于计算器或个人电脑的监管方式。
• 未来方向：自动化可能不会直接完成现有任务，而是重新定义工作流程，就像计算机彻底改变了会计和库存管理一样。

结论

自动化的核心难点在于处理不确定性和例外情况。成功的自动化往往需要重新设计流程，而非简单地模拟现有步骤。AI的潜力可能在于推动基础设施数字化重构，而非逐步改进现有流程。

# Python 3.13.0 发布摘要

Python 3.13 是 Python 编程语言的最新稳定版本，于 2024 年 10 月 7 日发布。它在语言、实现和标准库方面带来了多项重要更新。以下是主要亮点和变更的概述。

## 核心语言与解释器改进

*   **全新的交互式解释器**：默认启用基于 PyPy 项目代码改进的交互式 Shell。新特性包括：
    *   支持多行编辑并保留历史记录。
    *   直接支持 `help`、`exit`、`quit` 等 REPL 命令，无需作为函数调用。
    *   提示符和错误回溯默认启用彩色显示。
    *   支持 F1 浏览帮助、F2 浏览历史（跳过输出）和 F3 进入“粘贴模式”。
    *   可通过设置环境变量 `PYTHON_BASIC_REPL` 禁用。
*   **改进的错误消息**：
    *   终端中的错误回溯（traceback）默认使用彩色显示。
    *   当脚本名与标准库或第三方模块名冲突导致导入错误时，现在会给出更清晰的提示。
    *   当函数收到错误的关键字参数时，会尝试建议正确的参数名。
*   **`locals()` 语义定义（PEP 667）**：现在在优化作用域（如函数内）中，`locals()` 每次调用都返回一个**独立的快照**，而不是一个共享的、可能被其他代码（如调试器）更新的字典。`FrameType.f_locals` 现在返回一个**直写代理**（write-through proxy）。
*   **实验性自由线程模式（PEP 703）**：CPython 现在有**实验性支持**在禁用全局解释器锁（GIL）的情况下运行。此模式允许线程在多个 CPU 核心上完全并行执行，有望提升多线程程序性能。需要注意：
    *   这是实验性功能，默认不启用。
    *   需要使用特定的可执行文件（如 `python3.13t`）。
    *   预期会存在一些 Bug 和单线程性能下降。
    *   C 扩展模块需要特别构建以支持此模式（使用 `Py_mod_gil` 插槽）。
*   **实验性即时编译器（JIT）（PEP 744）**：通过构建选项 `--enable-experimental-jit` 启用。目前默认关闭，性能提升有限，预计在未来版本中改进。其内部架构涉及分层优化（Tier 1 字节码 -> Tier 2 中间表示 -> 机器码）。
*   **其他语言变更**：
    *   编译器现在会去除文档字符串（docstring）中的公共前导空白。
    *   类作用域内的注解作用域现在可以包含 lambda 和推导式。
    *   `__future__` 的相对导入不再触发未来语句。
    *   `global` 声明现在允许在 `except` 块中使用，只要该变量在对应的 `else` 块中使用。
    *   新增 `__static_attributes__` 和 `__firstlineno__` 类属性。
    *   `exec()` 和 `eval()` 现在接受 `globals` 和 `locals` 关键字参数。

## 标准库重要更新

*   **新增模块**：
    *   `dbm.sqlite3`：一个基于 SQLite 的 `dbm` 后端，现已成为默认后端。
*   **新增特性与改进**：
    *   `argparse`：支持对命令行选项、位置参数和子命令进行弃用。
    *   `base64`：新增 `z85encode()` 和 `z85decode()` 函数，支持 Z85 编码。
    *   `copy`：新增 `copy.replace()` 函数，用于创建修改后的对象副本，支持许多内置类型和实现 `__replace__()` 方法的类。
    *   `os`：新增一系列用于操作 Linux 定时器文件描述符的函数（`timerfd_create()` 等）。
    *   `random`：新增命令行界面。
    *   `ssl`：`create_default_context()` 现在默认设置更严格的 `VERIFY_X509_STRICT` 验证标志。
    *   `typing`：新增 `ReadOnly`（PEP 705）、`TypeIs`（PEP 742）等类型，类型参数支持默认值（PEP 696），新增 `warnings.deprecated()` 装饰器（PEP 702）。
*   **平台支持扩展**：
    *   Apple iOS（PEP 730）和 Android（PEP 738）现在成为官方支持的第 3 级（tier 3）平台。
    *   `wasm32-wasi` 提升为第 2 级（tier 2）支持平台。
    *   `wasm32-emscripten` 不再是官方支持平台。
*   **重要移除**：
    *   根据 PEP 594，移除了 19 个“遗留电池”模块，包括 `aifc`、`cgi`、`crypt`、`imghdr`、`telnetlib` 等。
    *   移除了 `2to3` 工具和 `lib2to3` 模块。
    *   移除了 `tkinter.tix` 模块。
    *   移除了 `locale.resetlocale()` 函数。
    *   移除了 `typing.io` 和 `typing.re` 命名空间。
    *   移除了链式 `classmethod` 描述符。

## C API 变更

*   **新功能**：
    *   新增 `Py_mod_gil` 插槽，用于扩展模块指示其支持在禁用 GIL 的情况下运行。
    *   新增 `PyTime` C API，提供对系统时钟的访问。
    *   新增 `PyMutex`，一个占用单字节的轻量级互斥锁。
    *   新增一套用于生成 PEP 669 监控事件的函数。
    *   新增许多辅助函数，例如返回强引用的 `PyDict_GetItemRef()`、`PyList_GetItemRef()` 等。
*   **已弃用**：软弃用返回借用引用的 `PyEval_GetBuiltins()`、`PyEval_GetGlobals()`、`PyEval_GetLocals()`，推荐使用新函数 `PyEval_GetFrameBuiltins()` 等。
*   **已移除**：移除了大量以前以下划线（`_Py`）或（`_PY`）开头的内部/私有函数和宏。如果项目受影响，可考虑使用 `pythoncapi-compat` 项目。

## 发布周期变更

根据更新的 PEP 602 政策，Python 3.13 及之后的版本将获得**两年**的全功能（bugfix）支持期，随后是**三年**的安全修复期。

## 升级注意事项

*   `locals()` 和 `f_locals` 的行为变更可能影响依赖旧有共享字典行为的代码，特别是调试器和代码执行工具。
*   许多标准库模块的导入时间已得到优化。
*   `textwrap.indent()` 对于大型输入的性能提升约 30%。
*   `subprocess` 在更多场景（如 `close_fds=True`）下使用 `posix_spawn()`，在某些平台上可提升进程启动性能。

更多详细信息请参阅官方文档、变更日志和具体的 PEP 文档。

John Carmack 论内联代码

John Carmack 在 2007 年和 2014 年的评论中讨论了内联代码的编程风格，强调了对状态管理、代码意识和可靠性的关注。以下是主要内容总结：

核心观点

• 内联代码的主要敌人是状态的意外依赖和变异，函数式编程可以更直接地解决这些问题。如果必须进行大量状态更改，内联能让开发者清楚看到执行过程，当过于复杂时，应将块分解为纯函数。
• 航空航天软件示例：禁止子程序调用和向后分支，所有代码内联以提高可靠性。Carmack 尝试在 Armadillo 火箭代码中应用内联，发现了变量多次设置、控制流问题，并使代码更小更清晰。
• 性能与可靠性：内联不是为了直接提升性能，而是提高对代码执行的意识，减少帧时间变异性，优先考虑最坏情况性能而非平均情况。
• 2014 年更新：Carmack 更强烈支持纯函数式编程，即使在 C/C++ 中；提到 Doom 3 BFG 版本中差点出现输入延迟错误；在移动等功耗约束环境中，“执行然后抑制”策略可能不适用。

内联代码的好处

• 提高代码意识：开发者能全面了解每帧执行的代码，避免忽略重要状态更新，减少因条件跳过操作导致的bug。
• 减少延迟：避免因嵌套调用导致的输入延迟，确保操作按顺序执行。
• 防止代码重复bug：函数只在单一位置调用时，内联避免了从多处调用带来的状态不一致问题。
• 简化控制流：减少条件执行路径，采用“执行然后抑制”策略，提高帧时间一致性。

实践建议

1. 内联时机：
   • 如果函数只被调用一次，考虑内联。
   • 如果函数被多次调用，尝试通过标志在单一位置执行工作并内联。
   • 合并多个函数版本为一个，使用默认参数。
2. 函数式编程：
   • 尽可能使函数纯函数化（只读输入、返回值，不修改全局状态）。
   • 使用 const 参数和函数来减少副作用。
3. 编码风格：
   • 在主要函数中使用注释块分隔内联部分，并用大括号限定作用域，方便折叠和扫描。
   • 避免过度模块化，优先考虑顺序执行的代码内联，但需权衡模块化和可维护性。
4. 避免bug：
   • 减少控制流复杂性，优先执行一致路径。
   • 明确循环和数组操作，避免复制粘贴修改错误。

总结

Carmack 认为内联代码能提升代码意识、减少bug和延迟，但需结合函数式编程和谨慎判断。关键是在可靠性、性能和可维护性之间取得平衡，特别适用于实时系统如游戏开发。

ARIA DevTools：网站无障碍树可视化工具

核心功能：该工具能将网站以屏幕阅读器（盲人用户使用的辅助技术）的视角呈现，可视化展示无障碍树。这有助于开发者直观地发现和修复无障碍性问题，主要包括：

• 检测缺失的ARIA标签
• 识别被误用的ARIA角色
• 排查不完整的键盘操作支持

主要价值：通过提供直观的无障碍视图，显著简化了无障碍网站的测试与开发流程，降低了理解残障人士如何使用电脑的难度。

项目详情：

• 性质：开源项目。
• 代码仓库：https://github.com/ziolko/aria-devtools
• 版本：1.4.2（更新于2026年5月27日）
• 开发者：Mateusz Zieliński (邮箱：mateusz@roombelt.com)
• 大小：156 KiB

隐私政策：

• 开发者声明不会收集或使用你的数据。
• 你的数据不会被出售给第三方。
• 你的数据不会被用于与项目核心功能无关的用途。
• 你的数据不会被用于信用评估或贷款目的。

背景：ARIA DevTools 是众多Web无障碍测试相关工具中的一款，旨在通过可视化手段提升无障碍开发效率。

未曝光的雷鸟电影胶卷在花园小屋中被发现

在花园小屋中发现了大量未曝光的雷鸟电影胶卷。这些材料大部分与已播出的内容相同，但其中包括一段替代编辑的剧集，包含以前未见过的场景。La Rivière先生指出，胶卷因损坏而暴露在自然环境中，因此需要先进行修复工作。修复后，这些胶卷计划在2025年公开展示，结束了60年“躺在角落等待被发现”的状态。

文章探讨了使用 htmx 构建单页面应用（SPA）的方式，尤其是在无需远程服务器的情况下，利用 service worker 和 IndexedDB 实现本地数据存储与交互。作者以一个待办事项列表为例，详细说明了如何将 htmx、service worker 和客户端存储结合，达到 SPA 效果，并分析了与传统 SPA（如 React）方式的差异、优劣和实际应用场景。

核心思想与实现架构：

• htmx 通常用于管理网络上的超媒体交换，但本文实验性地用于构建本地 SPA。
• 本地 SPA 的“服务器端”逻辑实际运行在浏览器的 service worker 中，拦截 htmx 的网络请求并直接生成响应 HTML。
• IndexedDB 用于状态持久化，关闭页面再打开时数据依然存在，实现“免费”数据保持和离线功能。
• 前端页面结构为单一 HTML，内容通过 htmx 的数据请求动态填充。 标签上设置了 hx-boost、hx-push-url、hx-get、hx-target、hx-trigger 等属性，实现页面加载时自动获取 UI、拦截表单/链接操作并进行内容局部替换、无刷新体验。
• service worker 使用简易 Express-like 路由库处理不同 data endpoint，如 /ui、/todos/add、/todos/:id/update、/todos/:id（delete）、/ui/todos/:id（切换编辑状态），并返回 HTML 响应。
• 业务数据持久化通过 IDB Keyval 简化 IndexedDB 的调用，实现 todo 列表增加、删除、筛选、更新（含编辑状态切换）。

主要组件与交互细节：

• App 组件负责渲染 filters 表单（全部/活跃/已完成）、todos 列表和添加新 todo 的表单。hx-boost 拦截所有表单提交，局部更新页面。
• Todo 项目包含复选框（完成状态）、删除按钮和文本。复选框触发 /todos/:id/update，删除触发 /todos/:id 的 DELETE。双击文本切换为编辑输入框，通过 /ui/todos/:id?editable=true 获取新 HTML，失焦/变更后提交至 /todos/:id/update，再刷新内容。
• 所有路由操作都以 HTML 形式返回，htmx 根据目标属性局部替换页面内容，无需整体刷新。

与传统 SPA（如 React）对比及优缺点：

• React 的 SPA 需协调客户端与服务器的数据通信，通常较为复杂。而 htmx/service worker 架构下，UI渲染与数据同在本地，省去很多通信流程。
• Service worker 的 IndexedDB 本地存储令状态持久化和离线更容易实现，但开发体验不佳。例如开发工具支持不足、Firefox 对 ES modules 支持有限，需要将所有代码合并为单文件。
• 完全本地的 htmx SPA 效率虽高，但 UI 更新的“间接性”较 React 更繁琐，因为每个操作都要发起请求+服务端逻辑生成HTML再局部替换，而 React 可同步直接更新内存状态并渲染。
• 该模式适用于本地、无需远程服务器的应用场景；对于需要本地与网络交互混合的应用，建议采用“交互岛”架构（Islands Architecture）。

结论与其他工具：

• htmx 的本地 SPA 是一种新尝试，更多是工具能力的拓展演示。实际开发时应考虑场景：全本地可用此法，大多数应用还是混合架构为佳。
• 类似 Mavo 这类工具专注于简单可视化的数据型 SPA，开发体验、代码复杂度可能优于当前 htmx/service worker 方案。
• hypermedia 是一种方法论，不限于某一工具，htmx 只是目前流行的代表。
• 作者认为这个实验性 SPA 展示了工具的灵活性，并鼓励开发者尝试不同方式扩展认知和实现方案。

代码及详细实现可参考作者开源仓库（jakelazaroff/htmx-spa）。

概要

据《华尔街日报》报道，包括Verizon、AT&T和Lumen Technologies在内的多家美国大型宽带提供商遭到中国黑客组织“Salt Typhoon”入侵。攻击目的疑似为情报收集，黑客可能已访问了美国联邦政府用于执行法院授权窃听请求的网络系统。

攻击详情

• 时间与持续：入侵发生在最近几周内被发现，但黑客可能已持网访问相关基础设施长达数月或更久。
• 影响评估：据称黑客从这些互联网服务提供商（ISP）处收集了大量互联网流量，其客户包括大小企业及数百万美国人。目前，攻击造成的具体数据泄露量及类型仍在评估中。
• 目标范围：除美国外，Salt Typhoon可能也入侵了其他国家的类似实体。

黑客组织背景

• 命名与追踪：该组织被微软命名为Salt Typhoon，其他安全公司对其有不同的追踪代号，如Earth Estries、FamousSparrow、Ghost Emperor、UNC2286等。
• 活动历史：该组织至少自2019年起活跃，通常专注于攻击东南亚地区的政府实体和电信公司，但也曾涉及巴西、南非、加拿大、英国等多国的酒店、工程公司和律师事务所。
• 攻击手法：历史上常利用漏洞（如Microsoft Exchange Server的ProxyLogon漏洞）获取初始访问权限，并使用自定义后门（SparrowDoor）、Mimikatz定制版和内核模式 rootkit（Demodex）等工具。

当前调查与关联活动

• 调查进展：美国政府和私营安全专家正在调查此次事件。攻击的初始访问方法仍在调查中，一种被探索的途径是入侵负责路由互联网流量的Cisco路由器，但Cisco表示未发现其设备被卷入的迹象。
• 相关趋势：近期中国APT组织（如Volt Typhoon、Flax Typhoon）频繁瞄准美国和欧洲的网络设备及ISP。例如：
  • Volt Typhoon曾利用Versa Director零日漏洞入侵ISP和MSP。
  • Flax Typhoon构建了一个感染超26万台路由器和IP摄像头的僵尸网络。
• 共同点：尽管这些攻击归属于不同的中国黑客组织，但它们被认为在同一框架下运作，通常共享基础设施和工具。

涉事方回应

• AT&T、Lumen均拒绝就报道置评。
• Verizon未回应置评请求。
• Cisco正在调查但未发现设备被利用的证据。

两种软件设计哲学的对比与“劣胜优汰”现象

本文主要对比了两种软件设计哲学：“the right thing”（MIT 方法）和“worse-is-better”（新泽西方法），并论证了后者在实际演化中更具生存优势。

“the right thing” (MIT 方法) 的特点：

• 简洁性：实现和接口都需简洁，但接口的简洁比实现更重要。
• 正确性：所有可观测方面都必须正确。
• 一致性：不允许不一致，一致性与正确性同等重要。
• 完整性：尽可能覆盖所有重要情况，完整性不可轻易牺牲。
• 代表：Common Lisp、Scheme。

“worse-is-better” (新泽西方法) 的特点：

• 简洁性：同样要求简洁，但实现的简洁比接口更重要，且简洁性是首要考虑。
• 正确性：应尽量正确，但简洁略优先于绝对正确。
• 一致性：为求简洁可牺牲一致性，优先删减低频场景而非增加复杂度。
• 完整性：可为实现简洁性牺牲完整性；接口一致性尤其不重要。
• 代表：早期 Unix、C 语言。

作者通过一个轶事生动说明了二者的分歧：在处理系统中断导致的“PC loser-ing”问题时，Unix 选择了在系统调用中返回错误码、由用户程序重试的实现简洁方案，而 MIT 的方法则要求系统回滚到调用前状态的接口简洁方案。

为何“worse-is-better”更具生存优势？

1. 病毒式传播：Unix 和 C 因实现简洁，易于移植到性能较弱的半数机器上。只要功能基本够用，便能像病毒一样广泛传播。
2. 用户预期管理：用户被“训练”接受不完美的解决方案，并习惯于在性能、资源与便利性间妥协。
3. 渐进式改进：一旦软件普及，后续会有动力将其功能提升到接近“正确的”程度（如从 50% 到 90%），但用户已接受其核心是“更差的”。
4. 促进组件化与集成：由于语言和系统功能有限，大型系统必须依赖组件重用，从而催生了集成传统。

相比之下，“the right thing”常陷入两种困境：

• 大而全的系统：设计复杂，实现耗时，对硬件要求高，最后 20% 的功能耗费 80% 的精力。
• 钻石般的珍宝：设计精巧但极难实现，或运行缓慢。

结论与启示： 作者认为，“worse-is-better”的成功并非因其“更好”，而是因其在现实世界的演化中更具适应性。它先以基本正确、易于实现的“半成品”快速占领市场，再逐步完善。反之，“the right thing”常因追求完美而延迟发布，错失机会。

文章最后警示：Lisp 社区需要反思其设计哲学，因为 Unix 和 C 的“病毒”策略已证明其有效性。对软件设计的启示是：有时，先提供一个功能足够、可移植的“不完美”系统，再渐进改进，比一开始就追求完美更为可行。

加州成为美国首个禁止使用"销售日期"标签的州，旨在减少食品浪费。该立法由州长加文·纽森于2024年9月28日签署，将于2026年7月1日生效，适用于所有人类食品的制造商、加工商和零售商。

新法规内容
除婴儿配方奶粉、鸡蛋、啤酒及麦芽饮料外，所有食品的日期标签必须标准化。食品需明确标注“最佳食用日期”（表示品质最佳）或“食用截止日期”（表示安全期限）。此举旨在消除消费者对模糊标签（如“销售日期”、“最鲜日期”）的困惑，避免因误解而丢弃仍可安全食用的食品。

销售日期标签导致浪费的原因
美国联邦政府除婴儿配方奶粉外未对食品日期标签作统一规定，导致标签语言混乱。销售日期原意是提醒商家调整库存，并非指示消费者食品的可食用性。研究表明，消费者常误将销售日期视为安全期限，从而提前丢弃食品。标准化标签后，“最佳食用日期”明确品质非安全问题，“食用截止日期”则标识安全风险，可有效减少误解。

食品浪费的影响
据非营利组织ReFED统计，美国每年约7800万吨（占总量33%）食品被浪费，仅加州2022年浪费量近1200万吨。浪费的食品在填埋场分解时产生甲烷，其温室效应比二氧化碳强28倍，加剧气候变化。此外，食品浪费造成巨大经济损失，仅因标签困惑导致的浪费每年高达150亿美元。

新法规的预期效益
新法通过统一标签语言，预计每年可防止加州7万吨食品被浪费，并为消费者节省3亿美元。这不仅有助于应对气候变化，也能减轻家庭和零售商的经济负担。

减少浪费的建议
公众可通过捐赠仍可食用的食品、妥善堆肥有机废物（分解时甲烷排放更少）等方式参与减少浪费。随着标签标准化，消费者将更容易理解食品期限，从而做出更明智的购买和消费决策。

本文探讨了AVX-512指令集中的vpternlogd（位运算三元逻辑指令）与1980年代Amiga计算机的blitter芯片之间的惊人相似性。

核心观点是两者均使用一个8位立即数来定义三个输入源（例如寄存器A、B、C）之间任意的布尔逻辑操作。这避免了为每种复杂逻辑（如(NOT A) OR ((NOT B) XOR (C AND A))）创建单独指令，是一个高度灵活的设计。

文章指出，这个8位立即数本质上是一个查找表（真值表）的编码。计算其值的简单方法是：

1. 列出三个输入位（A、B、C）的8种可能组合。
2. 为每种组合明确指定想要的输出结果（0或1）。
3. 将这8个结果位从下至上读取，得到的8位二进制数即为所需的立即数值。 例如，若要实现在“恰好有两个输入为1时输出1”的逻辑，填写真值表后得到立即数0x68。

文章通过一个常见示例进行了验证：Amiga上用于绘制遮罩精灵的blitter minterm值0xE2。通过同样的真值表方法（当遮罩位B为1时使用精灵源A，否则使用背景C），计算得出的结果正好是0xE2。

最后，作者注意到一个有趣的巧合：在Intel官方关于vpternlogd指令的文档示例中，选择的立即数恰好就是0xE2，暗示了历史与现代技术设计的巧妙呼应。

Sq.io：用于数据库和更多场景的jq工具

Sq.io 是一款免费/自由开源的数据处理瑞士军刀工具，可用于检查、查询、关联、导入和导出数据。可以将其理解为针对数据库和文档的jq工具，能够方便地执行单行命令，例如：

sq '@postgres_db | .actor | .first_name, .last_name | .[0:5]'

安装方式

# 通用脚本安装
/bin/sh -c "$(curl -fsSL https://sq.io/install.sh)"

# Windows (Scoop)
scoop bucket add sq https://github.com/neilotoole/sq
scoop install sq

此外也支持通过 apt、yum、apk、pacman、yay 等包管理器安装，具体选项请查阅安装页面。帮助信息可通过 sq help 获取，详细文档请参考官方文档站点。

发音说明：Sq 读作 "seek"，其查询语言 SLQ 读作 "sleek"。

核心功能亮点

1. 比较数据库表

使用 diff 命令比较源数据库的元数据或行数据差异。

2. 将Excel工作表导入PostgreSQL

将Excel XLSX文件中名为 actor 的工作表内容插入到新的PostgreSQL表 xl_actor 中。导入机制能较好地保留数据类型。

3. 查看数据库元数据

为 sq inspect 添加 --json 标志，可将架构及其他元数据以JSON格式输出，常通过管道传递给 jq 提取所需信息：

sq inspect @sakila_my.actor -j | jq -r '.columns[] | .name'

4. 跨数据库执行SQL并导入结果

添加（已存在的）SQL Server源并创建新的SQLite源，然后对SQL Server执行原生SQL查询，并将结果插入SQLite：

sq add sqlserver://sakila:xxxxx@localhost?database=sakila
sq add sqlite3:///tmp/sakila.db
sq sql 'SELECT * FROM actor' --insert @sqlite3

5. 导出所有数据库表为CSV

获取活动源的JSON元数据，通过 jq 提取表名，再用 xargs 针对每个表调用 sq 导出为CSV文件：

sq inspect -j | jq -r '.tables[] | .name' | xargs -I % sq sql 'SELECT * FROM %' --csv --output %.csv

源管理命令

• sq src：显示活动源
• sq add ./actor.tsv：添加源
• sq src @actor_tsv：设置活动源
• sq ls：列出源（-v 详细模式）
• sq group：获取/设置活动组
• sq mv @sales @prod/sales：重命名源
• sq ping --all：探测所有源
• sq rm @actor_tsv：移除源

数据库表操作命令

支持对单个数据库内的表进行复制、清空和删除操作：

sq tbl copy .actor .actor2   # 复制表
sq tbl truncate .actor2      # 清空表
sq tbl drop .actor2          # 删除表

注意：跨数据库复制需使用 --insert 机制。

查询JSONL日志文件

Sq.io可直接处理JSONL（每行一个JSON对象）格式的日志文件，例如其自身输出的日志：

{"level":"debug","time":"00:07:48.799992","caller":"sqlserver.go:452","msg":"Close database"}

通过这些功能，Sq.io提供了一种统一、便捷的方式，以类SQL或jq的语法操作多种数据源（包括数据库、文件等），极大简化了日常数据查询、转换与迁移工作。

本文探讨了将B树作为哈希表（HashMap）默认关联数据结构的替代方案的可行性，并针对其性能进行了深入的基准测试与分析。

哈希表的问题与B树的潜在优势 许多脚本语言默认使用哈希表，但哈希表存在一些固有缺陷：容易遭受哈希洪泛攻击；为防御此攻击而使用随机种子会导致迭代顺序不确定；插入时可能需要重新哈希，造成最差情况下的高延迟；在WebAssembly（wasm）目标上，重复扩大分配难以避免内存碎片；wasm上向量指令有限且无AES指令，导致许多哈希函数变慢。有序数据结构（如B树）则没有这些缺点，但通常认为其速度慢于哈希表。

基准测试方法与结果分析 作者进行了一系列基准测试，发现结果高度依赖测量方法：

1. 吞吐量 vs 延迟：最初的简单测试（lookup_hit_all和lookup_hit_one）显示了巨大的性能差异，原因在于测量的是平均延迟还是批量吞吐量。
2. 改进的测试：随后设计了更严谨的测试（lookup_hit_batch和lookup_hit_chain）。关键发现在于哈希表能利用多次查找之间的推测执行来提升吞吐量（batch模式），而B树则几乎无法从中受益（chain模式）。在chain模式下（每次查找的地址依赖于上一次的结果，阻止推测执行），哈希表（尤其是使用wyhash时）延迟显著增加，而B树延迟变化不大。
3. 性能因素：
   • 推测执行：哈希表计算哈希值的过程是几条无分支指令，可在等待缓存时推测执行下一次计算。B树则需要多次比较和分支，推测执行难以生效。
   • 缓存行为：哈希表（尤其是开放寻址）通常只需访问1-2条缓存行，而B树需要多次缓存访问（每层一次），且访问之间存在数据依赖，不利于预取。
   • 键类型影响：对于字符串键，特别是存在公共前缀时，B树性能会严重下降，因为每次比较都可能需要一次缓存访问。哈希表则不受此影响。
   • 环境影响：在wasm上测试，哈希函数的性能相对损失，但总体比例与x86类似。

B树优化尝试 作者尝试了多种B树优化，包括：

• 选择B+树以优化范围查询。
• 将节点大小固定为512字节（而非固定键数），这是测试中的性能甜点。
• 手动安排节点内存布局以优化缓存。
• 在搜索中使用**“无分支”二分查找**，但线性搜索在大多数情况下更快。
• 尝试了将键插入未排序叶子节点的变体，但最终因需要排序而未获益。

结论与权衡 尽管进行了优化，作者最终不认为B树值得进一步探索作为默认数据结构，主要原因包括：

1. 延迟敏感场景：单次或零星查找时，B树可能未在缓存中，导致极高的延迟（访问主存），而哈希表访问次数相对固定。
2. 内存占用：B树节点通常只有约67%的占用率（插入删除后），加上节点元数据开销，预计比哈希表多使用超过60%的内存。
3. 优化复杂性：针对不同键类型（特别是字符串）和不同场景的优化非常复杂。
4. 哈希表的替代方案：作者认为更好的方向是改进哈希表，例如：将哈希函数作为稳定API的一部分、使用保持插入顺序的开放寻址哈希表、通过回退到树结构来防御哈希洪泛，或考虑哈希数组映射尝试（HAMT）或内存LSM树等结构。

测试环境 测试在Intel i7-1260P上进行，禁用了效率核心、设置了性能调节器并禁用了涡轮模式，使用了Rust和Zig的特定编译器版本。

文章总结

2023年9月6日，56岁的苏格兰山地徒步爱好者查理·凯利（Charlie Kelly）在攀爬克雷斯山（Creise）时失踪。尽管格伦科山地救援队（Glencoe Mountain Rescue）动用了搜救犬、直升机、无人机等大量资源进行“赫拉克勒斯式”搜索，但六周内仅找到其背包，未发现踪迹。10月24日，来自湖区（Lake District）的救援志愿者丹·罗奇（Dan Roach）和大卫·宾克斯（David Binks）使用自研的无人机软件，在首次搜索时便找到了凯利的遗体。

该软件是宾克斯基于已有的山地救援地图工具（MR Maps）开发的扩展程序，并非人工智能（AI），但通过自动化飞行路径规划和图像分析提升了搜索效率。其核心功能包括：

• 飞行规划：利用英国地形测量局（OS）的激光雷达数据自动规划无人机路径，确保地面覆盖完全，避免死角。
• 位置计算：通过旋转向量算法计算图像中每个像素的精确网格坐标。
• 颜色异常检测：软件不预设特定颜色（如红色夹克），而是自动统计图像中各类颜色的像素分布，突出显示与环境不协调的颜色簇（如岩石地中的绿色），再由人工复核。该系统可离线运行，适用于偏远地区。

罗奇、宾克斯及其伙伴丹·帕森斯（Dan Parsons）均为志愿者，他们出于兴趣和实战需求开发了此软件。传统山地救援团队倾向于手动操控无人机，而他们主张自动化搜索，以应对复杂地形（如岩石、沟壑）。尽管初期遭遇质疑，但软件在凯利案例中首次验证成功——凯利身穿的棕色上衣和深蓝裤子在人工搜索中难以识别，但在软件分析中异常醒目。此后，该软件在其他搜索任务中帮助排除区域，提高了救援效率。

英国山地救援完全由志愿者运营，面临任务量激增的压力（部分团队年呼叫量超300次）。此软件有望减少资源消耗，尤其适用于正式搜索（占年呼叫量的10-15%）。开发者不谋求商业化，坚持免费提供给全球救援团队，包括警方。

对凯利的伴侣埃默·肯尼迪（Emer Kennedy）而言，软件带来了一个终结：家人得以告别，避免了漫长等待。该案例突显了技术创新如何弥补传统救援的局限，为志愿者提供了宝贵工具，同时体现了救援社区无私奉献的精神。

HTTP服务器通过Content-Length头告知客户端响应体的大小，其确定方式取决于响应大小：

小响应处理
当响应数据足够小（如Go中默认的缓冲区大小内），服务器会先在内存中缓冲整个响应体，计算其字节长度，然后一次性写入连接。例如，响应"Hello world!"（12字节）时，服务器在发送前已知总长度，故添加Content-Length: 12头后发送整个响应。

大响应处理
当响应过大无法一次性缓冲时（如示例中的3000个感叹号），服务器会采用分块传输编码（Transfer-Encoding: chunked）。此时：

1. 响应头包含Transfer-Encoding: chunked，而非Content-Length。
2. 响应体被分为多个块，每块前以十六进制数字标注该块的大小（如800对应2048字节，3bd对应957字节）。
3. 最终以一个大小为0的空块结束传输。客户端通过累加各块大小确定总长度。

技术细节

• 分块传输在HTTP/1.1中引入，允许流式发送未知长度的数据，并支持尾部（trailers），可在消息体后发送额外头信息（如数字签名）。
• HTTP/2和HTTP/3使用自身的流机制，不再支持分块传输。
• Go的net/http包自动处理这些逻辑：小响应隐式计算Content-Length，大响应自动切换为分块传输，并支持尾部声明。

总结：服务器根据响应大小自动选择策略——小响应预先计算长度，大响应通过分块传输逐步发送，从而平衡内存使用与传输效率。

Gleam Is Pragmatic 文章摘要

本文作者基于多年使用 Haskell 和 OCaml 的经验，指出 Haskell 简洁优雅但隐式且懒惰评估有缺点，而 OCaml 显式但过于冗长。通过介绍 Gleam 编程语言，作者认为它通过三个关键设计决策，务实结合了两者优点，且缺点较少。

Gleam 的三个核心设计选择

1. use 表达式：作为回调风格 API 的语法糖，简化嵌套回调为扁平代码。
2. 结构相等性：所有类型（包括用户自定义类型）自动支持相等比较，无需额外定义。
3. 无特设多态（ad-hoc polymorphism）：避免隐式类型类，保持代码显式。

Gleam 语言概述

Gleam 是强类型函数式编程语言，目标平台为 BEAM（Erlang 虚拟机）和 JavaScript。它允许非纯副作用，标准库数据结构不可变。示例代码展示了可选类型注解、一等函数、显式导入、可见性修饰符、列表字面量语法和管道运算符 |> 等特性。

Monadic 风格 API 比较

作者以键值查找可能失败的操作为例，对比三种语言的实现：

• Haskell：使用 do 符号和 Maybe 类型，隐式调用 Monad 函数，代码简洁但隐式。
• OCaml：需要显式定义 let* 和 return 函数，并通过局部模块打开实现，代码显式但冗长。
• Gleam：使用 result.try 函数和 use 表达式，显式调用且通过 use 消除回调嵌套，结合显式性和简洁性。

自定义类型作为键的比较

当使用自定义类型作为 Map 键时：

• Haskell：需要派生类型类（如 Eq、Ord）。
• OCaml：需手动实现比较函数，代码冗长。
• Gleam：自动支持结构相等性，无需额外代码，直接使用自定义类型作为键。

结论

Gleam 务实地融合了 Haskell 和 OCaml 的优点，减少了隐式性带来的混淆和冗长代码的负担。其 use 表达式等特性已用于构建解析器组合器、解码器等库，展示了实用性和灵活性，对函数式编程新手和经验者均有吸引力。

2024年诺贝尔生理学或医学奖授予了Victor Ambros和Gary Ruvkun，以表彰他们“发现microRNA及其在转录后基因调控中的作用”。两位科学家平分奖金。

该奖项是诺贝尔基金会本年度颁发的六项诺贝尔奖之一，旨在表彰“为人类带来最大益处”的成就。今年的14位获奖者的工作和发现涵盖了从量子隧穿到促进民主权利等多个领域。

故事梗概

本文是一部设定于英国贵族庄园背景下的悲剧爱情故事，主要讲述了庄园主之女伊丽莎·阿什伍德与园丁托马斯之间跨越阶级的禁忌之恋，及其在重重社会压力下走向破碎的过程。

人物与背景

• 阿什伍德庄园：坐落于英国乡间山丘的宏伟庄园，象征着阿什伍德家族数个世纪的财富、权势与高雅。庄园内秩序井然，仆人众多，生活奢华，与周围村民的生活有天壤之别。
• 伊丽莎·阿什伍德：庄园女主人，优雅而富有智慧。她教育出的两个女儿是贵族魅力的典范。
• 伊丽莎小姐：长女，外在沉静知性，内心却渴望庄园之外更真实的情感与生活。她隐藏着对庄园仆人世界的兴趣。
• 托马斯：年轻的园丁，出身贫寒，因勤奋与沉稳被庄园雇佣。他内心宁静，在花园劳作中找到归属感，同时对伊丽莎小姐怀有默默的倾慕。

情感发展与冲突 伊丽莎与托马斯在花园中偶然相遇并渐生情愫。尽管深知阶级鸿沟不可逾越，两人仍通过频繁而隐秘的交流，逐渐建立起深厚的感情连接。这份爱情为伊丽莎带来了平静与自我认知，也让托马斯感受到前所未有的被尊重与希望。然而，身份的天差地别始终是笼罩在他们关系上的巨大阴影，两人内心都充满对未来的恐惧与挣扎。

危机爆发 伊丽莎无法继续忍受内心的煎熬，向父母坦白了她对托马斯的爱意。此举引发了轩然大波。其父将此视为对家族荣誉与遗产的背叛，其母则斥之为丑闻。家族严厉禁止伊丽莎与托马斯见面，并加强对她的监视，试图将她引回“正轨”。庄园内外的议论与侧目使伊丽莎声名受损，身心健康皆受打击。

悲剧结局 不堪重负的伊丽莎决心与托马斯私奔。两人秘密会合后，选择秘密举行婚礼，以求能在一起。然而，他们的结合很快被发现。伊丽莎被家族囚禁，托马斯被驱逐并前途尽毁，两人均遭到社会唾弃。面对无法承受的痛苦与永恒的隔绝，伊丽莎最终决定离开，去寻找内心的平静。她与托马斯在昔日定情的花园中含泪诀别。故事以两人被迫分离收场，他们的爱情虽深刻美丽，却最终被残酷的阶级现实与社会规训所摧毁，成为一曲凄婉的挽歌。

字节跳动近期推出名为“Bytespider”的网络爬虫，抓取网页数据的速率远超行业其他主要公司。据网络安全公司Kasada研究显示，该爬虫于四月左右上线，抓取速率约为OpenAI旗下GPTbot的25倍、Anthropic旗下ClaudeBot的3000倍，且近六周内抓取活动出现显著增长。Bytespider与其他公司爬虫类似，不遵循网站的robots.txt协议（一种非法律约束的爬虫限制信号），其激进抓取行为涉及大量网络数据复制，可能引发版权争议。

字节跳动作为TikTok母公司，正加速布局生成式AI领域。此前公司曾因使用OpenAI服务开发自身大模型而违反条款，今年已推出聊天模型“豆包”。业界认为，其激进抓取数据是为了训练新一代大语言模型，可能用于优化TikTok的搜索功能。TikTok近期更新了关键词广告搜索功能，未来新AI模型有望进一步整合实时网络趋势数据，提升搜索商业价值。

目前字节跳动及TikTok尚未对爬虫行为作出回应。该做法虽在行业普遍，但抓取规模异常突出，反映了字节跳动在AI竞赛中追赶的意图。

文章总结：日费率收费方式的实践与优势

本文作者分享了其于2023年从项目固定报价转向日费率收费方式一年来的经历与体会，认为这一转变在多个方面产生了积极影响。以下是其核心观点与发现：

主要优势

1. 客户更易理解：以“天”为单位报价，客户能直观感知工作所需时间，相比打包式的项目报价，更易接受估算并理解资金去向。
2. 灵活性与减少争议：
   • 避免范围蔓延：新增功能或需求可通过增加工作日来协商，减少了“超出范围”的艰难对话。
   • 降低前期工作量：无需在项目初期就锁定全部细节和报价。通常从一个付费的短期“发现阶段”开始，根据实际情况共同决定后续步骤和时间估算，从而更灵活地调整范围。
   • 降低风险：减少了因前期固定报价而导致交付次优解决方案的风险，也避免了在范围未明时就投入大量免费前期咨询的情况。
3. 日程与财务管理更清晰：
   • 日程易规划：每月工作日有限，对自身可工作时间有清晰把握，也更容易为小型需求或项目插入工作时间。
   • 收入可预测：按月根据已完成工作日结算，消除了与项目里程碑支付相关的延迟风险，开票时间也明确无疑义。
4. 提高商业判断效率：能快速评估项目可行性。当以工作日估算时，明显不现实的时间安排或资源紧张情况会一目了然，避免接受不可行的小项目。
5. 定价更灵活：日费率便于为特定类型客户提供折扣，也为向大公司收取更高费率提供了合理依据（例如，因额外的会议、流程、利益相关者或使用权限等）。

对常见反对意见的回应

1. “按时计费惩罚高效率”：作者认为，一方面日费率本身已设定在合理水平；另一方面，随着经验积累，并非所有事情都会更快完成——有时因为意识到更多潜在解决方案，反而需要更长时间深入考量。
2. “价值定价便于对大企业收费更高”：作者指出，日费率同样可以通过合理的理由（如更复杂的流程、额外的权益等）进行调整，从而实现类似效果。

结论

作者坦言，虽然日费率并非普适的完美收费方式，且个人实践仅一年，但这一转变有效缓解了其之前在项目定价中感受到的诸多摩擦，整体体验非常积极，目前计划继续沿用。

Rust 需要一个为“懒惰开发者”设计的Web框架

核心问题

作者指出，尽管Rust拥有出色的类型系统、高性能和更佳的编译体验，但在构建Web应用时，与Django等成熟框架相比，开发者需要投入大量额外精力进行初始设置和组件集成。当前Rust生态缺乏一个开箱即用、高度集成的Web框架，导致即使是小型或趣味项目也显得繁琐。

期望框架应具备的功能

作者列出了一份他认为几乎每个Web应用都需要的核心功能清单：

必要功能：

• 路由/处理器：支持路径参数（带类型信息）、查询参数、表单处理。
• 模板引擎：生成HTML/JSON等，需支持基本逻辑（条件、循环）。
• 静态文件服务：集成在Web服务器中，方便开发和小型部署。
• 登录系统：可定制且易于集成，支持多用户应用。
• 权限管理：遵循check(user, object, action)模式，实现基础角色控制。
• 数据库接口：提供轻量ORM或类似工具，作为登录、权限等基础功能的数据层。
• 管理工具：内置常见管理操作，简化数据引导和日常管理。
• WebSocket支持：用于实时数据推送等功能。
• 热重载：快速反映代码和模板变更，提升开发体验。

有益的附加功能：

• 后台任务管理。
• 监控与可观测性。
• 缓存机制。
• 邮件/通知集成（如密码重置）。
• 部署工具（如自动生成Dockerfile）。
• CSS/JS打包工具集成。

当前Rust Web生态现状

作者分析了现有解决方案的不足：

1. 极简框架（如actix-web, axum）：类似Flask/Sinatra，仅提供基础路由和处理器，其他功能需自行集成。
2. 单页应用框架（如Dioxus, Leptos, Yew）：允许用Rust同时开发前后端，但通常不成熟且仍需大量手动配置。
3. 零散库：存在各种模板、登录、WebSocket等库，但缺乏统一整合，导致集成和维护成本高。

使用这些现有方案，开发者需要反复进行“选择基础框架 -> 搜索并集成各组件库”的过程，这带来了显著的初始设置摩擦和长期的维护负担（库更新、兼容性问题）。虽然存在一些启动模板，但模板会与个人项目代码偏离，且维护多个独立项目的更新非常低效。

作者的构想与行动

作者提出了理想中的框架愿景：一个功能全面、文档完善、版本管理得当的Rust Web框架，让开发者能像使用Django一样快速启动项目，专注于业务逻辑而非基础设施搭建。

他正在着手构建一个名为 “newt” (nicole's web toolkit) 的工具包，旨在通过有主见地组合现有组件来实现这一目标。其目标是将创建小型Web应用的时间从“天”缩短到“分钟”。该项目目前处于早期设计阶段，尚不可用，作者期望生态系统中能出现多个此类工具包。

结论

Rust Web生态需要这样一个集成的、对开发者友好的框架/工具包，以降低入门门槛，充分发挥Rust的优势，并吸引更广泛的开发者群体。这不仅有助于小型项目，也能提升整个生态系统的成熟度和吸引力。

福岛反应堆：东京电力公司机器人旨在提取核燃料

自2011年大地震和海啸导致福岛第一核电站发生堆芯熔毁和放射性物质大规模泄漏已过去十三年。运营商东京电力公司（TEPCO）通过一个特殊的伸缩式机器人设备，终于接近从该设施中提取首批熔融燃料。

任务背景与挑战

• 总体目标：退役整个核电站需要数十年时间，其中最危险复杂的任务之一是移除并储存约880吨高放射性熔融燃料。这些燃料是堆芯熔毁后，铀、锆等金属混合物熔化、冷却并再固化的产物，成分未知。
• 延迟原因：原计划2021年开始提取，但因技术路线障碍、开发延误及新冠疫情而推迟。
• 战略选择：从受损相对较轻、未发生氢气爆炸的2号机组开始试验。目标是先获取少量（最初目标为几克）燃料碎片样本进行分析，以指导未来大规模清理工作。

机器人技术方案

• 核心设备：由三菱重工等机构联合开发的一条主要为不锈钢和铝制的伸缩式机械臂。它长22米，重4.6吨，具有18个自由度，类似国际空间站的机械臂，收纳在密封舱内。
• 设备结构：包括一个推车、可折叠的臂链接、具有三个伸缩阶段的臂，以及末端装有相机和抓取器的“长杆”。
• 操作流程：
  1. 机械臂通过反应堆压力容器底部的2米长隔离阀进入。
  2. 沿7.2米长的导轨向下朝反应堆底部移动，穿过基座和平台的开口。
  3. 末端像抓娃娃机一样通过电缆下降至基座底部的燃料碎片区。
  4. 末端的精密抓取器（钳口仅5平方毫米）尝试夹取一小块碎片。
  5. 成功取出的碎片将被转移至容器，带回反应堆建筑内的手套箱进行初步检测，随后送往日本原子能研究开发机构进行详细分析。

当前进展与遭遇的挫折

• 近期尝试：一个较小的伸缩装置（用于先行探查和初步取样）上个月已成功抵达燃料碎片区并抓取了一块碎片（尚未确认是否为燃料）。
• 遭遇问题：该装置的四台相机中，有两台在几天后停止工作。推测原因是半导体元件因辐射积累电荷，导致故障。设备已被收回。东京电力公司认为在较低辐射环境中持续通电，电荷可能会消散。
• 后续计划：在完成对小型设备故障的排查和测试后，将使用更大型的机械臂进行更大规模的碎片提取。

东京电力公司发言人表示，提取燃料碎片是退役工作中极其困难但至关重要的一环，计划在30至40年内完成退役，将战略性地、系统地推进每一步工作。

即时HTML预览书签 (Instant HTML Preview Bookmarklet)

这是一个浏览器书签工具，核心功能是将剪贴板中的文本渲染为一个完整的HTML页面。它能够处理并显示包含CSS样式和JavaScript脚本的HTML代码，同时也支持SVG代码的预览。

• 主要功能：

  • 读取剪贴板：工具会读取系统剪贴板中的文本内容。
  • 创建新窗口并渲染：在一个新的浏览器窗口或标签页中打开，并将读取到的HTML代码直接写入其中进行渲染，从而实现实时预览效果。
  • 错误处理：如果剪贴板为空或浏览器权限阻止读取，会弹出相应的错误提示。

• 工作原理： 该工具本质上是一段JavaScript代码。用户点击书签后，代码会尝试异步读取剪贴板文本。成功读取后，使用window.open方法打开一个新窗口，并通过document.write将HTML代码写入该窗口的文档中，浏览器随后会解析并渲染完整的页面。

• 适用场景： 该工具尤其适用于需要快速预览代码片段效果的场景，例如在ChatGPT Canvas等环境中生成或修改HTML/CSS/JS代码后，可以一键查看其实际渲染效果，极大提升了开发与测试的效率。

这篇文章探讨了设计一款旨在使用至少50年的计算机（称为#ForeverComputer）的构想，其目标是应对电子设备快速更迭带来的资源浪费、注意力分散和垄断问题。

核心理念

作者以老式打字机为例，指出其耐用、可修复、功能专注的特性，与现代电子设备每几年就需要更换形成鲜明对比。因此，提议构建一种专注于永恒、基本功能的计算机，而非追求全能。它旨在主要服务于读写等不受时间淘汰的活动，例如写作、收发邮件、阅读文档和网络信息。

关键设计原则

1. 硬件：
   • 耐用与模块化：采用坚固的材料和设计，所有部件（计算单元、电池、屏幕、键盘等）应可轻松更换，规格开源。机身外壳应保持不变，以建立情感连接。
   • 低功耗：优先考虑节能，电池应易于更换。
   • 本地化与伦理：鼓励本地制造，使用符合伦理的材料。
2. 软件：
   • 完全开源：确保长期可维护、可修复，即使开发公司消失也能持续使用。
   • 定制化用户界面：设计专注于文本操作的界面，可能采用无指针设备（仅键盘）的交互模式，并支持渐进式学习，使其成为长期精通的工具。
3. 网络与连接：
   • 离线优先：设备默认不联网。需要时，通过有线连接（如RJ-45）进行有意识的同步（收发邮件、更新内容），完成后立即断开。这旨在减少干扰，回归专注。
   • 点对点连接：倡导设备间直接通过物理连接交换数据和消息，利用加密技术和分布式存储（如IPFS），减少对中心化服务器的依赖。
4. 使用理念：
   • 专注与所有权：该设备旨在夺回用户的注意力和时间。购买后，用户应完全拥有它，不受厂商的强制更新、监控或功能限制。
   • 并非替代品：它不会取代所有现有设备，而是提供一个更安静、专注的替代选择，旨在改变我们与技术的关系。

近期行动与愿景

作者自认是软件开发者，已提出一个过渡项目 WriteOnly：一个极简的发布平台，让作者专注于写作（Markdown文件），平台负责以各种方式（博客、邮件、RSS等）分发，内容本身不依赖特定平台。

最终愿景是构建一台开源、可持续、去中心化、离线优先且耐用的计算机，旨在减少消费、对抗垄断、保护隐私并节约资源。作者呼吁有想法和能力的人共同实现这一构想。

Zod：TypeScript 优先的模式验证与静态类型推断

Zod 是一个以 TypeScript 为核心的验证库，用于定义数据模式并进行验证，支持从简单字符串到复杂嵌套对象的数据。其核心示例展示了如何定义一个 User 模式，并对不可信输入数据进行解析和类型安全的验证。

主要特点：

• 零外部依赖
• 运行环境：支持 Node.js 和所有现代浏览器
• 轻量：核心库压缩后仅 2kb
• 不可变 API：方法返回新实例
• 接口简洁
• 语言支持：适用于 TypeScript 和纯 JavaScript
• 内置功能：支持转换为 JSON Schema
• 生态系统：拥有丰富且活跃的生态系统

安装与要求：

• 安装命令：npm install zod 或通过 @zod/zod 在 jsr.io 获取。
• TypeScript 要求：官方测试支持 TypeScript v5.5 及更高版本。必须在 tsconfig.json 中启用 strict 模式。

生态系统与资源： Zod 拥有丰富的生态系统，包括各类库、工具和集成，例如：

• API 库
• 表单集成（如与 React Hook Form 的 Zod 解析器集成）
• Zod 到其他格式的转换（如 Zod to JSON Schema）
• 其他格式到 Zod 的转换
• Mocking 库
• 其他由 Zod 驱动的项目

作者还参与维护以下重点集成项目：

• tRPC：端到端类型安全的 API，支持 Zod 模式。
• React Hook Form：基于 Hook 的表单验证，提供 Zod 解析器。
• zshy：Zod 内部构建工具，现已成为一个无 bundler、开箱即用的 TypeScript 库构建工具。

赞助： 该项目提供不同级别的赞助，并鼓励在使用 Zod 构建付费产品时考虑企业赞助。

这篇文章以第一人称视角，回顾了自E.F. Codd于1970年提出关系数据模型以来，关系数据库及SQL查询语言五十年的发展历程与深远影响。以下是核心内容的总结：

核心发展脉络

1. 起源与早期竞争：文章开篇提到，在Codd提出关系模型之前，数据库领域主要由层次模型（如IMS） 和网络模型（如IDS） 主导，这类“导航式”系统通过显式记录间连接来存取数据，编程复杂。1970年，Codd发表了开创性论文，提出了基于数学关系、数据独立性和关系代数的抽象模型。
2. SQL的诞生与验证：作者Don Chamberlin与同事Ray Boyce在研究当时流行的网络模型标准（DBTG报告）后，被Codd模型的简洁与强大所吸引。他们为非专业用户设计了一种更友好、基于英语关键字的查询语言SEQUEL（后改名SQL）。与此同时，两个关键的研究项目——IBM的System R和UC Berkeley的INGRES——通过构建工业级原型，证明了关系数据库在生产环境中的可行性和高性能，解决了核心的性能质疑。
3. 标准化与商业化：1974年ACM SIGFIDET会议上，网络模型与关系模型进行了公开辩论，标志着关系模型开始成为研究主流。随后，SQL语言被ANSI标准化（1986年成为首个SQL标准），并通过NIST的FIPS-127合规测试进入美国政府采购市场，极大地推动了其合法化与普及。商业化产品如Oracle（1979年）、IBM的SQL/DS和DB2，以及源自INGRES的商业公司相继推出，引爆了1980年代的市场增长。
4. 繁荣与开源兴起：关系数据库成为1980年代的主流选择。1990年代中期，三个开源SQL实现——MySQL、PostgreSQL和SQLite的出现，为Web应用提供了强大、免费且高质量的数据管理方案，进一步巩固了SQL的统治地位。
5. 当代挑战与演化：近年来，为满足Web应用的大规模可扩展性需求，出现了放松关系模型某些约束（如严格模式、强ACID事务）的NoSQL系统。然而，关系模型和SQL依然强大，SQL标准本身也在持续演化以容纳新功能（如递归查询、窗口函数）。文章也回应了对SQL的常见批评（如缺乏正交性、允许空值和重复行），解释了这些设计是基于灵活性、实用性和易用性的权衡。

持久成功的原因分析

作者认为，关系模型和SQL能够跨越半个世纪保持主导地位，主要原因包括：

• Codd模型本身的优越性：简单、强大、优雅的信息表示方法。
• 早期研究验证：System R和INGRES证明了高性能实现是可能的。
• 开放的知识共享：关键研究和语言规范被公开发表，没有专利壁垒。
• 数据的“粘性”：率先采用关系数据库的企业积累了数据，迁移成本高昂。
• 标准的牵引力：ANSI标准和政府认证创造了健康的市场竞争环境。
• 高质量开源实现：免费、强大的开源数据库支撑了现代电子商务基础设施。

结论

文章将数据库技术的发展归功于Bachman（提出数据库管理系统概念）和Codd（提出关系模型）两位图灵奖得主所描绘的蓝图，以及众多研究者、工程师和标准化组织的共同努力。关系数据库不仅彻底改变了数据管理方式，支撑了全球电子商务等现代奇迹，其产生的数据力量也在深刻塑造着我们的社会和文化未来。

摘要

本文指出了13至17岁青少年在网络上被广告商通过“广告ID”广泛跟踪的隐私问题，并解释了其原因及提供具体的防护步骤。

核心问题：青少年隐私保护的断层

1. 法律保护缺失：根据美国《儿童在线隐私保护法》(COPPA)，13岁以下儿童的数据受到严格保护，需获得父母明确同意才能收集。青少年年满13岁后，这一保护失效，使其直接暴露在商业数据收集之下。
2. 广告ID的激活：年满13岁通常意味着可以独立管理自己的Google账户等，同时也自动获得一个设备广告ID，这成为了广告商追踪他们的核心工具。

什么是广告ID？

广告ID是苹果设备上的IDFA和安卓设备上的AAID的统称，是一串唯一标识用户设备的代码。它允许第三方广告商收集设备和活动信息，用于投放定向广告。

如何保护青少年（及所有人）的隐私？

主要策略是删除或禁用设备上的广告ID，从而切断广告商追踪的关键链条。虽然操作后仍会看到广告，但广告将与用户过去的在线行为脱钩，减少了个人针对性。

具体操作指南

1. 在安卓设备上（Android 12及以上版本）：

   • 打开“设置” > 进入“安全与隐私” > “隐私” > “广告”。
   • 点击“删除广告ID”并确认。此操作将永久删除该ID，所有应用均无法再访问。
   • 若为旧版本系统，可重置广告ID并设置要求应用不跟踪。

2. 在iOS设备上：

   • 管理应用跟踪：前往“设置” > “隐私与安全性” > “跟踪”。可以逐个应用关闭跟踪权限，或关闭“允许App请求跟踪”总开关，以阻止未来所有跟踪请求。
   • 关闭Apple自身广告跟踪：在“设置” > “隐私” > “Apple广告”中，关闭“个性化广告”。

更广泛的建议

• 家长应主动为13-17岁子女的设备删除广告ID。
• 学校应在使用平板设备时，教育学生和家长如何禁用广告ID。
• 倡导为所有用户提供更强的隐私保护法规。

蛋白质粉价格比较网站摘要

核心功能

该网站专门用于比较不同品牌和类型蛋白质粉的价格。其关键特点是将所有产品的每份用量标准化为25克蛋白质，从而确保价格比较的公平性。

数据来源

网站的产品数据主要来源于 iHerb.com。

主要筛选维度

用户可以通过以下多个维度筛选和查找产品：

1. 类型：包括乳清蛋白、植物基蛋白、动物蛋白、酪蛋白和混合蛋白。
2. 饮食要求：支持无麸质、素食、纯素、无乳糖和非转基因等筛选。
3. 口味：提供香草、巧克力、草莓、无味等多种口味选择。
4. 重量范围：可按产品的最低和最高重量进行筛选。
5. 营养信息：可按每份的最低/最高卡路里以及最低/最高碳水化合物含量进行筛选。

其他信息

• 网站包含常见问题解答和隐私政策页面。
• 该网站通过付费联盟链接获得支持。

摘要：

• 内容为一个错误提示消息，表明在尝试访问网站时出现问题。
• 错误原因可能是由于隐私相关扩展在x.com上导致加载异常。
• 建议用户禁用这些扩展后重新尝试，以解决访问问题。
• 该内容不包含关于Starlink、hurricane helene或紧急消息的详细信息，仅涉及网站访问的技术问题。

根据提供的内容，文中没有包含具体的文章或视频实质信息。所给出的仅为一个YouTube视频页面的通用描述、导航链接及版权声明，标题“Nintendo isn't just attacking emulators”对应的视频内容本身并未包含在提供的文本中。

基于标题的常见语境，该主题通常涉及任天堂公司对游戏模拟器及相关工具的法律行动。此类行动通常基于版权保护，目标可能包括模拟器开发者、传播ROM的网站以及使用模拟器游玩受版权保护游戏的社区。任天堂的立场通常强调保护其知识产权、防止盗版和维护游戏生态系统的商业利益。然而，由于缺乏具体文章内容，无法提供更多关于此次特定事件、涉及的具体模拟器或最新动态的详细信息。

左撇子之谜：稀少的原因与科学发现

左撇子在人群中占比很低（约10%），但这一现象背后的科学原因尚未完全阐明。文章从多角度探讨了用手偏好（handedness）的成因、影响及相关争议。

1. 不对称性与普遍现象

• 人类不仅用手偏好不同，眼睛、耳朵和脚也有偏侧倾向：约40%的人是“左利耳”，30%是“左利眼”，20%是“左利脚”。
• 用手偏好从幼儿期即可显现，但左利手为何成为少数，仍是未解之谜。

2. 进化与历史视角

• 从进化角度，单侧手优势有助于提升精细动作效率（如黑猩猩用特定手捕食白蚁），但黑猩猩的左右手使用比例接近1:1，而人类左撇子比例始终稳定在约1:10。
• 尼安德特人牙齿上的磨损模式显示，其左撇子比例也与现代人类相似，表明该比例可能源于共同祖先。
• 历史上左撇子曾受歧视（如英语中“left”源于表示“弱”的古英语单词），但现代科学已摒弃此类偏见。

3. 遗传与脑组织差异

• 用手偏好有遗传基础，可能涉及多达40个基因，但具体机制仍不明确。
• 左撇子的大脑组织方式通常更不规则，因大脑半球对手部控制是交叉的。部分学者认为这可能赋予左撇子特殊才能或缺陷，但证据不足。

4. 争议与科学误区

• 有研究试图将左撇子与阅读障碍、自闭症等疾病或音乐、建筑等领域的成就联系起来，但这些关联可能存在“选择性报告偏差”。
• 在唐氏综合征、癫痫等疾病患者中，左撇子比例较高（接近50%），但这可能是潜在疾病的症状而非原因。对多数人而言，左撇子不影响认知发展。

5. 胎儿行为与先天因素

• 北爱尔兰女王大学的研究通过超声观察发现，约90%的胎儿在子宫内偏好吮吸右手拇指，且出生后用手偏好与此一致，表明用手偏好可能由先天因素决定。

结论

左撇子的成因涉及进化、遗传和胎儿发育等多重因素，但其比例稳定性的根本原因仍未知。尽管历史上存在偏见，现代科学更关注左撇子在脑结构和行为上的多样性，同时需避免对左撇子与能力或疾病的关联过度简化。

《大众科学》杂志档案摘要（1872年5月-2009年3月）

基本信息

• 标题：Popular Science Magazine Archives, May 1872-March 2009
• 载体：谷歌图书（Google Books）电子存档
• 时间跨度：1872年5月（第1卷）至2009年3月
• 出版方：Bonnier Corporation
• ISSN：0161-7370
• 首期规格：134页

杂志核心理念

《大众科学》（Popular Science）致力于为读者提供改进技术和改善世界的信息与工具。其与读者共享的核心信念是：未来将会更好，而科学与技术是实现这一愿景的驱动力。

存档页面功能

1. 按年代浏览：用户可通过页面链接浏览1870年至2000年每个十年的期刊。
2. 预览与订阅：页面提供杂志预览链接，并包含前往《大众科学》官网（popsci.com/popsci-plus/）的订阅入口。
3. 关键词云：页面列出了该杂志存档中常见的术语和短语（如科学、技术、人类、社会、理论等），反映了杂志长期关注的广泛科学与社会议题。

覆盖主题举例（基于关键词云）

存档内容涵盖极其广泛的领域，包括但不限于：

• 自然科学：大气、天体、热、气体、物种、植物学。
• 技术与医学：疾病、消化、消毒剂、除臭剂。
• 人文与社会：人类、社会、政治、宗教、女性、男性、种族、道德、智力。
• 历史与考古：青铜时代、巨石阵、古坟、凯尔特人、阿留申群岛。
• 哲学与思想：思想、理论、真理、信念、形而上学、存在。

可用性

该存档作为数字资源通过谷歌图书平台提供，用户可访问、预览并利用其检索功能查阅历史期刊内容。

Warm Handoffs 流程摘要

核心问题

随着组织规模扩大和团队重组，Slack渠道激增，员工难以快速找到解决问题的正确渠道。这导致冷转接（Cold Redirect）现象：提问者被简单告知“去找别的团队”，有时甚至被多次转接。这种做法会逐渐削弱团队间的协作与凝聚力，并可能助长“我们 vs 他们”的筒仓文化。

解决方案：Warm Handoffs

Warm Handoffs 是一种旨在改善Slack沟通与协作的流程。其核心规则是： “如果有人问你一个你无法回答的问题，请带他们找到能回答的人。如果你不知道那人是谁，请帮忙一起寻找。”

具体操作指南通常包括：

1. 若在错误渠道收到问题且知道正确渠道：将问题链接到正确渠道，@提问者，并解释转接原因及补充上下文。
2. 若不确定问题应去何处：将问题链接到一个共享渠道，寻求谁能够提供帮助，并补充上下文。

实施与巩固

• 必须成为标准：Warm Handoffs需作为团队或组织的强制性标准，而非仅仅推荐。它基于两个价值观：人们乐于帮助同伴，也需完成本职工作。
• 推广步骤：首先编写包含组织特定指南的流程文档，获得领导层支持。然后，将其作为政策在相关层级（如管理者的整个汇报线，乃至整个工程组织）进行分享。
• 坚持执行：由于Warm Handoffs比冷转接需要更多努力，需要持续强化。最佳提醒时机是当有人忘记执行而进行冷转接时。可以创建Slack工作流，当他人对某条消息添加特定表情符号时，系统自动发送简短、非对抗性的私信提醒，附上文档链接。

价值对比：冷转接 vs Warm Handoffs

文章通过一个详细示例展示了两种方式的区别：

• 冷转接示例：Andre因API速率限制问题在API网关团队频道提问，被简单告知去账户团队频道。在转接过程中，上下文丢失，导致账户团队成员Gina无法准确判断问题，甚至引发团队间关于职责归属的争论，最终需要经理介入协调。整个过程耗时漫长，用户体验差，且关键信息在争论中丢失。
• Warm Handoff示例：API网关团队的Miles在意识到问题不属于本团队后，亲自将问题链接到账户团队频道，并@了Andre，解释了转接原因（该端点由账户团队所有，且API网关本身未发现问题）。Miles继续参与对话，当他发现Gina未追踪某个关键指标（ip_rate_limited）时，能及时提供专业解释，最终快速定位问题（测试时未设置client_id）。
• 更优的Warm Handoff示例：Miles在转接前主动检查指标，发现存在IP速率限制，在转接时就将此关键上下文提供给账户团队。这使得问题几乎无需来回沟通，凭借各方专业知识迅速解决。

结论

Warm Handoffs通过确保问题被平稳转移并附带必要上下文，有效避免了冷转接带来的沟通断裂、责任推诿和解决延迟。它促进了跨团队协作，保护了提问者的体验，并能更高效地利用集体知识解决问题。

古斯塔夫·克里姆特对金箔的迷恋

古斯塔夫·克里姆特将金箔带入现代艺术。20世纪之交，这位维也纳艺术家以其大量运用金箔装饰的、曲线优美的女性（偶尔是男性）形象吸引了公众目光。这些作品感官、时常情色，配以闪烁的背景，改变了20世纪艺术的进程。

其中最著名的是其杰作《吻》（1907–08），描绘了一对相拥的男女，他们的身体融入金色的抽象中，处于超验的一刻。这幅画已成为艺术家著名的 “黄金时期” 的标志。该时期始于1898年的《帕拉斯·雅典娜》，艺术家以金色盔甲和威严的目光描绘希腊女神雅典娜，金箔运用于背景和盔甲，暗示了其后期作品那种非实体化与庄严之美。该时期持续至1909年。

美学反叛，以金箔装点

出乎许多人意料，这些金色作品仅占艺术家全部作品的一小部分。作为与法国新艺术运动紧密相连的维也纳分离派创始艺术家之一，克里姆特反抗传统风格的停滞，并拥抱跨学科影响。他一生（55岁死于西班牙流感）创作颇丰，每日素描，现存素描超过4000幅，已知绘画超过160幅。

黄金盔甲是他将金箔引入画作的方式之一。在1902年和1903年，他描绘了身着黄金盔甲的骑士，首先是著名的《贝多芬饰带》，随后是画作《生是挣扎（黄金骑士）》。在这些年，克里姆特广泛而创造性地使用金箔，装饰背景和人物，创造出复杂的图案。

金匠是克里姆特的家族事业

克里姆特1862年出生在一个富有创造力的家庭。父亲恩斯特·克里姆特是金匠兼雕刻师。家庭环境无疑培养了克里姆特对金箔的熟练运用和对所谓装饰艺术的欣赏。他早年作品更具写实风格，并与弟弟恩斯特和友人成立公司承接委托。后来，他也与小弟乔治（雕刻师兼金属工人）合作，乔治最著名的作品是1897年维也纳分离派大楼的门。克里姆特有时会委托弟弟制作画框，例如《帕拉斯·雅典娜》的金色画框。这些合作彰显了克里姆特对装饰艺术的热情、对黄金的热爱以及塑造其作品的家族纽带。

神圣与世俗

克里姆特艺术鉴赏力广泛，吸收了日本版画的平面感、埃及神话的母题以及印象派的现代主义。他对黄金的热情，则主要源于拜占庭时代的宗教圣像。1903年，他前往威尼斯和意大利拉文纳（两次），称拉文纳的拜占庭马赛克“令人难以置信地震撼”。艺术史家发现其为维也纳社交名媛阿黛尔·布洛赫-鲍尔所作的肖像，与几个世纪前拜占庭皇后狄奥多拉的描绘存在构图相似性。

在拜占庭马赛克和圣像中，黄金象征着永恒的、超越时间的、充满神圣之光的境界。其中平面化、无形的人物象征着宗教超验的灵魂出窍体验。克里姆特使用黄金来创造一种类似永恒无限的感觉；其“黄金时期”作品的背景点缀着闪烁的金箔（还有银和铂金），为画面营造出近乎宇宙般的背景。

但克里姆特的黄金所象征的狂喜，更多是尘世而非天国的愉悦。他曾写道“所有艺术都是情色的”，其作品无疑沉醉于女性身体的欢愉（他一生中通过隐秘风流至少生了14个子女）。在20世纪初，他试图（尽管有争议地）将肉欲欢愉的描绘提升至精神层面的地位。例如1901年的《朱迪思》，描绘的不是古代犹太女英雄与荷罗孚尼暴力冲突的身体动作，而是一种放纵感官征服的姿态。其最著名的画作《吻》也因公然暗示宗教圣像而引发争议，但它赞颂的不是神，而是男人和女人。仔细观察画中人物的服饰，会发现克里姆特用金箔在男士长袍上创造了笔直、矩形的图案，与女士长裙上旋涡状、卵形的图案形成阳刚的呼应（克里姆特对微观生物学、细胞和受精过程非常着迷）。

黄金彰显了艺术的“物体性”

虽然克里姆特可能是维也纳分离派中与黄金联系最深的画家，但他远非唯一使用这种媒介的艺术家。分离派主要艺术家科洛曼·莫泽和建筑师约瑟夫·霍夫曼于1903年创立了“维也纳工坊”。这个富有成效的联合体汇集了跨学科的创意人士，创作从皮具到珠宝的实用物品，镀金物品和细节非常流行。

约瑟夫·玛丽亚·奥尔布里希设计的维也纳分离派大楼以其独特的镀金叶穹顶为特征。在克里姆特的画作中，黄金的使用赋予了绘画一种物体般的质感——金箔作业在压缩画面平面的同时，赋予了画布一种雕塑般的、珠宝般的品质。克里姆特对黄金的拥抱，使其作品与同时代的设计和装饰艺术家产生了对话，并反映了维也纳分离派艺术家非常现代的感性。

摘要

文章标题为“AI won't replace human devs anytime soon”，但提供的内容是一个错误消息。该消息显示在x.com上遇到问题，可能由隐私相关扩展引起，建议用户禁用这些扩展并重试。内容未涉及AI与开发者主题的具体讨论，仅包含此错误提示信息。

Ziggy 数据序列化语言摘要

Ziggy 是一种用于表达 API 消息和配置文件的数据序列化语言。其核心设计目标是帮助用户直观理解数据布局，并提供比 JSON、YAML 等格式更佳的开发体验和工具支持。

主要特性：

1. 结构体 vs 字典：提供两种键值对表示方式。结构体用于键名在模式中预先定义的场景；字典用于键名由用户自由定义的场景。这有助于用户在查看模式前直观理解数据结构。
2. 标签联合支持：通过为结构体命名，Ziggy 可以自然地表示标签联合（tagged union），解决了 JSON 中表达此类结构困难的问题，并为人类和工具（如“跳转到定义”）提供了清晰的类型判别依据。
3. 其他便利性功能：包括可选的顶层花括号、多行字符串字面量、尾随逗号、注释、数字中的下划线等，提升了编写的便利性和可读性。

模式语言与数据布局定义： Ziggy 拥有配套的模式语言（Schema Language），用于创建和记录清晰的数据布局。模式可以定义结构体、联合体、枚举和自定义字符串字面量。其优势在于不能定义任意数据布局，从而强制数据结构清晰一致。Ziggy 的语言服务器协议（LSP）能够基于模式为用户提供诊断、上下文帮助和自动补全建议。此外，模式还可用于自动生成兼容的类型定义。

官方工具链： Ziggy 提供一个统一的命令行工具，涵盖常用功能：

• ziggy fmt：格式化 Ziggy 文件。
• ziggy check：使用 Ziggy 模式校验文件。
• ziggy convert：在 JSON、YAML、TOML 与 Ziggy 格式之间进行转换。
• ziggy query：查询 Ziggy 文件（即将推出）。
• ziggy lsp：启动 Ziggy 语言服务器，以便在编辑器或 IDE 中获得舒适编辑体验。

示例对比： 文章通过 package.json 和对应的 package.ziggy 文件对比，展示了 Ziggy 语法的特点。例如，仓库信息（repository）使用了标签联合（.git(.{...})），描述字段使用了多行字符串字面量，整体结构更贴近编程语言的语法风格。

Google Pixel手机持续追踪用户数据：即使禁用GPS

核心发现：
据Cybernews研究团队披露，谷歌Pixel 9 Pro XL手机会每15分钟向谷歌服务器发送数据包，包括位置、电子邮件、电话号码、网络状态等遥测信息。此行为在设备默认设置和新账户下持续发生，用户难以完全阻止。

关键问题：

1. 位置追踪持续进行：

   • 即使GPS被禁用，手机仍通过附近Wi-Fi网络估算位置并发送给谷歌。
   • 数据传送至谷歌的设备管理、政策执行及人脸分组等多个端点。

2. 未经同意的数据共享：

   • 手机自动联系谷歌照片等应用的端点（如人脸分组功能），即使用户未打开或使用该应用。
   • 数据传输涉及用户未明确同意的服务。

3. 潜在安全风险：

   • 设备会定期尝试下载并运行新代码，可能引入安全漏洞（但谷歌强调有Play Protect等防护）。
   • 研究者认为这种深度集成可能使用户面临隐私泄露风险。

谷歌的回应：
谷歌表示，用户安全和隐私是首要任务，并指出可在设置中管理数据共享和应用权限。谷歌称该报告“缺乏关键背景，误解技术细节”，并强调数据传输是移动设备用于软件更新、功能启用和个性化体验的常规需求。

测试限制说明：

• 测试基于新手机和默认设置，未探讨用户自定义隐私设置的影响。
• 手机已root以拦截数据，可能影响部分功能，数据捕获不完整。

结论：
该研究凸显了谷歌设备在默认设置下持续收集敏感数据的行为，尤其是位置信息在GPS关闭后仍被追踪，引发对透明度和用户控制权的质疑。尽管谷歌称数据传输为必要服务，但用户可能面临隐私风险。

• QuickPiperAudiobook 是一个命令行工具，可以将任意格式的文本文件（包括 PDF、epub、txt、mobi、djvu、HTML、docx 等）离线转换为自然语音的有声书，所有转换过程完全本地进行，保障隐私。
• 软件基于 piper 语音模型，支持多种语言与模型，用户可通过 piper 官方提供的 .onnx 和 .json 文件适配其它语种。
• 安装方式包括下载预编译版本、使用 Go 命令安装（go install github.com/C-Loftus/QuickPiperAudiobook@latest），或源码编译。需确保 ebook-convert 工具（calibre 包含），可选安装 ffmpeg 实现 mp3 和章节功能。
• 使用方法：
  • 直接输入本地文件或远程 URL，如 ./QuickPiperAudiobook test.txt
  • 对 epub 文件生成 mp3 章节，需加 --chapters 参数，如 ./QuickPiperAudiobook --chapters test.epub
  • 获取完整参数列表，可用 --help
• 多语种及 UTF-8 支持：
  • 从 piper 模型库下载所需语言模型并放入 ~/.config/QuickPiperAudiobook/
  • 使用 --speak-utf-8 和 --model 参数指定模型，如 ./QuickPiperAudiobook --speak-utf-8 --model=pl_PL-gosia-medium.onnx 文件名
  • 常用可将模型配置为默认值
• 支持配置文件（~/.config/QuickPiperAudiobook/config.yaml），可设置默认输出目录、模型、mp3 输出、章节生成等。

  output: ~/Audiobooks
  model: "en_US-hfc_female-medium.onnx"
  mp3: false
  chapters: false
  

• 注意事项：
  • Piper 不支持进度输出，处理长文本时本地运算可能时间较长
  • 工具已在 Linux 测试，MacOS 上需等待 Piper 上游修复相关 bug
• 项目支持：可通过 Github 或 Paypal 捐赠，亦可通过邮件或开发者网站联系商业合作。