硅谷的秘密：创始人流动性

创始人与早期员工的风险叙事
硅谷长期宣扬创始人承担巨大风险，因此应持有远高于早期员工的股权。但文章指出，这忽略了“创始人流动性”这一关键现象：创始人常在新融资轮次中出售部分股份，提前获得财务保障，而员工却无法享受同等机会。

创始人的套现现实
流动性指创始人在融资时出售部分股份，实现个人资金安全，同时公司继续获得风投。此操作常秘而不宣，仅限于董事会与股权表知晓。例如：

• 作者亲历的初创公司在A轮与B轮分别向创始人提供40万和75万美元流动性，员工毫不知情。
• WeWork创始人亚当·诺伊曼在估值高峰期套现超20亿美元，员工直到2019年才接触股票收购要约，且最终未成，权益化为乌有。
• Hopin创始人套现数千万后，公司以低于清算优先的价格出售，员工股权价值归零。

常见的误解与真相

• 误解1：披露流动性会打击员工士气。
  真相：员工可能支持创始人获益，但因隐瞒而产生不信任。
• 误解2：创始人承担最大风险。
  真相：一旦创始人获得流动性，其风险已降低，而员工仍完全暴露于风险中。
• 误解3：流动性会损害投资者观感。
  真相：实际操作中投资者常鼓励创始人套现以降低个人风险。

作者的亲身经历与作为新创始人的改革
作为早期员工时，作者发现创始人获得流动性后并无负面情绪，但认为隐瞒不公。成为创始人后，他采取透明化措施：

• 提供双倍平均值的员工期权池（20%）。
• 将股权归属期缩短至3年（行业标准为4年）。
• 将行权窗口延长至离职后10年（行业标准为90天）。
• 主张在每轮新融资时向员工公开流动性信息。

核心呼吁：透明化以平衡风险认知
作者认为，员工应了解创始人是否在融资中获得流动性，从而准确评估自身风险。若流动性仅限于创始人，员工实际承担的风险可能远高于创始人，却未获得相应补偿。文章建议员工主动询问融资轮的流动性情况，推动默认透明化，使所有利益相关方在信息对等的基础上决策。

总结：文章揭露硅谷通过隐瞒创始人流动性，维持了“创始人高风险”的神话，实则可能使早期员工承担更高风险。呼吁通过透明化重构公平的风险与回报分配。

Elixir 1.17 版本发布摘要

核心更新

1. 渐进集合论类型系统引入

本次发布首次将集合论类型引入少量语言构造中。虽然仍在早期阶段，但该里程碑已为开发者带来实质性好处——通过新的编译时警告来检测常见错误。开发者目前主要通过类型系统生成的警告与之交互，无需修改现有代码即可发现潜在缺陷。

当前类型模型包括：

• 基础类型：binary()、integer()、float()、pid()、port()、reference() 等，均为不可细分类型。
• 原子类型：atom() 是可细分的，如 :foo 和 :hello_world 被视为不同类型。
• 映射与结构体：支持“封闭映射”（仅允许指定键）和“开放映射”（允许额外键）。结构体是包含 __struct__ 键的封闭映射。
• 元组、列表与函数：当前建模为不可细分类型，未来版本将增加更细粒度支持。

初始版本重点优化了原子和映射（因分别代表最简单和最复杂的类型），并产生以下编译时警告：

• 模式匹配或访问不存在的映射/结构体键（如 %{adress: ...} 中的拼写错误）。
• 对非模块调用函数或捕获函数。
• 对结构体进行结构化比较（如 my_date < ~D[2010-04-17]）。
• 对不重叠类型进行比较（如 integer >= string）。
• 二进制模式中缺少类型说明符（如 <<name>> 应为 <<name::binary>>）。
• 救援未定义的异常或非异常结构体。

这些警告更可靠、精确，能在编辑器中实时显示，有助于开发者更早发现错误并提升重构信心。当前限制：仅从同一函数内的模式推断类型，守卫和跨函数分析将在后续版本加入。

2. 新增 Duration 数据类型与时间偏移功能

• Duration 类型：用于表示时间间隔。
• Date.shift/2 函数：基于时长偏移日期/时间/日期时间，正确处理不同历法和时区。使用“shift”而非“add”是因为时间加法不满足结合律（例如连续加一个月的结果与加两个月不同）。
• Kernel.to_timeout/1：将时长或整数规范为超时值，简化与 Process、GenServer 等 API 的交互。
• DateTime.shift/2：正确处理时区变化（如夏令时），并提供选项以处理不存在的时间点冲突。

3. 支持 Erlang/OTP 27 并废弃 OTP 24

• 新增支持：Erlang/OTP 27，其中包括 json 模块和进程标签（可通过 Process.set_label/1 访问）。
• 废弃支持：Erlang/OTP 24。建议开发者迁移至 OTP 26 或更高版本，尤其 Windows 用户。
• 未来变更：Elixir v1.18 将移除对 WERL（Windows Erlang 图形终端）的支持。

4. 其他重要改进

• 新函数：Keyword.intersect/2,3 用于列表交集。
• 性能分析工具：新增 mix profile.tprof（基于 OTP 27 的 tprof 分析器），软弃用 mix profile.cprof 和 mix profile.eprof。
• 守卫宏：Kernel.is_non_struct_map/1 用于安全匹配非结构体映射。
• 日志增强：Logger 格式化 gen_statem 报告，并在日志事件中包含 OTP 27 进程标签。

致谢与资源

• 类型系统开发：由 CNRS 与 Remote 合作，受 Fresha、Starfish*、Dashbit 赞助。
• 详细信息：完整变更列表见官方发布说明，安装指南与入门教程请访问 Elixir 官网。

《英雄萨姆》引擎通过其独特的确定性模拟和网络架构，在56k调制解调器等低带宽环境下成功实现了支持大量敌人的多人游戏体验。其核心设计思想是：**将游戏逻辑与渲染完全分离，并让所有参与方（服务器和客户端）运行完全相同的游戏世界模拟**。

### 核心概念：确定性模拟与Tick机制
*   **确定性模拟**：引擎的游戏逻辑是完全确定的。使用固定的伪随机数生成器（种子作为游戏状态的一部分同步），确保给定相同的玩家输入序列，所有客户端将产生完全相同的游戏状态。这是多人游戏同步和Demo回放的基础。
*   **Tick与帧解耦**：游戏逻辑以固定的20 ticks/秒运行，而渲染帧率则独立且可变（最高500 FPS）。通过插值技术平滑两个tick之间的视觉状态，使游戏看起来流畅。

### 网络多人游戏架构
引擎采用**客户端-服务器模型**，而非纯粹的点对点模型。服务器作为中心枢纽，负责验证和转发数据，但**不运行游戏世界模拟**。所有客户端（包括服务器主机的本地客户端）基于接收到的其他玩家动作数据，各自独立运行确定性的游戏模拟。这种模型在低带宽下极具优势，因为只需同步玩家输入（动作数据），而非庞大的世界状态更新。

网络通信被抽象为三个层次：

1.  **数据包层**：在无连接的UDP之上构建了一个自定义协议。通过序列号实现数据包排序和去重；通过可靠数据包（需确认）与不可靠数据包（直接发送）来满足不同数据的重要性需求；实现了流量控制和超时重传机制。
2.  **消息层**：在数据包层之上提供了流式消息（`CNetworkMessage`）的读写接口。支持消息压缩（默认使用LZRW1）以减少数据量。关键技巧是使用**增量编码**（例如，对`CPlayerAction`结构体进行XOR运算计算差值后再压缩发送），因为相邻帧的动作数据变化很小，极大提升了压缩效率。
3.  **游戏会话层**：这是游戏逻辑的核心。服务器和客户端在各自的主循环中处理网络消息和游戏流。
    *   **状态同步**：客户端加入时，服务器会发送一个基线游戏状态的“增量”（相对于一个共同的初始状态）。随后，服务器将包含所有玩家动作数据的**游戏流块**以不可靠消息发送给所有客户端。
    *   **游戏流处理**：客户端按顺序（通过序列号）处理收到的游戏流块，主要是`MSG_SEQ_ALLACTIONS`。这个块包含当前tick所有玩家的动作数据，客户端将其应用于本地对应的玩家目标，从而推进游戏模拟。
    *   **可靠性保障**：虽然`MSG_SEQ_ALLACTIONS`本身不可靠，但游戏流块有序列号。如果客户端检测到序列缺失（但收到了更晚的块），会在超时后向服务器请求重发，确保了关键游戏逻辑数据的最终可靠传递。
    *   **防作弊**：通过定期进行同步检查，对比客户端与服务器的关键对象校验和，来检测并断开状态不同步（可能由作弊或修改引起）的客户端。

### 预测机制
为了缓解网络延迟带来的操作不跟手的问题，引擎实现了预测。
*   对于**本地玩家**，客户端在将动作发送给服务器后，会立即使用自己发送的动作来预测未来的几个tick，并渲染这些预测状态。
*   对于**远程玩家**，则使用他们最后收到的动作进行预测。
*   预测通过创建“预测器”实体（原始实体的副本）来实现，避免影响正式的游戏状态。当收到服务器发来的权威动作数据后，预测状态会被纠正。

### 总结与对比
*   **设计哲学**：引擎通过将网络、文件回放等不同传输介质抽象为相同的游戏流接口，实现了代码的高度复用。单人战役本质上也是一个运行在本地的“多人”游戏。
*   **与Doom、Quake对比**：其模型更接近Doom（各客户端独立模拟），但采用了更先进的客户端-服务器架构。与Quake（服务器运行完整模拟并持续发送状态更新）相比，它在带宽使用上可能更高效，尤其适合《英雄萨姆》中敌人数量众多的场景。
*   **局限性**：由于所有客户端运行完整模拟，理论上存在客户端作弊（如透视）的可能。早期的消息序列化也未考虑跨平台兼容性（依赖单编译器布局）。

ARC Prize：推动开源AGI进步的百万美元竞赛

AGI进展停滞与当前AI的局限

现代AI（如大型语言模型LLMs）本质是强大的记忆引擎，能够记忆训练数据中的高维模式并应用到相似场景，其表现出的“推理”能力实为记忆推理模式的结果，而非真正的推理。它们无法基于全新情况生成新推理。当前AI进步依赖于通过增加训练数据来提升在记忆化基准测试（如MMLU、GSM8K）上的表现，但这并非通用智能。通用智能的核心是高效获取新技能的能力。

更多规模或数据无法使LLMs学会新技能，我们需要新的架构或算法，使AI系统能在测试时学习，从而适应新情况。现有的专用游戏AI（如下棋、扑克）无法简单地重新训练以解决其他问题，这反映了泛化能力的失败。若缺乏此能力，AI的发展将始终受限于人类通用智能。AGI的目标应是与人类共同发现和创造。

ARC-AGI：衡量通用智能的基准

ARC-AGI由François Chollet提出，是目前唯一衡量通用智能的评估：系统能高效获取新技能并解决新颖、开放性问题。该评估创建于2019年，当时AI最高得分仅为20%，如今最高分为34%。而人类（包括儿童）能迅速掌握任务。

与大多数迅速达到人类水平的记忆化基准测试不同，ARC-AGI至今未饱和，且进展速度正在放缓。它专门设计为抵抗记忆化，对当前最大的基础变换器模型和定制AI系统都极具挑战。解决ARC-AGI将开辟全新的编程范式，使程序能基于任意先验知识完美、可靠地泛化，这也是通往AGI的关键路径。

开源AGI进展的挑战与必要性

前沿AGI研究正走向封闭。自GPT-4起，主要实验室的技术报告缺乏关键细节，理由出于“竞争”。LLMs还将研究注意力从新架构和新算法上转移。大型实验室倾向于宣称“规模是全部所需”，私下却认为需要新想法才能实现AGI，它们赌注于在内部实验室中发现所有必要新思想。

然而，变换器架构的历史表明，突破性进展源于跨实验室、跨团队的开放科学交流（如Seq2Seq、注意力机制的演进）。接受封闭现状将降低全球发现AGI的概率。当前环境令许多新研究者感到沮丧，误以为所有问题都已解决，而“规模是全部所需”的错误观点甚至影响了AI监管政策。实际上，无人知晓如何构建AGI。

互联网和开源是世界上最强大的创新引擎。通过激励开源，可以增加新想法的产出率，提高发现AGI的几率，并确保新思想广泛传播，为大小AI公司创造更公平的竞争环境。

ARC Prize竞赛详情

ARC Prize是由Mike Knoop和François Chollet主持，Infinite Monkey和Lab42呈现的超过100万美元奖池的竞赛，目标是击败ARC-AGI评估并开源其解决方案。

竞赛目标：

1. 增加从事前沿AGI研究的人数。
2. 普及AGI进展的客观衡量标准。
3. 解决ARC-AGI，并从中获得关于智能本质的新认知。

竞赛欢迎任何人参与，无论背景。新想法可能来自任何地方。详细信息可通过官网获取。

文章标题： Intel正通过公路将916,000磅的“超级负载”运往其俄亥俄州新晶圆厂

内容摘要：

• 事件核心： Intel将于周三在俄亥俄州启动运输一个重达916,000磅（约400公吨，相当于76头大象）的“超级负载”，此次运输将耗时9天，行程约150英里，并导致当地交通中断超过一周。
• 运输对象与背景： 该超级负载是一个用于半导体制造的低温箱（cold box），这是一个独立的空气处理器结构，为芯片制造提供所需的低温技术。其尺寸巨大：高23英尺、宽20英尺、长280英尺（接近一个足球场的长度）。整个运输过程需以5-10英里的“巡游速度”进行。
• 项目意义： 此次运输是Intel在俄亥俄州纽奥尔巴尼建设“俄亥俄一号”园区的一部分。该项目投资280亿美元，计划建造一个占地1000英亩、包含两座芯片工厂的园区，被誉为“硅心地带”，将是美国中西部首个前沿半导体制造厂。一旦投入运营，将用于生产Intel 20A及更先进的“埃米时代”制程工艺。
• 规划与影响： 俄亥俄州交通部为包括此次低温箱在内的约20次“超级负载”运输进行了数月周密规划，包括评估桥梁和道路承重能力、迁移电线等。交通部发言人称，如此密集地运输此类超大型设备非常罕见，其他公司也已开始利用已规划好的路线。大量围观人群可能导致运输进一步延迟。
• 社区投资： 除创造就业外，Intel还承诺投资数百万美元用于当地学校和大学，以培养未来能在其工厂工作的本地人才。

文章标题： 我对 Excel 中 Python 的看法

文章概要：

本文是 xlwings 的创建者兼 O'Reilly 书籍《Python for Excel》作者对微软于 2023 年推出的“Python in Excel”预览版的深度分析与个人见解。作者通过开发相关课程和测试，发现并报告了诸多问题。核心观点认为，该功能的实现存在根本性的定位错误和诸多限制，但对特定场景仍具价值。

主要观点与批评：

1. 定位错误：用户期望获得 VBA（宏/脚本语言）的替代品，但 Python in Excel 被设计为 Excel 公式语言的替代品，本质上是将 Jupyter Notebook 的单元格嵌入了 Excel 网格。
2. 核心设计问题：
   • 破坏表格逻辑：Python 单元格（PY 单元格）的计算顺序是固定的（从左到右、从上到下、按工作表顺序），破坏了 Excel 自动处理单元格依赖关系的核心逻辑。
   • 代码复用性差：代码直接存储在 Excel 文件内，导致无法跨工作簿复用代码，回到了复制粘贴的老路。
   • 输出显示不友好：诊断面板（显示 print 输出和错误）与单元格分离，难以对应；预览窗口体验不佳；切换“对象”与“值”模式存在隐藏的“魔法”行为，易引发混淆。
   • 交互性差：无法像在 Jupyter Notebook 中那样方便地查看中间结果，不适合交互式数据分析。
3. 重大限制：
   • “无胶水”的胶水语言：无法安装第三方 Python 包，也无法连接外部 Web API 或数据库，限制了 Python 作为连接工具的核心优势。
   • 缺乏对 Excel 对象模型的访问：无法通过代码自动化处理多工作表合并、格式设置等常见报表任务。
   • 数据格式单一：xl() 函数默认返回 pandas DataFrame，获取 NumPy 数组或列表等其他格式不便捷。

肯定的方面与适用场景：

• 云端运行合理：将 Python 环境置于 Azure 云中是避免本地安装维护难题的合理方案，但需注意订阅费用、潜在配额和网络可靠性。
• 特定用例有价值：作者认为当前版本适用于：
  • 计算密集型任务（如蒙特卡洛模拟）。
  • 利用其内置的 AI/机器学习库（如 scikit-learn）。
  • 使用 Matplotlib/Seaborn 创建高级静态图表。
  • Excel 较为薄弱的时序分析。
  • 对于数据清洗和分析，作者认为可能直接使用 Power Query 更简单。

对未来和替代方案的看法：

• 改进 Excel 原生功能：作者认为，通过增强 Excel 本身的公式语言（如新增的 PIVOT()、GROUPBY() 函数及动态数组）可能是更好的路径。
• 作者的计划：作者正在开发“xlwings Lite”，一个基于 WebAssembly（WASM）的解决方案，旨在浏览器和 Excel 中本地运行 Python，支持自定义函数（UDF）、访问 Excel 对象模型、安装包、隐私保护等，作为现有功能的替代选择。

结论：

作者肯定 Python in Excel 有其存在空间，但认为将 Jupyter Notebook 单元格直接放入 Excel 网格的设计是错误的。鉴于该功能仍处于预览阶段，未来有望改进并减少限制。

埃隆·马斯克于周二撤销了在加利福尼亚州法院对OpenAI及其联合创始人萨姆·阿尔特曼和格雷格·布罗克曼提起的诉讼。这一决定发生在他公开批评OpenAI与苹果新合作伙伴关系的第二天。根据法庭文件，该诉讼已被"无偏见驳回"，这意味着理论上可以重新提起。

马斯克于今年2月提起诉讼，指控OpenAI、阿尔特曼和布罗克曼违反合同和信托责任。原定于周三在旧金山举行的听证会上，法官将考虑是否应被告要求驳回此案。

法律专家曾指出，该诉讼的法律基础存在疑问，因为其核心涉及的合同并非所有相关方签署的正式书面协议。马斯克在诉讼中主要声称，OpenAI的早期团队初衷是"为了人类的利益"开发通用人工智能（AGI），但该项目已转变为一个主要由大股东微软控制的营利性实体。这份长达35页的诉状（附有证据）很大程度上也是在强调马斯克在创建OpenAI过程中的角色，而该公司凭借ChatGPT的病毒式传播已成为全球最热门的初创公司之一（在CNBC 2023年颠覆者50榜单中排名第一）。

值得注意的是，马斯克去年推出了自己的人工智能初创公司xAI，与OpenAI竞争。该公司上个月宣布完成60亿美元的B轮融资，投资方包括Andreessen Horowitz、红杉资本等。根据其网站介绍，xAI致力于"理解宇宙的真实本质"。去年，xAI发布了名为Grok的聊天机器人，公司称其灵感来源于《银河系漫游指南》。

Twenty：现代化的Salesforce替代方案

Twenty 是一个专为技术团队设计的现代化CRM构建框架，旨在替代传统CRM（如Salesforce），帮助用户快速搭建和迭代符合复杂业务需求的自定义CRM系统。

核心价值与功能

• 模块化构建：提供类似乐高积木的构建模块，涵盖数据模型、用户界面和自动化流程，允许团队以生产级质量（包含权限、认证、工作流引擎）快速组装CRM和内部应用。
• AI驱动迭代：支持利用现有AI编程工具进行无限定制，将典型需要数周的工作（如CRM迁移）压缩到个人可监管的范围内，加速适应业务变化。
• 开源与控制权：基于开源软件，避免供应商锁定。开发者体验如同常规软件，支持本地设置、实时测试，无专有工具束缚，实现端到端自托管，降低成本（案例显示可降低超过90%）。

技术实现与示例

通过提供的SDK，开发者可以以代码形式定义CRM的结构：

• 数据建模：定义核心对象（如火箭、发射、载荷、客户、发射场）及其关系（一对多、多对一）。
• 视图与逻辑：创建自定义视图（例如“即将发射”列表）并编写业务逻辑。
• 测试与验证：提供集成测试以确保数据模型和关系正确。 示例代码片段展示了如何定义对象、字段、关系以及视图过滤器，体现了其声明式和结构化的开发方式。

解决传统CRM的痛点

文章指出构建自定义CRM通常面临两种困境：

1. 巨型单体架构：依赖专有语言、部署缓慢、逻辑不透明。
2. 自建负担：初期开发快，但长期维护和修改成本高昂。 Twenty旨在通过其灵活的框架解决这些折衷，让团队能够组合、迭代并适应一个健壮的CRM。

客户成功案例

多个公司利用Twenty实现了目标：

• W3villa：将其作为数据模型、权限和工作流引擎的生产级框架，用于构建AI模拟面试产品。
• AC&T：通过自托管Twenty实例，在替换一个已关闭的供应商CRM后，将CRM成本降低了90%以上，并消除了供应商风险和强制迁移。
• NetZero：采用模块化的Twenty设置，管理碳信用、农产品和工业系统等多元化业务，并高度评价其灵活性和API可访问性，使其工具生态系统得以互联。

用户体验优势

与传统CRM笨拙的UX相比，Twenty强调：

• 熟悉且现代的界面：设计简洁、直观，使用体验类似Notion。
• 实时数据与AI集成：数据实时更新，内置AI聊天助手协助操作。
• 高效的交互模式：通过智能模式、快捷键和布局加速日常任务执行。

总结

Twenty是一个开源、模块化、AI就绪的现代CRM构建平台。它赋予技术团队以代码优先的方式，在短时间内生产出具备完整功能、易于维护和扩展的自定义CRM，从而避免传统CRM的固有缺陷，助力企业快速响应业务需求。

本文探讨了《毁灭战士》（Doom）游戏中引入的二元空间分割（BSP）技术的创新性，并追溯了该技术的历史渊源。

核心问题：可见性判断（VSD）

• 在实时3D图形渲染中，核心挑战之一是“可见表面确定”（VSD）问题，即从特定视角快速判断场景中哪些部分可见。
• 早期游戏《德军总部3D》因场景结构简单（墙壁均为轴对齐），采用光线投射法即可高效解决VSD。
• 《毁灭战士》设计更复杂（斜墙、楼梯、不同高度的天花板），原渲染器在复杂关卡中速度骤降，亟需新方案。

BSP技术的引入与历史

• BSP树：一种通过递归地用分割平面将3D空间划分为二叉树的数据结构，可预先计算几何体的遮挡关系，从而高效确定从任一视角的渲染顺序。
• 技术起源：该思想最初源于1969年美国空军为飞行模拟器研究计算机图形学时提出的“遮挡矩阵”概念。1980年，Fuchs等人正式提出BSP树算法，旨在解决实时渲染中的VSD问题。
• 与《毁灭战士》的联结：程序员John Carmack在为超任移植《德军总部3D》时首次研究BSP树，随后将其应用于《毁灭战士》。他参考了Bruce Naylor等人1993年关于构建优化BSP树的论文以及《计算机图形学：原理与实践》等教材。

Carmack的实现与优化

• 离线预处理：在关卡编辑阶段预先生成BSP树，虽耗时较长，但避免了运行时计算开销。
• 渲染流程：
  1. 利用BSP树按从近到远的顺序绘制静态几何体（与1980年论文的从后往前顺序相反），结合简化的遮挡数据结构（非完整z-buffer）以节省内存。
  2. 随后按深度排序绘制动态角色（如敌人），并根据已绘制区域进行裁剪。
• 技术意义：BSP树解决了复杂关卡的渲染性能瓶颈，使《毁灭战士》能在当时硬件上流畅运行。

关于“天才之举”的再评估

• 文章指出，Carmack并非BSP树的首创者，该技术已有多年学术研究基础。但他的贡献在于：
  1. 从学术论文中识别出该技术对实时游戏的价值。
  2. 成功将其集成到《毁灭战士》引擎中，并针对游戏需求调整算法（如渲染顺序和简化遮挡判断）。
• 文章强调，《毁灭战士》引擎的整体创新（包括BSP树的应用）体现了Carmack的技术洞察力与工程实践能力，而单就BSP树而言，它是对现有技术的精妙应用，而非绝对原创。

结论

BSP树在《毁灭战士》中的应用是一次成功的“技术移植”，展现了如何将前沿学术研究转化为商业游戏中的关键性能解决方案。Carmack的成就在于其问题洞察力、研究能力及工程实现，而《毁灭战士》引擎本身是一个整合了多种巧妙设计的系统性工程奇迹。

Swift静态Linux SDK允许构建完全静态链接的Linux可执行文件，解决了传统Swift程序在Linux上需要安装运行时和特定发行版兼容性的问题。

核心优势与约束

• 完全可移植：生成的二进制文件仅依赖Linux系统调用接口，可在任何Linux发行版上运行。
• 零外部依赖：不依赖动态库（包括C库），甚至dlopen()函数也不可用。
• 自带依赖模式：需自行构建所有依赖项，SDK仅提供少量内置常见库。

静态链接概述

• 定义：在编译时将程序所有部分（对象文件、静态库）合并为单一可执行文件。
• 与动态链接对比：静态链接在构建时完成，动态链接在运行时完成；静态链接可剔除未使用的代码。
• 优点：无运行时开销、仅包含所需代码、无需安装独立动态库、无运行时版本冲突。
• 缺点：无法共享代码（内存占用可能更高）、更新依赖需重新构建、可执行文件较大。

安装与使用

• 前提条件：需从swift.org安装开源Swift工具链。在macOS上，必须使用开源工具链（非Xcode附带的工具链）。
• 安装命令：使用swift sdk install <URL或文件名> [--checksum <校验和>]命令安装。需确保工具链版本与SDK版本匹配。
• 构建示例：创建Swift可执行程序包后，使用swift build --swift-sdk <目标三元组>命令构建。支持目标包括x86_64-swift-linux-musl和aarch64-swift-linux-musl。

依赖项管理

• 内置库：SDK包含少量常见C库（如libxml2, zlib, curl）。
• C库差异：SDK基于Musl而非Glibc。项目中导入Glibc的代码需调整为导入Musl模块。
• 类型差异：Musl和Glibc在某些C库类型的导入上可能存在差异（如可选性、指针类型）。
• SBOM查询：SDK提供软件物料清单（SPDX格式），可用于查询内置的具体库版本。
• 额外依赖：需自行构建并提供静态库（.a文件），并确保其头文件和模块映射正确配置。

重要注意事项

• SDK采用“自带依赖”模型，不支持系统库。
• 使用macOS开发时，必须使用开源Swift工具链。
• 安装前需清理旧版SDK。
• 可执行文件在Linux上部署仅需复制，但需注意目标系统架构匹配。
• 不适用于Apple平台，因为Darwin内核的ABI要求动态链接系统调用。

T-Mobile在2017年向用户承诺“T-Mobile永远不会改变您支付的价格”，但近期却对包括“Simple Choice”在内的旧套餐实施了高达每线5美元的价格上涨，引发用户震惊与不满。

1. 争议核心：承诺与条款的差异

• 公开承诺：T-Mobile在2017年推广其“Un-contract”承诺时，强调“只有用户能改变自己支付的价格”，并声称永远不会主动涨价。
• 隐藏条款：公司在常见问题（FAQ）中注明，若涨价且用户选择取消服务，T-Mobile将支付用户最后一个月的账单（需在60天内通知）。该FAQ页面现已删除，但可通过网页存档查看。

2. 公司回应与辩护

• T-Mobile在回应FCC投诉时辩称，其“Un-contract”承诺本质是“若涨价且用户取消，将支付最后一个月账单”，而非价格永不上涨。
• 公司还区分了两个保障计划：
  • Un-contract（2017年1月-2022年4月）：适用上述条款。
  • Price Lock（2022年4月-2024年1月）：此期间开通的套餐承诺价格不变，但用户若更改套餐或账户状态不佳则失效。
• 2024年1月18日后推出的“Price Lock”新版本，实质又回归“涨价则支付最后一个月账单”的模式。

3. 用户反应与法律争议

• 许多用户认为T-Mobile的宣传具有误导性，他们误以为获得了价格永久不变的保障。
• 有用户向FCC投诉，但T-Mobile以条款细则为由要求驳回。
• 当前的服务条款中虽将“Un-contract”列为价格锁定保障的一部分，但未明确说明允许涨价的关键例外条款。
• 部分用户表示考虑更换运营商，但目前尚无集体诉讼或政府干预迫使T-Mobile撤回涨价。

4. 行业惯例与后续影响

• T-Mobile曾于2023年10月计划将用户自动迁移至更贵套餐，在遭到反对后撤销该计划。
• 此次事件可能加剧用户不信任，甚至引发法律诉讼，但短期内涨价已成事实。

文章指出，T-Mobile的案例凸显了电信行业营销承诺与实际条款之间可能存在的差距，消费者需仔细阅读细则以避免误解。

Raspberry Pi 在伦敦证券交易所成功上市

• IPO定价与股价表现：Raspberry Pi于2024年6月11日在伦敦证券交易所首次公开募股，发行价定为每股2.80英镑，公司估值达5.42亿英镑（约6.9亿美元）。开盘后股价迅速上涨32%至3.70英镑，此次IPO有望筹集超过2亿美元。

• 投资者参与情况：目前仅限机构股东交易，散户投资者将从周五开始买卖股票。

• 公司业务与市场地位：Raspberry Pi以低成本、低功耗的ARM架构单板电脑闻名，广泛应用于媒体服务器、复古游戏机、机器人项目及工业嵌入式系统。工业与嵌入式领域已成为其主要收入来源，占销售额的72%。自创立以来累计销售6000万台，2023年营收2.66亿美元，毛利润6600万美元。

• 股东结构与战略关系：上市公司为Raspberry Pi基金会的商业子公司，基金会仍是主要股东。ARM与索尼半导体解决方案公司均为战略股东，ARM曾表示计划通过公开募股增加持股。

• 对伦敦股市的意义：此次上市被视为伦敦股市的积极信号，尽管许多英国科技公司倾向于赴美上市，但Raspberry Pi的成功挂牌增强了伦敦市场的吸引力。

借用检查器的内在：四个改进方向

本文介绍了“借用检查器的内在”这一路线图，包含四项旨在让Rust更好地实现其核心设计精神——“修改独占共享”（mutation xor sharing）——的改进计划。这些改进旨在消除当前借用检查器拒绝某些实际上符合“修改独占共享”精神的代码模式，使规则更加完善。

1. Polonius：轻松处理条件返回的引用

当前Rust的“非词法生命周期”无法处理有条件返回引用的常见模式。例如，在一个函数中，当哈希表中没有某个键时，插入一个默认值再返回其引用，目前会报错。计划中的Polonius改进旨在解决此问题，它将借用检查重构为基于“位置表达式”（变量、字段），从而能更精确地追踪控制流。

2. 基于位置的显式生命周期语法

在Polonius的基础上，引入基于“位置表达式”的生命周期语法。除了现有的抽象生命周期参数（如'a），还可以使用程序变量或字段作为引用的“生命周期”，例如'x表示从变量x借入，'self.model表示从字段self.model借入。这能大幅减少手动标注生命周期的需求，并使Rust更易于教学和学习，因为该语法将生命周期的概念与具体的程序位置关联起来。

3. 视图类型与过程间借用

视图类型旨在解决因借用检查器逐函数分析而导致的保守性问题。例如，一个结构体的方法如果只修改counter字段，但另一方法在迭代widgets字段时调用它，目前会因借用冲突而失败。视图类型允许函数声明其访问的字段子集（例如&mut {counter} self），使编译器能精确判断借用兼容性。

• 附加价值：视图类型也能辅助分阶段初始化，允许在结构体完全构造前就调用操作部分字段的辅助函数。
• 限制与定位：视图类型因涉及字段名，目前更适用于私有函数；用于公共函数需考虑前向兼容性。

4. 内部引用

当前Rust不支持字段引用同一结构体中其他字段所拥有的数据。计划中的改进旨在原生支持此特性。例如，一个Message结构体可包含一个拥有所有权的text字符串，以及引用该字符串切片的headers和body字段。

struct Message {
    text: String,
    headers: Vec<(&'self.text str, &'self.text str)>,
    body: &'self.text str,
}

这样的结构体不携带外部生命周期参数，自身满足'static，因此可以安全地跨线程发送，为构建自引用和复杂数据结构提供了更自然的模型。

实施进展与影响

• 进展：Polonius和视图类型主要是工程问题；内部引用已在简化变体中完成建模；显式生命周期语法尚在讨论中。
• 复杂度权衡：这些改进虽然增加了类型系统的表达能力，但目标是通过将借用检查的分析结果具体化到类型和语法中，使得编译器错误更易理解、有明确的修复建议，从而降低用户的使用和感知复杂度。用户无需深入了解编译器内部机制即可修复相关错误。
• 优先级：这些改进源于对实际开发者（尤其是应用和GUI开发）在借用检查器上遇到挫折的洞察，具有重要的实践意义。

总结

这四项改进相互关联：Polonius重构借用模型，为显式生命周期语法奠定基础；后者是内部引用的关键构件；视图类型则允许在“部分借用”甚至“部分初始化”的值上暴露辅助方法。它们共同致力于让Rust的借用检查器更贴合其“修改独占共享”的核心精神，同时提升语言的可用性和教学友好性。

Alexa 在对话系统领域错失领先地位的关键原因

核心问题概述

尽管Alexa拥有超过5亿设备安装量的巨大数据优势，并曾投入大量资源发展对话式AI，但其内部的技术流程、组织结构和产品-科学脱节等问题阻碍了其成为市场领导者。前Alexa团队成员指出，团队虽构建了早期大型语言模型（LLM）、知识增强响应生成器（RAG原型）及多模态代理原型，但这些成果大多未能公开发布或产生显著影响。

主要挑战分析

1. 低效的技术流程

• 数据访问与基础设施瓶颈：内部数据访问审批周期长，数据标注质量差、文档缺失或过时，实验计算资源受限（例如仅能使用CPU训练Transformer模型），严重拖累研发效率。
• 僵化的数据治理：标注错误长期未纠正，修正需跨多部门协调，流程繁琐且缺乏激励，导致问题持续存在。

2. 分散的组织结构

• 内部竞争与协作壁垒：去中心化团队设计导致资源重复投入和恶性竞争，中层管理者优先维护自身领域而非推动跨团队合作。
• 技能生态系统缺陷：Alexa技能生态将对话系统分割为独立模块，难以实现跨技能上下文共享和多轮对话记忆，违背了对话系统设计的整体性需求。

3. 产品与科学目标冲突

• 短期需求压制长期研究：严格的“客户导向”文化要求所有研发直接关联产品指标，导致前瞻性研究（如开放域聊天系统）因缺乏短期可量化成果而被搁置。
• 脱离科学依据的目标设定：管理层设定的成功指标缺乏科学依据，引发研发团队与产品部门的持续摩擦，最终导致项目频繁更迭或中止。

改进建议

作者提出若重建对话系统应关注以下方向：

1. 强化基础设施：投资健壮的开发环境，优化计算资源、数据质量保障及采集流程。
2. 以LLM为核心重构架构：放弃过早碎片化的技能生态系统，将大型语言模型作为对话流程的基础单元。
3. 平衡研究与产品周期：避免以季度为单位的开发周期迫使科学项目妥协，为关键问题留出充足研发时间。

总结

Alexa的案例表明，仅靠数据规模和资源投入不足以保持对话AI领先地位，高效的工程文化、协同的组织设计以及科学与产品的合理平衡至关重要。随着GPT-4o等新型多模态系统出现，市场格局仍存变数。

Lexbor 开源 HTML 渲染库

核心定位：正在开发中的浏览器引擎基础，现有模块已可用于生产环境。提供一套快速、符合标准的工具，用于处理 HTML 解析、CSS 处理、URL 操作等现代网络技术。

主要特性

• 高性能：最快 HTML 解析器之一。
• 标准合规：严格遵守 WHATWG (HTML, DOM, URL, Encoding) 和 W3C (CSS) 规范。
• 模块化架构：按需使用模块（如仅 CSS 解析器），保持应用轻量。
• 零依赖：纯 C99 编写，易于构建、集成，无依赖管理问题。
• 生产就绪：已在超过 2 亿网页上进行严格测试，确保稳定性和正确性。

可用模块

使用案例

• PHP：自 PHP 8.4 起用于 DOM/HTML 扩展，8.5 起用于 URL 扩展。
• SerpApi：在生产中大规模用于 HTML 解析。
• Selectolax：流行的 Python 快速网页抓取库。
• Nokolexbor：Ruby 的高性能 Nokogiri 替代品。
• Nordstjernen：完全用 C 编写的网页浏览器。
• 其他语言绑定：Elixir, Crystal, D, Julia, Erlang 等。

模块详细说明

• HTML 模块：完全符合 HTML5 规范；支持元素/属性操作、片段解析、分块解析；通过所有树构建测试；在超过 2 亿 HTML 页面上通过 ASAN 测试；支持通过字节流确定编码及解析样式标签。
• CSS 模块：完全符合 CSS 语法规范；支持选择器、样式表树（CSSOM）。
• 选择器模块：使用 CSS 选择器搜索 HTML 元素。
• 编码模块：完全符合编码规范；支持 40 种编码的编码/解码；支持单次和缓冲处理。
• URL 模块：符合 URL 规范；支持 Unicode ToASCII。
• Punycode/Unicode 模块：符合相应规范；支持编码/解码、Unicode 规范化和 IDNA 处理。

构建与安装

• 二进制包：为 CentOS, Debian, Fedora, RHEL, Ubuntu 等主流发行版提供 x86_64 架构包。
• vcpkg：可通过 vcpkg install lexbor 安装。
• macOS：通过 Homebrew 或 MacPorts 安装。
• 源码构建：使用 CMake 构建，可运行测试和示例。
• 合并版本：可通过 single.pl 脚本将所有选定模块合并为一个头文件（lexbor_single.h），便于集成到 C/C++ 项目。
• 库形式：
  • liblexbor：包含所有模块的单一库。
  • liblexbor-{模块名}：按模块分离的库（如 liblexbor-html），模块间可能存在依赖。

AI 政策

• 核心库代码：完全由人类编写，以确保对性能关键和标准合规代码的完全理解与控制。
• 周边工作：欢迎并积极使用 AI 辅助工具进行绑定、WASM 构建、基准测试、文档、示例和测试等工作。
• 贡献者要求：核心库代码的 Pull Request 需由人类作者完成推理、设计和编码。

文档与支持

• 完整文档可在 lexbor.com 的文档部分找到。
• 路线图详情见 lexbor.com。
• 支持联系邮箱：support@lexbor.com。

许可

Lexbor 使用 Apache License 2.0 许可证，版权归 Alexander Borisov (2018-2026) 所有。

一项由马里兰大学公共卫生学院领导、发表于《eBioMedicine》期刊的研究比较了COVID-19感染者佩戴不同口罩时，呼出气体中病毒颗粒的逃逸情况。结果显示，鸭嘴式N95口罩表现最佳，能阻挡98%的病毒颗粒（包括99%的大颗粒和98%的小颗粒）从感染者呼吸中散播到空气中。其他测试的口罩也至少能阻挡70%的病毒颗粒。

研究使用“Gesundheit II Machine”设备测量志愿者呼气中的病毒量，志愿者在30分钟内进行重复字母、唱歌等发声活动，分别在有口罩和无口罩条件下测试。数据显示，未戴口罩的轻度症状感染者每小时呼出略多于两个感染剂量的病毒，佩戴N95口罩后风险指数级下降。

鸭嘴式N95口罩的成功归因于其紧密贴合、高效过滤器和较大的内部空间。相比之下，KN95口罩因贴合度不佳导致漏气，效果与布口罩或医用口罩相当，甚至不如布口罩。布口罩因覆盖面积更大、密封较好且气流阻力较低，表现出比KN95和医用口罩更好的效果。

研究强调，控制空气中的病毒颗粒是遏制高传播性呼吸道病毒的关键，尤其随着COVID-19病毒变异株（如奥密克戎）的出现。研究者建议，在养老院和医疗等高风险场所应优先使用鸭嘴式N95口罩，并认为这些发现可为未来应对流感等疫情提供公共卫生政策依据。

该研究由马里兰大学公共卫生学院、工程学院及香港大学等机构合作完成，获得美国国防高级研究计划局、美国国家过敏和传染病研究所等多方资助。

Flameshot 是一款开源的截图软件。

该页面主要提供了在不同 Linux 发行版上安装 Flameshot 的指南，包含多种安装方式：

1. 通用方式：下载 64 位的 AppImage，或通过 Snapcraft、Flathub 安装。
2. 通过各发行版包管理器安装：
   • Ubuntu/Debian：使用 apt install flameshot。
   • Fedora：使用 dnf install flameshot。
   • openSUSE：使用 zypper install flameshot。
   • Void Linux：使用 xbps-install flameshot。
   • NixOS：使用 nix-env -iA nixos.flameshot。
   • Guix：使用 guix install flameshot。
   • ALT Linux：使用 apt-get install flameshot。

页面还提供了获取更旧版本软件的途径。

绘图机器与旋轮几何

绘图机器（Drawing Machines）是一个涵盖多种机械绘图装置的领域。其中一种是旋轮几何（Roulette Geometry），通常被称为万花尺或斯皮罗图（Spirograph）。

这类装置能够绘制复杂的数学曲线，包括摆线（cycloids）、外摆线（epicycloids）、内摆线（hypocycloids）、次摆线（trochoids）和渐开线（involute curves）。尽管现代人熟知其作为玩具“万花尺”的形式，但其背后的数学原理和机械应用的历史实际上非常悠久。

Restate 是一个用于构建低延迟、持久化工作流的开源运行时，使用 Rust 编写，支持 JavaScript/Java 等多种语言。其核心目标是消除应用开发中用于防御性编码和基础设施对接的复杂性，让开发者能专注于核心业务逻辑。

核心功能与价值：

• 持久化执行（Durable Execution）：Restate 会自动存储应用程序执行的进度。当发生故障或重启后，应用能够自动从中断处恢复执行，无需开发者编写复杂的恢复逻辑。
• 提供内在弹性：通过将持久化执行、一致的状态管理和可靠的通信集成于一体，使应用具备端到端的韧性和正确性，能够从容应对生产环境中的各种问题。
• 专注于“快乐路径”：开发者可以使用常规的 if/else、循环和函数来编写主逻辑，Restate 负责处理重试和故障恢复等横切关注点。

技术特点与架构：

• 多语言支持：支持 TypeScript、Golang、Java、Python、Kotlin、Rust 等语言进行开发。
• 灵活部署：可在服务器、容器或 FaaS 平台上运行，兼容 Kubernetes、Vercel Functions、Cloudflare Workers、AWS Lambda、AWS Fargate、Google Cloud Run 等环境。
• 简单与可扩展：以单个无依赖的二进制文件启动，可通过增加实例轻松扩展为具备快速故障转移能力的高可用系统。
• 高性能：基于 Rust 的运行时实现了高吞吐和低延迟，据称工作流完成延迟（p99，10个步骤）低于 100 毫秒，在一个 3 节点集群中每秒可处理 13,000 个工作流。
• 托管选择：支持完全数据控制的自托管部署，也提供零运维的 Restate Cloud 云服务。

背景与反馈： Restate 由 Apache Flink 的原始创建者以及曾领导 Meta 行星级事件基础设施的工程师团队打造，将大规模生产环境的经验应用于设计中。多位用户（包括来自 Rhize、Cinder、Tier 1 US Bank 等公司的工程师）反馈称，Restate 显著减少了基础设施对接的编码工作量，提升了开发效率，并简化了构建弹性分布式系统和智能体（Agents）的复杂性。

Coqui.ai TTS 深度学习文本转语音工具包摘要

📣 最新动态与功能亮点

• XTTSv2 现已支持 16 种语言，性能全面提升。
• 发布了 XTTS 微调代码，并提供了示例配方。
• XTTS 流式传输延迟可低于 200 毫秒。
• 发布了生产级模型 XTTS，支持 13 种语言，并提供博客、演示和文档。
• Bark 模型现已可用于推理，支持无约束的声音克隆。
• 兼容约 1100 个 Fairseq 模型。
• TTS 现已支持 Tortoise 模型，推理速度更快。

❓ 问题与讨论渠道

• 错误报告：GitHub Issue Tracker
• 功能请求与想法：GitHub Issue Tracker
• 使用问题：GitHub Discussions
• 一般讨论：GitHub Discussions 或 Discord

🔗 资源链接

• 文档：ReadTheDocs
• 安装指南：TTS/README.md
• 贡献指南：CONTRIBUTING.md
• 路线图：主要开发计划
• 已发布模型：TTS 发布与实验模型
• 论文：TTS 相关论文

🥇 主要功能特性

• 高性能深度学习模型：支持文本转语音任务。
• 多种模型架构：包括 Text2Spec 模型（如 Tacotron、Glow-TTS 等）、声码器（如 MelGAN、HiFi-GAN 等）和声纹编码器（GE2E 等）。
• 高效训练：提供详细的终端和 TensorBoard 训练日志。
• 多说话人支持：可训练和部署多说话人 TTS 模型。
• 模块化与灵活性：代码库模块化，便于实现新想法，同时功能完整。
• 即用模型：提供大量已发布的预训练模型。
• 数据集整理工具：包含在 dataset_analysis 中。
• 实用工具：用于测试和使用模型。

🤖 支持的模型实现

光谱模型

包括 Tacotron、Glow-TTS、FastPitch、FastSpeech2、SC-GlowTTS、Neural HMM TTS 等众多架构。

端到端模型

• XTTS：多语言、支持声音克隆的生产级模型。
• VITS、YourTTS、Tortoise、Bark 等。

其他组件

• 注意力机制：如引导注意力、前向后向解码等。
• 声纹编码器：如 GE2E、Angular Loss。
• 声码器：如 MelGAN、WaveGrad、HiFi-GAN、UnivNet。
• 语音转换：支持 FreeVC 模型。

⚙️ 安装方式

• 环境要求：Ubuntu 18.04，Python 3.9 至 3.11。
• PyPI 安装（仅用于推理）：pip install TTS。
• 开发安装（用于训练/编码）：

  git clone https://github.com/coqui-ai/TTS
  pip install -e .[all,dev,notebooks]
  

• Docker 镜像：提供无需安装的快速体验方式。

🎤 使用示例

Python API

• 初始化：tts = TTS("模型名称").to("设备")。
• 语音合成：支持 tts.tts() 和 tts.tts_to_file() 方法。
• 多说话人/多语言模型：需指定 speaker_wav 和 language 参数。
• 声音克隆：使用 YourTTS 等模型，并提供参考音频。
• 语音转换：使用 voice_conversion_to_file 方法。
• 与 Fairseq 模型集成：可使用 tts_with_vc_to_file 进行带声音克隆的语音合成。

命令行接口

• 列出模型：tts --list_models。
• 查询模型信息：通过名称 (--model_info_by_name) 或索引 (--model_info_by_idx)。
• 基本合成：tts --text "文本" --out_path 输出路径。
• 指定模型：使用 --model_name 和 --vocoder_name 参数。
• 多说话人模型：使用 --list_speaker_idxs 列出说话人，并用 --speaker_idx 指定。
• 语音转换：使用 --model_name、--source_wav 和 --target_wav 参数。

📂 代码结构

• notebooks/：用于模型评估和数据的 Jupyter Notebooks。
• utils/：通用工具。
• TTS/：核心代码目录。
  • bin/：可执行脚本（如训练脚本）。
  • tts/：TTS 模型定义、层和工具。
  • speaker_encoder/：声纹编码器模型。
  • vocoder/：声码器模型。

AES-GCM 概述
AES-GCM（Galois/Counter Mode）是一种认证加密模式，结合了AES对称加密和Galois域认证。它确保数据的机密性和完整性，但前提是每个加密使用的nonce（一次性数字）必须唯一。如果nonce被重复使用，AES-GCM的安全保证将完全崩溃。

AES基础
AES是一个块加密算法，处理128位数据块。它是一个双射函数，使用密钥进行加密和解密，但本身不提供多块数据加密或认证功能。GCM模式扩展了AES，使其能加密任意长度数据并提供认证。

GCM工作原理
GCM包含两个部分：加密和认证。

• 加密：使用counter模式生成keystream，与明文异或产生密文。keystream由密钥和nonce决定，确保每个消息的keystream不同。
• 认证：使用GHASH函数基于Galois域算术生成认证标签，确保密文和关联数据（如发送者信息）未被篡改。

Nonce的重要性
Nonce是防止keystream重复的关键。如果两个消息使用相同密钥和nonce加密，keystream相同，导致加密被破坏。

Nonce重复时的加密攻击
如果nonce重复，攻击者可从一个已知明文-密文对中恢复keystream（通过XOR操作）。随后，使用该keystream解密所有相同nonce加密的密文，并能伪造新密文，从而彻底破坏加密机密性。

Nonce重复时的认证攻击
认证部分依赖GHASH密钥H（从AES密钥派生）。当nonce重复时，两个认证标签共享相同的加密值Ek(y0)。通过组合两个标签的公式，可消除Ek(y0)，得到一个关于H的多项式方程。
使用Cantor-Zassenhaus算法（一种多项式因式分解算法）求解该方程，可恢复H值。获得H后，攻击者可计算任意数据的认证标签，从而伪造认证消息，破坏完整性保护。

完整攻击流程

1. 攻击者观察使用相同nonce加密的多个消息。
2. 利用已知明文-密文对恢复keystream，解密其他消息。
3. 通过多项式方程求解恢复GHASH密钥H。
4. 使用H伪造认证标签，向接收者发送恶意消息，使其误以为来自合法发送者。

结论
AES-GCM在正确使用下是安全的，但nonce重复会同时破坏加密和认证。攻击者无需知道AES密钥，即可解密数据、伪造消息，导致完全的安全失效。因此，必须确保每个加密操作使用唯一nonce。

SQLite的优势与流行趋势

• 效率与稳定性：SQLite以其高效、快速和稳定著称，被视为轻量级但功能完整的数据库解决方案。
• 普遍安装：默认集成于操作系统中，降低了使用门槛。
• 本地优先支持：支持离线数据存储，适用于本地优先（local-first）应用场景。
• 与传统数据库对比：在特定场景下比Postgres或MySQL更具优势，尤其在资源占用和部署简便性方面。

常见误解

• 仅限单用户：许多人误认为SQLite仅适用于单用户或小型应用，但实际上它具备处理复杂需求的能力。
• 功能有限：开发者常低估其作为全功能数据库的潜力，需更多案例证明其可扩展性。

SQLite Cloud的增强功能

• 共享与协作：使SQLite数据库可共享，并添加企业级功能。
• 与其他托管服务的区别：强调其架构差异，支持更高扩展性和实时同步。
• 技术进展：SQLite仍在持续演进，未来可能支持分支等高级功能。

讨论焦点

• SQLite的流行源于其轻量化、易集成性及本地数据管理能力。
• 通过云端增强后，SQLite可用于分布式环境，兼顾离线与在线需求。

渐进式网络应用（PWA）钓鱼攻击分析

核心概念

渐进式网络应用（PWA）是基于Web技术（HTML、CSS、JavaScript）构建的应用程序，可被安装并类似原生应用运行。其能与操作系统深度集成（如拥有独立应用图标、支持推送通知），从而提高用户参与度。然而，PWA的界面（UI）可被恶意操纵以用于钓鱼攻击。

PWA 技术基础

构建一个基本的PWA需要以下关键文件：

1. 清单文件（Manifest）：一个JSON文件，提供Web应用的元数据，允许应用被安装到用户主屏幕。示例中配置了应用名称（如“Microsoft Login”）、显示模式、图标等。
2. 服务工作线程（Service Worker）：一个在后台运行的脚本，用于实现离线功能、推送通知和后台同步。通过监听install和fetch事件，实现资源缓存和请求处理。
3. HTML文件：主HTML文件链接清单文件并注册服务工作线程，为应用提供入口点。
4. 样式表和脚本：支持PWA正常运行的其他CSS和JavaScript文件。

攻击场景实现

攻击者可利用PWA的特性实施钓鱼攻击，步骤如下：

1. 设置诱饵页面：创建一个包含“安装Microsoft应用”按钮的着陆页。
2. 诱导安装应用：用户点击按钮后，浏览器会弹出安装提示。应用名称和图标可被伪造为合法品牌（如“Microsoft Login”并使用微软Logo）。注意：安装提示中会以小字体显示真实域名。
3. 重定向至钓鱼页面：应用安装成功后，PWA窗口会自动重定向到一个带有伪造URL栏的钓鱼页面。该伪造栏模仿了浏览器地址栏的外观，以增强欺骗性。

攻击演示与风险

• 演示效果：攻击者可创建一个完全模仿微软登录页面的PWA，安装后诱导用户输入凭证。
• 图标欺骗：应用图标被设置为微软Logo，增加了页面的可信度。
• 代码提供：攻击概念验证（PoC）代码已在GitHub上公开。

攻击局限性与安全意识

此攻击技术存在以下限制：

1. 要求受害者主动安装PWA应用。
2. 在安装过程中，PWA窗口会短暂显示真实域名（位于右上角）。

然而，文章指出，由于用户习惯性忽略URL检查，此短暂提示常被忽略。因此，提升安全意识对此类攻击的防范至关重要。

历史背景

值得注意的是，在本文发布前（2018年），已有人提出过关于PWA可能被滥用进行钓鱼的安全担忧，表明此类风险并非新出现。

文章《"The Door Problem"》(2014) 通过“门的问题”这一具体而日常的隐喻，向外界解释了“游戏设计师”这一职业的模糊性与复杂性。

核心概念：游戏设计师的职责 作者认为，游戏设计师的工作并非外界想象的充满炫酷创意，而是处理大量具体、琐碎的设计问题。她用“你正在制作一款游戏，那么游戏里有门吗？”这一假设性前提，展开了一系列必须由设计师决定的问题：

• 门的可交互性（玩家能否开门？所有门都能开吗？哪些是装饰？）
• 反馈与指引（如何让玩家区分可交互与不可交互的门？视觉、环境提示？）
• 机制细节（门能否上锁/解锁？解锁条件是什么？玩家如何开门？动画方式？）
• 关卡与流程（门后是否锁住？单人/多人游戏下门的行为？大场景中的门如何处理？）
• 与其他系统的联动（敌人如何出现？AI和盟友如何通过门？门的大小是否适合所有角色？） 这些看似微小的问题构成了游戏设计的核心工作，需要设计师系统性地解决。

团队中的协作与分工 为了说明游戏开发是团队合作，作者列举了同一个“门”如何在不同职能眼中各有侧重：

• 创意/管理层面：创意总监决定是否需要门；项目经理排期；制作人考虑将其作为预购奖励。
• 内容制作层面：概念艺术家绘制门的美术稿；艺术总监确定风格；环境艺术家将其做成游戏物件；动画师制作开关动画；音效设计师制作声音；编曲家为其创作主题曲。
• 技术实现层面：游戏程序员实现门的交互与脚本逻辑；AI程序员让NPC识别门；网络程序员处理多人同步；引擎程序员优化性能；工具程序员简化门的放置。
• 设计层面：关卡设计师放置并设定门的流程触发；UI设计师添加任务标记；战斗设计师设计敌人从门中出现的逻辑；系统设计师设定开门获得的经验/金币奖励；货币化设计师考虑将其作为付费点。
• 测试与支持层面：QA测试人员用各种方式测试门的功能；UX研究员进行可用性测试；本地化团队翻译“门”；客服解答玩家关于门的疑问。

总结 文章旨在说明：

1. 游戏设计是务实的：它关乎解决一系列具体的、日常的设计问题，而不仅是天马行空的创意。
2. 设计是系统的决策过程：设计师需要定义游戏中元素的规则、反馈与逻辑。
3. 游戏开发是高度协作的：一个“门”需要整个团队不同职能共同完成，凸显了大型游戏项目的复杂性。
4. 玩家可能浑然不觉：精心设计的门如果做得好，玩家可能根本不会特别注意到，这正是设计成功的体现。

融资概况

Mistral AI完成6亿欧元B轮融资，公司估值达60亿美元。General Catalyst作为联合领投方，这是自一年前Mistral成立以来对其投资的第三次加码。

公司背景与技术特点

• 起源与定位：Mistral AI被认为是从法国AI生态中涌现的全球领先科技公司，其开源前沿AI模式推动其迅速崛起。
• 核心优势：依托欧洲顶尖AI人才、谦逊务实的文化以及与开发者社区的深度信任，其开源模型在性能与成本前沿树立了标准。
• 产品平台：推出“La Plateforme”和“Le Chat”等产品，旨在赋能企业重塑核心业务并开拓新市场，助力欧洲跨越传统SaaS阶段。

战略意义与生态系统

• 推动创新与转型：Mistral的前沿AI技术正在国家级、区域级和全球层面催化AI产品创新、安全研究与行业变革。
• 增强韧性：其开放、可移植的平台被视为提升AI韧性的基石，为法国、欧洲及全球企业提供安全、稳定与可控性，契合“全球韧性”投资理念。
• 生态扩展：投资者期待与Mistral共同孵化更多AI优先的产业平台公司，类似已合作的Adept、Helsing等案例。

投资愿景

General Catalyst支持Mistral的使命，即推动智能发展、解决复杂全球问题，并邀请开发者基于Mistral平台构建高信任、高完整性应用，共同引领以欧洲为中心的“AI文艺复兴”。

ClipBook：macOS 键盘中心剪贴板历史应用

ClipBook 是一款为 macOS 设计的键盘优先剪贴板历史管理工具，旨在提升用户复制粘贴的效率和体验。

核心功能

• 无限剪贴板历史：后台运行，永久保存用户复制的所有内容，包括文本、图片、链接等，彻底解决 macOS 原生剪贴板仅保留一项内容的问题。
• 快速预览与粘贴：支持通过 ⌘P 快速预览完整内容；可一次性选择并粘贴多个项目，且支持选择后在每个项目后添加回车、制表符或不执行任何操作。
• 便捷键盘操作：
  • 通过 ⌘1..9 快速粘贴历史记录中的前9个项目。
  • 使用全局快捷键随时调出剪贴板历史。
  • 在历史记录中，可用 ↵ 或双击将选中项直接粘贴到当前活动应用。
  • 支持合并多个文本项，或通过 ⌘CC 从其他应用快速追加内容。
• 内容管理：支持编辑文本项、将项标记为收藏（置顶）、删除单个项或清空整个历史记录（收藏项除外）。
• 图像文字提取：可识别剪贴板图像中的文字并复制（⇧⌘C）。
• 链接处理：可直接在浏览器中打开剪贴板中的链接（⌥↵）。

键盘中心与自定义 应用强调键盘操作，减少鼠标使用。用户可高度自定义界面、行为、颜色主题（深色/浅色/跟随系统）以及几乎所有键盘快捷键，以适应个人工作流。应用支持多显示器，并会记住每个屏幕上窗口的位置和大小。

隐私与安全

• 所有数据均本地存储在 Mac 上，不会上传至云端。
• 无内置分析、无数据追踪。
• 可配置忽略包含密码、敏感信息的剪贴板内容，或排除特定应用不被记录。
• 支持通过全局快捷键快速暂停/恢复记录功能。
• 项目为开源，用户可审查代码以确认安全性。

适用场景 ClipBook 能为不同职业的用户节省时间，减少工作流程中断，例如：

• 软件开发者：管理代码片段、命令、日志。
• 技术写作者/文案：快速访问参考资料、网址、笔记。
• 客服/销售：快速调用标准回复、产品信息、历史对话。
• 设计师/学生/教师：管理颜色代码、研究资料、教学素材等。

获取方式 提供免费下载，试用后若喜欢可购买。

月球背面的初见：苏联“月球3号”的历史使命

背景与灵感来源
1956年，美国空军启动“Genetrix”计划，利用高空侦察气球拍摄苏联内陆影像。这些气球携带耐辐射、耐高温的特殊胶片。苏联工程师在缴获的气球残骸中发现此类胶片，并将其改造后用于自己的太空任务。

“月球3号”任务
1959年10月4日，苏联发射“月球3号”自动行星际站，任务是拍摄人类从未目睹的月球背面。探测器重约435公斤，搭载宽角与长焦相机，使用来自Genetrix气球的改造胶片。

技术挑战与突破

• 通信问题：探测器初期指令混乱，经地面协调后恢复正常。
• 轨道设计：首次应用“引力弹弓”效应，借助月球引力返回地球通信范围，轨迹由“斯特雷拉-1”计算机计算。
• 胶片处理：探测器内置微型暗房，在零重力下自动冲洗胶片。
• 影像传输：通过无线电传真方式逐行传输图像，每帧约需30分钟，但因信号微弱，初期图像充满噪点。

历史意义与科学发现
10月22日前，探测器成功传回12至17张月球背面影像，揭示重大发现：

1. 地形差异：背面几乎没有正面常见的暗色玄武岩平原（月海），仅覆盖1%（正面为31%），而陨石坑更密集。
2. 南极-艾特肯盆地：发现一个直径2600公里的巨大撞击坑，为太阳系最大撞击结构之一。
3. 科学谜题：背面与正面的不对称性（月球远侧高地问题）引发长期科学讨论，可能源于月球形成时的热分布差异或早期撞击事件。

影响与后续
1959年10月26日，苏联公开月球背面影像，震撼世界。1960年苏联发布首部月球背面地图。直至1968年阿波罗8号任务，人类才首次亲眼看到月球背面；2018年中国嫦娥四号成功着陆背面，实现首次背面实地探测。

月球背面的独特价值
由于始终背对地球，月球背面天然屏蔽地球无线电干扰，是建造射电望远镜的理想之地。其陨石坑可改造为巨型天线，助力宇宙深空探测。

结语
“月球3号”不仅完成了技术壮举，更揭开了月球背面的神秘面纱，推动了太空探索与行星科学的发展。