“电子表格就够了”：通过熟悉工具理解AI

本文介绍了一个激进的理念：用Excel实现GPT-2模型，以证明复杂的AI概念可以通过熟悉的工具（电子表格）来理解和掌握。作者延续这一 approach，旨在让复杂的AI话题变得易于理解，同时避免过度简化。

核心理念与课程推广

该理念的起源是为了降低AI学习的门槛。作者推出了一个名为 “电子表格就够了”的LLM架构课程，旨在帮助忙碌的STEM专业人员在几小时内快速理解大型语言模型的工作原理。课程聚焦于AI如何工作及其背后的强大理念，力求直观易懂。文中引用了学员的正面评价，表明该课程有助于理解此前难以掌握的核心概念。

相关博客文章概述

文章列出了多篇相关的博客内容，反映了作者在AI可及性、工具化和实践应用方面的思考：

1. AI工作流与工具化：讨论了像“View Source”之于网页开发一样，通过开源和直观工具（如HTML/JavaScript）民主化AI工作流的构建、扩展和分享。
2. 基准测试与代理：提到了针对MCP代理的基准测试“Live MCP 101”，以及对AI工作流程实用性的关注。
3. AI的实际应用与挑战：探讨了企业AI投资回报率问题，以及将AI工作流从个人使用扩展到团队共享的重要性。
4. 技术见解与评论：涉及对DeepSeek R1-Zero模型、FLOPs基础指标的分析，以及LlamaCon会议的观察。

模型实现方式

该理念的具体实践是：“电子表格就够了”LLM架构课程 使用纯JavaScript和Excel函数实现了GPT-2（一个早期的GPT模型）。这使得学习者可以从浏览器或Microsoft Excel内部直接观察一个真实AI模型的运作，将抽象概念可视化、具象化。

总结：文章的核心是倡导通过电子表格等普及工具来解构和教授复杂的AI技术，旨在提升技术理解的深度和广度。作者通过具体课程、系列博客文章以及GPT-2的电子表格实现，系统地展示了这一理念的可行性和价值。

逆向工程汽车钥匙遥控信号

项目背景与动机

作者出于对无线电通信协议的好奇，利用RTL-SDR和Flipper Zero等设备，对汽车钥匙遥控器的无线信号进行了逆向工程分析，旨在探索其通信协议、解码数据并尝试信号重放攻击。文章详细记录了从基础射频概念到完整信号解析的全过程，并指出大多数汽车并非轻易就能通过重放攻击被盗（本田除外），以此回应相关设备的争议。

使用的硬件

1. RTL-SDR：一个廉价的USB电视棒，因其使用的RTL2832U芯片支持软件定义无线电，可直接获取原始I/Q数据，从而接收和分析24 MHz至1750 MHz范围内的任何无线电信号，是一个强大的射频接收与分析工具。
2. Flipper Zero：一个集成了多种无线模块的设备。其搭载的CC1101芯片是一个Sub-GHz收发器，支持低于1 GHz的常见消费级设备频率，可用于发送信号。与RTL-SDR相比，它无法直接分析原始射频信号，但具备信号发射能力。
3. 硬件对比：RTL-SDR（RTL2832U）专注于接收和分析原始信号；Flipper Zero（CC1101）是一个收发器，但其接收功能依赖于预设的射频参数，无法进行原始信号分析。

射频基础概念（简要）

• 频率：载波每秒振荡的次数，决定波长和通信信道。
• 调制：将数据表示到载波上的方式。常见类型有AM（调幅）和FM（调频）。
• 带宽：已调制射频信号占用的频率范围，影响数据承载能力。

信号分析与解码过程

1. 信号发现与可视化

使用SDR#软件将RTL-SDR调谐至433.92 MHz（欧洲及周边地区常用的未规管频率）。观察发现，每次按下钥匙按钮都会产生3个连续的短信号突发。频谱显示在中心频率两侧有两个主要峰值，这与2-FSK（二进制频移键控）调制方式吻合，即用两个不同频率分别表示二进制“0”和“1”。

2. 实用解码分析

使用Universal Radio Hacker软件对信号进行录制和分析。通过录制多个重复信号，URH自动检测到调制参数（如50样本/符号，FSK）。分析显示信号包含5个部分：一个无数据的长突发（可能是唤醒序列），以及4个数据包。

3. 协议逆向工程

• 编码识别：通过尝试不同解码算法，发现Manchester编码能正确解码数据，将0x55（01010101）转换为空值，数据结构更清晰。
• 信号结构：每个按键信号包含：
  1. 一个长唤醒突发。
  2. 三个相似的滚动代码数据包（每个包含递增ID、命令、滚动代码、校验和等）。
  3. 一个较短的最终数据包。
• 关键发现：
  • 滚动代码：为防止重放攻击，系统使用加密算法生成随每次操作变化的滚动代码。信号中高熵部分即为此代码。
  • 递增ID：在滚动代码前的一个字节随每次按键递增，很可能是滚动代码系统的计数器。
  • 命令字节：比较锁定和解锁信号，发现了一个字节用于标识命令（如8代表解锁，4代表锁定）。
  • 校验和：数据包末尾字节变化随机，通过与相邻字节进行XOR运算得到恒定值，证明其为校验和。该计算排除了数据包开头的同步字。
  • 同步字：数据包开头的两个字节在计算校验和时被排除，用于接收端同步。

结论

作者成功逆向工程了一个汽车钥匙遥控器的无线信号，完整解析了其协议结构，包括同步字、递增ID、命令、滚动代码和XOR校验和。文章最后暗示，未来计划在Flipper Zero上集成对该信号格式的支持，以实现读取、序列化和重放功能。

LaVague：用于自动化Selenium浏览的开源大动作模型

项目概述

LaVague 是一个面向开发者的开源框架，用于创建能够自动化浏览器流程的 AI 网页代理。它通过接收目标指令（例如“打印Hugging Face Diffusers库的安装步骤”），自动生成并执行一系列网页操作来完成任务。

核心架构

LaVague 代理由两大核心组件构成：

1. 世界模型：接收目标指令与当前网页状态（当前页面），输出一套适当的行动指令。
2. 动作引擎：将指令“编译”为可执行的动作代码（如Selenium或Playwright代码）并执行。

专属工具：LaVague QA

基于LaVague框架构建的 LaVague QA 是一个专为QA工程师设计的工具，能够将Gherkin规范自动化转化为易于集成的测试，旨在提升网页测试效率十倍。

主要特性

• 内置配置与可定制化
• 用于性能测试与基准测试的测试运行器
• 令牌计数器（用于估算使用量与成本）
• 日志工具
• 可选的交互式Gradio界面
• 调试工具
• Chrome浏览器扩展

支持的浏览器驱动

LaVague支持三种驱动：

• Selenium WebDriver
• Playwright WebDriver
• Chrome扩展驱动

不同驱动对功能的支持存在差异（例如，仅Selenium当前完全支持无头代理、处理iframe及多标签页功能）。

快速入门

通过pip install lavague安装后，可使用Python代码快速创建代理：

from lavague.core import WorldModel, ActionEngine
from lavague.core.agents import WebAgent
from lavague.drivers.selenium import SeleniumDriver

selenium_driver = SeleniumDriver(headless=False)
world_model = WorldModel()
action_engine = ActionEngine(selenium_driver)
agent = WebAgent(world_model, action_engine)
agent.get("https://huggingface.co/docs")
agent.run("Go on the quicktour of PEFT")
agent.demo("Go on the quicktour of PEFT")

注意：示例默认使用OpenAI API，需在本地环境中设置有效的OPENAI_API_KEY。

成本与数据收集

• 运行成本：依赖于所选LLM模型（默认为OpenAI的GPT-4o）、目标复杂度及交互网站。框架提供工具来跟踪令牌使用并估算成本。
• 数据收集：LaVague默认收集匿名使用遥测数据（如版本、动作序列、URL、执行结果等），旨在构建用于改进大型动作模型的数据集。收集时绝不应包含个人信息。用户可通过设置环境变量LAVAGUE_TELEMETRY为"NONE"来完全关闭数据收集。

支持与贡献

• 支持：遇到问题可查阅故障排除指南、在GitHub提交Issue或在Discord频道留言。
• 贡献：项目通过GitHub Issues公示任务，鼓励社区成员通过评论认领、讨论并提交PR的方式参与贡献。

在罗马数字中，4通常写作“IV”。然而，在许多使用罗马数字的钟表表盘上，4点位置却普遍使用“IIII”而非“IV”。关于这一现象，存在多种解释。

一种理论认为，14世纪末的法国国王查理五世曾要求制表匠将“IV”改为“IIII”，因为他认为“IV”会带来坏运气，其构成是从他的头衔数字5（V）中减去1（I）。另一种说法指出，最早于14世纪末在英国建造的“威尔斯大教堂”的钟就采用了“IIII”的写法，并由此成为惯例。也有观点认为“IV”容易与“VI”混淆，且与对称位置的“VIII”在视觉上更平衡。

历史上，在17世纪之前的欧洲中世纪，普遍使用“IIII”而非“IV”来表示4。事实上，17世纪前制造的机械塔钟上常可见到“IIII”。

最流行的理论则侧重于设计美观：在放射状表盘上，“IIII”的外观显得更加平衡，这一设计惯例因此在钟表行业延续至今。看似熟悉的钟表数字，背后也有其独特的历史。

芬兰宣布建造工业规模的“沙电池”，容量达100 MWh，输出功率1 MW，可为当地提供一周的冬季供暖。该电池由Polar Night Energy开发，尺寸为高13米、宽15米，比2022年运行的试点电池（高4米、宽7米，功率100 kW，容量8 MWh）大约10倍。

沙电池利用电网多余电力（如可再生能源高峰时的廉价电）通过热交换器加热沙子存储热能，能量损失极少，可存储数月。最有效的方式是直接使用热能，而非转换回电能。在芬兰Pornainen市，该电池将集成到Loviisan Lämpö公司运营的区域供热系统中，通过管道网络为住宅、建筑和游泳池供暖。

新电池预计可满足Pornainen冬季一周或夏季一个月的供暖需求，每年减少160吨二氧化碳排放，相当于碳排放降低近70%。沙子材料采用破碎的滑石，这是当地工业的副产品，可持续采购且导热性优于普通沙子。

沙电池可能不适用于无区域供热的地区，但可作为气候变化应对工具的一部分，与锂离子电池、重力电池、熔盐电池等电网级存储技术并列。新电池预计在13个月内完成建设和测试。

文章摘要：现代Web体验退化与开发者的责任

作者反思其技术文章常显负面的原因，并非刻意为之，而是源于对现代Web体验普遍退化（“jank”）的深切忧虑。文章核心观点如下：

• Web体验的矛盾发展：作者承认，顶级Web应用（如邮件、文档处理）的功能和质量远超以往，但大量普通网站的用户体验却在下降。浏览器本身是强大的软件，能高效处理HTML页面和表单，但现代网站常通过开发者干预破坏其默认、可靠的交互行为。
• 问题根源：作者认为，导致网站不稳定、难用的主要原因，是开发者过度自定义并干扰了浏览器的原生功能。例如，破坏“后退”按钮的行为、丢失表单填写数据等。这些问题让习惯基本Web交互的普通用户（如作者父亲）感到困惑和挫败，但技术用户却可能学会避开或调试。
• 原生功能的价值：作者强调，利用浏览器默认遵循的链接点击、表单提交、输入填充等行为，能构建出稳定、符合用户预期的基础体验。采用“渐进增强”的方式构建基础功能（如用复选框和提交按钮实现日历），通常能提供更可靠的服务并减少支持成本。
• 情感动机：作者写作风格虽显严厉，但源于对Web的关切和失望。他无法对不断出现的、破坏基本交互的网站保持沉默，因为这些“自摆乌龙”的设计失误本可避免，并直接损害了用户体验。

总之，作者呼吁重视Web的基础性、可靠性，并对开发者随意破坏浏览器默认交互模式的做法提出批评，其最终目的是希望Web能更好地为所有人服务。

赢得黑客马拉松，却失去理智

几周前，我和朋友Ben在塔夫茨大学的JumboHack黑客马拉松中获胜。我们的项目通过爬取塔夫茨的餐饮计划门户，生成类似Spotify Wrapped风格的学生餐饮习惯总结。通过Ben的巧妙推广，几天内就有数百名学生使用它。我们赢得了总赛道、“最完整项目”奖及全部奖项。

技术背景与挑战

塔夫茨大学使用一家名为Atrium的公司提供的软件（其专利已过期），该软件自称非“遗留”系统，但实际上充满问题。塔夫茨将其称为“JumboCash”，但通过URL参数（如cid）可切换至其他学校门户，安全性存疑。

主要技术难题与解决方案

1. 会话密钥与访问控制：

   • 会话密钥作为URL参数存储，虽设置cookie但被忽略，导致可通过URL复制访问。
   • 为避免让学生复制URL，我们利用JumboCash的“访客访问”功能：学生添加guest@jumbo.cash为访客，我们通过拦截邮件获取密码并登录。

2. 数据获取与处理：

   • 交易历史可通过CSV导出，简化了爬取过程。
   • 但需要根据学生姓名（仅提供法律姓名）查找其邮箱。我们通过公开目录的JSON API尝试匹配，尽管遇到首选名与法律名不符、分页损坏等问题，仍通过尝试多种格式近似匹配。

3. 登录机制：

   • 登录需两步HTTP请求：首先POST发送用户名和密码创建会话密钥，然后GET请求“激活”该密钥，否则系统处于“半登录”状态。
   • 开发中因工具（HTTPie）隐式执行JavaScript导致调试耗时，最终发现需手动触发第二步请求。

4. 安全漏洞与隐患：

   • 系统存在多项设计缺陷，如访客可自行提升权限、禁用访客后仍可重新启用。
   • 中间页面的JavaScript虽检查浏览器功能，但代码存在潜在风险（如XSS），但由于时间限制未深入探索。

推广与成果

• 项目界面设计模仿Spotify Wrapped和Instagram Stories风格，响应式但适配有限。
• 通过在校园张贴海报、在Sidechat匿名发帖模仿用户，迅速吸引数百名学生使用。
• 最终项目赢得比赛，获得奖品（如AirPods），并验证了技术实现的可行性。

总结

项目成功结合了逆向工程、数据爬取与创意设计，但过程充满技术挑战，尤其是与过时且不安全的遗留系统交互。尽管最终获胜，但开发过程的曲折体现了黑客马拉松的“理智与疯狂”并存。

Nanos – A Unikernel

Nanos 是一个 unikernel，专注于提升代码执行速度。最新基准测试显示，Nanos 在服务静态内容时性能几乎达到 Linux 的两倍。测试在 Google Compute Engine 上使用 Go 语言（net/http）进行，配置为 1 个虚拟 CPU。该项目仍处于早期阶段，未来还有更多优化空间。

BreakTime: 在Google日历中运行Breakout游戏

这是一个在Google日历界面中运行的经典Breakout（打砖块）游戏的Chrome扩展项目。游戏中的“砖块”是用户的日历会议，球拍由用户控制，目标是击碎（并可选自动拒绝）这些会议。项目代码量约1500行JavaScript，无外部依赖。

灵感与原型

项目灵感源于iOS快捷指令API，作者发现可以通过移动日历事件来创建动画，从而萌生了在日历中嵌入游戏的想法。一个关键建议是让游戏能够实际拒绝被击碎的会议。初期原型利用浏览器的getBoundingClientRect获取日历事件元素的坐标，使用简单的矩形碰撞检测和setInterval循环驱动小球移动，虽粗糙但足以在社交媒体上引发关注并吸引谷歌官方注意。

碰撞检测的优化

为提升游戏体验，作者实现了更精确的圆形与矩形碰撞检测。核心算法是找到矩形上距离圆心最近的点，若该点到圆心的距离小于半径则判定碰撞。关键挑战在于确定小球的反弹方向，特别是处理角落碰撞和边缘情况，这需要精细的逻辑来避免不自然的反弹行为。

增强游戏“质感”

为了改善视觉效果和增加游戏的“生动感”（Juice），作者添加了多项效果：

• 粒子效果：当会议被击碎时，会根据会议颜色生成碎片粒子动画。
• 屏幕震动：在碰撞时触发短暂的随机位移，增强冲击感。
• 动态颜色：小球颜色随时间变化，碰撞时变化加速。
• 物体缩放：小球和球拍在碰撞时会有缩放动画。
• 运动轨迹：小球会留下逐渐消失的路径尾迹。
• 界面优化：添加了游戏元素滑入动画，并在屏幕底部区域添加模糊效果以避免该区域的碰撞。

动画流畅性改进

最初的setInterval方案导致动画不够平滑。作者改用requestAnimationFrame，根据每帧的时间差（deltaTime）计算移动距离，使动画更流畅并与显示器刷新率同步。

实现会议拒绝功能

通过MutationObserver监听日历对话框的出现，模拟点击“拒绝”按钮来实现自动拒绝会议。此过程需要处理逐一拒绝、没有拒绝选项的事件、以及循环事件等特殊情况。由于基于按钮文本识别，该功能目前仅支持英文界面的Google日历。

从书签工具到Chrome扩展

项目最初设计为可粘贴至浏览器控制台的书签工具代码。在获得积极反响后，作者将其开发为Chrome扩展并成功上架。扩展的审批过程迅速，且其仅在用户主动触发时运行，权限要求简单。

项目总结

作者认为该项目乐趣十足，不仅因为将游戏嵌入了非常规平台，更因为游戏机制与平台（日历）的特性（管理会议）产生了有意义的结合。通过自行构建游戏引擎，作者深入理解了碰撞检测和DOM操作。项目获得了社区和谷歌官方的关注。

《Algorithms for Modern Hardware》是Sergey Slotin撰写的一本关于高性能计算的书籍。其目标读者广泛，包括性能工程师、算法研究人员以及希望学习比单纯降低渐近复杂度更实用的程序加速方法的计算机科学本科生。本书内容托管在GitHub上，代码仓库独立。这是一个非协作项目，但作者欢迎贡献与反馈。

书籍规划与发布： 本书计划分部分依次完成，各部分之间有较长间隔。

• 第一部分：性能工程（截至2022年3月约完成75%，计划2022年夏完成95%以上）。内容涵盖计算机架构基础与单线程算法优化，涉及缓存、SIMD、流水线等主题，以C++为例并包含大量案例研究。预计页数为450-600页，目标发布日期为2022年第三季度。
• 第二部分：并行算法（计划2023-2024年发布）：涉及并发、并行模型、OpenMP、CUDA、锁无关数据结构等。预计页数为150-200页。
• 第三部分：分布式计算（发布日期待定）：涵盖网络、消息传递、MapReduce、分布式数据库等。
• 第四部分：软件与硬件（发布日期待定，完成可能性较低）：涉及LLVM IR、编译器优化、FPGA、ASIC等。

书籍状态与发行： 对于开源书籍，“发布”意味着完成所有核心章节、基本确定目录、完成最终编辑、绘制插图并生成优化PDF。电子版和印刷版计划以“随意支付”模式销售，网页版将始终免费提供。

支持与参与：

• 修正错误：欢迎通过直接编辑GitHub、创建Issue、联系作者或在讨论平台留言等方式报告错误。
• 财务支持：受作者个人情况限制，目前无法接受预订或财务支持。鼓励通过分享和帮助修正拼写错误来支持本书。
• 翻译：网站支持翻译管理，已有意大利语和中文的翻译意向。建议待第一部分完成后再启动系统翻译，但鼓励自行翻译并分享链接。作者指出，俄语网站上的文章主要关于经典算法，而非高级性能工程。

写作目标与教学意义： 本书的一个重要目标是改变大学算法设计教学方式。作者认为，现代硬件已发生巨大变化，渐近复杂度不再是唯一决定因素，许多课程却仍停留在旧有模式。他希望本书能成为首部全面的教材，推动性能工程作为算法导论后的核心课程。完成主体部分后，作者还将致力于开发配套的课程材料与工具。

第一部分（性能工程）内容概览： 第一部分详细规划了从第0章（前言）到第12章（数据结构案例研究）的目录，主要章节包括：

• 复杂度模型（现代硬件、编程语言、计算模型）
• 计算机架构（指令集架构、汇编语言等）
• 指令级并行（流水线风险、分支代价、指令调度等）
• 编译（编译阶段、编译器优化与局限）
• 性能分析（插桩、统计分析、基准测试）
• 算术（浮点数、整数运算、位操作）
• 数论（模逆、蒙哥马利乘法、哈希、随机数生成）
• 外部存储器（内存层次、外部排序、缓存无关算法）
• 内存与CPU缓存（内存带宽与延迟、缓存行、预取等）
• SIMD并行（内部函数、向量化类型、寄存器内操作等）
• 算法案例研究（如二进制GCD、整数因式分解、快速傅里叶变换、排序等）
• 数据结构案例研究（如二分搜索、静态B树、线段树、哈希表等）

书中列出了众多预期的性能提升示例，例如：比std::gcd快2倍的二进制GCD、比std::lower_bound快8-15倍的二分搜索、比朴素实现快100倍的矩阵乘法等。

技术选择与致谢： 书中的示例主要使用C++、GCC、x86-64、CUDA和Spark，但所传达的原则具有普适性。作者表示对这些技术选择并非完全满意，仅因其目前最广泛稳定。书中大量内容基于众多研究者的工作、博客文章、论文和演讲，作者在致谢部分列出了相关贡献者。

项目动机

作者在生成艺术作品中希望使用文本，但避免使用字体。浏览器中的“web safe”字体可能产生不一致的结果，包含字体文件会增加文件大小，且作者希望所有视觉元素都是自己创建的。因此，作者使用p5.js和JavaScript创建了自定义的基于路径的字母表。

字体基础与字母定义

作者研究了字体的基本概念，如x高度和大写高度。字母围绕中心点（mid_x和mid_y）定义，使用Letter类管理关键位置（如x高度、大写高度），这些位置与字体大小相关。例如，从基线到顶部的全高等于字体大小，y_mid到y_x为全高的三分之一。作者还定义了可调整的小距离（如adj_1到adj_4），用于细化点的位置。每个字母的初始路径通过迭代过程手动调整，参考字体和手写草稿，但结果最初显得参差不齐。

曲线平滑：Chaikin算法

为了平滑路径，作者采用了Chaikin曲线算法。该算法递归运行：每轮中，复制第一个和最后一个点，并为中间点添加两个新点，分别位于原点向前后点的25%处。经过3-4次迭代，路径变得平滑，适合小尺寸使用；对于更大尺寸，可能需要更多迭代以避免尖锐边缘。这允许仅通过少量点定义光滑曲线，显著改善了字母的外观。

代码优化与形状化

初始代码冗长，作者编写了一个函数将字母路径转换为基于简单数字值的代码，基于字体大小20，并可按比例缩放。例如，字母“a”的路径被优化为简洁的数值列表。

为了模拟手写效果，路径被转换为2D形状，使用“shapify”算法。该算法沿路径每点计算角度（基于当前点到下一点的方向），并使用Perlin噪声选择该点的路径宽度，从而创建变宽路径。在路径端点，添加小循环以形成圆润的线帽。虽然算法在急转弯处可能产生内部循环，但由于填充效果，影响不大。

抖动与美学调整

作者使用Perlin噪声轻微抖动所有点，增加自然感和多样性。系统设置后，可通过调整参数（如基于字母位置的线宽变化或更高分辨率的噪声）创造不同效果，从而增强手写感。

文件大小与应用

字母类当前为9.7kb，包含A-Z大小写字母、7个标点符号、字母间距调整、路径调整大小函数、平滑路径函数等。作者不寻求进一步优化建议。该系统已用于作品中，并且进化版手写代码的生成打印品现已发售，每件作品独特且按需生成。

文章摘要：改进Wayland下的光标渲染

基本术语

• 主题：一组光标形状的集合。
• 形状：光标的特定形态，例如指针、文本指示器或抓取手形。
• 图像：某个形状在特定分辨率下的单张图片（或SVG矢量图）。

传统光标（XCursor）的问题

1. 光栅格式的局限性：传统光标（如XCursor）基于光栅图像（如PNG）。当需要调整大小时，计算机必须通过算法（如最近邻或双线性插值）进行猜测，导致结果模糊或像素化，难以获得像素级完美的效果。
2. 多尺寸存储：为应对此问题，XCursor为每个形状存储多个预设尺寸（如96、64、48等）。这导致文件体积庞大（例如，一个完整的Bibata主题约44.1MB）。
3. 缺乏灵活性：无法在预设尺寸之间获取任意大小，客户端通常无法自行缩放，导致在高分辨率屏幕（如8K）上表现不佳。
4. 历史技术限制：XCursor诞生于PNG、GIF、JPEG等高效压缩格式之前，其图像数据是未压缩的，进一步增大了文件体积。

Hyprcursor新格式的优势

为解决上述问题，作者创建了全新的光标格式hyprcursor，其主要优势包括：

1. 支持现代存储格式：允许光标以PNG（高效无损光栅格式）或SVG（无限可缩放的矢量图形）形式存储。矢量格式尤其关键，能实现任意分辨率下的清晰渲染。
2. 元数据驱动：每个形状伴随一个meta.hl元数据文件，详细定义其属性、覆盖规则和缩放算法，避免了使用符号链接等传统笨拙方法。
3. 简化的API：提供了简洁的C/C++ API，方便开发者将光标形状渲染为PNG图像。
4. 极高的空间效率：
   • 使用PNG可将Bibata主题从44.1MB压缩至约6MB。
   • 使用SVG可将体积进一步降至171KB，实现约250倍的缩减。

在Wayland中的光标渲染

• 客户端渲染模式（传统）：Wayland最初的设计规范要求客户端自行绘制光标。这导致不同应用程序渲染效果不一致，尤其在HiDPI屏幕上问题突出。
• 服务器端渲染协议（改进）：新的wp_cursor_shape协议允许应用程序请求合成器绘制指定形状。这确保了光标风格的统一，并允许合成器（如支持hyprcursor的Hyprland）利用hyprcursor的优势进行高质量渲染。
• 当前支持情况：
  • 支持客户端：QT、Chromium、Electron及Hypr系列应用程序支持该协议，可在相关合成器中使用hyprcursor。
  • 不支持客户端：GTK尚未支持该协议，导致Firefox、GNOME套件等应用仍会回退到旧版XCursor主题，显示效果不佳。

采用与展望

• 制作主题：可以使用hyprcursor-util工具快速将XCursor主题转换为hyprcursor格式。为获得最佳效果，建议使用原始SVG源文件进行构建。
• 采用前景：作者认为该系统明显更优秀且易于实现。关键在于推动GTK等主流工具包支持wp_cursor_shape协议，这将使大多数Linux桌面应用受益。
• 结论：hyprcursor为现代桌面（尤其是Wayland）提供了空间高效、无限可缩放且渲染一致的光标解决方案，但其广泛采用依赖于现有生态系统对wp_cursor_shape协议的支持。

BlenderBIM 是一个用于 Blender 的开源插件，旨在提供美观、详细且数据丰富的 OpenBIM 工作流程。其核心是一个免费、开源的原生 IFC（工业基础类）创作平台，主要功能包括：

• 审计与分析：对建筑信息模型进行检查与评估。
• IFC 模型创作：直接创建符合行业标准的 IFC 格式模型。
• 绘图生成：从模型自动生成工程图纸。
• 结构分析：进行建筑结构相关的计算分析。
• MEP 系统：支持机械、电气与管道系统的设计与建模。
• 成本估算与进度安排：协助进行工程造价与施工计划管理。
• 设施管理：用于建筑运营与维护阶段的信息管理。
• 实时建筑传感器：能够集成或显示来自建筑物的实时传感器数据。

IBM与NASA合作开发科学语言模型

IBM与NASA合作，基于Transformer架构创建了一套高效的科学领域语言模型。这些模型在科学文献上训练，可用于分类、实体提取、问答和信息检索等多种任务，在多个科学领域实现高性能并能快速响应。模型已在Hugging Face开源，供科学与学术界使用。

技术基础与训练

• 模型基于Transformer架构（如BERT、RoBERTa、IBM的Slate和Granite系列），通过掩码语言建模任务训练，学习语言统计规律。
• 采用定制分词器处理科学术语（如“磷脂酰胆碱”“轴”“多晶”），相较于通用分词器更能适应专业词汇。
• 训练数据涵盖天体物理学、行星科学、地球科学、太阳物理学及生物与物理科学文献，共计600亿令牌。模型处理的5万令牌中超过一半为科学独有术语，与开源RoBERTa模型不同。

性能表现

• 在生物医学任务BLURB基准测试中，性能比开源RoBERTa模型高5%。
• 在内部科学问答基准测试中F1分数提升2.4%，在地球科学实体识别测试中提升5.5%。
• 检索能力突出：基于模型构建的检索器在NASA策划的约400个问题测试集中，相关段落检索准确率比微调RoBERTa模型高6.5%，比BGE-base开源模型高5%。

应用与开源

• 编码器模型可微调用于非生成性语言任务，并生成信息丰富的嵌入以支持检索增强生成（RAG）。RAG分两步：检索模型编码问题并从向量数据库检索相关文档，再由生成模型基于检索内容生成答案。
• 检索器通过对比损失函数优化，将锚文本嵌入与相关文档靠近，与不相关文档远离，训练使用约2.68亿文本对（如标题-摘要、问题-答案）。
• 模型已在Hugging Face开源：编码器模型可进一步微调用于太空领域应用，检索器可用于RAG信息检索。IBM与NASA正合作利用这些模型提升科学搜索引擎。

差异算法在版本控制系统中至关重要，用于展示代码变更、辅助合并和存储历史。Myers算法是Git默认的差异算法，其核心目标是找到从源字符串到目标字符串的最短编辑脚本，即最少的插入和删除操作。

该算法将编辑过程建模为一个图搜索问题。网格中的每个点 (x, y) 代表一个状态：x 表示已从源字符串删除的字符数，y 表示已从目标字符串插入的字符数。向右移动对应删除源字符串的字符，向下移动对应插入目标字符串的字符。若当前字符相同，则可沿对角线免费移动（无需操作）。算法通过广度优先搜索探索所有可能路径，寻找从起点 (0, 0) 到终点 (len(a), len(b)) 的最短路径（即最少非对角线移动）。

文章以字符串 a = ABCABBA 和 b = CBABAC 为例，演示了算法如何逐步构建搜索图并找到需要5次编辑的路径。它强调了好的差异应倾向于：最小化编辑次数、先显示删除后显示插入、保持代码块结构的完整性。Myers算法通过其贪心策略（优先匹配相同字符，在选择时优先考虑删除操作）倾向于生成符合这些特性的差异。

《Lemonade Stand》文章摘要

这篇文章围绕苹果电脑上的经典游戏《Lemonade Stand》展开，融合了个人回忆、代码历史考证与技术分析。

游戏简介

《Lemonade Stand》是一款于1973年由Bob Jamison为大型机创作、后移植到Apple II平台的经营模拟游戏。玩家每天根据天气预报，决定制作柠檬水的杯数、广告牌数量和售价，这些决策与天气共同影响需求和利润。作者在1983年获得Apple //e后接触到该游戏，并尝试通过“逆向工程”其Applesoft BASIC源码来求解利润最大化的策略。

代码历史与版本

文章指出，现存的苹果版本主要源自Charlie Kellner的移植（lemonade.bas），而MECC的“selll.bas”可能更接近1973年的原始版本。两者在变量命名、注释和部分逻辑上存在差异。作者将代码整理后发布于GitHub，包括早期版本和后续由Drew Lynch等人进行的图形与音效更新版本。

策略优化尝试

作者编写Python脚本（lemonade_strategy.py），采用暴力计算法，遍历所有可能的柠檬水杯数、广告牌数量和售价，以寻找使期望利润最大化的组合。由于核心需求公式已知，理论上可直接求解。作者借此对比了现代Python与1980年代Applesoft BASIC的执行速度——同一计算在Apple //e上需近4小时，而在现代笔记本电脑上仅需不到一秒，速度差距超过20万倍。

技术发现：未声明变量与代码修改

当作者在互联网档案馆的在线版本中测试其最优策略时，发现结果不符。调查发现，该特定版本对游戏原始代码进行了三处关键修改：

1. 调整了天气生成的随机概率（如将晴天概率从60%降至40%）。
2. 注释掉了一段强制游戏前两天为晴天的代码（IF D<3 THEN SC=2）。
3. 然而，另一处代码仍限制前两天的实际需求计算仍基于“晴天”（R1参数未随之改变）。

更关键的是，这些修改依赖于Applesoft BASIC的一个特性：变量无需预先声明，未赋值的变量默认值为0。例如，被注释的代码中使用的变量D在访问前从未被赋值，这在Python中会导致错误，但在Applesoft BASIC中默认为0，从而使得游戏前两天仍按“晴天”处理。这一特性在原始Applesoft参考手册中有记载，但作者表示此前并未意识到或利用过。

结论

文章不仅是一次对经典游戏的技术探索与怀旧之旅，也揭示了复古计算环境中一些不为人知的特性（如变量默认值），以及代码修改可能带来的意想不到的连锁影响。作者强调，其初衷并非完全“破解”游戏，而是通过一个具体例子展现早期计算环境的限制与特点。

为他人写作，但主要是为自己

作者最初开设博客是为了推动职业发展，将自己树立为技术领域的权威。六年后回顾，他发现博客确实成为了职业发展的关键，但方式出乎意料——它主要是一个磨练思维和深化理解的工具，而非仅仅是作品集。

写作的核心价值：深化思考与发现盲点

• 严肃的写作态度：作者重视声誉和读者，这迫使他只写自己真正理解或愿意先深入学习透彻的主题，避免浪费他人时间或遭遇公开批评。
• 写作揭示知识薄弱点：详细阐述技术主题（如工作原理、权衡取舍、替代方案）时，会触发内心的“虚假探测器”。它不断质问“你怎么知道这个？”，暴露知识根基的脆弱，促使作者去填补认知空白，寻找根本原理，从而能真实、可靠地解释事物。
• 自我提升的引擎：定期写作并直面这种自我审视，迫使作者以更高的标准学习，无可替代地推动其思维能力的升级。这帮助他学会了如何思考、如何发现他人未察觉的见解。

带来的职业益处

通过持续输出高质量文章，作者在其技术细分领域获得了能见度，并最终转化为了更多的工作机会。这验证了写作的“个人品牌”效用，但其根源在于写作过程本身带来的深度理解。

将写作私有化：持续应用于团队

如今，作者不仅公开写作，也会为团队撰写私有的技术文档或设想（如新特性构思、技术原理）。与他人分享的预期，同样会激活内心的“虚假探测器”，促使他：

1. 检验思考的严密性，发现逻辑漏洞。
2. 充实想法，考虑所有权衡。
3. 有时，这些私有写作内容会因足够通用而发展为公开文章（如他的Apache BookKeeper内部原理系列和USE指标系列）。

最终建议

作者建议，不要仅将博客写作视为打造“个人品牌”的手段。虽然它有此作用，但首要且最重要的是，它是个人用于提升技能、深化知识和批判性思维的工具。

核心比喻：写作是针对思维的训练，使其更强大，从而带来更深刻的理解和更卓越的洞察力。即使读者寥寥，受益最大的始终是写作者自己。

Passkeys – Under the Hood 摘要

Passkeys概述
Passkeys是一种基于FIDO凭证和WebAuthn规范的认证技术，旨在替代传统密码。其主要优势包括抗钓鱼攻击和抗服务器泄露能力。服务端仅存储公钥，私钥由用户端保管，因此服务器泄露不会暴露私钥；浏览器在签名中包含服务地址，可有效防止钓鱼。此外，Passkeys支持跨设备同步（如Apple和Android），解决了硬件安全密钥的备份问题，但可能导致供应商锁定。

技术实现与WebAuthn规范
Passkeys通过浏览器遵循WebAuthn规范创建。注册时，服务（依赖方）发起凭证创建请求，浏览器调用navigator.credentials.create()生成非对称密钥对（如ECDSA with SHA-256或RSASSA-PKCS1-v1_5 with SHA-256）。私钥存储在用户设备，公钥发送至服务端。认证时，服务发送随机挑战，浏览器调用navigator.credentials.get()使用私钥签名，签名中包含服务地址等信息，确保安全性。

实际操作示例
以webauthn.io为例：注册时，浏览器弹出验证请求（如指纹或PIN码），控制台显示注册选项（如算法参数）和响应（包括公钥和凭证ID）。认证时，服务发送挑战，浏览器签名后返回响应，其中clientDataJSON包含origin字段，由浏览器直接读取，防止钓鱼。在Windows系统中，Passkeys由Microsoft Hello和TPM（如果可用）保护，但详细存储机制不透明，且不支持跨平台同步。

与硬件安全密钥的对比
硬件安全密钥将私钥安全存储在安全元件中，即使物理访问也无法提取；而Passkeys的私钥在设备内存中可能被攻击者访问，威胁模型不同。硬件密钥需要为每个服务注册多个密钥以备份，但Passkeys通过同步解决了备份问题。然而，Passkeys的同步可能局限于特定生态系统（如Apple或Google），导致供应商锁定。

Bitwarden实现分析
Bitwarden作为开源密码管理器，通过覆盖WebAuthn调用（如拦截navigator.credentials.create和get）支持Passkeys。Passkeys在Bitwarden中加密存储，并通过端到端加密同步到服务器，允许跨设备访问，减轻供应商锁定。私钥可导出为JSON格式，便于迁移到其他服务。分析显示，私钥在创建和签名过程中暴露在内存中，与硬件密钥的安全性形成对比。

结论
Passkeys提供了比密码更安全的认证方式，解决了钓鱼和服务器泄露问题，并通过同步改善用户体验。但其安全模型与硬件安全密钥不同，私钥在用户设备上可能暴露，用户需根据用例评估威胁。同步功能虽便捷，但可能依赖于特定供应商，需权衡利弊。

DBOS 操作系统总结

DBOS 是一个专注于为应用程序和 AI 代理构建可靠、持久化工作流和队列的操作系统。它基于多年麻省理工学院和斯坦福大学的研究，旨在简化构建可扩展、容错应用的过程。

核心概念与价值

DBOS 的核心思想是为代码提供类似“保存点”的功能。其工作流具备持久性，意味着即使在执行过程中遇到失败（如服务器重启、代码重新部署），工作流也能从最后一个成功的检查点恢复，确保操作原子性和最终一致性。

主要功能与应用场景

1. 构建可靠且可观察的 AI 代理：

   • 通过持久化工作流，使 AI 代理能够容错、可观察且可复现。
   • 原生集成主流 AI 代理框架，如 Pydantic AI、LlamaIndex 和 OpenAI Agents SDK。
   • 代码示例展示了如何定义工具并将其包装为 DBOS 步骤（@DBOS.step()），并创建工作流（@DBOS.workflow()）来运行代理。

2. 编排持久化工作流：

   • 开发者可以使用常规代码（包含分支、循环、子任务和重试逻辑）编写业务逻辑。
   • DBOS 自动使这些逻辑具备容错能力。例如，在一个结账工作流中，即使支付步骤后失败，也能自动执行释放库存和取消订单的补偿操作。

3. 使用持久化队列进行可靠扩展：

   • 提供持久化队列来简化数千个并发任务的容错编排。
   • 可以控制并发任务数或任务启动频率。例如，可以创建一个队列来并行处理文档索引任务，并等待所有任务完成。

4. 实时监控与工作流管理：

   • 提供实时仪表板，用于监控工作流和队列的健康状态与性能指标。
   • 支持检查工作流执行、跟踪队列指标，并可以取消、恢复或重启工作流。
   • 集成 DBOS Conductor 工具，用于故障排除、警报和修复。

5. 简易的动态调度：

   • 支持创建精确的持久化调度（Cron），确保工作流在每个指定时间间隔内只运行一次。
   • 可以动态创建、更新或回填调度，无需管理外部调度器。例如，每分钟记录一次股票价格，或每小时同步一次客户数据。

6. 支持人机交互（Human-in-the-loop）工作流：

   • 工作流可以暂停、等待人工输入，然后可靠地恢复，即使跨越重启和重新部署。
   • 利用持久化睡眠与通知机制，工作流可以等待数天或数周，直到收到外部信号（如审批通知）后继续执行。

技术原理与特点

• 易于集成：只需安装开源的 DBOS 库并将其连接到一个 Postgres 数据库即可，无需新的基础设施。
• 代码注解驱动：通过在代码中注解工作流和步骤，即可使应用程序默认具备容错和可观测性。
• 管理与监控：通过 DBOS Conductor 统一管理和监控所有应用的工作流与队列。
• 安全性与隐私：符合 SOC 2、GDPR 和 CCPA 标准，不存储用户数据，保证完全隐私。
• 灵活部署：支持在本地或任何云环境中运行，可以自托管 DBOS Conductor。
• 自定义警报：可以定义自定义警报，通知团队工作流编排中的问题。

用户评价与反馈

来自不同公司的技术高管（CEO、CTO）对 DBOS 给予了积极评价，主要强调：

• 易用性与简洁性：“DBOS 使构建可靠、低延迟的 AI 体验变得极其简单”，“DBOS 让管理变得非常简单，只需少量编码和额外基础设施即可获得持久化编排和可观测性”。
• 可靠性设计：其设计像游戏中的“保存点”，允许函数在失败后从检查点重新开始，“让犯错变得不可能”。
• 解决实际问题：相比 Google Workflows、Temporal 等工具，DBOS 解决了更多实际问题，同时保持了实现的灵活性。
• 提升可观测性：显著提升了对工作流失败原因和统计数据的了解，简化了基础设施。
• 轻量与灵活：团队对其轻量、灵活、快速迭代和高水平支持印象深刻。

本文内容主要提示用户当前访问的 SondeHub 实时天气气球追踪界面版本已过时。页面将自动刷新，或可点击链接手动刷新以加载最新版本。若持续看到该提示信息，可尝试特殊操作以解决访问问题。

文章标题“我对Linux系统的理解”与提供的实际内容不符。所提供的内容是GitHub平台的导航页面和功能概述，而非关于Linux系统的总结。

内容概述

该页面展示了GitHub平台的核心功能、产品分类、用户支持资源及企业解决方案，旨在帮助开发者和团队了解并使用GitHub的服务。

主要功能与分类

1. AI代码创建：包括GitHub Copilot等AI辅助编码工具。
2. 开发者工作流：涵盖自动化工作流（Actions）、云开发环境（Codespaces）、问题跟踪（Issues）、代码评审等。
3. 应用安全：提供高级安全扫描、代码构建时安全防护及密钥泄露防护等功能。
4. 按用户规模分类：针对企业、中小企业、初创公司及非营利组织提供不同方案。
5. 按使用场景分类：包括应用现代化、DevSecOps、DevOps及CI/CD等。
6. 按行业分类：覆盖医疗、金融、制造、政府等行业解决方案。
7. 探索资源：可按主题（AI、软件开发、DevOps、安全等）或类型（客户案例、活动、电子书等）浏览。
8. 支持与服务：提供文档、客户支持、社区论坛、合作伙伴等资源。
9. 社区与开源计划：包括GitHub Sponsors、安全实验室、加速器等。
10. 企业解决方案：提供企业级平台、高级安全功能、Copilot商业版、高级支持等附加服务及定价信息。

页面结构

• 顶部为全局导航栏，包含各类功能入口。
• 主体部分按不同维度对产品和服务进行分类展示。
• 包含反馈提交、搜索、账户登录/注册及外观设置等页面元素。

HTTP协议演进总结

HTTP基础与早期版本

• HTTP/0.9：首个草案，仅支持GET方法，响应为纯HTML文本，无头部和状态码。
• HTTP/1.0：引入HEAD、POST方法、MIME类型、状态码和协议版本标识，HTTP消息采用ASCII文本结构。
• HTTP/1.1（1997年）：关键改进包括持久TCP连接（减少开销）、Host头部（支持同一IP多域名）及头部规范（编码、缓存等）。

HTTP/2（2015年）

• 基于Google SPDY协议，核心创新：
  1. 二进制分帧：消息以二进制格式传输，分为更小的帧，便于解析。
  2. 多路复用：在单一TCP连接上并行传输多个请求/响应（通过“流”实现），解决了HTTP层队头阻塞问题。
  3. 头部压缩：使用HPACK算法压缩头部，减少冗余数据。
• 局限：虽解决HTTP层阻塞，但TCP和TLS层的队头阻塞仍存在（如TCP丢包会阻塞后续数据）。

HTTP/3

• 基于QUIC协议（运行在UDP之上），主要改进：
  1. 独立流传输：每个流独立，丢包仅影响对应流，解决了TCP和TLS层队头阻塞。
  2. 集成TLS 1.3加密：加密与传输层结合，支持0-RTT连接建立，减少握手延迟。
  3. 连接迁移：使用连接ID而非IP/端口标识连接，适应网络切换（如Wi-Fi转4G）。
• 技术细节：
  • QUIC将加密应用于每个数据包，可单独解密，无需等待全部数据。
  • 采用QPACK进行头部压缩。

对比与选型建议

• 适用场景：
  • HTTP/2：在稳定网络中性能更优，适合大多数场景。
  • HTTP/3：针对移动网络、卫星连接等不稳定环境设计，抗丢包能力强，但可能因UDP优化不足或加密计算带来性能损耗。
• 注意事项：
  • HTTP/1.1可通过多TCP连接模拟并行，但效率较低。
  • 服务器可同时支持HTTP/2和HTTP/3，由客户端选择最优协议。