CVM算法：一种高效估算数据流中不同元素数量的新方法

问题背景

传统方法需要存储并比对所有已见元素来统计不同元素数量，在数据量极大（如数十亿）时内存消耗巨大且效率低下。例如，在野生动物普查中识别唯一动物，或在社交平台统计每日登录的不同用户，均面临此挑战。

算法核心思想

CVM算法由Chakraborty、Variyam和Meel提出，通过随机化抽样显著降低内存需求。其核心是利用概率筛选机制，在有限内存空间内保留元素子集，并通过数学关系估算原始总数。

算法步骤（以《哈姆雷特》音频词频统计为例）

1. 初始化：设定固定大小的内存空间（如100个词槽）。
2. 填充阶段：依次处理数据流元素（如听到的单词），跳过重复项，直至内存填满。
3. 分轮筛选：
   • 轮次k=1：对内存中每个元素独立抛硬币，仅保留正面（概率1/2）。
   • 轮次k>1：处理新元素时，若遇到重复项，需连续抛出k次硬币均为正面才保留；内存满后再次按1/2概率随机删除元素。
4. 估算公式：经过k轮后，内存中剩余元素数除以保留概率（1/2^k），即得到不同元素总数的估计值。

算法特性

• 内存高效：仅需存储固定数量的元素，与数据流总量无关。
• 精度可控：估计精度与内存大小正相关。实验显示，用100词内存估算《哈姆雷特》不同单词数（实际3967个）的平均误差约0.3%，用1000词内存误差降至0.08%。
• 通用性强：适用于任何逐项到达的数据流（如语音、工业生产线、交通监控等）。

重要意义

• 解决了计算机科学领域持续40余年的“不同元素问题”，在有限内存下实现了高效近似计算。
• 算法极其简洁且易于实现，可能成为实践中处理该问题的默认方法。
• 体现了随机化技术在经典问题中的创新应用价值。

约翰霍普金斯大学工程学本科生团队发明了一种更安静的吹叶机设计，该设计已提交专利申请，并有望在两年内上市销售。该团队成功将吹叶机的整体噪音水平降低了近40%，并几乎完全消除了最恼人的高频噪音。

研发过程

• 团队从去年九月开始工作，目标是改进电动或电池驱动的吹叶机。
• 他们花费数月时间逐个部件分析吹叶机，识别其噪音来源。
• 随后，团队提出了超过40个版本的解决方案，最终确定了一种类似枪械消音器或汽车排气管的附加装置设计。

技术原理

• 该装置通过一个附件实现降噪。它将输入的完整气流进行分离，一部分气流原样排出，另一部分气流经过“偏移”处理后再排出。
• 这两部分气流的组合使吹叶机的噪音显著降低，同时保持了原有的风力。
• 该设计将最刺耳的高频噪音降低了约12分贝（使其安静了94%），并将吹叶机的总体噪音降低了约2分贝（相当于降低了37%的感知噪音量）。

成果与反响

• 最终产品的噪音听起来更低沉、更悦耳，类似于风声而非尖锐的哨音。
• 团队导师和项目赞助商史丹利百得公司对此设计印象深刻。
• 史丹利百得公司高级产品经理内特·格林称该设计“已准备好进行大规模生产”，是一个“罕见且引人注目的成功”。
• 团队成员认为，该降噪方案未来可应用于吸尘器、吹风机等其他嘈杂的家用电器。

Neovim 0.10 更新概要

Neovim 0.10 是自 0.5 版本以来开发周期最长的一个版本，包含了大量新功能和一些破坏性变更。用户可以通过 :h news 查看完整的发行说明，插件作者应仔细阅读。

核心亮点

1. 默认设置改进

• 新默认配色方案：由 Evgeni Chasnovski 贡献，旨在改善可访问性和美观度，替换了旧方案。
• LSP 与诊断默认键位：为便于上手，新增了常用 LSP 操作的默认映射。
  • K：显示光标下符号的悬停信息。
  • [d / ]d：在当前缓冲区的诊断信息间导航。
  • <C-W>d：以浮动窗口显示光标下的诊断信息。

2. 内置注释功能

内置了类似 vim-commentary 的注释功能，使用 Lua 重写。支持 Tree-sitter，可在混合语言环境（如 HTML 中的 <script> 标签）中使用正确的注释语法。

3. 终端 UI 增强

• 同步输出：通过新的 'termsync' 选项（默认启用）减少快速 UI 更新时的闪烁和撕裂。
• 系统剪贴板同步：在 SSH 会话等情况下，可通过 OSC 52 转义序列读写系统剪贴板。
• 超链接支持：实验性功能，在 Markdown 文件中可通过 OSC 8 序列将文本渲染为可点击的超链接。
• 真彩色自动检测：自动检测终端是否支持 24 位真彩色并启用 'termguicolors'。

4. LSP 内联提示

支持 LSP 服务器提供的内联提示，例如在变量声明处显示类型注解。这些是“虚拟文本”，可通过 vim.lsp.inlay_hint.enable() 动态开关。

5. Tree-sitter 查询编辑器

增强了 Tree-sitter 工具链：

• 树检视器 (:InspectTree)：可查看源文件的语法树。
• 查询编辑器：新增功能，允许在编辑器内实时编写和测试 Tree-sitter 查询，并即时在源缓冲区中高亮显示匹配结果。可通过在树检视器中按 o 或 :EditQuery 命令打开。

其他重要变更

• :terminal 命令支持修饰符（如 :botright terminal），且无参数启动的终端在 shell 退出后会自动关闭。
• gx 映射调用系统默认程序打开光标下的内容（如 URL）。
• Lua、Vimdoc 和 Tree-sitter 查询的语法高亮默认使用 Tree-sitter。
• 可视模式下 Q 和 @ 可对选中的每一行执行上次录制/执行的宏。
• 支持 Kitty 键盘协议，可使用 <D- (super) 和 <T- (meta) 前缀创建映射。

未来路线图

项目遵循“兴趣驱动开发”模式，未来重点包括：

• Tree-sitter 改进：将解析器分发方式从编译后的共享对象改为可移植的 WASM 格式，以便更好地内置更多语言支持。
• LSP 体验提升：计划将代码片段和自动补全等常用功能集成到 Neovim 核心中，并考虑整合 nvim-lspconfig 的部分逻辑。
• 社区参与：鼓励用户通过贡献代码、插件或参与社区讨论来共同推动项目发展。

该内容主要介绍了四本关于D3.js及相关技术数据可视化的书籍，旨在帮助学习者从基础开始掌握相关技能。

1. 《Data Dashboards with JavaScript》：教授如何使用React、Chart.js和Leaflet构建数据仪表板。
2. 《D3.js数据可视化》：一本关于使用D3.js创建自定义数据可视化的书籍。据引用评价，其内容清晰、易于跟随、概念扎实，被认为是优秀的D3书籍之一。
3. 《Visualising Data with JavaScript》：教授如何使用Chart.js、Leaflet、D3和React来构建图表和数据故事。
4. 另一本基础书籍：专注于教授用于在网络上构建数据可视化的基础技能，包括HTML、SVG、CSS和JavaScript。

这些书籍共同构成了一个从基础到进阶的学习路径，覆盖了D3.js及其相关的前端技术和库。

这是一则由Springer Nature Ltd发布的招聘信息，职位为Associate or Senior Editor, Communications AI & Computing。工作地点包括上海、北京、浦那、新德里、柏林或马德里，采用混合办公模式。内容以“Appli...”结束，表明可能涉及申请流程，但细节不完整。

F*（读作F star）是一个面向证明的通用编程语言，支持纯函数式和带副作用的编程。它结合了依赖类型的表达能力与基于SMT求解的证明自动化及基于策略的交互式定理证明。

核心特性与获取 F* 程序默认编译到 OCaml，也可通过 KaRaMeL 工具提取到 F#、C 或 Wasm，或通过 Vale 工具链生成汇编。F* 本身用 F* 实现并用 OCaml 引导。它在 GitHub 上开源，由微软研究院、Inria 及社区积极开发，采用 Apache 2.0 许可证，提供 Windows、Linux、Mac OS X 的二进制文件，也可通过 OPAM、Docker、Nix 安装或从源码构建。

学习资源 主要学习资源包括正在编写的在线书籍《F* 中的面向证明的编程》及其配套的浏览器交互练习。此外，还有关于其低级子集 Low*（可编译为 C）的教程，以及多个大学暑期学校的课程资料（例如 2021 年俄勒冈编程语言夏令营、2019 年 ECI 等）。

社区与沟通 社区主要通过 GitHub Discussions、Zulip 公共论坛和低流量的邮件列表进行交流。定期举办用户与开发者会议（F* PoP Up Seminar）。

主要应用

1. 工业应用：

   • Project Everest：旨在开发高保证安全通信软件的总项目。
   • HACL、ValeCrypt、EverCrypt：高保证密码学原语库（用 F 编写并提取为 C），其代码已用于 Mozilla Firefox、Linux 内核、Python、mbedTLS、Tezos 区块链、Wireguard VPN 等生产环境。
   • EverParse：从形式化证明的 F* 提取 C 代码的二进制格式解析器生成器，用于 Windows Hyper-V 等生产环境，验证每个通过 Azure 云平台的网络数据包。

2. 学术研究：涵盖语言设计、语义与效果系统、安全与密码学、系统、解析、程序验证与分析以及 AI 辅助编程等多个领域。

   • 语言设计：核心参考论文包括《F* 中的依赖类型与多单子效果》(POPL 2016)，以及描述 Low*、Vale、Meta-F*、Steel 等特性的后续论文。
   • 语义与效果：重要概念包括 Dijkstra 单子及其扩展，以及用于并发和单调状态推理的分离逻辑（如 SteelCore、PulseCore）。
   • 安全与密码学：大量论文集中在 Project Everest 框架下，涵盖 TLS 1.3、QUIC、信号协议、ACME、MLS 等协议的形式化验证实现与安全证明。
   • 系统：应用包括 WebAssembly 沙箱验证、数据完整性监控、实时反应式系统验证、并发内存分配器验证（StarMalloc）等。
   • 解析：除了 EverParse，还扩展到 ASN.1、CBOR 等格式的验证解析。
   • 程序验证与分析：应用于可逆电路编译、会话类型编程、抽象解释、法律编程语言编译器验证、Rust 程序验证、量子分离逻辑、安全编译框架等领域。
   • AI 辅助编程：近期研究利用大型 F* 代码数据集训练模型，以自动化程序和证明合成。

医学后缀“-ectomy”、“-ostomy”与“-otomy”的区别

根据1986年Cecil Adams在专栏中的解答，这三个医学后缀均描述不同类型的手术操作：

• -ectomy：指切除身体某部分的操作，通常翻译为“切除术”。例如，扁桃体切除术（tonsillectomy）即切除扁桃体，输精管切除术（vasectomy）仅移除一小段输精管。
• -ostomy（或-stomy）：指在器官上制造开口或通道，通常用于建立引流或替代原有通道，可译为“造口术”。例如，结肠造口术（colostomy）是在结肠上开一个人工肛门。
• -otomy（或-tomy）：指切开或切割组织的手术，通常为了探查、引流或操作内部结构，译为“切开术”。例如，额叶切除术（lobectomy）是移除脑叶，而额叶切开术（lobotomy）仅是切开或破坏脑组织。

文中以额叶手术为例说明差异：额叶切除术（lobectomy） 是切除脑叶组织，而额叶切开术（lobotomy） 则通过穿刺破坏脑区。文章进一步引申，提到历史上曾用于治疗精神疾病的额叶切开术，其中“冰锥术”即通过眼眶插入器械切断脑部神经，以缓解精神症状。该手术在1940年代曾广泛实施，后因精神药物的发展及手术风险与伦理争议而逐渐淘汰。

总结而言，这三个后缀分别对应“切除”、“造口”和“切开”三种主要手术类型，具体区别需结合手术部位和目的理解。

Project Gameface 已正式登陆 Android 平台。该项目最初于2023年 I/O 大会上推出，是一款开源的、免提的“游戏鼠标”，允许用户通过头部移动和面部表情来控制电脑光标，旨在提升游戏的无障碍性。

其灵感来源于患有肌营养不良症的四肢瘫痪游戏主播 Lance Carr 的故事。此前，已有企业如 playAbility 利用其核心组件（如 MediaPipe Blendshapes）进行开发。此次 Android 版本的开源，旨在帮助开发者构建应用，使 Android 设备更易用。

核心设计原则：

1. 为残障人士提供操控 Android 设备的新方式。
2. 打造经济实惠的解决方案，实现规模化应用。
3. 沿用初版的经验，确保产品易用且可定制。

技术实现与功能：

• 虚拟光标： 利用 Android 无障碍服务创建光标，并通过 MediaPipe 的 Face Landmarks Detection API 追踪用户头部移动来控制光标。该 API 包含 52个面部混合形状值，可映射诸如抬眉、张嘴等面部动作。开发者还可通过设置混合形状系数来自定义阈值。
• 移动操作： 不同于Windows版仅支持点击，Android版支持更广泛的 全局动作，包括返回（GLOBAL_ACTION_BACK）、主页（GLOBAL_ACTION_HOME）、通知（GLOBAL_ACTION_NOTIFICATIONS）和应用列表（GLOBAL_ACTION_ACCESSIBILITY_ALL_APPS）等。
• 摄像头反馈： 提供实时摄像头画面浮窗，辅助用户进行手势校准和理解。通过 Android 无障碍服务，即使用户进入系统设置等关键界面，此浮窗也能持续显示。
• 拖拽功能： 针对 Android 无障碍服务原生不支持实时拖拽的问题，本项目新增了 拖拽功能，允许用户自定义起止点，实现沿指定路径的无缝拖拽操作。

合作与开源： 在开发过程中，团队与印度支持残障人士的社会企业 Incluzza 合作，探索该项目在教育、工作等场景的应用（如发送信息、求职搜索）。目前，Gameface 的代码已在 GitHub 上开源。

项目团队感谢了所有参与者，包括 Lance Carr、Google 及 Incluzza 团队的成员。

技术摘要：SiLU和SoftMax函数的优化

该内容记录了在ggml项目中对SiLU和SoftMax函数进行的一项关键优化，主要围绕引入新的向量化指数函数来提升性能和精度。

核心优化

• 方法：将llamafile项目中的向量化expf()函数集成到ggml中。
• 替代方案：取代了GGML之前为提高速度而使用的short[65536]查找表方法。
• 兼容性：新实现支持aarch64和**SSE2+**指令集。
• 精度保证：最坏情况下的舍入误差仅为2ulp，在保持完全精度的同时实现了显著加速。

性能提升

在CPU后端进行的SOFT_MAX性能测试（test-backend-ops -o SOFT_MAX -b CPU）显示了明显的速度提升：

• SSE2+FMA：速度提升1.5倍
• AVX2+FMA：速度提升1.9倍
• AVX512：速度提升2.1倍

编译选项问题与修复

在重写SiLU和SoftMax的过程中，发现使用编译选项-ffast-math（会隐含启用-ffinite-math-only）会导致结果不确定。

• 问题：当使用超过一个计算槽（slot）时，SiLU函数在处理极小值时不会正确地将其归零为0.0，而是返回NaN或其他错误值。
• 原因：-ffinite-math-only选项禁用了对非有限数（如NaN和Inf）的算术处理，这与ggml部分代码依赖非有限数学运算的要求相冲突。
• 解决方案：强制在编译时检查并确保设置了-fno-finite-math-only，以覆盖-ffast-math带来的该限制，从而恢复对NaN/Inf的正确处理，保证了计算结果的确定性和正确性。

后续影响

该优化和相关的编译修复被多个下游项目（如whisper.cpp及其他llama.cpp分支）广泛采纳和应用，体现了该改进在提高AI模型推理效率方面的重要价值。

Jepsen：Datomic Pro 1.0.7075 测试报告摘要

核心发现

Jepsen 对 Datomic Pro 1.0.7075 的测试表明，其事务间的安全性比官方声称的更强。每个历史都是可序列化的（Serializable），绑定到单个 Peer 的会话表现出了强会话可序列化性（Strong Session Serializable）。当写入事务和使用 d/sync 的读取结合时，历史表现出强可序列化性（Strong Serializable）。 然而，在事务内部，Datomic 的行为如同操作被并发执行。这种设计可能违反三个最广泛接受的可序列化性形式化定义，因为它们都要求事务内部具有串行语义。这也为组合事务函数时引发不变量违反埋下了隐患。

背景

Datomic 是一个通用的、时态的实体-属性-值（EAV）数据库，设计用于记录系统。它以 datom（五元组）的形式存储数据，并显式建模时间，允许查询任何时间点的数据库快照。它支持多种查询方式，并提供 Peer（胖客户端）和 Client（瘦客户端）两种接入模式。

架构与事务模型

• 架构：由 Transactor（执行写入事务）和 Peer（执行查询并缓存）组成。数据存储在支持最终一致性的底层存储（如 DynamoDB）中，通过顺序一致性的比较并设置（CaS）操作来推进全局状态指针，从而保证事务顺序。
• 事务模型：Datomic 严格区分读写路径。读取操作获得的是不可变的数据库快照，写入事务则是一系列操作（断言、撤回、事务函数）的列表。事务不提供交互式通道，不能向调用方返回任意数据，仅返回事务前后的数据库状态和产生的 datom。这鼓励将读取移出写事务路径。

一致性保证与测试方法

Datomic 文档声称支持 ACID 事务，并隐含地表示写入事务是可序列化的。Jepsen 的测试验证了以下预期：

1. 写入事务是可序列化的，且可能具有强可序列化性。
2. 基于单个 Peer 的会话是强会话可序列化的。
3. 使用 d/sync 保证读取最新状态时，历史是严格可序列化的。 测试使用了多种工作负载（如列表追加、带 CaS 的列表追加、内部一致性、授权状态机），并注入了进程暂停、崩溃、网络分区和时钟错误等故障。

主要测试结果

1. 事务间语义符合预期：未发现违反 Datomic 核心安全声明的行为。事务看起来以总顺序执行，该顺序与每个 Peer 观察到的本地顺序一致。
2. 事务内语义存在重大差异：
   • 内部一致性：事务内的操作（包括事务函数）表现得像并发执行，均基于事务开始时的数据库状态进行计算。例如，两个递增操作可能只产生一次递增的效果。如果同一事务中对同一实体、单值属性产生冲突的断言，事务会中止。
   • 伪写偏斜：即使单个事务函数能独立维护不变量，但将它们组合在同一个事务中可能破坏该不变量。测试中的 “授权” 工作负载演示了这一点：一个事务同时调用 approve 和 deny 函数，导致同一笔拨款同时被批准和拒绝。这是因为两个函数都读取了事务开始时的状态（拨款未被批准/拒绝），然后分别写入了不相交的属性。Datomic 的事务内冲突检查器（用于检测同一单值属性的冲突）无法阻止此类情况。
3. 补救措施：Datomic 提供了实体谓词（Entity Predicates）等机制来强制执行全局约束。通过显式请求实体规约（Entity Specs），可以在事务提交前验证数据库状态，从而防止上述不变量违反。

结论与建议

• 结论：Jepsen 认为 Datomic 的事务间安全性可靠，其实现比文档描述的更强。其独特的事务内并发语义虽然与主流形式化模型不符，但文档中有相应说明，并非缺陷。测试未发现安全错误。
• 对用户的建议：
  • 务必理解 Datomic 事务内操作是并发执行的语义。
  • 谨慎在同一事务中组合多个事务函数，尤其是当它们有相交的读取集和不相交的写入集时。
  • 注意对同一值的多次更新（如递增）可能会静默地合并为一次更新。
  • 利用实体谓词和属性约束来维护业务规则不变量。
  • 注意 Transactor 在存储连接不稳定时可能会自行关闭，需要外部监控重启。

文档更新

根据测试合作，Datomic 已全面修订文档，更准确地描述了其更强的安全属性，详细说明了事务语法和语义，并删除了关于“单写入者”等不准确的说法。

未来研究方向

Jepsen 提出，Datomic 的“事务内并发”模型是独特且值得研究的。未来工作可探讨该模型与传统事务模型的关系、与其他时态数据库的比较、以及在单调性等理论框架下的安全性等。

应用名称：Cosmos
核心功能：为视频制作公司提供基于本地智能搜索的图像/视频管理工具，帮助销售团队快速检索并分享过往作品，以提升业务成交率。

解决的问题

• 传统效率低下：当客户要求提供相关作品示例时，制作团队通常需要手动在档案中查找，平均响应延迟达24小时，且结果往往不够精准，导致商机流失。
• 信息不对称：销售团队无法实时展示适合的作品，客户可能仅基于网站现有内容决策，而许多优质作品因未及时展示而浪费。

工作原理

Cosmos作为现有档案库的智能访问层，允许后期团队控制内容索引与标签化，销售团队则可通过自助工具快速获取经授权的可分享内容。

主要功能

1. 多维度智能筛选

   • 支持按行业、格式、客户、交付类型、风格、年份、团队、时长等元数据进行组合筛选，无需记忆项目名称，直接精准定位相关作品。

2. 快速生成分享链接

   • 点击即可整理项目合集，生成可公开访问的链接，客户无需账户或下载即可在任意设备浏览，并可追踪查看时长与频率。

3. 权限分离管理

   • 销售团队快速获取已授权内容，后期团队保持对共享内容的控制权，避免未授权内容外泄，同时消除跨部门协作瓶颈。

团队背景

创始人Brian Correa拥有10年以上计算机视觉与视频系统开发经验，曾服务于多家技术公司，基于行业痛点开发了Cosmos，旨在通过AI解决档案检索效率问题。

总结：Cosmos通过本地化AI检索技术，解决视频制作公司销售与后期团队之间的协作效率问题，实现档案价值最大化，加速业务转化。

地球自转限制相机机身防抖至6.3档

核心观点

• 2016年，奥林巴斯宣称其相机防抖达6.5档，限制因素为地球自转，这引发了行业关注。
• 理论计算表明，由于地球自转，标准全画幅相机（像素宽度约0.0059mm）的机身防抖（IBIS）在物理上被限制在约6.3档。

技术原理

1. 陀螺仪传感器限制：防抖系统性能提升依赖于陀螺仪传感器精度。传感器零偏噪声会导致系统漂移，而当防抖档数超过约6档时，限制因素从电子噪声转变为地球自转。
2. 地球自转的影响：
   • 地球自转速度约为7.27×10⁻⁵弧度/秒。
   • 当相机指向东西方向时，防抖系统会尝试保持相机在惯性参考系中的稳定，但拍摄对象随地球旋转，导致相机相对拍摄对象发生缓慢旋转。
   • 长时间曝光后，这种相对运动会导致图像模糊。
3. 理论计算：对于2400万像素全画幅相机（像素宽0.0059mm），考虑地球自转和焦距，可推导出最大允许快门速度，并换算得出约6.3档的防抖极限。这意味着防抖系统必须能检测并补偿与地球自转相当的缓慢旋转（每天360度）。

后续发展与质疑

• 后来，奥林巴斯OM-D E-M1X宣称达到7.5档防抖，松下某些镜头也宣称7档防抖，突破了6.3档的理论限制。
• 可能的突破方法：
  1. 使用GPS、加速度计和罗盘实时计算相机方位和纬度，进行针对性补偿。
  2. 使用高通滤波器，仅补偿高频手部抖动，滤除低频的地球自转影响。
• 作者质疑：这两种方法在实际拍摄中均有局限（如信号问题、指向稳定性要求）。作者更怀疑这可能与CIPA防抖测试标准有关。
• CIPA测试问题：
  • 测试中，相机固定在振动平台上，平台预先稳定，可能使相机更容易识别并滤除地球自转等低频干扰。
  • CIPA测试标准和设备不对个体或研究机构开放，限制了独立验证，使得宣称的高防抖档数可能部分源于测试条件的特殊性。

结论

作者指出，尚不清楚相机厂商是真正突破了地球自转的物理限制，还是利用了CIPA测试标准的特性。需要实际测试来验证相机在真实场景中能否超越6.3档防抖，或证实地球自转确为实际性能的硬性限制。

使用Julia在100行代码内实现RAG精确二进制向量搜索

背景与动机

本文探讨了在检索增强生成（RAG） 场景中，如何通过二进制向量空间实现快速精确检索。RAG旨在为大语言模型（LLM）提供外部上下文以提升回答质量，通常需要将查询编码为向量并在数据库中查找最近邻。

二进制向量空间相比32位浮点向量能大幅节省存储空间（从1TB降至约32GB），同时保持相近的准确性。这使得内存检索更可行，尤其适合如维基百科（约1500万向量）或内部文档等数据集。

核心实现

• 向量表示：使用mixedbread-ai/mxbai-embed-large-v1模型生成1024维浮点向量，通过二值化转换为1024位向量，最终用64字节（512位）表示。
• 距离计算：采用汉明距离，通过位异或（XOR）和计数操作（popcnt指令）高效计算。利用Julia的count_ones函数直接调用硬件指令。
• 优化技术：
  • 使用@inbounds和@simd宏提升循环性能。
  • 采用StaticArrays存储查询向量，减少内存分配开销。
  • 支持多线程并行搜索，提升多核利用率。

性能表现

在M1 Air上测试：

• 单向量比较：通过位操作优化后，耗时约6纳秒；使用StaticArrays进一步降至4纳秒。
• 大规模搜索：
  • 100万行：单线程约12毫秒，4核并行约3毫秒。
  • 1500万行（维基百科规模）：约180毫秒。
  • 10万行：查询时间低于1毫秒。
• 对比现有库：相比usearch（近似搜索库），本实现在单线程下快16倍，4核下快30倍。

结论

通过约100行Julia代码，实现了高性能的二进制向量精确搜索。该方法适用于中小规模RAG数据集（如2000万行以内），在查询延迟和计算资源间达到良好平衡，避免了对复杂向量数据库的依赖。

欧盟委员会宣布正式对Facebook和Instagram展开儿童保护调查，重点关注其设计可能导致未成年人成瘾的问题。此次调查源于欧盟《数字服务法》自2023年8月生效后，监管机构多次要求母公司Meta提供信息未获满意答复。

根据《数字服务法》，Facebook和Instagram被认定为“超大型在线平台”，需直接接受欧盟监管，必须评估并减轻系统性风险，包括对未成年人心理健康的影响。欧盟怀疑Meta未能妥善履行这一义务，具体问题涉及：

1. 成瘾性设计：平台通过算法推荐内容，可能导致“兔子洞效应”，使未成年人观看一个视频后被推送更多相似内容，例如涉及抑郁或不良身体形象的内容，从而影响其心理健康。
2. 年龄验证漏洞：Meta目前采用的年龄核实方法可能过于简单，易于被未成年人绕过，欧盟质疑其有效性。

此次正式调查将赋予欧盟更强的执法权，包括现场检查和实施临时措施。若最终确认违规，Meta可能面临高达全球年营业额6%的罚款。

欧盟还同时就选举诚信问题对Facebook和Instagram展开调查，并于上月对TikTok的成瘾性设计问题启动了类似程序。

Meta回应称，公司十年来已开发超过50种工具和政策保护年轻用户，目前采用自我申报年龄结合人工智能评估的方法验证年龄，并允许举报疑似未成年账户。Meta表示，其内部测试显示这些措施已阻止96%试图将年龄从18岁以下改为18岁以上的青少年在Instagram上修改生日。

本文档是互联网号码分配局（IANA）的官方端口注册列表，用于记录TCP/IP协议中已分配的服务端口。

端口分类

端口号分为三个范围：

• 众所周知端口：0 到 1023。通常由系统进程或特权程序使用。
• 注册端口：1024 到 49151。可由普通用户进程使用。
• 动态和/或私有端口：49152 到 65535。

核心内容

文档主体以表格形式列出了已分配端口，包括以下列：

• 关键字：服务的缩写名称。
• 十进制端口号：具体的端口号（TCP/UDP）。
• 描述：该端口提供的服务或协议。
• 引用：负责该分配的联系人信息。

重点端口示例：

• 端口 80：用于 HTTP（万维网HTTP）。
• 端口 443：用于 HTTPS（基于TLS/SSL的HTTP协议）。
• 端口 22：用于 SSH（SSH远程登录协议）。
• 端口 25：用于 SMTP（简单邮件传输协议）。
• 端口 53：用于 Domain（域名服务器）。

关键发现：根据列表，端口 666 被正式分配给了 doom 服务，描述为“doom Id Software”，即游戏《毁灭战士》的通信端口。这是对标题“Port 666 is officially registered to Doom”的直接印证。

结构与内容

1. 众所周知端口列表：详细列出了从0到1023端口的完整分配情况。
2. 注册端口列表：详细列出了从1024到49151端口的完整分配情况。
3. 动态端口范围说明：仅声明了范围为49152至65535，未提供具体列表。
4. 参考文献：引用了UDP和TCP的相关RFC文档。

Tarsier：面向网页交互代理的视觉工具

项目概述

Tarsier 是由 Reworkd 开发的开源视觉工具，旨在解决利用大型语言模型自动化网页交互时面临的核心挑战。它主要用于为网页代理提供感知能力，帮助 LLM 理解页面结构并执行操作。

核心问题与解决方案

在使用 LLM 进行网页自动化时，常遇到以下问题：

1. 如何将网页内容（HTML、辅助功能树、截图）有效输入 LLM。
2. 如何将 LLM 的响应映射回具体的网页元素。
3. 如何让纯文本 LLM 理解页面的视觉布局。

Tarsier 通过以下方式解决这些问题：

• 视觉标签系统：为页面上的可交互元素添加带 ID 的标签（如 [23]），建立元素与 ID 的映射，使 LLM 能通过指令（如 CLICK [23]）操作元素。
• OCR 文本表示：开发了将页面截图转换为结构化字符串（类似 ASCII 艺术）的 OCR 算法，使无视觉能力的 LLM 也能理解页面。
• 性能优势：在内部基准测试中，结合 Tarsier 文本表示的纯文本 GPT-4 性能，比结合截图表示的 GPT-4V 高出 10-20%。

工作原理与功能特性

• 可交互元素定义：包括页面上可见的按钮、链接或输入框；通过设置 tag_text_elements=True 可标记所有文本元素。
• 标签类型区分：不同元素使用不同标签格式以帮助 LLM 识别操作类型：
  • [#ID]：可插入文本的字段（如 textarea、文本类输入框）。
  • [@ID]：超链接（<a> 标签）。
  • [$ID]：其他可交互元素（如按钮、选择框）。
  • [ID]：纯文本（启用文本元素标记时）。

安装与使用

依赖与凭证

• 当前支持两种 OCR 引擎：Google Cloud Vision 和 Microsoft Azure Computer Vision。
• 需要配置对应的服务凭证（Google 服务账户密钥或 Azure API 密钥与端点）。

基本用法示例

通过 Playwright 控制浏览器，使用 Tarsier 处理页面：

import asyncio
from playwright.async_api import async_playwright
from tarsier import Tarsier, GoogleVisionOCRService
import json

async def main():
    # 加载凭证并初始化 OCR 服务与 Tarsier 实例
    ocr_service = GoogleVisionOCRService(google_cloud_credentials)
    tarsier = Tarsier(ocr_service)

    async with async_playwright() as p:
        browser = await p.chromium.launch()
        page = await browser.new_page()
        await page.goto("https://example.com")

        # 获取页面文本表示与标签到 XPath 的映射
        page_text, tag_to_xpath = await tarsier.page_to_text(page)
        print(tag_to_xpath)
        print(page_text)

asyncio.run(main())

开发与测试

• 提供设置脚本支持本地开发。
• 修改 TypeScript 文件后需编译为 JavaScript 以供 Python 包使用。
• 使用 pytest 进行测试，提交前需运行格式化脚本。

支持与路线图

当前支持的 OCR 服务

• Google Cloud Vision（已支持）
• Amazon Textract（即将推出）
• Microsoft Azure Computer Vision（即将推出）

计划功能

• 完善文档与示例。
• 优化接口并添加单元测试。
• 提升 OCR 文本处理性能。
• 添加自定义标签样式的选项。
• 根据需要支持其他浏览器驱动程序。

引用信息

项目以 GitHub 仓库形式发布，作者为 Rohan Pandey、Adam Watkins、Asim Shrestha 和 Srijan Subedi（2023年）。

这篇文章通过展示一系列Scheme语言实现的阶乘函数，生动描述了一位Scheme程序员从入门到精通的成长历程。文章以代码形式呈现，每个代码块代表一个不同的学习阶段或编程风格。

文章的核心内容如下：

1. 初学阶段：从大学课堂或《The Little Schemer》一书开始，学习基本的递归和Lambda表达式。
2. 新手阶段：开始享受递归和简洁的函数式风格。
3. 抵触阶段：在大学里学习Scheme后，可能对函数式编程产生反感，转而使用命令式循环和可变状态。
4. 系统学习SICP阶段：阅读《计算机程序的构造和解释》(SICP)，开始理解尾调用优化和辅助函数的重要性，并学会使用内部定义来避免污染命名空间。
5. 习惯养成阶段：熟悉了Scheme的惯用法，例如使用let循环。
6. 跨语言影响阶段：接触其他函数式语言后，开始使用模式匹配（match-lambda）。
7. 工具链依赖阶段：开始依赖列表操作和标准库，例如使用build-list、apply和SRFI-1中的fold、iota。
8. 库探索阶段：热衷于寻找现成的解决方案，例如SRFI-42的枚举推导式或Racket特有的for/product宏。
9. 理论探索阶段：出于兴趣，尝试使用Y组合子、皮亚诺算术和组合子逻辑来实现阶乘，虽然这些实现通常很晦涩难懂。
10. 宏迷恋阶段：发现了宏的强大功能，尝试用宏展开来优化代码，甚至“循环展开”。
11. 高级概念实践阶段：开始实践延续传递风格和一等延续，但可能对如何应用它们感到困惑，有时会导致复杂或有问题的实现。
12. 性能优化阶段：关注性能，引入记忆化技术来缓存计算结果。
13. 惰性求值阶段：使用协程、生成器或流来实现惰性计算的阶乘序列。
14. 最终阶段（库的忠实用户）：认识到最佳实践往往是直接使用经过充分测试的标准库（如Racket的math/number-theory），从而放弃自己实现。

文章灵感来源于《一位Haskell程序员的进化》，旨在幽默地展示程序员在掌握一门语言过程中，从学习基本概念到探索高级特性，最终回归实用和依赖成熟解决方案的成长轨迹。

这篇文章以一个创意故事的形式，介绍如何构建一种名为“Easel”的自定义编程语言。主角Orpheus在一个周六早晨收到一个神秘包裹，内含一台计算机和一块空白的“画架”，附带的信件要求她通过编写编程语言来“绘画”这块画架，以解开送件人之谜。信中提供了一段用Easel语言编写的示例代码，用于绘制一个64x64的像素图像。

文章展示了Easel语言的主要特性：

• 变量定义：使用 prepare 和 as 关键字。
• 数据类型：支持字符串、数字、布尔值和数组。
• 注释：使用波浪符号 ~ 标记。
• 结构体：使用 brush 关键字定义，类似于映射或字典，具有预定义的键。
• 函数定义：使用 sketch 关键字定义函数。如果函数需要参数，则使用 needs 关键字。
• 控制流与逻辑：支持 if 条件语句、循环 (loop)，以及逻辑运算符 &&、||、!。
• 返回与输出：使用 finished 返回值，使用 ink 进行输出。

随后，文章转向技术实现，指导读者从头开始构建Easel语言：

1. 环境设置：创建一个Node.js项目，通过 npm init -y 初始化。
2. 配置：在 package.json 中添加 "type": "module" 以使用ES模块语法。
3. 代码结构：
   • 创建 easel.js 作为主程序入口。
   • 创建 stdlib.js 用于错误处理等基础功能。
4. 运行：通过命令 node easel.js test.easel 执行脚本，但文章指出此时功能尚不完整，需要进一步开发语言解释器。

文章通过一个生动的故事框架，引入了构建一种简单编程语言所需的初始步骤和语法设计概念。

Dragonfly：基于商用佳能镜头阵列的光学望远镜

Dragonfly 是一个创新的多镜头阵列，专为可见光波长的超低表面亮度天文学设计。该望远镜于2013年启用，最初仅有三个镜头，但如今规模持续扩大，已能探测星系周围极其微弱的复杂结构。其主要科学目标是揭示宇宙中预测存在但尚未被观测到的微弱结构，如星系周围的细流和丝状物，这些结构与冷暗物质（CDM）宇宙学模型相关。CDM模型认为宇宙结构自下而上增长，小星系合并形成大星系，但现有大型望远镜图像中的散射光可能掩盖了这些细节。

为解决这一问题，Dragonfly 采用多项技术创新。它使用商用佳能400mm镜头，这些镜头配备了前所未有的纳米制造涂层，具有亚波长结构，能显著减少光学系统内的散射光和内部反射。此外，Dragonfly 通过多个镜头同时成像，模仿蜻蜓的复眼原理，进一步去除杂光，从而生成清晰显示极微弱星系结构的图像。

在进展方面，Dragonfly 团队于2022年完成了其超宽勘测项目的70%，该勘测完成后将覆盖斯隆数字巡天的全部区域。2023年，项目正在扩展中，计划新增120个镜头。该望远镜的共同首席研究员为多伦多大学的Roberto Abraham教授和耶鲁大学的Pieter van Dokkum教授。

Kernel.org 服务器在2009年遭恶意后门感染长达两年

感染事件概述

根据安全公司ESET的研究，负责维护和分发Linux操作系统内核的基础设施（kernel.org）从2009年开始，遭到一种名为Ebury的高级恶意软件感染，持续时间长达两年。这比此前公开披露的2011年感染事件要早两年。攻击者成功入侵了kernel.org域名下的至少四台服务器，并获取了系统上551个用户的加密密码哈希数据（存储在/etc/shadow文件中）。通过密码破解技术和恶意软件内置的凭据窃取功能，攻击者成功将其中275个账户的密码还原为明文，并利用这些服务器发送垃圾邮件及进行其他恶意活动。

恶意软件Ebury的技术细节

Ebury是一种复杂的恶意软件，其主要形式是一个恶意代码库，通过感染OpenSSH（用于安全远程连接的SSH协议实现）文件来植入后门。该后门允许攻击者在无需有效密码的情况下，以远程root shell的形式访问受感染的主机。

• 传播与规模：Ebury主要通过窃取SSH凭证在服务器之间传播。自2009年以来，该恶意软件已感染超过40万台服务器（绝大多数为Linux系统）。感染并非一次性发生，而是一个持续的过程：新服务器不断被感染，旧的被清理或退役。在2023年，由于一家大型托管提供商被攻陷，被感染的活跃IP地址数量曾激增至约11万个。
• 多种传播方法：除了窃取SSH凭证，研究还发现了五种新的传播方式，包括：凭据填充、从虚拟机管理程序或容器向所有子系统传播、从托管提供商向所有相连的服务器传播、利用漏洞（如Dirty COW）进行攻击，以及在同一网络内实施中间人攻击来窃取其他服务器的SSH凭证。
• 盈利模式：攻击者利用被感染的服务器通过多种方式牟利，包括窃取支付卡信息和加密货币、进行流量重定向、发送垃圾邮件以及窃取凭证。为此，他们部署了诸如Apache模块、内核模块、防火墙穿透工具和中间人攻击脚本等一系列专用工具。

感染范围与影响

Ebury的感染范围极其广泛，涉及大学、大中小型企业、互联网服务提供商、加密货币交易所、Tor出口节点、共享及专用服务器提供商等各类环境。例如，2019年曾有一家美国大型域名注册和网站托管提供商的基础设施被感染，影响了约2500台物理服务器和6万台虚拟服务器，以及超过150万个托管账户。2023年，通过在一家美国托管提供商处设置“蜜罐”服务器进行测试，ESET研究人员证实该提供商有约7万台服务器在一周内被Ebury感染。

关键点：尽管kernel.org在2011年公开披露了其服务器被入侵（当时主要归因于另一个名为Phalanx的rootkit），但ESET的报告指出，Ebury的感染很可能是由另一个不相关的威胁组织实施的，并且没有证据表明任何一次感染导致了Linux内核源代码被篡改。

总结与建议

Ebury恶意软件历经15年持续演化，传播手段多样且隐蔽，对全球Linux服务器安全构成严重威胁。ESET的报告提供了入侵指标，供管理员自查。报告指出，虽然为SSH服务部署多因素认证能有效提升安全性，但由于其依赖第三方模块且需要手动配置，并非主流Linux发行版的默认设置，因此实际部署率很低。鉴于Ebury的持续威胁，所有组织都需保持警惕，实施严格的安全措施以最小化其传播和影响。

被遗忘的“间谍”：库尔特·哥德尔在原子弹故事中的角色

本文指出，2023年的电影《奥本海默》完全从其主角J·罗伯特·奥本海默的视角叙述了原子弹的故事，但遗漏了许多重要内容。

文章强调，美国的原子弹研发工作早在1943年奥本海默接管新墨西哥州洛斯阿拉莫斯实验室的曼哈顿计划负责人职位之前多年就已开始。该项目由物理学家利奥·西拉德发起。出于对德国核科学发现速度的担忧，西拉德在1939年8月说服阿尔伯特·爱因斯坦给时任总统富兰克林·D·罗斯福写了一封信，警告他希特勒手中掌握原子弹的风险。

文章标题暗示，数学家和逻辑学家库尔特·哥德尔在此历史中扮演了一个被遗忘的（可能是失败的）“间谍”角色，但所提供的内容主要聚焦于原子弹计划的起源背景和历史叙述的局限性，并未详细展开哥德尔的具体经历。文章其余部分为期刊的访问选项、更正声明、利益冲突声明、相关文章列表及学科领域更新，与主旨内容无关。

PaliGemma：Google开源多模态模型总结

模型概述

PaliGemma 是 Google 推出的一款开源视觉语言模型（VLM），由视觉模型 SigLIP 和大语言模型 Gemma 组合而成（包含 Transformer 解码器和 Vision Transformer 图像编码器）。该模型拥有 30 亿参数，支持多语言，并允许商业使用。与 GPT-4o 等闭源模型不同，PaliGemma 的核心设计理念是通过微调（Fine-tuning）来适应特定任务，而非直接开箱即用。

核心功能与部署

• 支持任务：图像与短视频描述、视觉问答（VQA）、光学字符识别（OCR）、目标检测与实例分割。
• 部署方式：支持通过开源 Inference 包进行部署，可自托管于云端或 NVIDIA Jetson 等大型边缘设备，提供高度的灵活性。

性能评估

• OCR（光学字符识别）：表现卓越，平均准确率达 85.84%。在速度效率和成本效率上大幅超越 GPT-4o 和 EasyOCR，是极具性价比的本地 OCR 方案，但对提示词（Prompt）较为敏感。
• 文档理解与 VQA：能处理简单的信息提取（如菜单价格）和基础视觉问答，但在复杂推理（如计算硬币总额、识别特定电影场景）和复杂文档（如收据税金提取）上表现欠佳。
• 目标检测与分割：使用官方指定的关键词（如 detect [object] 或 segment [object]）可实现准确的检测与分割，但在复杂或隐蔽场景下容易失效或产生幻觉。

核心应用场景

1. 定制化行业应用：企业可利用专有数据对其进行微调，解决制造、医疗、安防等领域中闭源模型无法覆盖的特定问题。
2. 大规模 OCR 应用：凭借其轻量级、低成本和高准确率，非常适合需要平衡延迟、成本与精度的生产级 OCR 场景。

局限性

• 不擅长复杂推理：仅适用于指令清晰的具体任务，无法处理开放式、复杂或需要深度逻辑推理的问题。
• 知识边界受限：不具备外部知识库能力，认知仅限于预训练和微调数据。
• 零样本性能一般：开箱即用的零样本表现并非行业最优，必须依赖自定义数据微调才能发挥最大价值。
• 提示词高度敏感：输出结果极易受提示词微小变化（如名词的单复数形式）的影响，需要反复调试。

核心价值

PaliGemma 打破了以往大型多模态模型微调成本高、算力要求严苛的壁垒。作为一款轻量级且专为微调设计的开源模型，它赋予了开发者在自有硬件上构建、训练和部署定制化多模态 AI 应用的能力，极大推动了多模态 AI 技术的普及与落地。

Android 推出一系列高级防盗保护功能，旨在通过技术手段在盗窃发生前、发生时和发生后保护设备和数据安全。这些功能将通过 Google Play 服务更新推送给运行 Android 10 及以上版本的数十亿设备，部分功能将在 Android 15 中提供。

一、 盗窃发生前：增强设备与数据安全，威慑犯罪

1. 升级恢复出厂设置保护：针对企图通过快速重置并转卖手机的盗窃行为，新机制确保盗窃者在不知晓设备密码或 Google 账户凭据的情况下，无法完成重置后的设置，从而使被盗设备无法被再次使用，减少盗窃动机。
2. 私密空间：允许用户创建一个可隐藏、并用独立 PIN 锁定的手机分区，为包含健康或金融等敏感数据的应用提供额外安全层。
3. 敏感设置更改需认证：更改“查找我的设备”或屏幕超时等敏感设置时，需要输入 PIN、密码或进行生物认证，增加了安全屏障。
4. 增强身份验证：当启用后，从不可信位置访问或更改关键账户和设备设置（如修改 PIN、禁用防盗保护、访问密钥）时，将强制要求生物识别验证，防止 PIN 泄露后造成的风险。

二、 盗窃发生时：自动识别与即时保护

1. 盗窃检测锁：利用 Google AI 技术，识别手机被抢夺后可能伴随的奔跑、骑车或驾车等可疑运动模式。一旦检测到，手机屏幕将迅速锁定，阻止盗窃者轻易访问数据。
2. 离线设备锁：若盗窃者试图长时间断开手机网络，设备会自动锁定屏幕。此外，当检测到多次错误的认证尝试等异常情况时，设备也会自动锁定。

三、 盗窃发生后：快速响应与远程控制

1. 远程锁定：作为紧急救济功能，用户即使忘记了 Google 账户密码，也可以通过任何其他设备，仅使用手机号码和一个快速安全验证来远程锁定丢失手机的屏幕。这为用户争取了时间，以找回账户详情并使用“查找我的设备”的其他功能，例如远程执行完整的恢复出厂设置。
2. 查找我的设备增强：该应用本身已支持远程锁定或擦除丢失/被盗手机，现在用户还可以将其标记为丢失，以便于追踪。

这些综合性措施共同构成了一个更强大的防盗体系，旨在全面降低智能手机被盗的风险，并在盗窃发生时最大限度地保护用户的隐私与财产安全。

深海猎手达纳鱿鱼：致命“头灯”与高速捕食

科学家首次在太平洋中部约1000米深的漆黑海底，拍摄到大型达纳鱿鱼（Taningia danae）发动攻击的完整过程。这种鱿鱼拥有海洋顶级的捕食装备，包括其触手末端一对明亮的“头灯”——实际上是动物王国中最大的生物发光器官（photophores），大小如柠檬。它们通过化学反应发光，旨在瞬间眩晕猎物，使其僵直，便于鱿鱼用布满致命钩刺的触手将其擒获。

研究发现与拍摄细节

• 攻击行为：视频显示，鱿鱼在自由下落的诱饵框架（速度约每分钟60米）附近发动迅猛攻击，其发光器官的薄膜能开合以控制灯光闪烁。它错误地抓住了摄像头，展现了从猎物视角看到的冲击性画面。
• 研究意义：此前对该物种的了解多来自搁浅或鲸胃残留物样本，本次拍摄是首次在其原生深海环境观察其活跃捕食行为，揭示了其日常生存状态。
• 技术手段：由西澳大学（UWA）和Minderoo-UWA深海研究中心团队使用带诱饵的自由下落摄像头拍摄。团队得到慈善海洋组织Inkfish（由亿万富翁Gabe Newell创立）支持，利用名为“Dagon”的科考船及能下潜至全海洋深度（11公里）的载人潜水器“Bakunawa”开展研究。
• 后续计划：首席科学家Alan Jamieson教授即将使用“Bakunawa”潜水器探测太平洋汤加海沟的Horizon Deep（深达10,816米），为世界第二深海渊进行科学考察。

该文章批评了像凯西·梅里尔（Cathy Merill）这样对远程工作持恐惧态度的CEO们，认为他们的核心问题在于控制欲、对变化的恐惧以及管理能力的不足。

文章指出，梅里尔在《华盛顿邮报》的观点文章中犯了两个根本性错误：

1. 忽视既有方案：许多组织在疫情前已成功实践远程工作多年，并解决了她认为无法解决的问题。她的无知被视为一种无能。
2. 低估员工能力：她假设员工在没有高管亲眼监督的情况下就无法保持高效和协作，这是一种将员工幼稚化的表现。

文章以一个管理失败的案例为佐证：某财富500强公司的一名新员工在远程工作中遇到困难，但领导团队无人提供反馈，还将其归咎于远程技术的限制。作者一针见血地指出，这纯粹是管理失职，公司理应拥有多种沟通工具和与远程人员合作的经验。

对于梅里尔关于远程工作无法进行非正式协作与指导的观点，文章反驳称，存在大量成功的在线协作工具和指导项目，且像Automattic和Citrix这样的完全远程公司拥有充满活力的企业文化。作者批评梅里尔因此主张远程员工应降薪或失去福利的威胁性言论。

文章进一步探讨了问题的根源：梅里尔将工作绩效下降单一归咎于远程工作，而无视了疫情期间可能存在的其他心理或文化因素，且其证据多来源于高管朋友们自述的管理无能例子。

最后，文章对比了恐惧型CEO与优秀CEO的特质。优秀的CEO能面向未来、主动担责、从多元网络中学习并邀请员工共同解决问题。他们不会将技术当作问题的替罪羊，而是致力于投资和培育面向未来的企业文化。技术常被高估，但在此议题上，它成了管理文化缺陷的安全借口，而那些以此为借口的领导者只会让竞争对手因保持好奇心和开放心态而获得优势。

Wuffs：安全处理不可信文件格式的语言与库

Wuffs 是一门内存安全的编程语言，以及一个用该语言编写的标准库，其核心目标是安全地处理（解析、解码、编码）不可信的文件格式（如图像、音频、视频、字体、压缩档案等）。它在性能上追求极致，被称为“极其快速”。

核心目标与特性

1. 安全与速度兼顾：

   • 安全性：旨在提供与 Go 或 Rust 同等水平的安全性，具体通过在编译时（而非运行时）检查来杜绝缓冲区溢出、整数算术溢出和空指针解引用三类关键错误。这意味着“如果能通过编译，则针对这些错误类别就是安全的”。
   • 速度：性能目标对标 C 语言。基准测试显示其在多个格式的解码速度上超越现有 C、Go、Rust 库（例如，解码 deflate 比 zlib 快 1.4 倍，解码 PNG 比 libpng 快 1.2-2.7 倍）。
   • 代价：为了证明安全性，程序员需要在代码中显式添加安全注解，可能比编写普通 C 代码耗时更长。

2. 封闭性与非通用性：

   • Wuffs 不是通用编程语言，仅用于编写库，而非完整程序。
   • 代码是封闭的，只能进行计算（如将压缩字节转换为解压缩字节），不能进行任何系统调用（如读写文件）。因此，它无法分配或释放内存，从而从根本上避免了内存泄漏、释放后使用等内存安全问题。
   • 生成的库属于 Sans I/O 风格，库本身不负责 I/O，由调用方负责，因此可以与同步或异步 I/O 灵活结合。

3. 编译时安全验证：

   • 语言设计强制要求编译器在编译期间证明所有操作的安全性。例如，x += 1 语句只有在编译器能证明 x 不是其类型最大值（如 u8 类型的 255）时才能编译通过；x / y 必须确保 y 非零。
   • 文章通过一个具体的 LZW 解码器代码修改示例，演示了一个会导致编译错误的更改（溢出检查失败），以及另一个能通过编译但会导致运行时解码测试失败的更改，直观展示了其编译时检查机制。

4. 部署与兼容性：

   • Wuffs 语言编写的库会被转译为 C 代码。
   • 这意味着其他 C/C++ 项目可以像使用任何第三方 C 库一样直接使用 Wuffs 库，无需依赖 Wuffs 语言工具链。
   • 其设计初衷是仅用于程序中对性能和安全均敏感的部分（如文件格式解析），而非整个程序。

性能与现状

• 基准测试证实其在多种格式（bzip2, deflate, GIF, PNG）解码上具有显著性能优势。
• 当前最新稳定版本为 0.3（2023年4月），但由于是 0.x 版本，不提供长期支持且不保证与后续版本的兼容性。
• 尽管编译器可能仍有缺陷，但其 GIF 解码器自 2021 年起已被用于 Google Chrome 浏览器。

项目结构

• lang：Wuffs 语言的 Go 语言实现（分词器、AST、解析器等）。
• std：Wuffs 标准库的源代码。
• release：以 C 代码形式发布的 Wuffs 库。
• test / fuzz：常规测试与模糊测试。
• cmd：Wuffs 语言的命令行工具。
• 项目提供构建说明、详细文档（包括入门指南、基准测试、语言/库概述等），并采用 MIT 和 Apache 2.0 双许可证。
• 存在 Python 绑定，Go、Rust 等语言的绑定正在开发中。

优化PostgreSQL查询：提速1000倍的案例

问题背景

Mattermost在大型部署中使用Elasticsearch来减轻数据库搜索查询的压力。Elasticsearch需要为所有待搜索数据建立索引。当从头索引一个包含1亿条帖子的数据库时，发现索引任务运行了18小时仍未完成一半，且进度越来越慢。

问题定位

通过监控仪表盘发现，数据库调用PostStore.GetPostsBatchForIndexing耗时随索引进展不断增加，最终超过30秒超时。该查询的目的是按创建时间排序，获取一批比给定时间戳更新的帖子。

核心SQL查询如下：

SELECT Posts.*, Channels.TeamId
FROM Posts LEFT JOIN Channels ON Posts.ChannelId = Channels.Id
WHERE Posts.CreateAt > ?1
   OR (Posts.CreateAt = ?1 AND Posts.Id > ?2)
ORDER BY Posts.CreateAt ASC, Posts.Id ASC
LIMIT ?3;

根本原因分析

通过EXPLAIN (ANALYZE, BUFFERS)分析发现：

1. 查询耗时约24秒，处理了约309GB数据
2. 关键问题：查询计划使用了Filter而非Index Cond
3. Filter会先获取所有行再根据条件过滤，而Index Cond直接利用索引定位所需行
4. 随着索引进展，需要丢弃的行数持续增加，导致查询越来越慢

解决方案

尝试1：拆分查询

将原始OR条件拆分为两个独立查询：

1. CreateAt > ?1
2. CreateAt = ?1 AND Id > ?2

结果：每个查询都快了1000倍以上。

尝试2：使用行构造器比较

发现PostgreSQL支持行构造器比较语法：

WHERE (Posts.CreateAt, Posts.Id) > (?1, ?2)

这与原始OR条件在语义上等价，且能让查询优化器使用Index Cond。

优化后查询：

SELECT Posts.*, Channels.TeamId
FROM Posts LEFT JOIN Channels ON Posts.ChannelId = Channels.Id
WHERE (Posts.CreateAt, Posts.Id) > (?1, ?2)
ORDER BY Posts.CreateAt ASC, Posts.Id ASC
LIMIT ?3;

结果对比

• 优化前：24秒，处理309GB数据
• 优化后：34毫秒，处理78MB数据
• 提升：约1000倍

兼容性问题

MySQL不支持行构造器比较的优化，使用该语法反而变慢50倍。因此最终方案是根据数据库类型使用不同查询。

关键学习

1. 使用EXPLAIN时务必添加BUFFERS选项获取详细数据
2. 优先使用Index Cond（MySQL中称Index range scan）而非Filter
3. PostgreSQL和MySQL的行为可能完全不同，需要分别测试

影响范围

此优化已发布在v9.7.0及后续版本，并回移至9.5 ESR（从v9.5.3开始）。

Swift 做Web服务性能很差？还是另有隐情？

本文是对一次基准测试及其后续调查过程的复盘。最初，开发者Axel Roest发布了一个简单的Web服务器性能对比，但测试结果令人费解。深入调查揭示了多层问题，其过程本身比最终性能数据更具启示意义。

测试概述与初步结果

Axel 的测试旨在比较吞吐量、延迟与内存、功耗的关系。他使用了十年前的Intel i3-550硬件，以斐波那契数列计算作为负载，测试了四种技术栈：

1. PHP (FPM + NGINX)
2. Node.js (JavaScript)
3. Helidon (Kotlin/Java)
4. Vapor (Swift)

初步结果是：Helidon 和 Node.js 表现符合预期（吞吐量高、延迟低但资源消耗大），而 Vapor 虽然耗能最少，却过早出现大量请求失败。这似乎“证实”了Swift在Web服务领域性能不佳的刻板印象。

调查过程与关键发现

尽管有人认为结果合理，但Axel和Swift社区的专家们对Vapor的异常表现提出质疑。调查过程中暴露了一系列超越编程语言本身的问题：

1. 逻辑矛盾与基准工具问题：最初，测试报告的成功率与吞吐量数据存在逻辑矛盾（例如，高并发下几乎全部请求成功，但报告的吞吐量却很低），这直接指向了基准测试工具 wrk 本身存在缺陷（如错误报告不准确、连接管理异常）。

2. 第三方库性能低下：测试中用于Swift的BigInt库（attaswift/BigInt）性能远差于其他语言的实现。更换为更优的库（如Numberick）后，Swift的性能立即提升了数倍。

3. 框架与系统层配置：

   • Vapor的连接接受策略：发现Vapor在事件循环中接受新连接的方式与其他框架不同，这影响了在高并发下的表现。
   • 操作系统限制：macOS（及Linux）内核中存在关键的系统参数限制，如单个进程的文件描述符上限和未接受连接队列的最大长度（kern.ipc.somaxconn，默认仅128）。这些限制在高并发测试下极易被触发，导致连接错误。
   • 内核Bug：调查最终发现macOS内核在非阻塞TCP套接字的错误报告和事件通知上存在严重缺陷或错误行为。

4. 测试工具缺陷：使用的wrk工具本身也存在多个bug，包括连接数配置不准、延迟测量不准确以及错误报告混乱。

最终结论与启示

经过一系列修复和优化（更换库、调整Vapor代码、修正系统配置、识别并规避工具和内核问题后），Vapor/Swift 的基准测试结果变得合理，并在吞吐量和能效上表现出色。

但文章的核心结论并非“Swift性能最强”，而是强调：

• 基准测试的价值在于过程而非排名：一个引发深入讨论和排查的测试，远比一个被轻易接受的结果更有价值。
• 系统性问题常被忽略：性能问题往往出在第三方库、系统配置、测试工具乃至操作系统内核等层面，而非应用框架或语言本身。
• 方法论启示：文中通过“不起作用的假设”、“未被重视的线索”、“被误解的变通方法”等案例，强调了在性能调查中保持批判性思维、从基础验证起、仔细审查数据矛盾以及不满足于表面解决方案的重要性。

文章标题的双关语“Swift sucks at web serving… or does it?”既暗示了表面的性能争议，也指向了更深层的真相：我们往往难以仅凭一个基准测试就得出确切结论，而真正的收获在于调查过程中获得的知识与认知。

NetBSD基金会宣布了一项新的开发政策，禁止向NetBSD提交由大型语言模型或类似技术（如ChatGPT、GitHub Copilot）生成的代码。根据该政策，这类代码被推定为受到污染，即版权不明确，不符合NetBSD的开源许可目标，因此不能纳入代码库。该政策已在NetBSD的提交指南中正式发布。

Viking 7B 模型概述

Viking 7B 是由欧洲最大的人工智能实验室 Silo AI 与 图尔库大学TurkuNLP研究组 及 HPLT 联合发布的首个覆盖所有北欧语言的多语言大语言模型（LLM）。这是一款在低资源语言处理方面表现顶尖的开源模型，同时兼顾英语和编程语言的性能，是迈向覆盖所有欧洲语言的先进LLM家族的重要里程碑。

核心特性与优势

• 多语言覆盖：主要支持丹麦语、芬兰语、挪威语、冰岛语、瑞典语等北欧语言，同时覆盖英语和编程语言。
• 性能表现：评估显示，在不损害英语性能的前提下，其在所有北欧语言上的表现达到了同类开源模型中的最佳水平。基准测试包括翻译测试、MMLU、Arc-C、HellaSwag等，困惑度指标也证实了其优越性。
• 模型家族：提供 7B、13B 和 33B 三种参数规模的模型版本。当前训练进度：7B已完成100%，13B为85%，33B为65%。
• 现代架构：采用类似Llama 2的架构，支持Flash Attention、旋转嵌入、分组查询注意力，序列长度为4k。
• 训练数据：使用包含上述语言和编程语言的 2万亿个令牌 的数据集进行训练。
• 开源与许可：在Apache 2.0许可下开源，可用于商业和研究目的。

技术方法与创新

• 训练策略：延续并扩展了Poro模型的方法，专注于提升低资源语言性能。关键策略包括优化预训练架构、调整数据采样（如增加低资源语言数据重用频率），以及融入高低资源语言间的翻译平行文本。这些策略利用了跨语言信号来增强模型对语言关联的理解，从而在不牺牲英语性能的情况下，显著提升低资源语言的表现。
• 文化敏感性：模型设计注重对当地价值观和文化的敏感性，旨在成为数字通信中的连接器而非分隔符，以加强欧洲数字基础设施。

训练基础设施

• 硬件：在芬兰的LUMI超级计算机上进行训练，使用了多达 4096个AMD MI-250X GPU。
• 性能与可持续性：LUMI是欧洲最强大、全球第五强大且最绿色的超级计算机之一。其电力100%来自水力发电，废热约占卡亚尼市区域供热的20%。
• 软件与经验：团队拥有在大规模AMD GPU上训练模型的成熟经验，其开源训练框架在AMD硬件上实现了优异的吞吐量，验证了在弱扩展和强扩展实验中的理论预测。

使用与获取

• 模型获取：完整的模型权重已发布，并承诺在训练过程中定期发布检查点以确保透明度。
• 适用场景：目前发布的研究检查点适用于学术和行业研究。若要用于生产环境，需进行进一步的训练、微调和测试。Silo AI通过其SiloGen平台提供基于SaaS的定制LLM服务。
• 致谢：感谢LUMI/EuroHPC超级计算机运营商（包括AMD、HPE、CSC-芬兰科学IT中心）提供的计算资源和技术支持。TurkuNLP研究人员获得了欧盟地平线欧洲计划HPLT项目的资助。

Elicit – AI研究助手摘要

核心目的： Elicit是一款AI研究助手，旨在帮助研究人员和科学家快速、高质量地进行研究，以应对快速变化的世界，并将AI技术引导向积极影响。

主要要点：

• AI的潜力与挑战： AI有潜力显著改变世界，但其变革复杂，需要谨慎引导以确保积极影响。
• 研究需求： 强调科学严谨性、良好推理和高质量研究的重要性，以适应动态环境。
• 工具功能： Elicit帮助用户理解宇宙奥秘、取得医学突破（如终结疾病）、解决社会问题（如贫困、探索新领域、创建繁荣社区）。
• 用户导向： 感谢用户的好奇心和对真理与进步的承诺，目标是简化寻找真理的过程。

关键功能：

• 支持快速行动而不牺牲研究质量。
• 助力动态研究以保持相关性。
• 应用于科学发现和社会问题解决。

结构概述：

• 背景：介绍AI变革的复杂性。
• 目标：阐述Elicit的构建目的。
• 应用：列举具体研究领域和问题。
• 结尾：致谢用户并表达工具愿景。

文章摘要：Remix 与 React Router 合并

核心公告：React Router v7 已发布，所有新项目推荐直接使用该版本。现有 Remix 应用应准备升级至 React Router v7，仅需更改导入路径。

背景与历史

• React Router 已有 10 年历史，是 React 生态中使用最广泛的路由库之一，承载着数百万个项目（包括 Shopify 核心应用）。
• Remix 作为基于 React Router 的全栈框架已发展近 4 年，提供了自动代码分割、简化数据加载、表单操作、乐观 UI、服务端渲染等先进功能。
• 两者关系紧密，Remix 本质上曾是“React Router 的框架”，且 Remix 的特性已逐步回流至 React Router。

合并原因

1. 项目界限模糊：随着 Remix 引入 Vite 插件和 SPA 模式，其与 React Router 的差异变得难以区分。Remix 作为 React Router 的上层已变得极其精简。
2. 简化升级路径：将 Remix v3 更名为 React Router v7，可将“从 React Router 迁移到 Remix”这一复杂项目，转化为一次简单的“主版本升级”，极大降低开发者心理和实际升级负担。
3. 填补 CRA 空缺：Create React App (CRA) 已停止维护，React 官方推荐使用框架。合并后的 React Router v7 将成为一个强大的、基于 Vite 的现代 React 项目启动方案。
4. 普及高级特性：希望让所有 React Router 用户都能轻松获得 Remix 的核心优势（如 SSR、优化数据获取等）。

合并后的具体变化

• React Router v7 将吸收 Remix 的所有主要特性和架构。
• 升级路径：对于现有 Remix 或 React Router 项目，升级流程预计为：
  1. 升级到当前库的最新次版本。
  2. 启用所有未来特性标志。
  3. 将 @remix-run/* 依赖项替换为 react-router。
  4. 将代码中的 @remix-run/* 导入更改为 react-router。
• 工具支持：官方将提供 Codemod 工具和详细指南，确保升级平滑无痛。
• Remix 的未来：Remix 品牌将继续存在，团队将专注于 React Router v7 的稳定与发布。Remix 包本身将暂时“休眠”，但团队暗示未来有更强大、更以服务端为中心的计划（可能与 React Server Components 深度结合）。

结论

此次合并旨在消除冗余，通过一次主版本升级（从 v6 到 v7）而非跨库迁移，为整个 React 社区提供一个统一、强大且易用的路由与全栈框架解决方案。团队正全力稳定 React Router v7 并推进其发布。

研究概述

麻省理工学院（MIT）的研究团队（包含多名本科生）在银河系“晕”中发现了三颗宇宙中最古老的恒星。这些恒星形成于120亿至130亿年前，正值宇宙首批星系形成时期。该发现为研究早期宇宙和星系演化提供了重要线索。

恒星特征与起源

研究团队将这些恒星命名为“SASS”（小吸积恒星系统恒星）。它们曾属于各自的小型原始矮星系，后被不断扩张的银河系吞噬，如今是其原星系仅存的遗迹。由于SASS恒星位于银河系内，距离更近且亮度更高，它们可作为研究遥远且暗淡的“超暗矮星系”的理想类比，帮助科学家更便捷地了解早期星系的化学演化。

发现方法与过程

该发现源于MIT一门名为“观测恒星考古学”的本科课程。学生们通过分析麦哲伦-克莱望远镜收集的恒星光谱数据，寻找大爆炸后不久形成的恒星特征——即锶、钡和铁等重元素丰度极低。团队最终锁定了三颗此前未被深入分析的恒星，确认其化学元素丰度极低，其中一颗的铁氦比不到太阳的万分之一。

轨道动力学证据

借助盖亚（Gaia）天体测量卫星的数据，研究人员追踪了这三颗恒星的轨道，发现它们均表现出“逆行运动”（运动方向与银河系主盘中的大多数恒星相反）。这一特征结合其极低的化学丰度，有力证实了它们是从外部被银河系吸积而来的古老天体。此外，文献回顾显示另有65颗具备低元素丰度的古老恒星也表现出这种高速逆行特征。

科学价值与未来展望

基于此次发现，团队总结出寻找宇宙最古老恒星的有效策略：筛选低化学丰度恒星并追踪其逆行轨道。研究人员预期该方法能在银河系中找出更多同类恒星，从而进一步完善对宇宙早期星系形成和恒星演化的认知。该研究不仅展示了本科生直接参与前沿科研的教育模式，其成果也已在《皇家天文学会月报》上发表并获得多家媒体的广泛报道。

LDAPjs 项目因维护者收到仇恨邮件而宣布停维

项目停维公告 LDAPjs 项目的维护者 James Sumners 宣布，该项目已被正式停维（decommissioned）。他最初接手该项目是因为它当时缺乏维护，但满足了生态系统的需求，且他此前在某组织工作时所构建的系统曾依赖此项目。

维护者的解释 Sumners 解释，他投入了大量时间处理问题并重构代码，以期让社区志愿者能更轻松地维护。然而，他坦言自己已很长一段时间无法投入足够时间，而一些待解决的问题至少需要一整周的开发时间，他无法为此请假。由于他已离开曾使用该项目的组织很久，且极不可能再次任职需要该项目的岗位，因此长期维护变得不现实。

停维的直接原因 他决定现在停维的直接原因，是于 2024年5月14日 收到了一封充满辱骂且隐含死亡威胁的邮件。Sumners 强调，他无法容忍针对业余项目的虐待行为，尤其不能容忍隐含的死亡威胁。他指出，正是这封邮件的发送者导致了项目的停维。

对用户的建议与未来可能 Sumners 建议用户若需执行 LDAP 操作，应考虑使用更适合此类任务的语言编写网关，他特别推荐了 Go 语言。此外，他表示：

• 如果未来自己确实再次需要该项目，可能会恢复开发，但仍会坚持上述建议。
• 愿意考虑将项目转让给感兴趣的接管者，但前提是该接管者必须至少得到一位 Node.js 核心贡献者 的推荐，且该推荐需经过他本人认识的团队成员的核实。

本文探讨了OpenStreetMap坐标系统的一个关键问题：并非所有数据都严格遵循WGS84基准。WGS84坐标参考系统基于ITRF基准并与地球自转锁定，但由于构造板块运动（如澳大利亚板块每年移动70-80毫米），固定于地壳上的点的WGS84坐标会随时间变化，因此缺乏纪元的WGS84坐标无法保持高精度。

为方便测量工作，许多国家使用与本地板块绑定的静态基准，这些基准在特定时间点锁定。例如：

• 美国使用NAD83
• 澳大利亚使用GDA94（ITRS纪元1994.0）
• 欧洲使用ETRS89（ITRS纪元1993.0）
• 法国使用RGF93（可视为ETRS89）

实际案例表明，OpenStreetMap中的部分高分辨率航空影像采用本地基准而非WGS84。例如：

• 在澳大利亚，使用GDA94坐标的节点与多幅影像对齐，但若使用ITRF坐标则会产生超过1.5米的偏移。
• 在法国，使用RGF93基准的影像与测量标志对齐良好，否则会出现70-80厘米偏移。

这引发了两个主要问题：

1. 部分OSM数据实际未使用WGS84坐标，偏移量可达2米。
2. 如何保证数据随时间的准确性。

文章提出两种应对方案：

• 维持本地基准：简单且能保持影像一致性，但需选定每板块单一基准，并告知数据使用者。
• 转换所有数据至ITRF基准：需借助板块运动模型将本地基准数据转换为WGS84，但实现复杂且易出错。

此外，国家基准更新（如澳大利亚2020年采用GDA2020、美国2022年采用NATRF2022）将导致新旧影像间出现较大偏移。作者建议通过实地测量标志或GNSS天线验证影像的实际基准，并呼吁社区共同完善参考点列表。

终端技术现状概览

本文是作者在Neovimconf 2023演讲的配套文章，探讨了终端技术的历史、现状、面临的挑战及现代解决方案。

历史背景与基础

现代终端模拟器主要源自DEC VT100终端，该终端因支持ECMA-48/ANSI标准而成为事实标准。硬件终端后来被软件模拟器取代，其中1984年开始的Xterm成为新标准，并引入了鼠标跟踪和可配置颜色等扩展功能。

终端应用通过可打印文本和控制码与终端模拟器交互。控制码主要包括：

• C0字符集中的单字节码（如回车\r、换行\n）
• 转义序列：以ESC（0x1b）开头的字节序列，可分为三类：
  • CSI（控制序列引导符）：用于光标移动、颜色设置等
  • OSC（操作系统命令）：用于与外部环境交互（如系统剪贴板、窗口标题）
  • DCS（设备控制字符串）

这些序列易于使用，例如可通过shell命令输出彩色文本。

面临的挑战与现代解决方案

1. 键盘编码问题

传统终端中，修饰键（如Ctrl、Alt）的编码存在歧义和限制。例如，Ctrl+M与回车键无法区分，某些修饰键组合完全不可用。

现代解决方案：采用将按键编码为转义序列的方式，如：

• Xterm的modifyOtherKeys选项
• libvterm作者Paul Evans提出的CSI u编码
• Kitty终端扩展的kitty键盘协议

该协议已被多个现代终端（Wezterm、Alacritty、kitty等）和应用（Vim、Neovim、Helix等）支持，彻底解决了按键编码歧义问题。

2. 装饰与图形能力

现代终端支持：

• 256色及24位真彩色：提供更丰富的颜色选择
• 富文本标记：如删除线、多种下划线样式（支持拼写错误波浪线等）
• 内联图像/视频：存在sixels、iTerm2图像协议、kitty图形协议三种方式，但终端支持不一，应用采用仍不普遍

终端UI的进步也归功于应用和库作者的创新，如charm.sh创建的交互式终端界面。

3. 功能检测问题

传统方法依赖terminfo数据库，但存在诸多问题：版本差异、新终端支持滞后、远程连接时条目缺失。这导致许多终端错误地将$TERM设为xterm-256color，形成恶性循环。

现代改进：

• 大多数现代终端支持的转义序列已趋同
• 应用可通过查询序列检测特定功能支持（如kitty键盘协议），且通过SSH仍有效
• 新TUI库（如vaxis）正转向完全依赖查询而非terminfo

4. 系统集成能力

现代终端通过OSC序列支持系统集成：

• OSC 2：设置窗口标题
• OSC 8：创建可点击超链接
• OSC 9：发送桌面通知
• OSC 52：系统剪贴板交互（复制功能安全，粘贴需用户授权）

剪贴板解决方案：传统Vim在远程会话中依赖X11转发，问题多且依赖性强。OSC 52提供更好方案，允许通过终端直接操作剪贴板，无依赖且远程有效。Neovim 0.10版将默认支持此功能。

总结

终端作为应用平台虽有其古怪特性，但其可移植性、普及性和相对易用性使其持续流行。技术虽老，但仍在不断创新（如改进字形聚类、同步输出、自定义着色器）。终端模拟器将持续演进以解决问题、提升体验，底层平台的持久性是其优势所在。