2025-11-01

美国移民及海关执法局强制使用面部扫描技术，数据保存15年

根据美国国土安全部（DHS）的一份内部文件，美国移民及海关执法局（ICE）在其新的面部识别应用程序“Mobile Fortify”的使用过程中，并不允许人们拒绝被扫描。该应用程序被用于验证个人身份和移民身份。

主要要点：

• 强制扫描： ICE 不允许被扫描者拒绝使用 Mobile Fortify 应用程序进行面部扫描。
• 数据存储： 通过该应用程序拍摄的所有面部照片，包括美国公民的照片，都将被存储长达 15 年。
• 应用目的： Mobile Fortify 的目的是验证个人身份和移民身份。
• 广泛应用： 之前 404 Media 的报道指出，ICE 和海关及边境保护局（CBP）的特工已经在街头扫描人们的面部进行身份验证。
• 数据透明度： 该文件提供了关于 Mobile Fortify 技术、数据处理和存储方式，以及 DHS 使用该技术的理由的详细信息。

来源说明：

这篇文章主要基于公共记录请求获得的信息，并免费向公众开放。 404 Media 鼓励读者订阅或捐赠以支持此类调查性报道工作。

arXiv 计算机科学 (CS) 分类对综述文章和立场论文的审核实践更新

以下是对 arXiv 计算机科学 (CS) 分类更新审核实践的总结：

主要变化:

• 要求成功同行评审: 从现在起，要将综述文章或立场论文提交到 arXiv CS 分类，必须首先获得期刊或会议的接受，并完成成功的同行评审。提交时，作者必须提供同行评审的证明文件，才能获得充分的考虑。
• 并非政策变更: 综述文章和立场论文并非 arXiv 官方接受的内容类型，因此这并非政策变更，而是审核实践的调整。过去，这些文章的接受是基于审核员的酌情权，而现在审核员需要同行评审的证明。

原因:

• 提交量激增: 近年来，arXiv 上的论文提交量大幅增加，尤其是由于生成式 AI 和大型语言模型（LLM）让撰写论文变得更加容易。CS 分类受到的影响尤为显著。
• 审核员资源紧张: 审核员需要将精力集中在官方接受的内容类型上，以减少提交等待时间并保持科学发现的步伐。
• 质量问题: 大量涌入的综述文章和立场论文，很多质量不高，仅是带有注释的文献综述，缺乏对开放研究问题的实质性讨论。

目标:

• 提升价值: 帮助 arXiv 读者更容易找到由领域专家撰写的有价值的综述文章和立场论文。
• 优化资源: 解放审核员的时间，使其能够专注于官方接受的内容类型。
• 遵循核心使命: arXiv 的核心使命是快速、自由地分享研究论文并促进科学发现，此调整旨在支持这一使命。

提交指南:

• 先进行同行评审: 在提交到 arXiv 之前，确保综述文章或立场论文已在具有同行评审的期刊或会议上获得接受。
• 提供证明: 提交时，提供同行评审的期刊引用和 DOI 元数据。
• 会议工作坊不满足要求: 会议工作坊的评审通常不符合传统同行评审的标准。
• 申诉机制: 如果因未完成同行评审而被拒绝，可以提交申诉，并在文章完成同行评审后重新提交。

例外情况:

• 社会科学研究: 研究科学和技术对社会影响的科学论文（例如 cs.CY 或 physics.soc-ph）仍然可以不经过同行评审提交。

其他分类:

• arXiv 的其他类别有不同的审核员，他们会根据各自领域的标准来决定是否调整审核实践。
• 如果其他类别也面临 LLM 生成的综述文章和立场论文激增的问题，可能会采取类似的措施。

希望这个总结对您有帮助!

Debian 邮件总结：硬 Rust 依赖要求 (2025年10月31日)

这封邮件来自 Julian Andres Klode，通知 Debian 项目将引入硬 Rust 依赖，以及 Rust 代码，最早于 2026 年 5 月开始实施。

主要内容：

• Rust 依赖引入: Debian 项目计划在 2026 年 5 月起，强制使用 Rust 编译器、标准库以及 Sequoia 生态系统。
• 应用领域: 该变化将首先应用于解析 .deb、.ar、.tar 文件以及进行 HTTP 签名验证的代码。
• 原因: 使用 Rust 可以提高代码的内存安全性和单元测试质量。
• 现有端口要求: 如果某个端口依赖于没有工作 Rust 工具链，请在未来 6 个月内确保其具备，否则可能需要停止维护该端口。
• 总体目标: 旨在让项目能够采用现代工具和技术，避免被旧设备限制发展。

总结: 这封邮件宣布了 Debian 项目对 Rust 技术的进一步采用，并要求维护者在规定时间内更新其端口，以适应新的硬 Rust 依赖。 该举措旨在提高代码质量、安全性和可维护性。

中文翻译：

这封邮件由 Julian Andres Klode 发送，宣布 Debian 项目计划从 2026 年 5 月起引入硬性的 Rust 依赖和 Rust 代码。

核心要点：

• 强制使用 Rust: Debian 项目将强制使用 Rust 编译器、标准库和 Sequoia 生态系统，最早于 2026 年 5 月开始。
• 影响范围: 影响 .deb、.ar、.tar 文件解析以及 HTTP 签名验证等代码。
• 动机: Rust 的内存安全特性和强大的单元测试能力将提升代码质量。
• 端口要求: 维护者需要在 6 个月内为依赖于缺少 Rust 工具链的端口添加支持，否则可能需要停止维护。
• 战略意义: 此举旨在让 Debian 项目能够拥抱现代技术，摆脱旧硬件的限制。

简而言之： Debian 项目将逐步采用 Rust 技术，并要求相关端口进行适配。 这是一项旨在提高代码质量和适应现代软件开发趋势的重大举措。

好的，这是对提供的内容的总结，字数少于800字，并使用Markdown格式，以及中文：

未来锁 (Futurelock) 概述

本文档描述了一种名为 未来锁 (futurelock) 的死锁类型。它发生在以下情况：一个任务中的 Future A 拥有一个资源，而另一个 Future B 需要这个资源才能继续执行，但负责这两个 Future 的任务不再轮询 A。 未来锁是异步 Rust 编程中一种微妙的风险。

问题示例

通过一个示例代码来说明问题：

1. 创建一个共享锁 (Mutex)。
2. 启动一个后台任务，获取锁并持有 5 秒，模拟资源竞争。
3. 在主任务中调用 do_stuff 函数。

do_stuff 函数使用 tokio::select! 同时等待两个 Future：

• future1：等待获取锁。
• future2：睡眠 500 毫秒。

由于只有一个锁，且主任务只轮询 future1，导致死锁。 future1 阻塞在等待锁，future2 睡眠 500 毫秒后，会尝试获取锁，但因为锁被后台任务持有，所以也阻塞。 后台任务释放锁后，future1 获取锁，但由于任务不再轮询 future1，导致 future1 无法继续执行，从而死锁。

未来锁的原因

未来锁的根本原因在于：

• 一个任务阻塞在 Future F1 上。
• F1 阻塞在 Future F2 上 (例如，获取共享的 Mutex)。
• 负责任务阻塞在 F1 上，但没有轮询 F1，因为任务正在轮询另一个 Future。

这种模式常见于使用 tokio::select! 并使用 &mut future，或者在 tokio::select! 的分支处理程序中使用 await。

如何避免未来锁

• 避免使用 &mut future： 尽可能使用 tokio::spawn 创建新的任务来运行 Future，而不是传递 &mut future 到 tokio::select!。
• 避免在 tokio::select! 分支中使用 await： 如果必须使用 tokio::select!，避免在分支处理程序中使用 await，或者确保 Future 之间没有依赖关系。
• 使用 tokio::JoinSet： 如果你正在使用 FuturesOrdered 或 FuturesUnordered，考虑使用 tokio::JoinSet。
• 谨慎使用有界通道： 不要简单地增加有界通道的容量来避免未来锁，这可能会导致其他问题。

调试未来锁

未来锁通常表现为程序挂起。 调试时，需要注意任务是否阻塞在某个 Future 上，以及该 Future 是否依赖于其他尚未轮询的 Future。

总结

未来锁是一种微妙的死锁类型，需要谨慎处理。通过避免潜在的依赖关系和正确使用异步工具，可以有效地避免未来锁的发生。

Jellyfin 与 SQLite 并发问题及解决方案总结 (Jellyfin and SQLite Concurrency Issues and Solutions Summary)

本文介绍了 Jellyfin 在使用 SQLite 数据库时遇到的并发问题，以及 Jellyfin 团队采取的解决方案，并希望这些解决方案能帮助其他使用 SQLite 的 EF Core 应用开发者。

SQLite 的局限性:

• SQLite 是一个基于文件的数据库引擎，数据存储在单个文件中，这带来了便利但也带来了限制。
• 为了确保数据一致性，SQLite 要求同一文件只有一个应用程序能够访问和写入数据。
• 即使在单个应用程序内，也需要确保对 SQLite 文件的并发写入操作受到限制。

Write-Ahead-Log (WAL) 机制:

• SQLite 提供了 WAL 机制来尝试缓解并发写入问题。
• WAL 将写入操作记录在一个单独的文件中，允许并行写入操作被排队。
• 读取数据时，会读取实际数据库文件，并扫描 WAL 文件应用更改，但 WAL 并非万无一失，仍然可能发生锁冲突。

SQLite 事务:

• 事务旨在确保修改的可回滚性，并可选地阻止其他读取操作。
• Jellyfin 团队发现，在某些系统上，SQLite 引擎在事务期间报告数据库被锁定，并拒绝等待事务完成，导致应用程序崩溃。
• 此问题不规律且难以重现，跨操作系统、驱动器速度和虚拟化环境均出现。

Jellyfin 的具体情况:

• 在推荐的配置（非网络存储，最好是 SSD）下，Jellyfin 使用 SQLite 通常不会出现问题。
• 但在 10.11 版本之前，Jellyfin 存在并行任务限制错误，导致库扫描操作被过度调度，数据库引擎被数千个并行写入请求压垮。
• 过长的、效率低下的事务也可能导致数据库过载。

解决方案：EF Core 拦截器与锁策略

Jellyfin 团队通过使用 EF Core 的拦截器，实现了对数据库操作的控制，并引入了三种锁策略：

1. 无锁 (No-Lock): 默认策略，不进行任何锁操作，性能最佳，但可能存在并发问题。
2. 乐观锁 (Optimistic Locking): 假设操作成功，如果失败则重试，降低了开销，但仍有可能失败。Jellyfin 使用 Polly 库进行重试。
3. 悲观锁 (Pessimistic Locking): 在每次写入操作时都进行锁，确保只有一次写入操作发生。虽然最稳定，但性能最低。Jellyfin 使用 ReaderWriterLockSlim，允许多个并发读取，但只允许一次写入。

未来展望:

未来可能将乐观锁和悲观锁结合使用，以获得更佳的性能和稳定性。

总结:

Jellyfin 团队的解决方案提供了一种简单易用的“开箱即用”的并发锁定方案，可以轻松复制到其他 EF Core 应用中，解决类似 SQLite 锁定问题。该方案利用 EF Core 拦截器，无需修改大量 EF Core 查询。

使用 <button> 元素而非 <div> 的重要性

这篇文章探讨了在Web开发中，使用 <div> 元素模拟按钮的行为，与直接使用 <button> 元素相比，为何是错误的实践。作者强调了使用 <button> 元素的重要性，并解释了使用 <div> 元素并手动添加交互功能的弊端。

主要观点：

• 无障碍性问题: <div> 元素默认情况下不会被屏幕阅读器识别为可交互元素。即使添加 role="button" 属性，也无法解决键盘焦点和键盘交互的问题。
• 复杂性: 为了使 <div> 元素像按钮一样工作，需要手动添加 tabindex 属性使其可聚焦，并监听 keydown 事件来响应 Enter 和 Spacebar 键。这会增加代码的复杂性和维护成本。
• <button> 元素的优势: <button> 元素天生具备以下特性：
  • 自动拥有正确的 role 属性。
  • 自动可聚焦。
  • 自动响应 Enter 和 Spacebar 键的点击事件。
• 最佳实践: 开发者应该遵循“使用正确的元素完成工作”的原则，避免不必要的代码编写。使用<button>元素是简单、高效且无障碍友好的解决方案。

总结:

作者认为，在构建Web应用程序时，应尽可能避免使用 <div> 元素来模拟按钮的行为。 使用 <button> 元素可以简化开发过程，提高代码可维护性，并确保应用程序对所有用户（包括使用屏幕阅读器或键盘导航的用户）都具有良好的可访问性。 避免不必要的复杂性，选择最合适的元素，是优秀开发者的标志。

JavaScript HTML 表格 API 的复兴：一种更安全、更高效的构建方式

本文探讨了 JavaScript 构建 HTML 表格的两种常见方法，以及一种鲜为人知的、但潜力巨大的替代方案：HTMLTableElement API。

主要内容：

• 传统方法及其问题： 通常，开发者使用 DOM 方法 (createElement()) 或直接拼接字符串并通过 innerHTML 将数据转换为 HTML 表格。 innerHTML 方法存在安全风险。
• HTMLTableElement API： 存在一个相对古老且被遗忘的 HTMLTableElement API (参考 https://developer.mozilla.org/en-US/docs/Web/API/HTMLTableElement)，它允许开发者循环创建表格、表体、行、单元格、表头、页脚和摘要 (HTML 表格实际上支持这些元素)。 这种方法避免了每次更改都重新渲染整个表格，从而提高了效率。
• 示例代码： 文章展示了如何使用该 API 从嵌套数组创建表格。 具体代码如下：

let table = [
  ['one','two','three'],
  ['four','five','six']
];
let b = document.body;
let t = document.createElement('table');
b.appendChild(t);
table.forEach((row,ri) => {
  let r = t.insertRow(ri);
  row.forEach((l,i) => {
    let c = r.insertCell(i);
    c.innerText = l;
  })
});

• 访问表格单元格： 可以通过索引访问表格单元格，例如 t.rows[1].cells[1] 返回 <td>five</td>。
• 动态修改表格： 可以删除和创建单元格和行。 例如，添加一行并包含一个单元格：

t.insertRow(-1);
t.rows[2].insertCell(0);
t.rows[2].cells[0].innerText = 'foo';

• API 的局限性： 该 API 存在一些奇怪之处，例如使用 -1 添加行到表格末尾，并且无法直接创建 <th> (表头单元格) 元素，所有单元格都是 <td>。
• 未来展望： 作者建议重新审视并扩展 HTMLTableElement API，借鉴 HTML 表单的改进 (例如 formData 和 change 事件)，为表格添加事件和其他功能。 这样可以提升表格的地位，使其成为真正的数据结构，而不仅仅是布局内容的手段。

总结：奥地利经济部转向 Nextcloud，欧洲数字主权趋势日益明显

主要观点：

奥地利经济部（BMWET）已完成向基于 Nextcloud 的云协作平台迁移，该平台由奥地利本土基础设施提供支持。此举是欧洲范围内日益增长的数字主权运动的一部分，旨在减少对美国大型科技公司的依赖，并加强对敏感数据的控制。

关键细节：

• 迁移规模： 1,200 名员工迁移至 Nextcloud 平台。
• 动机： 奥地利经济部认为，作为公共机构，有责任保护大量敏感数据，因此依赖非欧洲公司的云解决方案存在风险。
• 欧洲趋势： 越来越多的欧洲政府和机构正在采取类似措施，例如德国的石勒苏益格-荷尔斯泰因州放弃了 Microsoft Exchange 和 Outlook，丹麦政府放弃了 Microsoft Office 和 Windows，以及法国里昂市放弃了 Microsoft Office 和 Windows。
• EuroStack Initiative： 欧洲企业成立了 EuroStack 倡议基金会，旨在推动“购买欧洲产品、销售欧洲产品、投资欧洲产品”的理念。
• 技术选择： Nextcloud 平台被选为解决方案，因为它提供了开源的优势，并允许国家和组织保持对其应用程序、数据和命运的控制。
• 混合架构： BMWET 采用了混合架构，Nextcloud 用于内部协作和安全数据管理，而 Teams 则保留用于外部会议。
• 集成： Nextcloud 与现有的工作流程集成，包括通过 Sendent 的 Outlook 应用程序与 Outlook 电子邮件和日历的无缝集成。
• 挑战： 奥地利司法部尝试转向 LibreOffice 的经历表明，缺乏周密的计划会导致兼容性问题和用户不满。
• 美国反应： 美国外交官对欧洲推动数字主权表示担忧，并就此问题与法国和德国官员进行了交谈。

总结：

奥地利经济部成功转向 Nextcloud 平台，体现了欧洲数字主权趋势的兴起。虽然完全摆脱现有系统可能具有挑战性，但通过周密规划和适当的实施，开源解决方案可以为公共部门提供安全、用户友好且快速的数字主权途径。

S.A.R.C.A.S.M 项目总结

S.A.R.C.A.S.M (Slightly Annoying Rubik's Cube Automatic Solving Machine) 是一款3D打印的机器人，它使用 Teensy 作为主控制器，并配备 ESP32-CAM 用于图像捕捉，能够扫描、解决并带有讽刺性评论的鲁班立方体。该项目代码和原理图已发布在 GitHub 仓库中。更多细节可在 Teensy 论坛线程中找到：https://forum.pjrc.com/index.php?threads/sarcasm-an-over-engineered-rubiks-cube-solving-robot.77338/。

演示视频：

• 短视频：https://youtube.com/shorts/Xer4mPZZH8E
• 完整演示：https://youtu.be/WV52RtuWXk0

主要特点：

• 主控制器: Teensy 4.1，搭配 ESP32-CAM 用于图像采集。
• 显示屏: ILI9341 显示屏，显示自定义的 2D 和 3D 图形、动画以及唇同步效果。
• 运动控制: 步进电机和舵机用于控制立方体，并配备位置传感器以检测故障。
• 灯光: RGBW 灯光与音频同步。
• TTS (文本转语音): 集成设备 TTS (使用 espeak-ng)，包含一系列讽刺性的语句。
• 其他: 鲁班立方体扫描、解决功能。

注意事项：

为了使整个代码能够装入 RAM，需要对 Teensy 的核心代码进行轻微修改。需要编辑 cores/teensy4/usb_serial.c 和 cores/teensy4/usb_serial2.c 文件，并在 txbuffer[] 和 rx_buffer[] 数组的定义前移除 DMAMEM 属性。

警告：

这是一个正在进行中的项目。代码仓库目前处于非常混乱和不完整的状态（并且很可能保持这种状态，直到有时间进行维护...）。 抱歉！

关于美国在线体育博彩的反弹：一场对企业赌博扩张的反击

今年早些时候，马里兰州参议员Joanne C. Benson 引入了 Senate Bill 1033，旨在“废除该州的网络体育博彩”。虽然通常情况下，一位州议员提出一项提案并不引人注目，但此次事件标志着对美国企业主导的赌博扩张的反击，这种趋势自 1970 年代以来一直未受到有效挑战。 值得注意的是，佛蒙特州和纽约州也正在采取行动，预计更多的州立法机构将加入其中。

背景：盛行与担忧

自从2018年美国最高法院的判决为网络体育博彩扫清障碍以来，在线体育博彩在美国迅速蔓延。 约有五分之一的美国人过去一年内参与过赌博，主要通过博彩应用程序。 迄今为止，美国人已在体育博彩上花费超过五千亿美元。 这种趋势通过亚马逊 Prime 等媒体平台上的大量广告，以及与主要体育媒体、联盟和播客的合作，在文化中变得无处不在。 FanDuel 甚至开始运营15家原本濒临破产的区域体育网络。

负面影响日益显现

这种快速扩张带来的负面影响也逐渐显现。 体育领域受到腐蚀，运动员面临不公正的压力。上周，政府就赌博相关的欺诈行为指控了六人，其中包括两名 NBA 球员。 此外，在线体育博彩还助长了成瘾行为，并引发了财务问题。 调查显示，21%的体育博彩者在输钱后曾辱骂过运动员，四分之三的博彩者使用博彩应用程序，其中四分之一无法支付账单，三分之一背负着赌博债务，一半背负着信用卡债务，并且四分之一的人无法控制自己的赌博行为。 经济学家发现，在合法化在线体育博彩的州，消费者破产率、债务上缴、债务整合贷款使用和汽车贷款逾期率都有“显著增加”。 专家预计，在未来五年内，包括彩票、拉斯维加斯赌场和在线体育博彩在内的所有赌博活动，美国人总共将损失约一万亿美元。

成瘾的陷阱与社会成本

许多人，包括精神科医生 Kavita Fischer，都亲身经历了在线体育博彩的成瘾性。 Fischer 下载 DraftKings 以放松心情，最终损失了 60万美元。 这种经历并非个例，甚至蔓延到青少年群体，他们也开始拨打帮助热线。 这一现象已经引发了 Saturday Night Live 的恶搞，讽刺了 “Rock Bottom Kings” 这种允许人们在朋友的赌博成瘾行为上进行投注的公司。

公众舆论的反转

公众对在线体育博彩的态度正在发生转变。 根据皮尤研究中心的数据，43% 的美国成年人认为将体育博彩合法化对社会是件坏事，比三年前增加了 9%。 其中，不满情绪尤其集中在 30 岁以下的男性群体中。 重要的是，那些参与赌博的人对这种形式的赌博的反对情绪比那些不参与赌博的人更为强烈。 问题不在于人们是否反对朋友间的赌博，而是围绕着企业以赌博为基础建立商业模式。

历史渊源：从道德谴责到合法化

这种对企业主导的赌博的快速合法化颇为讽刺。 历史上，美国一直对系统性的赌博持谨慎态度，将其视为类似于高利贷等滥用权力行为的道德和社会灾难。 这种态度一直持续到 20 世纪，当时企业赌博被限制在黑帮控制的拉斯维加斯和亚特兰大等场所。

1963 年，新罕布什尔州州长 John King 签署了一项法案，创建了第一个州彩票，引发了全国主要报纸和联邦政府的强烈抗议。 这一举动被认为是赌博合法化的开端，从此赌博从一种可疑的活动转变为州政府认可的活动。

随后，新泽西州和纽约州也效仿，并在 20 世纪 70 年代，一些进步倾向的东北州为了应对财政困境，纷纷推出了彩票。 这一趋势逐渐蔓延到全国各地，只有犹他州、阿拉斯加州和夏威夷州没有合法化彩票。

企业力量的崛起

里根总统时期，宗教保守派对赌博

混沌吸引子的可视化：从简单方程到复杂模式

本文探讨了混沌吸引子，以及其背后的数学概念，并展示了使用 Three.js 创建其可视化的过程。

核心概念：动力系统与混沌理论

• 动力系统: 描述系统随时间变化的数学模型。系统由规则（或函数）定义，这些规则根据当前状态确定下一状态。例如，行星运动、天气模式、病毒传播等。
• 相空间: 包含系统所有可能状态的集合。每个状态代表系统在特定时刻的快照。
• 混沌理论: 动力系统的一个分支，研究表现出随机性和不可预测性的系统。即使系统遵循确定性规则，由于信息不完整或初始条件微小变化的影响，预测变得困难，这就是所谓的“蝴蝶效应”。

吸引子与混沌吸引子

• 吸引子: 系统在演化过程中趋于稳定的状态集合。例如，摆锤最终静止在最低点，最低点就是吸引子。
• 混沌吸引子: 一种复杂的、非重复轨迹的吸引子，具有以下特征：
  • 分形结构: 呈现不同尺度上的复杂重复图案。
  • 对初始条件的敏感性: 初始状态的微小变化会导致长期行为的巨大差异（蝴蝶效应）。
  • 不可预测的轨迹: 轨迹不会重复，表现出随机性。
  • 混沌中的秩序: 虽然看似随机，但混沌吸引子仍然展现出潜在的秩序和结构。

Thomas 吸引子示例

文章通过 Thomas 吸引子展示了混沌吸引子的行为。通过微调控制面板中的参数(a值)或初始状态（从立方体到球形表面），可以看到系统行为的显著变化，体现了蝴蝶效应。

实现细节：使用 Three.js 进行可视化

文章介绍了使用 Three.js 创建可视化时的实现细节：

• 帧缓冲对象 (FBO): 使用两个 FBO (ping 和 pong) 来存储粒子状态，实现高效的 GPU 计算。
• 着色器程序: 使用着色器程序在 GPU 上应用吸引子动力学规则，根据吸引子方程更新粒子位置。
• 乒乓渲染: 通过在每个帧中交换 FBO 的角色，实现高效的粒子系统更新。

总结

文章介绍了动力系统、混沌理论和混沌吸引子的基本概念，并通过可视化的方式，展示了混沌系统中的复杂行为和秩序。 使用 Three.js 的乒乓渲染技术能有效实现大规模粒子的可视化，展示了混沌吸引子的美丽和复杂性。

好的，以下是基于您提供的文本的摘要，使用 Markdown 格式，并以中文呈现：

Android 开发者验证与 APK 加载器方案：面临的挑战与未来展望

Google 近期引入了开发者验证机制，旨在将所有 APK 与开发者关联，提高 Android 平台的安全性。此举引发了诸多争议，主要集中在对小型开发者和 sideloading (侧载) 应用的限制。

问题与担忧：

• 成本与门槛： 基本验证层级需要支付 25 美元，且需要身份验证。虽然有“业余爱好者”免费许可，但其限制未知，可能不适用于需要较高安装量的开发者。
• 隐私问题： 法律信息不再公开，与 Play Market 不同。
• 技术不确定性： 验证码位于 Play Services 中，但 Google 未公开源代码。ADB 安装虽被允许，但未来是否可用且安全性如何尚不明确。
• AOSP 限制： Google 近期将 Android 开发私有化，并更改 AOSP 发布格式，使得追踪 Google 的具体操作变得困难。
• 兼容性问题： 现有 APK，例如使用过时存储权限的引擎移植，可能无法通过验证。
• 用户体验： 用户自行进行 sideloading 操作复杂，可能成为开发者的负担。
• 设备限制: 厂商如三星已开始限制 Bootloader 解锁，进一步限制了用户自定义及刷机。

解决方案构想：APK 加载器

为了应对这些问题，作者提出了一个 APK 加载器的方案：

• 原理： 用户只需获取一次经过验证的加载器 APK，然后可以动态加载任意 APK，无需每次都进行安装。
• 技术基础： 利用 Android Runtime (ART/Dalvik) 原生支持的动态代码执行功能 (PathClassLoader)，将 APK 加载到内存中并执行。
• 实现方法： 加载器需要正确初始化目标 APK 的主活动，并处理文件处理和命名冲突等问题。可能的实现方式包括：
  • 动态编译和修改 APK 字节码 (.odex/.dex)。
  • 使用 Unsafe Dalvik API 将目标 APK 的活动注册为加载器 APK 的活动桩。

面临的挑战：

• 技术复杂性： Android 的活动管理逻辑复杂且版本间差异大，实现加载器较为困难。
• Google 限制： 加载器代码可能被 Google 标记为恶意软件，需要进行代码混淆和功能隐藏。
• 维护成本： 加载器可能很快被 Google 禁用，需要持续维护和更新。
• 验证问题： 业余爱好者许可的限制和 Google 对应用验证的严格性是主要问题。
• 依赖性： 方案依赖于志愿者或随机用户进行代码签名和混淆，存在潜在的安全风险。

未来展望：

作者认为，即使当前方案尚未完善，但解决 Android 开发者验证问题的技术方案仍然值得探索。未来可能出现更完善的解决方案，尤其是在 Google 限制 ADB 安装的风险日益增加的情况下。作者强调，真正的希望在于 root-based 解决方案，并希望它们能够持续存在。

更新：

作者分享了在 Ycombinator 上的讨论，并解释了为什么即使存在 ADB 和 Shanzuku，仍然需要探索替代方案，因为 Google 可能会进一步限制 ADB 的使用。

**总而言之，**该文章探讨了 Android 开发者验证机制带来的挑战，并提出了一种基于 APK 加载器的潜在解决方案。虽然该方案面临诸多挑战，但作者认为，探索替代方案对于维护 Android 平台的开放性和灵活性至关重要。

CharlotteOS – Catten 项目总结 (CharlotteOS – Catten Project Summary)

以下是对 CharlotteOS 项目中 Catten 内核文档的总结：

一、Catten 内核简介 (Introduction to Catten Kernel)

Catten 是 CharlotteOS 的内核，设计为一个健壮、通用、单内核系统，强调清晰性、安全性及架构灵活性。虽然是 CharlotteOS 的一部分，但其结构允许作为其他系统的基础。Catten 借鉴了 exokernels、Fuchsia 和基于能力的微内核设计理念，同时保持单内核的性能和简洁性。它提供了一个极简的低层系统调用接口，方便各种高级运行时和用户环境构建在之上。Catten 还提供了一个类型安全、基于能力的系统命名空间，采用类似于 Plan 9 和 Fuchsia 的 URI 路径，并进行了扩展，以实现更强的类型安全、干净的访问语义以及无需挂载即可访问其他主机命名空间的能力。命名空间操作由细粒度的能力和强制访问控制策略控制。目前项目仍处于早期开发阶段，欢迎贡献。

二、编程语言 (Programming Languages)

• Catten 主要使用 Rust 编写，架构相关的部分使用汇编语言。
• x86-64 汇编使用 Intel 语法，由 rustc/llvm-mc 实现。
• 对于高质量 Rust 替代方案不存在的经过验证的组件，允许使用少量 C 代码。

三、外部依赖 (External Dependencies)

• 仅允许使用 Rust、C 和汇编语言进行实现。
• 任何 C 依赖项都需要批准和证明其必要性。
• 禁止使用非 Rust/C/ASM 依赖项。
• 除非由于规范或互操作性约束，否则优先选择高质量的 Rust crate。

四、平台与固件要求 (Platform & Firmware Requirements)

CharlotteOS 旨在支持提供标准化、有文档且可互操作的硬件接口的平台。重点是操作系统可以依赖明确定义的固件和可发现机制的系统，而无需进行特定于供应商的 hack 或不透明的初始化序列。

• 支持架构 (Supported Architectures):
  • x86-64 (主要架构): Invariant Timestamp Counter, Local APIC with x2APIC mode, 全面的 UEFI 和 ACPI 固件环境。
  • RISC-V64 (次要架构): RVA23 或更高版本, V 扩展非必需, SBI 运行时用于早期启动, 采用 ACPI 或 符合 DTSpec 标准的设备树。设备树必须引用公开记录的 IP 模块，特定于供应商的外设需要可访问的文档。

五、固件模型 (Firmware Model)

Catten 支持 ACPI 和设备树，两者权重相同，格式并非决定性因素，文档和正确性才是关键。

• UEFI: PC/服务器级系统所有架构都需要。提供引导服务、内存描述符和帧缓冲区/控制台访问。
• ACPI: PC/服务器级 RISC-V 和所有 x86-64 系统预期使用。ACPI 表必须完整且符合规范，以便在没有特定于供应商的解决方法的情况下进行设备发现。
• 扁平化设备树 (FDT): 完全支持 SoC 风格平台。FDT 必须符合 DTSpec 并且准确描述硬件资源。所有 compatible 字符串必须映射到公开记录的硬件模块或 IP 核心。

六、硬件建议 (Hardware Recommendations)

• 内存 (Memory): 推荐 ≥ 1 GiB，最小 128 MiB。
• 存储 (Storage): 推荐 ≥ 64 GiB，最小 4 GiB。支持 NVMe (PCIe) 和 USB Mass Storage (MSC)。
• 显示 (Display): 通过 UEFI GOP 或 FDT simplefb 节点暴露线性帧缓冲区。
• 输入设备 (Input Devices): 支持 i8042 PS/2, USB HID, 以及文档化的 ACPI/FDT I²C HID 键盘；支持 USB HID 指针。
• 串行控制台 (Serial Console): NS16550 兼容的 UART 或 USB CDC-ACM (虚拟串行)。
• 网络 (Networking): USB CDC-NCM (USB 上的以太网)。

七、贡献 (Contributing)

欢迎各种形式的贡献：代码、设计提案、文档和测试。 可以通过 Discord 或 Matrix 加入社区参与。新的硬件支持贡献必须

初创公司盈利的重要性：控制命运，专注价值 (The Importance of Profitability for Startups: Controlling Your Destiny, Focusing on Value)

这篇文章探讨了初创公司长期以来被灌输的“优先增长，忽视盈利”的观念，并阐述了盈利对初创公司的重要性。作者以自身公司 Linear 的经验为例，强调了盈利不仅可行，而且能带来诸多优势。

核心观点：

• 盈利并非 unambitious，而是掌控命运的关键。 盈利意味着公司无需依赖外部投资生存，可以专注于最初的愿景和使命，并自主决定增长速度。
• “Ramen Profitability” 的价值。 借鉴 Paul Graham 的观点，当公司能够仅靠创始团队的收入维持生存时，将更具吸引力，表明其能获得客户付费，并且对产品建设和成本控制有自律性。
• 小团队的优势。 作者认为，小团队通常能提供更高质量、更快的进度，而过度追求团队扩张可能导致管理负担、意见分歧和愿景稀释。
• 盈利带来的内心平静。 盈利后，公司不再担忧生存问题，可以专注于构建卓越的产品，并做出对客户和产品最好的决策，而非为了迎合投资者。

关键策略与建议：

• 关注单位员工营收 (Revenue per Employee)。 作为衡量招聘是否合适的指标，初创公司可以考虑目标范围为每位员工 50 万至 100 万美元。
• 谨慎招聘，缓慢增长。 产品市场契合 (Product-Market Fit) 之前，团队规模应控制在十人以内。之后，每位新员工都应解决特定的、紧迫的需求，而非仅仅为了填补组织架构。
• 在自己设定的条件下融资。 盈利不意味着排斥投资者，而是拥有选择权。公司可以根据自身情况决定是否融资、融资多少以及何时融资。
• 了解风险概况。 如果是构建全新的市场，或者需要大量前期投资，盈利可能需要更长时间。但如果是在现有市场基础上进行创新，则可能更快实现盈利。

Linear 的经验：

• Linear 在发布后仅 12 个月内就实现了盈利，并持续保持盈利状态。
• 公司通过保持团队精简和专注，构建了卓越的产品，并获得了用户的高转化率。

总结：

文章鼓励初创公司重新审视盈利的重要性，并相信在适当的条件下，盈利是可以实现的。 盈利不仅能带来财务上的稳定，更能赋予公司更大的自主权和战略灵活性，最终专注于创造价值。 许多成功的公司其实在早期就实现了盈利，只是没有公开谈论。

数据.gov 档案搜索：重新思考成本、复杂性和访问的平衡

本文档介绍了哈佛大学法律信息实验室 (LIL) 开发的数据.gov 档案搜索项目，旨在探索一种新的、低成本且易于维护的在线数据发现方法。该项目解决了长期以来困扰图书馆、数字人文项目和文化遗产组织的难题：如何在数据访问和可负担性之间取得平衡。

传统困境：

• **动态服务器方案：**提供强大的数据发现功能（如浏览、过滤和搜索）通常需要昂贵的专用计算基础设施，包括服务器和数据库。维护、安全更新和持续运维都需要专业人员，长期成本高昂且容易因预算变化和人员变动而导致项目失效。
• **静态文件托管：**虽然成本低廉（例如，在Amazon S3上存储数据每月只需1美元或更少），但静态托管限制了数据发现的丰富性，用户只能通过预先渲染的浏览层级或受限于客户端内存的搜索功能访问数据。

项目背景与目标：

LIL 致力于为 Data.gov 档案提供发现服务，并希望构建一个轻量级且易于维护的访问点。目标是实现低成本的数据发现，同时确保长期可访问性。 该项目借鉴了 LIL 之前 Caselaw Access Project (CAP) 的经验，后者已转向静态站点。 Data.gov 档案包含近 18TB 的数据，手动浏览非常耗时，因此项目旨在解决如何在静态托管下实现动态、可扩展的数据发现问题。

技术方案：

该项目采用了一种创新的方法，利用了新兴的客户端数据分析技术：

• 数据存储： 将 Data.gov 档案目录元数据存储为排序、压缩的 Parquet 文件在 Source.coop 上，利用高性能的静态文件托管。
• 客户端查询引擎： Web 应用程序加载 DuckDB-Wasm，一个在用户浏览器中运行的完整数据库引擎。
• 按需数据访问： 用户导航到资源或提交搜索时，DuckDB-Wasm 客户端执行有针对性的数据检索，以满足请求，无需专用服务器，查询完全在浏览器中运行。

面临挑战与未来发展：

尽管该方案取得了积极成果，但也存在一些挑战，例如DuckDB-Wasm 二进制文件的大小导致延迟，以及对数据工程要求较高。 LIL 正在探索替代方案，如 hyparquet 和 Arquero，以进一步提升性能。

项目意义：

该项目为图书馆、学术档案和数字人文项目提供了一个有吸引力的模型：

• 降低运营成本： 通过从昂贵的服务器转向低成本的静态存储，项目可以可持续地为用户提供数据访问。
• 减少技术负担： 无需专用后端服务器，降低了安全风险，无需打补丁或升级，避免了服务器崩溃。
• 持续访问： 项目可以精心设计，但无需持续关注，组织可以更有信心，即使人员或资金发生变化，档案和发现界面仍然可用。

LIL 鼓励其他组织尝试基于浏览器的搜索工具，并欢迎社区分享经验和合作，通过 lil@law.harvard.edu 联系。

Grokipedia 早期印象总结 (Grokipedia Early Impressions Summary)

本文记录了 Tim Bray 对新平台 Grokipedia 的早期体验，Grokipedia 旨在作为对维基百科“觉醒偏见”的解药。Bray 比较了 Grokipedia 和维基百科关于他本人的条目，并分享了他的观察和结论。

主要发现：

• 内容详尽但错误百出： Grokipedia 条目（超过七千字）比维基百科条目（一千三百字）更详尽，明显由大型语言模型 (LLM) 生成。然而，Bray 认为条目存在大量错误，甚至自相矛盾。
• 写作风格平淡： LLM 生成的文本缺乏个人风格，显得“平淡无奇”。
• 引用问题： 引用仅仅是 URL 链接，且很多链接无法支持文本内容。Bray 以其参与 FTC 对 Meta 收购 Instagram 和 WhatsApp 的诉讼为例，指出引用来源的文档中并未找到支持相关论断的信息。
• 未能满足维基百科的两种主要用途： Grokipedia 既不能提供快速了解基本信息，也不能提供深入研究特定主题的深度信息。
• 对抗“觉醒”的尝试： Grokipedia 试图通过反驳“觉醒”观点来实现其目标。Bray 举例说明，在讨论 FTC 诉讼时，Grokipedia 引用了多篇文章，强调大型科技公司的投资和对经济的贡献，以此反驳对垄断行为的批评。类似的情况也出现在 Greta Thunberg 和 J.D. Vance 的条目中，通过引用特定来源来质疑他们的观点。
• 结论： Bray 总结，维基百科允许有引用的任何人编辑，而 Grokipedia 则是由 Elon Musk 的 LLM 编辑，带有可疑的引用和对“觉醒”论点的攻击。他认为 Grokipedia 正在按照其设计意图运作。

总体评价：

Bray 对 Grokipedia 的评价较为负面，认为其内容不准确、引用不足，且写作风格平淡。虽然他承认这可能只是 0.1 版本，但目前来看，Grokipedia 并未成为一个有用的百科全书替代品。他认为其主要目标是反击所谓的“觉醒偏见”，但这种做法带来了内容质量和准确性的问题。

电子邮件验证协议 (Email Verification Protocol) 总结

该协议旨在解决当前网页上验证电子邮件地址的挑战，提供一种无需发送电子邮件、且用户无需离开网页的验证方法。

现有方法及其问题：

• 发送验证链接/代码： 用户需要切换到邮箱，等待邮件并进行验证，容易导致用户放弃。此外，电子邮件传输会泄露用户使用应用程序的信息给邮件服务提供商。
• 社交登录： 需要与多个社交提供商集成，管理密钥和配置，且用户必须使用这些服务并愿意共享更多个人资料信息。

Email Verification Protocol 的解决方案：

该协议通过以下方式实现电子邮件验证：

1. 邮件域名委托： 邮件域名将电子邮件验证的责任委托给一个 Issuer，Issuer 拥有用户的身份验证 Cookie。
2. Token 交换：
   • 用户在 HTML 表单字段中输入电子邮件地址。
   • 浏览器调用 Issuer，传递身份验证 Cookie。
   • Issuer 返回一个 Token。
   • 浏览器验证 Token 并将其提供给 Web 应用程序。
   • Web 应用程序验证 Token，从而获得已验证的电子邮件地址。

核心概念：

• SD-JWT+KB Token: 一种特殊的 JSON Web Token (JWT)，由两个 JWT 组成，使用 ~ 分隔。
  • Issuance Token (SD-JWT): 由 Issuer 签名，包含用户的 email 和 email_verified 声明，以及浏览器用于请求的公钥。
  • KB Token: 由浏览器签名，包含对 Issuance Token 的哈希值。
  • SD-JWT+KB 结合 Issuer 提供的电子邮件地址和浏览器验证的签名，确保了验证的安全性。
• Issuer: 验证用户控制电子邮件地址的服务。它通过 DNS 记录进行标识，并提供 .well-known/email-verification 描述文件，其中包含 issuance_endpoint (用于获取 Issuance Token 的 API 终点) 和 jwks_uri (指向包含 Issuer 公钥的 JWKS 文件的 URL)。

用户体验：

用户在需要验证电子邮件的网站上输入电子邮件地址，浏览器会显示用户先前提供的电子邮件列表供用户选择。

处理步骤：

1. 电子邮件请求: RP (Web 应用程序) 生成 nonce 并绑定到会话。
2. 电子邮件选择: 用户选择电子邮件地址。
3. Token 请求: 浏览器查找 Issuer 的 DNS 记录，获取 issuance_endpoint，并生成一个 request token。
4. Token 发行: Issuer 验证请求，生成 SD-JWT 并返回给浏览器。
5. Token 呈现: 浏览器验证 SD-JWT，创建 KB Token，并将 SD-JWT+KB 提供给 RP。
6. Token 验证: RP 将 SD-JWT+KB 发送给 RP Server，RP Server 验证 SD-JWT 和 KB-JWT。

隐私考虑：

• Issuer 不会知道 Web 应用程序的身份，请求由浏览器中介。
• Issuer 可能学习到用户拥有特定邮件域的电子邮件地址。

替代方案:

• 使用 .well-known 域名进行邮件域名委托，但会给小型域名带来技术挑战。
• 使用 Passkey 身份验证，允许用户通过 Passkey 验证身份并提供电子邮件地址。

总结：

Email Verification Protocol 提供了一种安全、隐私友好的电子邮件验证方法，无需发送电子邮件或重定向用户。它通过浏览器中介和 SD-JWT+KB Token 的使用，实现了电子邮件验证的去中心化和保护用户隐私。

关于“打破信息孤岛”的再思考：拥抱孤岛，优化协作 (Reconsidering "Breaking Down Silos": Embrace Silos, Optimize Collaboration)

本文挑战了普遍存在的“打破信息孤岛，促进协作”的观点，认为过度协作反而可能有害，而适当的“信息孤岛”则是高效组织的关键。

核心观点：

• 内部团队协作至关重要，跨团队协作应尽量减少。 高度协作的团队能够共享目标、提高专注度、促进知识交流、激发创新，并降低人员变动带来的影响。
• 信息孤岛是必然存在的，也是人类认知和沟通能力的限制所致。 随着公司规模扩大，沟通和依赖关系会增多，需要明确的结构来管理这些关系，避免沟通负担过重。
• “打破信息孤岛”是一种不完整的思考。 这种说法将问题归咎于个人，而非系统本身。更重要的是，要区分协调、沟通和协作这三个概念。

详细内容：

1. 为什么最大化团队内部协作？

作者强调，高效的团队需要内部高度协作，原因包括：

• 共享状态： 团队成员对目标、进度和分工有共同理解。
• 提高专注度： 团队成员能更好地协调工作。
• 知识共享： 内部互相评审和学习。
• 增强创新： 团队成员互动能够激发更多想法。
• 降低风险： 团队成员离职影响较小。

2. 为什么最小化跨团队协作？

作者认为，跨团队协作应尽量减少，因为：

• 规模扩大带来的问题： 随着公司规模扩大，跨团队沟通会变得复杂，难以管理，最终导致项目执行困难。
• New Relic的案例： 过度鼓励跨团队协作，最终导致项目无法顺利进行，最终解决方案是通过定义团队交互模式、减少依赖关系和建立优先级结构。
• Bezos 的 API 强制令： 亚马逊通过限制团队间的依赖关系来提高效率。

3. 什么是信息孤岛？

信息孤岛是指基于组织结构和团队划分的团队之间的边界。

4. 为什么信息孤岛存在？

信息孤岛的存在源于人类的认知和沟通限制：

• 人际关系数量有限。
• 沟通能力有限。
• 天生倾向于团队合作。
• 专注力有限。

5. 为什么领导者想打破信息孤岛？

领导者通常在以下情况下会考虑打破信息孤岛：

• 部门目标与公司整体目标不一致。
• 不同团队重复工作。

6. “打破信息孤岛”的缺陷：

作者认为，“打破信息孤岛”是一种缺乏具体性的呼吁，未能深入分析问题。

7. 协调、沟通和协作的区别：

• 协调： 确保各个部分和谐运作以实现有效结果。作者建议集中协调、分散决策和执行，这是一种高效的组织设计模式。
• 沟通： 信息在个人或团队之间的传递。改善沟通的关键在于了解信息流，并进行优化。
• 协作： 团队共同努力以实现结果。作者认为，团队需要协作通常表明团队结构不够完善。

8. 技术类比：

作者将信息孤岛类比为“封装”，指出过度深入其他团队的代码是解决问题的错误方法，需要进行更好的结构化。

9. 如何更好地协调团队？

作者将在下一篇文章中分享具体的协调模式。

总结：

本文强调了信息孤岛在组织中的重要性，认为适当的“隔离”能够提高效率，并建议领导者关注协调和沟通，而不是盲目地追求跨团队协作。 核心在于优化组织结构，而不是简单地要求员工“打破信息孤岛”。

总结：科技巨头裁员、投资人工智能及市场现状 (Summary: Tech Giants' Layoffs, AI Investments, and Market Status)

本文分析了近期科技行业出现的大规模裁员现象，以及这些公司对人工智能（AI）的巨额投资之间的关系，并揭示了其背后的复杂经济逻辑。

主要要点：

• 大规模裁员： 亚马逊宣布裁员 3 万人，加上微软、Meta、谷歌等公司今年已裁员超过 18 万名科技工人。
• 人工智能投资激增： 这些公司今年计划在人工智能领域投入超过 3000 亿美元。
• 裁员的借口： 公司普遍以“调整业务以适应人工智能”、“人工智能取代部分工作岗位”、“为人工智能项目提供资金”等理由进行裁员。
• 资金循环： 这些公司并非节省下来的资金用于投资，而是相互购买产品和服务，形成了一个循环。例如：
  • 微软购买英伟达芯片、租用亚马逊AWS云服务、购买其他软件。
  • 亚马逊购买英伟达芯片、使用微软软件、租用无法快速构建的云服务。
  • Meta购买英伟达芯片、租用谷歌云和AWS基础设施。
  • 苹果租用谷歌、AWS和Azure等公司的AI基础设施。
• “七大奇迹”公司及市场影响： 苹果、微软、英伟达、亚马逊、Alphabet（谷歌）、Meta和特斯拉这七家公司合计市值高达 17 万亿美元，营收 2.2 万亿美元，净利润约 5500 亿美元。它们的平均市盈率高达 35，远高于标准普尔 500 指数（不包括这七家公司）的 15.5。市场对人工智能未来盈利能力的预期推高了这些公司的估值。
• 被困的军备竞赛： 这些公司无法停止投资人工智能，因为任何停止都会导致股价下跌，投资者会认为他们放弃了人工智能，落后于竞争对手。这导致它们陷入了军备竞赛，不得不继续支出，即使这些支出尚未产生回报。
• 对GDP的贡献： 人工智能支出对GDP的贡献微乎其微，仅为 0.5%，如果剔除人工智能支出，GDP增长可能达到 0.6%。
• 实际盈利情况： 目前，只有 Meta 展现出实际的人工智能收入。其他公司仅仅在进行支出，希望未来能够获得回报。高盛和西科资本的研究报告表明，目前人工智能的投资回报率几乎为零。
• 退休金受影响： 许多人的 401k 退休金账户可能包含大量标准普尔 500 指数基金，而标准普尔 500 指数的三分之一由这七家公司组成，2024 年的增长中有 54% 来自这些公司的人工智能支出。如果人工智能投资未能带来预期的回报，这些公司将会被严重高估。

总结：

科技巨头们正在通过裁员来“资助”人工智能投资，但实际上，他们是将资金在彼此之间循环，而尚未获得实际的利润。这种模式支撑着股市的上涨，但也存在风险，因为一旦投资未能带来回报，这些公司将面临巨大的估值风险。 投资者需要意识到，他们的退休金可能很大程度上依赖于这些公司的人工智能投资能否成功。

扩展与收缩模式：安全迁移数据库结构指南

本文介绍了“扩展与收缩模式”，这是一种安全地迁移客户端到新的数据结构，而无需系统离线的多步骤过程。该模式适用于数据库管理员和软件开发人员，可用于数据库结构变更，并允许在出现问题或需求变更时轻松回滚。

核心概念：

• 数据库迁移: 指更新实际的数据结构，而扩展与收缩模式侧重于数据转换、迁移到不同表或列以及更新数据以符合新期望。
• 扩展与收缩模式: 一个逐步的过程，通过一系列离散步骤引入新的结构，准备数据以供实时使用，然后无缝切换到新的结构。

使用扩展与收缩模式的步骤：

1. 构建并部署新模式:

   • 设计满足新需求的新模式，优先进行小规模修改。
   • 在现有结构旁边部署新的数据结构，避免直接修改现有列。例如，如果需要将 name 列拆分为 first_name 和 last_name，则添加这两个新列，而不是修改 name 列本身。
   • 确保新列没有会使当前客户端行为失败的约束，通常需要将新列设置为可为空或提供默认值。

2. 扩展接口:

   • 更新客户端代码，使其识别新的列和表。
   • 在执行写入操作时，客户端同时向旧结构和新结构写入数据。
   • 客户端开始向新结构插入数据，同时继续读取旧结构的数据，外部行为保持不变。

3. 迁移现有数据到新模式:

   • 将现有数据从旧列或表迁移到新列或表。
   • 可能需要修改数据类型、拆分值、回填默认值等。
   • 确保数据迁移的正确性和语义等效性。

4. 测试新接口:

   • 在新结构拥有数据后，测试新接口的功能和性能。
   • 可以使用备用或副本服务器进行测试，以避免影响生产流量。

5. 切换读取到新接口:

   • 修改客户端行为，使客户端从新模式读取数据。
   • 这是一个关键的切换点，如果需要回滚，可能会导致数据丢失。

6. 停止写入到原始结构:

   • 更新客户端代码，停止向原始结构写入数据。

7. 从系统中移除原始结构:

   • 在所有客户端都已更新后，可以安全地删除原始的数据结构。

示例：

本文以一个公园区设备管理表的例子说明了该模式的应用：

• 最初，equipment 表包含 city、park 和 playground 列来记录设备安装位置。
• 新的设计将位置信息移动到 playground 表中，包含 city、park 和 sq_ft 列。
• 通过以下步骤实现迁移：
  1. 创建新的 playground 表。
  2. 更新客户端代码，同时向 equipment 表和 playground 表写入数据。
  3. 开发脚本将现有数据迁移到 playground 表。
  4. 测试新接口。
  5. 切换客户端读取到 playground 表。
  6. 停止向 equipment 表写入数据。
  7. 删除 equipment 表中的旧位置列。

总结：

扩展与收缩模式是一种强大的工具，可以安全地过渡数据库结构和数据，同时保持客户端服务。 通过仔细规划和实施，可以避免常见问题，并确保系统无中断服务。 它允许在出现问题或需求变更时轻松回滚，但需要注意在切换点可能丢失的数据。

相关工具:

• Prisma Migrate: Prisma 提供的工具，可以基于声明式 Prisma Schema 生成和应用迁移文件。
• Redis: 用于定义和管理功能标志，例如控制写入和读取目标。

早期猜谜游戏：Wordle 的历史渊源与 BASIC 编程的兴起 (Early Guessing Games: The Historical Roots of Wordle and the Rise of BASIC Programming)

这篇文章探讨了流行游戏 Wordle 的历史渊源，并追溯了更早期的猜谜游戏，这些游戏主要基于 BASIC 编程语言。

Wordle 的前身：WORD

虽然 Wordle 通常被追溯到 1987 年的电视游戏节目 Lingo，但文章指出，早在 1973 年，Digital Equipment Corp. 的 101 Computer Games 就包含了名为 WORD 的类似游戏。WORD 后来也被收录在 Creative Computing 的畅销书 BASIC Computer Games 中，后者销量超过一百万册。WORD 的玩法类似于 Wordle，玩家通过猜测单词并获得反馈（字母是否正确且位置是否正确）来猜出一个隐藏的单词。

猜谜游戏的早期起源：GUESS

文章提到，猜谜游戏有一个简单的结构：计算机隐藏信息，玩家猜测，计算机提供线索。其中一个最早的此类程序名为 GUESS，由 Walt Koetke 使用 FOCAL 语言编写。GUESS 启发了许多其他游戏，包括 WORD。

基于 BASIC 的猜谜游戏系列

文章详细介绍了许多基于 BASIC 编程语言的猜谜游戏，它们都源于 GUESS 的启发：

• HI-LO: 猜一个数字，每次猜对赢得相应金额的奖金。
• NUMBER: 猜一个 1 到 5 之间的数字，赢或输特定金额。
• STARS: 猜一个数字，越接近数字，屏幕上显示的星号越多。
• TRAP: 猜两个数字，试图“困住”隐藏的数字。
• BAGELS: 猜一个三位数，根据猜对的位数给出提示（Pico, Fermi, Bagels）。
• LETTER: 类似于 BAGELS，但使用字母代替数字。
• HURKLE: 将数字猜谜扩展到二维网格上，并赋予游戏背景故事。
• MUGWMP: 在二维网格上寻找四个 Mugwumps。
• TARGET: 一个星际迷航主题的猜谜游戏。
• 其他战斗主题游戏: Bombardment, Depth Charge, Gunner, Salvo (类似于经典游戏“战舰”)。

计算机猜人类：反向猜谜游戏

文章还介绍了计算机猜人类思维的逆向猜谜游戏，例如：

• ANIMAL: 计算机试图根据玩家的描述来猜动物。
• SALVO: 计算机和玩家轮流猜测，类似于“战舰”。
• DIGITS: 玩家随机写下 0、1 或 2，计算机尝试猜测。
• NICOMA: 计算机通过三轮提问来猜玩家心中 1 到 100 之间的数字。

可玩性与现代意义

所有这些经典 BASIC 猜谜游戏现在都可以通过浏览器进行游玩。文章暗示，这些游戏可能为在智能手机时代复兴游戏提供灵感。

总而言之，这篇文章揭示了 Wordle 的历史渊源，并展示了 BASIC 编程语言在早期游戏开发中的重要作用，特别是在猜谜游戏领域。

使用 Typst 轻松创建可访问的 PDF：无需额外软件

本文探讨了如何使用 Typst 创建可访问的 PDF 文件，旨在消除传统 PDF 可访问性创建过程中的复杂性和成本。

问题：传统 PDF 可访问性创建的痛点

通常，创建可访问的 PDF 需要手动操作，例如使用检查表、学习 PDF 标签以及可能需要购买 Adobe Acrobat 等软件。这使得可访问性成为一项耗时且昂贵的任务。

可访问性的重要性

可访问性对于确保每个人都能访问文档至关重要。 缺乏可访问性会导致排除部分受众，降低曝光率，并可能违反法规。

Typst 的解决方案：内置可访问性

Typst 是一款基于标记的专业写作平台。与传统软件不同，Typst 在内容创建过程中就考虑了可访问性。它利用标记来定义文档结构，并在格式化文档的同时自动创建可访问的 PDF 文件。

PDF 可访问性的基础

可访问的 PDF 旨在满足有阅读障碍的人的需求，例如：

• 高对比度：确保前景色和背景色具有足够的对比度。
• 语义数据：包含屏幕阅读器能够正确读取文件的语义数据，包括：
  • 正确的阅读顺序
  • 图像和图形的描述
  • 正确的语言识别
  • 准确的文本读取

Typst 如何实现可访问性

Typst 采用基于 元素 的方法，每个元素都具有特定的含义。例如：

• 标题使用 table.header 和 table.footer 元素。
• 表格使用 table 元素，设计目的的布局使用 grid 元素。
• 列表使用 list, enum 或 terms 元素。
• 图形使用 figure 元素并提供替代描述（alt 参数）。

通过使用这些元素，Typst 自动为最终的 PDF 文件生成标签，从而确保了屏幕阅读器用户的良好体验。

最佳实践

• 使用语义元素： 始终使用适当的 Typst 元素来定义文档结构。
• 提供替代描述： 为图像和图形提供清晰的替代描述，以便屏幕阅读器可以将其传达给用户。
• PDF/UA-1 标准： 启用 PDF/UA-1 导出，Typst 将在导出时检查可访问性问题，并提示用户进行修改。

总结

Typst 通过内置可访问性功能，简化了 PDF 可访问性创建过程。它鼓励使用语义元素，自动生成标签，并提供内置验证，从而使可访问性成为写作流程的自然组成部分，而不是事后补救措施。通过 Typst，可以轻松创建可访问的、符合国际标准的 PDF 文件，从而扩大受众范围，并确保每个人都能访问您的内容。

尝试 Typst

Typst 提供 Web 应用和开源编译器，方便用户体验内置可访问性功能。 更多信息请访问 Typst 的文档。