本文基于神经科学与语言学证据，论证语言在现代人类中主要是一种交流工具，而非思维的基础。核心观点与证据如下：

1. 大脑中的语言网络

• 人脑左侧半球存在一个专门的语言网络，负责词汇加工与句法处理，支持语言的理解与产生。
• 该网络的表征是抽象的（独立于输入/输出模态），且对语义和句法结构敏感。

2. 语言与思维的分离（双重分离）

• 语言并非思维所必需：严重失语症患者（语言能力严重受损）仍能完成数学、逻辑推理、计划、心理理论等多种认知任务。这表明复杂思维可在没有语言的情况下进行。
• 语言也非思维的充分条件：某些遗传或精神疾病（如威廉姆斯综合征、精神分裂症）患者的语言能力相对完好，但存在智力障碍。
• 神经影像学证据：fMRI研究发现，语言网络在非语言认知任务（如数学推理、执行控制、心理理论）中不活跃，这些任务由其他脑网络（如多需求网络、心理理论网络）支持。

3. 语言作为高效交流系统的优化特征

跨语言分析表明，自然语言在多个层面都体现出为高效信息传递而优化的特性：

• 语音层面：音素在语音空间中分散，以增强抗噪性。
• 词汇层面：高频、低信息量的词形更短；词义系统在简洁性与信息量之间达到帕累托最优（如亲属词、颜色词）。
• 句法层面：语言普遍存在最小化依存距离的倾向，以减轻认知负荷；语序类型（如主-宾-动、主-动-宾）的演化也与交流效率相关。
• 歧义性：语言中的歧义并非缺陷，而是交流上有益的特性（如允许使用简短形式、利用上下文）。

4. 结论

语言的主要功能是交流，它是传递文化知识的强大工具。虽然语言的出现无疑重塑了人类文化，但它并非复杂思维（包括象征性思维）的先决条件。语言很可能与我们的思维和推理能力平行进化，反映而非导致了人类认知的独特复杂性。人类文明的累积成就，关键在于语言所实现的跨代知识传递。

生成式AI在电路板设计中的应用测试总结

测试目的

评估前沿大语言模型（GPT-4o、Claude 3 Opus、Gemini 1.5 Pro）在电路板设计这一高精确度任务中的实用性，明确其能力边界与最佳应用场景。

测试任务与结果

1. 基础知识问答

• 任务：询问走线延迟等跨领域基础问题。
• 结果：Claude 3 Opus表现最佳，能准确指出延迟受布线层和材料影响的关键陷阱。Gemini 1.5因受低质量网络内容干扰表现最差。

2. 元器件选型

• 任务：为机器人电机驱动器寻找适合紧凑、抗振动环境的光以太网菊花链元器件。
• 结果：所有模型表现均不佳。未能识别实现菊花链所需的三端口交换机，且推荐了不适用的大型数据中心SFP收发器。LLM倾向于提供“平均”建议，缺乏特定场景的细微考量。

3. 数据手册解析

• 任务：从820页的芯片数据手册中提取引脚表并生成封装代码。
• 结果：Gemini 1.5 Pro凭借大上下文窗口表现最可靠，精准提取引脚信息并生成高准确度的JITX代码。让LLM将提取的数据转化为代码是提升准确率的有效策略。

4. 模拟电路设计

• 任务：设计麦克风前置放大器。
• 结果：模型在架构建议上存在技术瑕疵，生成底层网表代码时常犯信号接错、滥用去耦电容等错误，导致电路无法工作。
• 改进：让模型生成调用高级参数化API的代码效果更好，表明“人类专家构建模块，LLM负责调用”的混合模式更具前景。

核心结论

1. 上下文缺失：互联网设计数据缺乏工程师脑中的设计意图与上下文，导致AI在复杂决策中表现挣扎。
2. 模型优势分化：
   • Claude 3 Opus：最适合解答跨领域问题，辅助学习新知识。
   • Gemini 1.5 Pro：最适合从庞大数据手册中提取数据并生成代码。
   • GPT-4o：在本次测试中表现相对平庸。
3. 工具定位：当前LLM擅长信息提取与代码生成，但在原始设计综合上能力不足。它们应作为辅助人类专家的工具，而非独立设计师。针对网表生成的微调可能会在未来改善这一现状。

• 奖项与获奖者：阿姆斯特丹自由大学计算机科学荣誉教授Andrew S. Tanenbaum因开发MINIX操作系统而荣获ACM软件系统奖。
• MINIX的背景：Tanenbaum于1987年创建MINIX 1.0，旨在配套其教材《操作系统：设计与实现》。该系统是一个基于微内核的小型UNIX系统，代码约1.2万行，适用于当时的IBM PC。
• MINIX的影响：
  • 教学领域：成功辅助教材，影响了多代学生的操作系统原理教学。
  • 对Linux的启发：直接启发了Linux操作系统的设计，后者已成为驱动云服务器、手机和物联网设备的最成功开源操作系统。
  • 其他应用：作为MeikOS操作系统的基础，并运行于流行微芯片中；后续版本MINIX 3.0针对资源受限、嵌入式计算及高可靠性场景设计。
  • 设计范式影响：Tanenbaum对微内核设计的倡导，影响了数代操作系统设计者。
• 开源化：MINIX于2000年成为自由开源软件。
• 奖项详情：ACM软件系统奖授予开发具有持久影响力的软件系统的个人或机构，奖金为3.5万美元，由IBM提供资助。

工具名称： Web Check

核心定位： 一个一体化的开源情报（OSINT）工具，旨在快速获取和检查任何网站的详细数据。

主要功能与价值：

• 目的： 为安全研究人员、开发者或任何对网站技术架构感兴趣的用户提供一个便捷的网站分析平台。
• 特性： 工具整合了多种信息收集与检查功能，用户可以通过一个统一的界面快速执行多项操作。
• 应用场景： 快速评估目标网站的技术栈、安全性配置、服务器信息、DNS记录、相关子域名等关键数据。

获取方式： 该工具以“Show HN”的形式在Hacker News上发布，具体使用方式和访问链接需查看原始发布帖。

互联网档案馆因出版商法律诉讼被迫移除50万本书籍

核心事件：由于去年在与出版商的版权诉讼中败诉，免费在线图书馆互联网档案馆（Internet Archive, IA） 被迫下架约50万本书籍，这对依赖其获取难以触及书籍的读者造成了“毁灭性损失”。

事件背景与诉讼：

• 出版商成功起诉互联网档案馆，指控其“受控数字借阅”（将实体书数字化并借出）侵犯版权。
• 作为回应，互联网档案馆已提起上诉，计划于6月28日进行口头辩论，试图说服美国第二巡回上诉法院推翻原判。

互联网档案馆的立场与辩护理由：

1. 合理使用抗辩：认为其借阅行为符合版权法中的“合理使用”原则，旨在促进教学、研究和学术目的。
2. 无市场损害证据：指出出版商利润持续增长，未能提供证据证明其电子书市场因档案馆的借阅而受损。
3. 技术保护与非商业性：强调使用行业标准技术防止书籍被下载和再分发，且其作为非营利机构，借阅行为是非商业性的。
4. 图书馆使命与社会价值：将此案提升为关乎所有图书馆存续、信息平等获取以及民主社会基石的斗争。认为知识应无论出身地域，都能公平获取。
5. 对原判的批评：认为原审法院错误地将捐赠和小额收入视为商业行为，且未能充分考虑版权法“促进作品广泛可得”的根本目的。

下架行动的直接影响：

• 全球读者受阻：移除导致大量书籍显示“借阅不可用”，仅对有印刷障碍的读者保留访问权限。
• 用户强烈反应：档案馆每天收到大量询问，社交媒体上充斥着用户关于书籍消失的质疑。一份由近1.9万人签名的公开信恳请出版商停止下架。
• 对弱势群体的冲击：信件指出，此举对学者、学生、教育者（特别是资源匮乏社区的）造成负面影响，阻碍学术进步。同时严重打击了低收入家庭、残障人士、农村社区及LGBTQ+等群体，他们可能缺乏本地图书馆或安全获取信息的途径。
• 用户亲述：世界各地用户将IA视为“生命线”，书籍的移除“暂停”或延误了他们的学术进展。对于许多绝版书籍或特定地区的用户，IA是唯一的资源。

出版商的回应：

• 美国出版商协会（AAP）为下架行动辩护，称这是根据法院裁决及互联网档案馆的同意而执行的，旨在纠正其“向全球传输文学作品却拒绝获得必要授权”的侵权行为。

未来走向：

• 互联网档案馆正在等待上诉法院的裁决，过程可能需要数月甚至超过一年。
• 在此期间，IA的其他图书馆服务（如图书数字化保存、馆际互借、公共领域图书借阅等）将继续进行。
• 本案的最终判决被认为将对整个图书馆界及公众信息获取权产生深远影响。

本文是作者在2024年TLA+会议主题演讲的核心观点阐述，旨在论证形式化方法是优秀软件工程实践的关键组成部分，尤其适用于大规模、分布式或关键底层系统的开发。

核心论点：形式化方法能优化工程成本 工程本质是优化时间与金钱。作者认为，形式化方法虽初看成本高，但能通过以下两方面显著节省开支：

1. 减少返工：软件工程的特性（设计与构造常并行）使得设计迭代易转化为代价高昂的实现迭代。形式化设计能提前发现并解决问题，从而减少后期返工。
2. 降低变更成本：一旦系统有用户，变更会因用户对系统行为（包括实现细节）的依赖（海勒姆定律）而变得极其昂贵。形式化设计能更早地完成接口设计，降低后期变更的难度和成本。

适用性与工具选择

• 适用系统：形式化方法并非适用于所有软件。对于需求快速变化或难以形式化的领域（如UI、网站），敏捷开发等方法可能更优。但对于需求相对明确、稳定的大规模系统，形式化设计能大幅降低实现阶段及生产环境中的错误密度和返工。
• 形式化的价值：除了验证实现的正确性，形式化工具（如TLA+）更重要的价值在于加速设计思考、探索优化可能性，并帮助在设计早期权衡正确性与性能，从而构建更快、更优的系统。
• 有用工具：作者根据经验列举了包括规约语言（P, TLA+, Alloy）及其模型检测器、确定性仿真工具（如turmoil）、验证感知编程语言（如Dafny）、数值仿真技术以及白板上的形式化方法（如状态机、决策表）等。

结论 在设计阶段使用工具辅助思考，能显著加速软件开发、降低风险，并从一开始就构建更优的系统。对于从事大规模复杂系统开发的工程师而言，形式化方法应是一项标准的工程实践。

C/C++ 中的自定义常量折叠优化

问题背景

在 Clang 编译器（直到 18.1.0 版本）中，使用 -ffast-math 编译选项时，_mm_sqrt_ps 内置函数的调用会被错误地转换为使用 rsqrtps 指令并辅以两次牛顿-拉弗森迭代来修正精度。这会导致生成的代码比直接使用 sqrtps 指令复杂得多，且可能因 rsqrtps 在不同 CPU 架构（Intel/AMD）上的精度容差问题而引入不一致性。

解决方案与核心挑战

1. 直接方案：使用内联汇编强制选择 sqrtps 指令，以确保生成预期的指令。

   __asm__ ("sqrtps %1, %0" : "=x"(vec) : "x"(vec));
   

2. 新问题：内联汇编会阻止编译器进行常量折叠。即使函数内联且参数为编译时常量，编译器也无法在编译时计算出结果并省略运行时指令。

高级解决方案：自定义常量折叠

为了在保证指令选择的同时允许常量折叠，作者采用了以下策略：

1. 检查参数是否为常量：使用编译器扩展 __builtin_constant_p 在运行时判断参数是否为编译时常量。
2. 分支处理：
   • 如果参数是常量，则调用原始的 _mm_sqrt_ps 函数，让编译器的常量折叠优化生效。
   • 如果参数不是常量，则使用内联汇编确保使用 sqrtps 指令。

关键实现细节

• 向量参数的检查：直接对向量参数使用 __builtin_constant_p 无效（Clang/LLVM 继承了 GCC 的此限制）。必须逐个检查向量中的每个浮点元素。
• 最终代码示例：

  __attribute__((always_inline)) __m128 test(__m128 vec) {
      if (__builtin_constant_p(vec[0]) &&
          __builtin_constant_p(vec[1]) &&
          __builtin_constant_p(vec[2]) &&
          __builtin_constant_p(vec[3])) {
          return _mm_sqrt_ps(vec); // 常量输入，允许编译时折叠
      }
      __asm__ ("sqrtps %1, %0" : "=x"(vec) : "x"(vec)); // 非常量输入，确保指令
      return vec;
  }
  

• 效果：
  • 当参数为常量（如 _mm_setr_ps(1.f, 2.f, 3.f, 4.f)）时，编译器会在编译时计算结果并生成只包含常量数据的代码。
  • 当参数非常量时，生成的代码会正确使用 sqrtps 指令，并且由于分支判断在编译时会被优化，不会产生额外的运行时开销。

结论与展望

通过编写自定义的常量折叠逻辑，开发者可以在使用内联汇编精确控制指令的同时，不丧失编译器原有的优化能力。作者指出，当前对 __builtin_constant_p 不支持向量参数的限制是不必要的，建议 LLVM 社区放宽此限制以简化类似优化的实现。

Farm：基于 Rust 的极速 Vite 兼容构建工具

Farm 是一款使用 Rust 编写的极速 Web 构建工具，全面兼容 Vite 插件生态。其核心设计旨在提供极致的构建性能与丰富的前端工程化支持。

核心功能与特性

• 极致性能：基于 Rust 开发，能够在毫秒级启动 React/Vue 项目，并在大多数情况下实现 10ms 内的热模块替换（HMR）更新。
• 增量构建：默认开启模块级缓存并支持持久化缓存，确保任何未发生更改的模块都不会被二次编译，大幅提升构建效率。
• 局部打包（Partial Bundling）：将项目打包为少量合理的 Bundle 文件，在不丢失缓存粒度的前提下，有效加快资源的加载速度。
• 一致性与兼容性：确保开发环境的预览效果与生产环境的最终产物完全一致，并同时支持传统（ES5）与现代浏览器。

架构与插件生态

Farm 采用完全插件化的架构，内部所有功能均由插件驱动，同时支持 Rust 和 JavaScript 插件，并开箱支持 Vite 插件。

• 开箱即用：原生支持编译 HTML、CSS、CSS Modules、JS/JSX/TS/TSX、JSON 以及各类静态资源。
• 官方插件扩展：通过官方插件可轻松集成 Sass、Less、PostCSS，以及对 Vue、React、Solid 等主流前端框架的支持。
• 高级特性：支持懒编译（Lazy Compiling）和局部打包等进阶构建优化功能。

1955年8月30日，悉尼上空发生一起无人驾驶Auster飞机被击落事件。飞行员Anthony Thrower在Bankstown机场练习飞行时，飞机发动机故障；手动重启后刹车失灵，飞机在风助力下无人起飞，绕机场盘旋后飞向悉尼市区。

飞机失控后，地面紧急响应：警察、消防、救护车及港口消防船均处于警戒状态；母亲们将放学孩子召回家中。军方展开追击：海军Auster飞机率先发现并追踪；空军RAAF的Wirraway和Meteor飞机随后加入。尝试射击过程中，Wirraway的勃伦枪无效，Meteor机关炮卡壳；最终，海军805中队的两架Sea Furies飞机抵达，由飞行员J.R. Bluett和Peter McNay驾驶，在确认飞机无人后开火，约1.5分钟后飞机坠入离岸五英里的海面，时间约上午11:42。

事件引发媒体广泛报道，标题如“飞行中的潜在灾难”；政治家质疑国防效率，民用航空部门展开调查。尽管追击中遭遇初始挫折，但海军和空军最终成功处置，飞机未造成地面伤亡。

HybridNeRF: 高效神经渲染的性能对比与引用

核心性能对比

HybridNeRF 在 Eyeful Tower 数据集上与先前工作进行了对比（所有方法均在单张 NVIDIA 4090 GPU 上进行 2Kx2K 分辨率渲染，展示了 FPS 数据）。对比的关键点如下：

• 兼容性与功能：MERF、3DGS 和 VolSDF*（作者使用 iNGP 加速基元实现的版本）不支持在 HDR 环境下训练模型，因此不支持曝光调整功能。
• 渲染质量与速度：HybridNeRF 的渲染质量略优于 VR-NeRF，同时渲染速度提升了超过10倍。
• 效果建模能力：与那些渲染速度更快的方法相比，HybridNeRF 的结果质量有显著提升，尤其是在建模镜面反射等效果时优势明显。

论文引用信息

该工作已发表于 2024 年的计算机视觉与模式识别会议（CVPR）。完整的引用格式如下：

@InProceedings{turki2024hybridnerf,
  title={HybridNeRF: Efficient Neural Rendering via Adaptive Volumetric Surfaces}, 
  author={Haithem Turki and Vasu Agrawal and Samuel Rota Bulò and Lorenzo Porzi and Peter Kontschieder and Deva Ramanan and Michael Zollh\"{o}fer and Christian Richardt},
  booktitle = {Computer Vision and Pattern Recognition (CVPR)},
  year={2024}
}

Tachyonfx 终端 UI 特效库摘要

Tachyonfx 是一个专为 Ratatui 应用程序设计的特效与动画库。其主要目的是通过组合和分层简单的特效来构建复杂的动画，从而为终端界面带来平滑的过渡和视觉增强。

核心特性

• 丰富的特效库：提供 50 多种独特特效，包括颜色变换、文本动画、几何扭曲，并支持自定义特效。
• 空间模式：支持径向、对角线、棋盘格和有机等模式，用于控制特效的时序与空间分布。
• 特效组合：支持链式调用与组合，以构建高级动画。
• 单元格级精准定位：可将特效精确应用于特定区域或符合自定义条件的单元格。
• 跨平台支持：兼容 WebAssembly 和 no_std 环境，可在浏览器和嵌入式环境中运行。
• 交互式 DSL：提供基于浏览器的 TachyonFX FTL 编辑器，支持使用内置 DSL 实时迭代特效。

关键功能与机制

• 状态化与后处理：特效是有状态的（创建一次，每帧应用），并在 Widget 渲染后对缓冲内容进行转换。
• 组合与编排：通过 parallel（并行）和 sequence（顺序）灵活编排多个特效。
• 单元格过滤 (Cell Filtering)：可根据前景色、特定区域或文本等条件，选择性地应用特效。
• 自定义特效：开发者可通过 effect_fn 闭包或实现 Shader trait 来编写自定义特效逻辑。
• 特效 DSL：支持在运行时通过字符串动态编译特效，支持变量绑定、方法链和复杂的特效组合。

内置特效分类

• 颜色特效：淡入淡出、颜色绘制、HSL 色彩空间偏移、饱和度与亮度调整等。
• 文本与运动特效：文本聚散与溶解、字符演变、方向滑动、扫光、粒子爆炸、双向扩展与拉伸等。
• 控制特效：并行/顺序执行、循环、乒乓播放、延迟、冻结、重映射及单次运行等时间与行为控制。
• 空间模式：径向、菱形、螺旋、对角线、波浪、有机聚散/溶解，以及模式的组合、混合与反转。
• 几何特效：内容平移与缓冲区移动。

配置与兼容性

项目通过 Cargo features 提供灵活的配置选项：

• std 和 dsl（默认启用）。
• ratatui-next-cell（适配 Ratatui > 0.30 版本的 Cell API 变更）。
• sendable（使特效实现 Send trait）。
• std-duration（使用标准库的 Duration 替代自定义 32 位类型）。
• wasm（启用 WebAssembly 兼容性）。

该项目基于 MIT 许可证开源。

查找暴露敏感信息的简单方法

敏感数据暴露是一种漏洞，指软件系统或用户将敏感数据（如API密钥、用户信息、私密文档等）泄露给潜在对手。文章介绍了几种发现此类意外泄露的基本技术。

搜索引擎高级搜索

利用搜索引擎的特殊查询语法（如Google Dork）可精准定位潜在敏感信息。

• 示例查询：filetype:pdf site:hackerone.com "confidential" 用于查找特定域名下包含“confidential”一词的PDF文件。
• 自动化：可通过SERP抓取API自动化查询，但结果仍需人工审核。
• 实际案例：搜索 "contractors" filetype:xls "@gmail.com" site:gov 可发现政府机构承包商列表（含邮箱地址），此类信息可能被用于社会工程攻击。
• 漏洞报告示例：曾发现包含美国军人社会安全号码的PDF文件，以及国防部培训材料中的用户名密码。

GitHub代码搜索

在公共代码仓库中查找意外泄露的敏感数据。

• 凭证文件：查询 path:**/.git-credentials 可查找意外提交的Git凭证文件。
• API密钥：通过查询与API相关的代码片段（如 "static let placesAPI"）可能发现硬编码的API密钥。
• 防护措施：GitHub已内置密钥扫描功能，可自动检测并警告（或撤销）已泄露的合作伙伴服务密钥。

生产环境网站代码搜索

使用 PublicWWW（代码级搜索引擎）在网站中查找硬编码的敏感信息。

• 示例查询："api_key" depth:all 或 "apiKey" depth:all 可用于查找客户端JavaScript中的API密钥。
• 注意事项：部分API密钥本身设计为公开；免费账户结果受限，付费用户可获完整结果及API访问权限。
• 案例：曾发现因客户端API密钥泄露导致的安全问题。

客户端预加载数据检查

一些依赖JavaScript的网站使用预加载状态（JSON或JS对象）传递初始数据，其中可能包含非直观可见的敏感信息（如邮箱地址）。

云存储服务配置检查

AWS S3及其他兼容服务（如Digital Ocean Spaces、MinIO）若配置错误，其存储桶可能对外完全开放。

• 专用工具：包括S3Scanner、Grayhat Warfare（提供API搜索）、OpenBuckets等。

人为泄露因素

敏感信息也可能通过公开渠道（如会议演讲、社交媒体）被主动泄露。一旦信息公开，便失去控制权。

注：文章强调上述技术主要用于安全研究或信息泄露排查，所有发现均需谨慎处理并遵循合法伦理规范。

本文分为两部分，详细介绍了爱因斯坦求和约定（Einsum）的基础知识，并解析了基于 Jax 框架的简单 Transformer 代码实现。

第一部分：Einsum 基础

Einsum 是 NumPy、PyTorch 和 Jax 等科学计算库提供的张量操作 API，利用爱因斯坦求和约定简化多维数组的复杂线性代数运算（如张量收缩）。其优势在于执行速度快、内存效率高且代码具备自文档化特性。

核心语法规则（格式为 输入索引 -> 输出索引）：

1. 相乘：输入数组中重复的字母表示沿该轴的元素相乘。
2. 求和（张量收缩）：在输出索引中省略的字母，表示沿该轴进行求和降维。
3. 重塑/转置：输出索引的字母顺序可任意排列，从而改变输出张量的维度顺序。

通过 Einsum，可以用极简的字符串表达式替代繁琐的数组重塑、广播和嵌套循环，轻松实现矩阵乘法、求迹、转置等操作。

第二部分：Jax Transformer 代码解析

Jax 结合了 NumPy 的语法与函数式编程理念（纯函数、不可变数组），并通过 JIT 编译提升运行速度。文章解析了一个无位置编码的纯解码器 Transformer 实现，核心结构如下：

1. 前馈网络 (FFN)： 采用带有 SiLU 激活函数的门控机制。包含两个并行的线性变换，其中一个经 SiLU 激活后与另一个逐元素相乘，最后再进行线性投影，以增强模型的非线性表达能力。

2. Transformer 块与 jax.lax.scan： 使用 jax.lax.scan 替代传统 for 循环来迭代处理多层网络。这不仅能在底层展开循环以加速计算，还能保持纯函数特性以避免状态突变。每层包含注意力机制、FFN 以及相应的残差连接和层归一化。

3. 多头注意力机制 (Multi-Head Attention)： 该模块大量使用 Einsum 处理高维张量：

   • 线性投影：通过 einsum('bld,dhk->blhk') 将输入投影到多个注意力子空间，生成 Query、Key 和 Value。
   • 分数计算：使用 einsum('blhk,bmhk->bhlm') 计算 Q 和 K 的点积，并除以 $\sqrt{k}$ 进行缩放。
   • 因果掩码：应用上三角掩码将未来 token 的注意力分数设为负无穷，确保自回归生成特性。
   • 加权求和与输出：经 Softmax 获取权重后与 Value 结合，最后通过 einsum('blhk,hkd->bld') 完成最终的线性投影输出。

本杰明·索普：首位专业古英语学者及其遗产

本杰明·索普是首批大规模出版和翻译古英语文本的学者之一，被誉为“首位专业的盎格鲁-撒克逊学者”。他出身背景不明，44岁时在哥本哈根大学师从著名语言学家拉斯穆斯·拉斯克学习，并与玛丽·安妮·奥特结婚，继女艾莉丝曾协助其工作，但索普作为继父要求严苛，导致继女最终出走。

学术贡献与谦逊态度 索普以翻译古英语文本为生，作品涵盖诗歌、法律、诗篇、编年史和布道文，范围广泛。他在《盎格鲁-撒克逊文选》序言中表现出谦逊，承认其初版作品在计划和执行上存在缺陷，旨在推动古英语研究。面对《古英语押韵诗》和《埃克塞特书谜语》等难解文本，他坦承翻译困难，并期待更合适的人选完成诠释。

主要作品列表 索普的著作包括古英语语法、文本编辑与翻译，关键作品按时间顺序如下：

• 《盎格鲁-撒克逊语语法》 (1830)：翻译拉斯克的古英语语法。
• 《凯德蒙释经诗》 (1832)：编辑并翻译《朱尼厄斯手稿》中的古英语诗歌。
• 《盎格鲁-撒克逊文选》 (1834)：学生用古英语散文与诗歌选集，未附翻译。
• 《阿波罗尼乌斯故事》 (1834)：首次编辑并翻译该古英语浪漫故事。
• 《诗篇》拉丁文与古英语版 (1835)：首次编辑《巴黎诗篇》。
• 《英格兰古代法律与制度》 (1840)：两卷本法律文本编辑，仅翻译古英语部分。
• 《埃克塞特书》 (1842)：首次编辑并翻译所有古英语诗歌。
• 《四福音书》古英语版 (1842)：未附翻译。
• 《盎格鲁-撒克逊教会布道文》 (1843-1846)：首次编辑并翻译阿尔弗里克的天主教布道文，至今仍是唯一现代英语译本。
• 《阿尔弗雷德大帝传》 (1852)：翻译传记并编辑古英语《奥罗修斯》。
• 《贝奥武夫》 (1855)：编辑并翻译该史诗及相关文本。
• 《盎格鲁-撒克逊编年史》 (1861)：编辑手稿A至E，附翻译。
• 《盎格鲁-撒克逊时期英国文书》 (1865)：编辑拉丁语和古英语法律文件，仅翻译古英语部分。

学术地位与声誉风波 索普是伦敦古物学会会员，并成为慕尼黑皇家科学院和莱顿荷兰文学学会成员。尽管常被同代学者约翰·米切尔·肯布尔遮掩光芒，他对盎格鲁-撒克逊研究的专业化发展影响深远。

索普的《贝奥武夫》编辑享有声誉，但其身后重印版本出现错误。1879年，荷兰学生G. J. P. J. 博兰德指出1875年第二版中的拼写错误（如将“fyren-þearfe”误作“eyren-þearfe”），并批评其质量。然而，这些错误未见于1855年初版，且因其出现在索普去世后的版本中，其声誉基本未受损害。初版的持久印象使其学术遗产得以保全。

索普于1870年去世，享年88岁，作为古英语研究的先驱，其工作为后世奠定了重要基础。

台积电试验矩形晶圆以提升芯片产量

• 核心动向：全球最大的芯片制造商台积电（TSMC）正在探索新的先进芯片封装方法，试验使用矩形晶圆（基板）替代传统的圆形晶圆，旨在每片晶圆上制造和封装更多的芯片。
• 主要驱动力：此举是为了应对并满足由人工智能（AI）快速发展所推动的巨大算力需求。
• 行业趋势：除台积电外，英特尔（Intel）和三星（Samsung）等大型半导体制造商也在同步测试矩形基板技术。业界正致力于通过创新的封装方法，在单块基板上放置更多芯片组，以进一步释放和提升计算能力。

电子墨水价签破解技术总结

项目背景与目标

作者将商店中常见的电子墨水电子货架标签（ESL）改造为实用的照片相框和状态显示器。通过逆向工程和自定义固件开发，实现了灰度显示、无线图像更新等功能。项目涉及多个设备型号，包括三星/SoluM、DisplayData Chroma、ZBD等系列。

技术挑战与解决方案

1. 逆向工程与固件提取

• Marvell 88MZ100芯片：通过SWD调试接口和UART引导加载程序，提取了QSPI闪存中的完整固件。发现芯片缺乏代码读出保护，固件未加密。
• 引导加载程序分析：识别出应用代码存储在外部QSPI闪存中，通过4KB引导程序加载到RAM执行。交互式UART shell可用于固件读取和调试。
• 自定义固件开发：采用“库化”方法，在原有固件基础上添加新功能，解决了代码空间限制问题（约6KB可用空间）。

2. 电子墨水屏驱动

• 黑白屏驱动：逆向工程了屏幕控制器，实现了基础的黑白显示。
• 灰度显示实现：通过反复试验，开发出适用于室温的4级灰度波形（LUT），解决了灰度显示中的温度敏感和电荷损伤问题。
• 三色屏支持：针对黑/白/黄（BWY）屏幕，开发了复杂的驱动方案，实现了7级灰度加纯黄色的8色显示。通过多阶段驱动策略避免黄色污染。
• 部分屏幕更新：实现了基础的黑白部分更新功能，用于显示下载进度条。

3. 无线通信协议

• 协议设计：基于802.15.4（ZigBee）开发了自定义低功耗协议，支持设备配对、签到和数据传输。
• 多频段支持：针对不同芯片支持2.4GHz（QPSK）和915MHz（GFSK）两个频段。
• 安全机制：实现了AES-CCM加密通信，每个设备使用唯一密钥，通过根密钥派生实现安全存储。
• 功率优化：通过精细的外设电源管理和睡眠模式优化，显著降低了功耗。

支持设备型号

三星/SoluM设备

• 4.2英寸黑白标签：使用Marvell 88MZ100芯片，实现4级灰度显示。
• ZBS242/SEM9110设备：包括版本025和026的2.9英寸标签，使用8051架构的自定义芯片，支持5-6色显示。

DisplayData设备

• Chroma 74：7.4英寸黑/白/黄三色标签，分辨率640×384，支持7级灰度加黄色。
• Chroma 29：2.9英寸黑/白/红三色标签，分辨率128×296，通过多阶段驱动实现5色显示。

ZBD设备

• EPOP50：2.2英寸双稳态LCD，分辨率224×90，仅支持黑白显示。
• EPOP900：3.6×4.8英寸透明LCD，分辨率360×480，驱动复杂，支持黑白和红色区域。

图像处理与压缩

• 图像格式：支持BMP格式，开发了bmp2grays转换工具，支持1-4位深度的灰度图像生成。
• 自定义压缩：实现了背引用压缩算法，平均节省20%的传输数据量。
• 像素打包：针对5色和6色显示，开发了3×5_7和3×6_8等打包算法，进一步节省存储空间。

固件特性

• 照片相框模式：支持多图像自动轮播显示。
• 固件更新机制：实现了OTA无线更新，但更新过程需要保持供电。
• 条形码显示：在UI界面中集成Code128条形码显示，方便设备识别。
• 硬件问题规避：通过看门狗定时器解决了特定硬件缺陷导致的死锁问题。

配套资源

作者提供了完整的固件源代码和预编译二进制文件，包括：

• 三星/SoluM黑白标签固件
• Chroma/ZBD设备固件
• 基站固件（nRF52840实现）
• 图像转换工具
• 设备管理工具

项目展示了如何将商业产品改造为高度可定制的个人电子设备，克服了芯片文档缺失、屏幕驱动复杂、无线协议设计等多重技术挑战。

Arm64EC（“模拟兼容”）是一种新的应用程序二进制接口（ABI），适用于在搭载Windows 11的Arm设备上运行的应用。它允许在同一个进程内混合运行x64代码（通过模拟执行）和Arm64EC代码（以原生性能运行），从而让开发者能充分利用Arm设备的原生速度与性能优势，包括更好的功耗、电池续航以及对AI/ML工作负载的加速。

核心特点与互操作性

• 原生与模拟混合：进程中的Arm64EC代码以原生性能运行，而x64代码则通过Windows 11内置的模拟器执行。
• 遵循x64约定：为确保与x64代码互操作，Arm64EC遵循x64的调用约定、栈使用、数据结构布局和预处理器定义等软件约定。
• 不兼容Arm64：Arm64EC代码与使用不同软件约定的Arm64代码不兼容。
• 系统级应用：Windows 11 on Arm系统本身大量使用Arm64EC，使x64应用在加载时也能获得部分原生性能。

进程与构建时的兼容性

• 进程加载：
  • x64/Arm64EC进程：可加载x64和Arm64EC二进制文件，但不能加载Arm64二进制文件。
  • Arm64进程：只能加载Arm64二进制文件。
  • Arm64X二进制文件（包含两种架构代码）可被以上两种进程加载。
• 构建链接：
  • Arm64EC二进制可链接x64和Arm64EC库。
  • Arm64二进制只能链接Arm64库。

渐进式迁移现有应用 Arm64EC允许开发者逐步将现有x64应用的代码模块从模拟转换为原生，无需一次性全部重编译。通过优先重编译最耗CPU的模块为Arm64EC，可以在每一步以最小努力获得最大性能提升，最终过渡到完全原生的Arm64EC应用。

应用依赖处理

• 使用Arm64EC版本依赖项，也可依赖x64版本依赖项。
• 不可使用Arm64版本依赖项。
• 依赖项中的x64代码将通过模拟执行；应优先将最耗CPU的依赖项迁移到Arm64EC以提升性能。

识别Arm64EC二进制文件

• 文件头检查：使用 link /dump /headers 命令查看最终PE文件（EXE或DLL），若显示 (x64) (ARM64X) 则表示部分或全部代码为Arm64EC。
• 任务管理器：在“详细信息”选项卡的“架构”列中，部分或全部编译为Arm64EC的应用会显示为 ARM64 (x64 compatible)。
• 注意：构建中间文件（OBJ或LIB）可能显示 A641 machine (ARM64EC)，这是内部标识，并非最终PE文件的有效机器类型。

缓存工作原理探索

缓存是位于CPU内部的高速临时存储器，旨在缓解CPU与主内存（RAM）之间的速度差异。其核心作用是将频繁访问的数据和指令副本存储在更靠近处理器的地方，从而大幅提升数据访问效率。

缓存的基础概念

• 缓存行（Cache Line）：缓存以固定大小的数据块（如32、64、128字节）为单位与主内存交换数据，这个数据块称为缓存行。缓存行的大小（空间局部性）直接影响CPU与内存子系统的交互效率。
• 命中与未命中：当CPU请求的数据在缓存中找到时，称为缓存命中（Cache Hit）；反之，则为缓存未命中（Cache Miss），此时需要访问更慢的主内存。编写缓存友好型代码的目标就是提高命中率。

缓存的层次结构与速度

现代CPU采用多级缓存结构（L1、L2、L3），它们在速度、容量和位置上有所不同：

• L1缓存：速度最快（约3个CPU周期），容量最小，通常分为独立的指令缓存（i-cache）和数据缓存（d-cache）。
• L2缓存：速度次之（约10个CPU周期），容量更大。
• L3缓存：速度最慢，但容量最大，通常在多个CPU核心间共享。
• 主内存（RAM）：访问延迟最大（约250个CPU周期）。

缓存的物理位置与演变

缓存从早期位于主板（如486的L2缓存）逐渐发展到完全集成在CPU芯片内部。现代多核CPU架构中，L1和L2缓存通常为每个核心独有，而L3缓存则为核心共享。

缓存的数据放置策略

缓存需要一种策略来决定主内存中的数据应放置在缓存的哪个位置。直接映射缓存是一种简单策略：

• 每个内存地址通过一个映射函数（通常是取模运算）确定其唯一的缓存块索引。
• 为了区分映射到同一缓存块的不同内存地址，缓存中存储了地址的标记位。
• 每个缓存块还有一个有效位，用于指示该缓存块中的数据是否有效。

编写缓存友好型代码的关键实践

理解缓存机制有助于编写高性能代码：

1. 利用数据局部性：

   • 时间局部性：确保被频繁使用的数据保持在缓存中。
   • 空间局部性：尽量顺序访问内存（步长为1）。例如，在遍历C语言中按行存储的二维数组时，逐行遍历（mat[i][j]）比逐列遍历（mat[j][i]）更高效。
   • 由于节点可能分散在内存中，链表的访问模式对缓存不友好。

2. 避免复杂的循环：过长的循环体可能导致循环开始时缓存的数据在循环结束时被替换出缓存，从而在下一次迭代开始时产生缓存未命中。

3. 优化数据结构对齐：

   • C/C++中的结构体会因对齐要求而产生填充字节，导致实际大小大于成员大小之和。
   • 通过合理排序结构体成员（例如将相同或较小大小的成员连续放置），可以减少填充，降低内存占用，从而在单个缓存行中容纳更多数据或实例。

4. 利用编译器优化：现代编译器能进行循环展开、向量化等优化，正确设置编译器标志可以帮助生成更高效的代码。

文章总结：将数据库置于浏览器中会发生什么？

WebAssembly (Wasm) 正在革新浏览器能力，使高性能应用无需外部依赖即可运行。DuckDB Wasm（通过Wasm在浏览器中运行的DuckDB）为此提供了丰富应用场景。本文探讨了其用例，并提供了一个可尝试的实用示例。

Wasm的优势

Wasm允许在浏览器中直接运行用C++或Rust编写的复杂软件（如Figma），实现快速、轻量级部署。浏览器功能不断增强，甚至可通过WebGPU利用GPU资源，支持本地机器学习训练等。对于数据库，DuckDB Wasm的关键优势在于在客户端直接执行复杂分析查询，大幅减少网络延迟和后端基础设施需求，提升响应速度、降低服务器成本，并增强数据隐私（敏感信息无需离开用户设备）。此外，类似Pyodide的项目将Python环境移植到Wasm，进一步减少云依赖。

DuckDB Wasm的当前用途

DuckDB是C++编写的嵌入式数据库，非常适合Wasm环境。其常见应用场景包括：

• 数据湖临时查询：直接在浏览器中探索Parquet、CSV、JSON文件的schema或预览数据样本。
• 仪表板动态查询：交互式控件（如过滤、聚合）在浏览器即时处理，提供更流畅的用户体验。
• 教育工具：创建自包含的SQL学习环境或浏览器内SQL IDE。
• 新兴应用：客户端数据转换、离线分析工具，以及与Origin Private File System (OPFS)集成实现高性能持久化存储（数据库状态可在浏览器重启后保留）。DuckDB Wasm还可作为中小型数据集的计算引擎。例如，lakeFS、Evidence和Count等公司已集成DuckDB Wasm以提升性能。

如何开始使用DuckDB Wasm

要集成DuckDB Wasm，可使用@duckdb/duckdb-wasm包。通过Web Workers实例化数据库，确保复杂查询不阻塞UI线程。基本步骤包括：

1. 选择并加载Wasm捆绑包。
2. 创建Worker和AsyncDuckDB实例。
3. 实例化数据库后，创建连接并执行SQL查询。

示例代码展示了如何实例化数据库、注册远程文件（如Parquet）、执行查询（如parquet_metadata()）和导出结果为CSV（通过COPY命令）。结果可通过浏览器文件系统下载，实现无服务器数据管道。

Firefox扩展示例

本文展示了一个Firefox扩展：当鼠标悬停在GCP Cloud Storage中的Parquet文件上时，显示其schema。该扩展使用DuckDB Wasm直接查询远程文件的元数据，无需下载整个文件。核心代码包括：

• 在Web Worker中初始化数据库。
• 处理查询结果并提取列名。
• 通过悬停事件触发parquet_metadata()函数查询schema，解析URL获取文件路径。

MotherDuck与未来展望

MotherDuck UI使用DuckDB Wasm处理本地数据，减少云通信，实现“1.5层架构”（客户端和云处理结合）。其Wasm SDK支持开发者构建数据驱动应用。随着Wasm发展，DuckDB Wasm有望推动更复杂的浏览器内数据应用，为数据专业人员提供高效分析工具。

总体而言，DuckDB Wasm通过在浏览器中直接执行SQL查询、支持多种数据格式、持久化存储和高效元数据检查，正重塑Web应用中的数据分析范式。

Envelope 环境变量管理工具

Envelope 是一款现代的环境变量管理命令行工具，用于创建、管理和切换不同的环境配置（如开发、测试、生产环境），并将所有配置存储在一个名为 .envelope 的本地 SQLite 数据库文件中。

核心功能与命令

环境与变量管理

• 初始化 (init)：在项目目录初始化 .envelope 数据库。
• 添加 (add)：向指定环境添加变量。变量名会自动转为大写，支持通过 --stdin 安全输入敏感值。
• 列表 (list)：列出所有已保存的环境，或查看特定环境的所有变量。支持表格化美观输出 (--pretty-print) 和多种排序选项。
• 删除 (delete)：软删除变量（可恢复）或整个环境。
• 丢弃 (drop)：硬删除环境及其所有变量和历史记录，不可恢复。
• 复制 (duplicate)：复制一个现有环境到新环境，便于创建备份或基础配置。
• 编辑 (edit)：在默认文本编辑器中交互式编辑当前环境的变量。

变更追踪与恢复

• 历史 (history)：查看特定变量键值的完整修改历史，包括已删除的值。
• 回滚 (revert)：将变量回退到上一个历史值。可多次执行以逐步回溯。
• 差异对比 (diff)：对比两个环境之间变量的差异（值不同、仅在一方存在等）。

安全与加密

• 锁定 (lock)：使用密码加密 .envelope 数据库文件。
• 解锁 (unlock)：使用密码解密数据库以进行操作。

执行与集成

• 运行 (run)：使用指定环境的变量执行命令，无需手动导出到当前 Shell。--isolated 选项可确保子进程只继承这些变量。
• 导入 (import)：从 .env 文件或标准输入 (stdin) 导入变量到环境。
• 检查 (check)：检查当前 Shell 中导出的变量与哪个已存储的环境完全匹配。

主要特点

• 软删除与完整历史：变量被“删除”后仍保留在数据库中，便于查看历史和恢复。
• 环境隔离：轻松在不同环境（dev, staging, prod）间切换。
• 安全设计：支持加密数据库、通过标准输入添加敏感值、建议将 .envelope 文件加入 .gitignore。
• 多种安装方式：支持 Homebrew、二进制下载、Cargo（Rust）或从源代码构建。

典型工作流程

1. 项目设置：在项目中运行 envelope init，导入现有 .env 文件，并将 .envelope 添加到 .gitignore。
2. 日常开发：使用 envelope run dev -- your_command 运行程序，或导出变量 export $(envelope list dev) 后操作。
3. 环境配置：使用 duplicate 从现有环境创建新环境（如从 prod 复制出 staging），然后用 edit 或 add 修改特定变量。
4. 部署前检查：使用 diff 对比生产环境与待部署环境的差异，使用 history 审计关键变量的变更历史。
5. 安全维护：对敏感项目使用 envelope lock 加密数据库，并定期使用 --stdin 输入机密信息。

安全最佳实践

• 务必将 .envelope 数据库文件排除在版本控制（如 Git）之外。
• 在共享环境或提交代码前，使用 envelope lock 加密数据库。
• 利用 history 命令进行审计和故障排查。

《Opus Magnum》24小时解谜挑战赛概览

赛事背景与目的

• 核心理念：测试“赶工是否等于粗糙工程”，在游戏《Opus Magnum》中以低风险场景验证。
• 游戏简介：《Opus Magnum》是一款工程解谜游戏，玩家需设计机器完成炼金任务。
• 挑战形式：在限定时间内解决大量程序生成的可解谜题，推动自动化解题工具（Bot）开发或团队协作破解。

赛事安排与关键日期

• 测试样本：已提供100个样例谜题（来自玩家“panic”的生成程序）及Python解析库（om.py）。
• 预赛测试（2024年6月2日）：
  • 发布1000个新谜题，开放24小时提交解决方案。
  • 用于测试端到端流程（谜题发布→方案提交→自动评分）。
• 正式挑战（2024年10月20日）：
  • 同样发布1000个谜题，24小时内完成。
  • 参赛者需提交解决方案文件（.zip），系统自动评估成本（Cost）、周期（Cycles）、面积（Area） 三项指标。

主要参与者与策略

1. 自动化解题器（Bot）开发

• 历史参考：玩家“gtw123”曾于2018年展示可生成游戏内解决方案的Bot（开源代码）。
• 本次差异：挑战仅需生成“蓝图”方案文件，无需处理UI交互，可大幅提速。
• 目标：鼓励创新算法，追求更优的指标得分，而非简单复用现有Bot。

2. 人类团队协作（Team Nobots）

• 发起人：玩家Zorflax组建“Team Nobots”，力图纯靠人类战胜机器。
• 难点分析：
  • 人类UI操作耗时：单个复杂谜题优化可能需30秒至1分钟，1000个谜题需数十小时。
  • 认知负荷：若进一步优化指标（如成本/区域优化），方案复杂度上升，时间成本可能达数百小时。
  • 合理规模：需至少10-100名熟练玩家全天候协作。

3. 混合策略

• 模组辅助：利用游戏模组扩展功能（如宏指令、快进），提升人类效率。
• Bot优化：例如GrimBOT可自动精简方案（移除冗余部件）。
• 人机协同：Bot筛选“可优化谜题”交由人类重点攻关，提交混合方案以提高综合得分。

评分机制

• 基础分：每个谜题的每个指标（成本/周期/区域）提交即得1分。
• 优化分：在该指标上与所有提交方案的最优值比较，得分=1+（最优值/本方案值）。
• 总分计算：3000个评分单元（1000谜题×3指标），总分范围3000-6000分。
• 允许策略：同一谜题可提交多个不同优化目标的解决方案，分别评估。

预期结果与社区交流

• 结果公布：优先发布积分汇总表，具体方案细节可能后续公开。
• 社区平台：讨论预计集中于Discord和Reddit。
• 长期展望：若Bot技术成熟，未来可能类似“AI象棋竞赛”，衍生出结果集锦视频等内容。

谜题设计说明

• 标准化：所有谜题均支持全指令与机械臂类型，无特殊限制（如禁止三键键合）。
• 生成方式：由panic的程序批量生成，确保可解性但非“锦标赛级”复杂设计。

总结：该挑战以游戏为平台，探索自动化解谜与人类协作在限时压力下的表现，通过量化评分推动技术创新与社区参与。