课程概述

drlzh.ai 是一门动手实践的深度强化学习课程，其核心理念是引导学习者亲手构建算法，而不仅仅是阅读理论。课程内容覆盖了从基础到前沿的广泛主题，包括马尔可夫决策过程、表格强化学习、Atari游戏智能体、连续控制机器人、AlphaZero式规划、用于语言模型的基于人类反馈的强化学习、决策变换器、视觉-语言-动作策略、世界模型、Dreamer及元学习等。

课程结构与内容

课程被组织成一系列的Jupyter Notebook，分为练习路径和解决方案路径。练习路径的Notebook中，部分代码被有意替换为引导性的TODO待办项，供学习者填写完成。解决方案路径则提供完整可运行的版本，便于学习者自我解惑。课程大纲如下：

• 基础 (00-07)：涵盖MDP、表格RL、DQN、REINFORCE、Actor-Critic方法、DDPG、TD3、SAC、PPO。
• 突破假设 (08-10)：包括RND好奇心驱动、多智能体RL、基于行为克隆和离线强化学习的离线RL。
• 规划 (11)：讲解蒙特卡洛树搜索、自我对弈、AlphaZero式的策略/价值学习。
• 现代AI技术栈 (12-13)：涉及基于PPO的RLHF、DPO、GRPO、决策变换器，以及NanoVLA。
• 生产实践 (14)：介绍TensorBoard、模型检查点保存、调试、多随机种子运行、Ray分布式框架、Optuna超参数优化。
• 世界模型 (15-16)：包括基于SAC的模型引导策略优化，以及DR3AM/Dreamer结合RSSM的隐空间想象。
• 元学习与总结 (17-18)：讲解MAML、FOMAML、快速适应技术，并进行课程总结。

课程建议按顺序完成基础部分，高级部分Notebook则相对独立。

学习环境与AI助手

课程推荐使用Docker快速搭建环境，该环境集成了代码服务器、所有Notebook、Python 3.13、Jupyter内核、所有依赖项以及配套的AI助手。

DRL-ZH AI助手是专为本课程设计的VS Code扩展，它能感知你当前所在的Notebook和TODO任务，并提供苏格拉底式的引导提示而非直接答案，支持文本和语音模式。学习者可自行配置大语言模型密钥（默认使用Gemini，同时支持OpenAI、Anthropic和Groq）。

快速开始

课程强烈推荐使用Docker进行环境配置：

1. 安装Docker和Git。
2. 克隆课程仓库。
3. 在Linux/macOS中设置文件权限。
4. 通过docker compose up --build -d启动默认环境（支持可选的GPU或精简CPU版本命令）。
5. 在Chromium浏览器中打开http://localhost:8080并选择Python (drl-zh)内核开始学习。

对于偏好原生环境的学习者，课程也提供了详细的MANUAL.md指南。

前提条件

学习者需要具备Python和PyTorch基础，并熟悉机器学习相关的数学知识，包括概率论、统计学、线性代数和微积分。Notebook会教授强化学习理论，但假设学习者具备阅读和修改实际训练代码的能力。

许可证

本课程采用MIT许可证。

在文章中，Keygen的创始人分享了关于软件试用期的重要见解。他最初采用了行业常见的14天免费试用期，但很快发现这个时间框架不足以让潜在客户完成API集成——包括阅读文档、进行引导和完成概念验证。

作者通过数据分析发现，大多数付费客户实际上都申请过试用延期，且这些客户的转化率更高。他进一步使用Stripe数据分析了自己的"转化时间"（从注册到付费的时间），发现其中位数长达41天，90分位数更是达到130天。这意味着14天的试用期与客户实际需要的决策时间严重不匹配。

这种不匹配导致许多有意向的客户因时间压力而流失。他们可能有兴趣，但在14天内无法完成技术评估，最终放弃后再未回来。

为了解决这个问题，作者做出了一个违反常规建议的决定：将14天有限试用改为无限期免费层级。结果不仅增加了总体注册量，而且付费注册量也有所提升，转化率保持稳定，同时减少了手动管理试用延期的工作量。

文章最后通过提供的Stripe查询代码，鼓励读者计算自己产品的转化时间，以便做出更符合实际情况的试用期决策。

网站名称：GetAnyPlant
核心功能：免费在线浏览与探索植物目录，收录超过6000种植物。
主要用途：适用于玻璃缸、水族箱或家居植物选择。
筛选方式：支持根据养护需求、外观特征等条件查找植物。
访问链接：GetAnyPlant官网
配套信息：网站提供开放图谱图片（opengraph-image.png）用于社交分享。

• 核心事件：一项调查揭示，纽约大学教授大卫·艾布拉姆斯和雷·尼亚乌拉在青少年电子烟危机高峰期公开为电子烟辩护时，未披露其与电子烟公司Juul存在未公开的协作关系。

• 协作细节：据公司邮件显示，在2017-2018年间，艾布拉姆斯教授与Juul高管在公关信息上进行了广泛协调，包括索要发言要点、在发表前允许公司审阅其学术文章，以及参加Juul的科学顾问会议。

• 未披露情况：上述与Juul的联系并未向相关的学术期刊或国会披露，而两位教授当时是作为支持电子烟作为戒烟策略的权威声音出现的。

• 调查来源：本报道基于STAT的调查，并引用了Juul公司内部的电子邮件作为证据。

BlackHole: macOS 音频回环驱动

核心功能 BlackHole 是一款现代化的 macOS 虚拟音频回环驱动，允许应用程序之间以零额外延迟传递音频。

主要特性

• 多通道支持：提供 2、16、64、128 和 256 声道版本。
• 高度可定制：支持自定义通道数、延迟、隐藏设备，并支持创建镜像设备以分别处理输入或输出。
• 广泛采样率：支持从 8kHz 到 768kHz 的多种采样率。
• 零延迟与高兼容：无额外驱动延迟，兼容 macOS 10.10 及更新版本，同时构建支持 Intel 和 Apple Silicon 芯片。
• 安全便捷：无需内核扩展或修改系统安全设置。

安装与卸载

• 安装：可通过下载官方安装包或使用 Homebrew（如 brew install blackhole-2ch）进行安装。
• 卸载：可使用专用卸载工具，或通过终端命令手动删除驱动文件并重启 CoreAudio 服务。

使用场景

• 录制系统音频：通过创建“多输出设备”，将系统音频路由至 BlackHole，在 DAW 中进行录制。
• 应用间音频路由：将发送应用的输出设为 BlackHole，并在接收应用中将其设为输入源。
• 连接特定软件：提供将 Logic Pro X、GarageBand、Audacity 等音频软件与 FaceTime、Zoom 等通讯软件连接的指南。

开发者指南

• 许可：非 GPL-3.0 项目使用需联系获取许可。
• 构建与自定义：支持在构建时通过编译器预定义常量来自定义驱动名称、Bundle ID、图标、通道数、延迟和采样率等。
• 镜像设备：可配置生成第二个隐藏的镜像设备，实现独立的输入或输出功能。
• CI/CD：可集成到持续集成/持续部署流程中。

常见问题

• 不显示：BlackHole 仅出现在音频相关设置（如音频 MIDI 设置）中，不在“应用程序”文件夹里。
• 同时监听：需通过创建“多输出设备”实现。
• 位深度：使用 32 位浮点，与 macOS Core Audio 原生兼容。
• 音频故障：使用多输出或聚合设备时，需为主要/主设备外的所有设备启用“漂移校正”。
• 兼容性：少数应用（如 Apple 播客）与多输出设备存在已知兼容问题。

相关资源

• MultiSoundChanger：用于更改聚合设备音量的小工具。
• BackgroundMusic：一款可自动暂停音乐、单独设置应用音量及录制系统音频的 macOS 音频实用工具。

护柱：定义与重要性

什么是护柱？

护柱是足够坚固、形状特殊的物理屏障，能够阻止车辆与其重叠。无论是有意还是无意，车辆都无法穿越护柱。护柱可以固定在环境中或可移动，尺寸和外观各异。其核心功能是保护行人、建筑和空间免受车辆冲击。

护柱能创造“安全阴影”，如摩纳哥视频所示，护柱保护了路边的行人。学校附近的护柱既防止车辆误停，也可设计得美观（如铅笔形状护柱）。

护柱缺失的后果

没有护柱时，失控车辆可能造成严重破坏。司机误踩油门等微小错误可能导致车辆冲入建筑，造成伤亡。文章举例：一名男子在7-Eleven门前被车辆撞断双腿，该公司在美国有数千起店铺前撞车记录。

另一个悲剧：两名社区成员在人行道行走时被失控车辆撞倒，一人死亡。作者指出，此类事故本可通过安装护柱避免。

美国交通工程的批评

文章批评美国交通工程师常将护栏安装在人行道“错误”一侧，保护司机而非行人。这源于对“清晰区域”政策的错误应用：该政策旨在为偏离车道的车辆提供安全恢复空间，却忽视了行人安全。

作者认为，交通工程师过度保护车辆，甚至将护柱描述为“不耐撞”（意为可能损伤车辆），而护柱的本质是可靠阻挡车辆。美国道路设计常以车辆为中心，忽视行人安全，这种模式可追溯至通过城市高速公路驱散社区的 settler-colonialist 历史。

柔性立柱的不足

柔性立柱被误认为是护柱的廉价替代品，但文章强调其欺骗性：无法真正阻挡车辆。作者建议，若使用柔性立柱，应随机混入少量真实钢制护柱或类似坚固物体以提供实际保护。

护柱的美观与应用

护柱设计多样，可美观融入环境。作者展示多种设计，如树木、灯柱、巨石等自然元素也可作为屏障。例如，丹佛已有许多护柱和类似屏障，作者呼吁增加并优化设计。

结论

护柱是保护行人、建筑和公共空间免受车辆事故的关键基础设施。其缺失导致本可避免的伤亡和破坏。美国交通工程体系存在系统性缺陷，过度优先考虑车辆而忽视行人安全。正确安装护柱能有效减少事故后果，且其设计可兼顾功能与美观。

替代云服务商正因企业寻求更经济的GPU访问渠道而迅速崛起。以GPU基础设施提供商CoreWeave为例，该公司本周获得11亿美元新融资，估值达190亿美元，总融资额已达50亿美元。其他类似企业如Lambda Labs、Voltage Park和Together AI也在近期获得大额融资。

这一趋势的驱动力在于生成式AI的兴起。训练和运行AI模型需要大量GPU算力，而传统云巨头（AWS、Google Cloud、Azure）的GPU实例成本较高。以Nvidia A100 40GB为例，CoreWeave的租赁价格约为每月1200美元，而Azure和Google Cloud的费用分别高达2482美元和2682美元。

替代云服务商的优势在于更低的定价和更优的可用性。分析师指出，它们专注于GPU服务，没有传统云厂商的基础设施负担，因此能以更具竞争力的价格提供专项服务。甚至一些大公司（如微软）也开始依赖替代云提供商来解决算力瓶颈问题。

然而，这一领域的长期可持续性面临挑战。传统云厂商正在投资定制芯片（如谷歌TPU、微软Maia），以减少对Nvidia的依赖。此外，非GPU密集型工作负载仍可使用CPU处理。最大的风险可能是生成式AI泡沫破裂，导致GPU供过于求。尽管如此，短期内替代云市场仍将保持增长，尤其受到多云策略企业的青睐。

开源项目面临的社会工程接管威胁

事件背景
XZ Utils 的后门事件（CVE-2024-3094）可能并非孤立案例。OpenJS 基金会近期拦截了一起类似的社会工程接管尝试，显示此类攻击正成为开源生态系统的普遍威胁。攻击者通过冒充贡献者，试图获取项目维护者权限，模式与“Jia Tan”渗透 XZ/liblzma 事件高度相似。

社会工程攻击的特征模式

• 施压与诱导：未知社区成员以友好但持久的方式施压，要求提升为维护者。
• 虚假背书：利用“傀儡账号”进行虚假推荐。
• 代码可疑点：提交包含二进制文件（blob）、故意混淆的代码，或逐步升级安全风险（例如替换安全函数）。
• 流程异常：偏离项目常规的编译、构建或部署流程，可能引入恶意负载。
• 制造紧迫感：迫使维护者降低审查标准或绕过安全控制。

开源项目防护建议

1. 身份与访问管理：

   • 启用双因素认证（2FA/MFA），使用强密码管理器。
   • 定期审查提交者与维护者身份，限制关键权限（如 npm 发布权）。

2. 代码审查与合并策略：

   • 强制代码可读性要求，减少不透明二进制文件的使用。
   • 所有合并请求（PR）均需经过至少一名其他开发者的代码审查。
   • 启用分支保护与提交签名。

3. 安全策略与流程：

   • 制定安全政策，包含漏洞协调披露流程。
   • 参考 OpenSSF 指南、CISA 或 ENISA 的社会工程防范建议。

4. 社区协作与警惕：

   • 透明公开可疑活动，帮助其他项目保持警觉。
   • 关注维护者的心理状态，避免因攻击产生自我怀疑或妥协。

行业与政府支持措施

• 开源基金会的作用：
  Linux 基金会、OpenJS 基金会等通过提供技术、法律和运营支持，为维护者减压。Alpha-Omega 项目（由微软、谷歌、亚马逊资助）直接为关键开源项目提供安全开发资源。
• 公共资金支持：
  德国“主权科技基金”为 OpenJS 基金会等机构提供资金，强化基础设施与安全。文章呼吁全球政府借鉴此模式，加大对开源生态的公共投资。

结语
社会工程攻击利用开源社区的信任与协作精神，难以通过纯技术手段防御。提高警惕、加强审查流程、完善支持体系，是抵御此类威胁的关键。开源维护者需保持警觉，基金会与政府机构应持续提供资源，共同守护数字基础设施的安全。

大型语言模型（LLM）的工作原理可以简化为几个核心步骤，其本质并非魔法，而是一种复杂的计算机算法。

核心功能：预测下一个词元 LLM的根本任务并非直接“理解”或“对话”，而是根据给定的文本序列，预测最有可能紧接着出现的下一个词元。

基础单元：词元

• 词元是LLM处理文本的最小单元，不完全等同于单词。它们可能是完整的单词、单词的一部分、标点符号或空格。
• LLM通过一种称为字节对编码（BPE） 的算法，从大量训练数据中生成一个固定的词元词表。例如，GPT-2的词表包含50,257个词元。
• 用户输入的文本通过分词器转换为由词元ID组成的序列，才能被模型处理。

生成文本的过程 由于模型只能一次预测一个词元，因此生成连贯文本需要循环执行：

1. 预测概率：给定一个输入词元序列（即提示），模型会输出一个概率分布，表示词表中每个词元作为下一个词元的可能性。
2. 选择词元：根据这个概率分布选择一个词元。选择可以基于最高概率（贪心选择），也可以通过温度、top_p、top_k等超参数控制随机性，从而影响输出的创造性和多样性。
3. 迭代生成：将选中的词元添加到输入序列末尾，作为新的输入，重复上述过程，直到生成所需长度的文本或遇到终止符。生成的文本可能缺乏段落或句子的完整概念。

模型如何学习（训练） 简单的训练思路是：统计训练数据中所有连续词元对出现的频率，构建一个“哪个词元跟在哪个词元后面”的概率表。例如，从句子“I like apples”中可以学到“like”后面跟“apples”的模式。

• 问题：这种方法（马尔可夫链）的“上下文窗口”太小（仅依赖前一个词元），难以生成连贯长文。要使用更大的上下文（如考虑前N个词元），所需的概率表会指数级膨胀，变得不可行。
• 解决方案：用神经网络取代巨大的概率表。神经网络是一个参数化的函数，它接收词元序列作为输入，输出下一个词元的概率分布。
• 训练：通过反向传播等算法，用海量文本数据迭代调整神经网络的数十亿甚至数万亿个参数，使其预测越来越准确。训练后的模型像一个黑箱，其知识蕴含在参数中。

关键架构：Transformer与注意力机制 现代LLM普遍采用Transformer架构。其核心是注意力机制，它允许模型在生成每个新词元时，动态地“关注”输入序列中与当前任务最相关的部分，从而更好地捕捉长距离依赖和上下文关系，这是实现高质量预测的关键。

关于智能的看法 作者认为，LLM并非具有真正的推理或原创思维能力。其看似智能的表现，源于对海量训练数据中复杂模式的精巧复用和拼接。由于存在“幻觉”（生成看似合理但有事实错误的内容）的风险，LLM的输出在关键应用中需要人工验证。至于未来更大的模型能否达到类似真智能的程度，作者认为现有GPT架构存在局限性，但这不排除未来创新突破的可能。

在尝试加载相关内容时遇到了技术问题。系统提示“出了点问题”，并建议不要担心，会重新尝试。具体而言，该问题可能与用户浏览器中安装的某些隐私相关扩展程序（extensions）有关。为了排除故障，系统建议用户临时禁用这些隐私扩展，然后再次尝试加载页面。

谷歌的软件工程文化强调使用设计文档来定义软件设计。这些非正式文档由软件系统的主要作者在编码项目开始前创建，记录高层次的实现策略和关键设计决策，重点突出决策过程中的权衡考量。

设计文档的主要功能：

• 在修改成本较低的阶段早期识别设计问题
• 在组织内就设计达成共识
• 确保考虑跨领域关注点（如安全、隐私）
• 将高级工程师的知识扩展到整个组织
• 构成围绕设计决策的组织记忆基础
• 作为设计者的总结性技术作品

设计文档的典型结构：

• 上下文与范围：客观背景概述，让读者快速了解现状
• 目标与非目标：明确系统要实现和不实现的内容（非目标不是“系统不应崩溃”这类否定，而是明确选择不作为目标的需求）
• 实际设计：从概述到细节，重点阐述权衡考量。建议包含系统上下文图、API设计（避免直接粘贴完整定义）、数据存储方案（同样避免粘贴完整模式）等
• 考虑的替代方案：列出其他可行设计，重点说明各自的权衡以及为何当前方案最优
• 跨领域关注：组织应标准化需要考虑的跨领域问题（如安全、隐私、可观测性）

设计文档的约束程度：

• “绿地项目”：约束少，需快速定义规则以聚焦可行方案
• 约束严格的系统（如遗留系统或受限库设计）：需创造性组合有限方案实现目标，文档应聚焦于在已识别的权衡中选择最佳路径

文档长度：

• 大型项目建议10-20页
• 可为增量改进编写1-3页的“迷你设计文档”

何时不需要编写设计文档：

• 设计问题不模糊（无复杂性）
• 解决方案明显无权衡需说明
• 文档实质是实现手册而非设计分析
• 原型开发和快速迭代与文档开销不兼容

设计文档生命周期：

1. 创建与快速迭代：作者编写，与密切协作者快速迭代至稳定版本
2. 审查：与更广泛受众分享。形式多样，从轻量级的团队邮件列表讨论到正式的资深工程师评审会议。审查核心价值在于结合组织经验，早期确保考虑跨领域关注点
3. 实现与迭代：实施过程中，如出现设计缺陷需更新文档。若系统未发布，则务必更新；实践中常通过添加“修订案”链接维护
4. 维护与学习：文档是了解系统历史设计思路的重要入口。作者应定期回顾自己的设计文档，反思得失，提升设计能力

结论： 设计文档有助于厘清思路、就关键问题达成共识，避免无效编码投入，但本身也有时间成本。是否编写应考虑：设计是否不确定、是否需要资深工程师参与、是否存在争议需共识、是否需确保考虑跨领域关注点、是否需要理解遗留系统。若符合其中多条，设计文档是启动项目的优秀方法。

这是一个AI攀岩教练项目，能够根据用户的身体条件可视化任何攀岩路线的攀爬方法。

Stack Overflow 与 OpenAI 于2024年5月6日宣布建立新的API合作伙伴关系。此次合作旨在结合Stack Overflow作为全球领先技术内容知识平台的优势，以及OpenAI作为最受欢迎的AI开发大语言模型提供商的能力，从而赋能开发者。

合作的核心是通过Stack Overflow的OverflowAPI，为OpenAI的用户和客户提供准确且经过审核的数据基础，帮助AI工具快速找到问题解决方案，让技术人员能专注于优先任务。同时，OpenAI将把Stack Overflow上经验证的技术知识直接整合到ChatGPT中，使用户能够轻松访问由数百万开发者、历时15年贡献积累而成的可信、可溯源、准确且高度专业的技术和代码知识。

具体合作内容包括：

• OpenAI方面：将利用Stack Overflow的OverflowAPI产品，并与之合作，通过来自Stack Overflow社区的增强内容和反馈来改进其AI模型性能，特别面向使用其产品的开发者。此集成还将帮助在ChatGPT中对Stack Overflow社区内容进行归属引用，以促进用户与内容的更深层互动。
• Stack Overflow方面：将在开发其产品OverflowAI时利用OpenAI的模型，并与OpenAI合作，利用内部测试的见解来最大化OpenAI模型的性能。OpenAI的合作伙伴关系将帮助推动Stack Overflow的使命，即通过集体知识赋能全球技术发展，使其能创建更好的产品，惠及Stack Exchange社区的健康、成长和参与度。

双方高管均强调了此次合作对开发者社区的重要性。OpenAI的首席运营官Brad Lightcap表示，与Stack Overflow的深度合作将有助于增强双方平台上的用户体验和开发者体验。Stack Overflow的首席执行官Prashanth Chandrasekar则指出，此次合作旨在通过社区、一流数据和AI体验的力量来重新定义开发者体验，提升效率和协作，并为负责任的AI设定新的标准。

首批新的集成和功能预计将于2024年上半年推出。此次合作还将使Stack Overflow能够持续投资于社区驱动的功能。

关于Stack Overflow：它是全球最大的开发者社区，拥有超过5900万个问题和答案，平台用于开发者提问、学习和分享技术知识。其企业版产品Stack Overflow for Teams已帮助超过15，000个组织分发知识、提高效率并加速创新。 关于OpenAI：是一家AI研究与部署公司，其使命是确保通用人工智能造福全人类。

TasteAtlas是一个全球美食地图，旨在帮助用户探索和品尝各地的传统美食及本地食材。平台收录了12194道传统菜肴、7587种地方食材，以及20934家提供地道食品的餐厅，强调“吃正宗”的理念。通过图谱及餐厅信息，用户能够了解全球丰富多样的饮食文化，体验各地真正的特色美食。

日本有140家历史超过500年的企业，部分甚至连续经营逾千年。这些企业被称为“shinise”，研究发现它们普遍持有大量现金且没有债务，这是其能在各种灾难中延续至今的重要原因。

作者引用Kent Nerburn的话：“债务定义你的未来，而当你的未来被定义时，希望开始消逝。”债务不仅让希望消失，也缩小了你能承受的结果范围。生活中可能遇到各种波动：经济衰退、战争、疾病、家庭变故等。如果没有债务，可以承受的波动范围较广，极端事件可能会导致终结，但整体较为坚韧；债务增加时，可承受的波动范围缩小；高负债下，可承受的波动变得很有限。

作者认为，债务最实用的思考方式是：债务越多，你在各种生活波动中能存活的结果范围越窄。这与传统对债务的看法不同，后者通常只把债务当作提前需求和资产杠杆的工具，主要考虑资本成本。

重要的两个方面：

1. 波动性是常态。以50年为例，遇到战争、经济衰退、恐怖袭击、疫情、政治决策失误、家庭危机、健康危机、职业变动、孩子问题等，概率几乎是100%。因此，需认真对待债务带来的生存结果缩窄。

2. 需思考哪些波动性事件会导致不可承受。财务波动性是最明显（无法偿还债务），还有心理波动（难以忍受工作）、家庭波动（离婚、照顾亲人）、子女波动、健康波动、政治波动等，各类事件都可能发生。

作者并非反对债务，认为债务在合理使用时可成为有效工具。但当把债务视为让你在充满不确定性的世界中减少选项和灵活性的约束后，它就不只是资本成本，而是对最重要资产——自由选择和应对能力的限制。

摘要：HN讨论“最改变人生的博客文章”

该Hacker News讨论帖围绕“读过的最改变人生的博客文章”展开，网友们分享了多篇对其人生轨迹、思维方式和职业发展产生深远影响的文章与书籍，并引发了关于社会、职场和心理学的广泛辩论。

核心推荐内容及影响

1. 心理认知与自我提升

• ADHD（注意力缺陷多动障碍）科普：多位网友表示，阅读关于ADHD的文章促使他们寻求专业诊断。确诊及药物治疗极大地改善了他们的生活质量。
• 接纳自我与心智管理：Derek Sivers的《Slow》让读者接纳自己作为“慢思考者”的特质；David Foster Wallace的《This is Water》（这是水）教会读者主动选择关注点，避免消极的内心独白；另有文章帮助读者识别社交媒体对注意力的剥削，从而成功戒除。
• 自我重塑：关于提升“可约会性”的文章帮助读者重塑自我认知，甚至促成了改变人生轨迹的跨国婚姻。

2. 职场、商业与社会运作

• 《The Gervais Principle》（杰维斯原理）：深刻剖析了企业内部的权力结构，改变了读者对职场角色和晋升逻辑的认知。
• 《The Almanack of Naval Ravikant》（纳瓦尔宝典）：启发了读者追求“特定知识”，并利用编程和营销作为杠杆，推动了向创业和独立开发的转型。
• 技术批判与文化战争：Ted Kaczynski的《工业社会及其未来》引发了对技术奴役的反思；Ribbonfarm关于“新文化战争”的文章则帮助读者理解社会冲突中的不同角色与动态。

3. 财务独立与生活方式

• FIRE（财务独立，提前退休）运动：网友讨论了相关博客带来的反消费主义启示。同时，评论指出FIRE理论（如4%安全提取率）在缺乏持续现金流时的脆弱性，强调了副业收入和 frugality（节俭）的重要性。

延伸的深度讨论

• “奋斗文化”（Hustle Culture）的批判：网友批评了打鸡血式的职场竞争，认为这种“内卷”只是劳工阶级的零和博弈，最终让资本获益。部分人呼吁拒绝纯粹的功利主义，回归对他人的真实关怀。
• 社会协调与系统性困境：讨论引入了囚徒困境、古德哈特定律（Goodhart's Law）和“平台劣化”（Enshittification）等概念，指出许多社会和商业问题本质上是难以解决的协调失败和激励扭曲。
• 关于“特权”与进步主义话语的争议：一篇探讨特权的文章引发了激烈交锋。部分网友认为当前的进步主义话语缺乏对男性困境的共情，容易将年轻男性推向保守主义；另一方则强调弱势群体争取权利的长期性，批评优势群体缺乏耐心与实质性的倡导行动。

奥逊·威尔斯醉酒拍摄葡萄酒广告始末

背景与动机
奥逊·威尔斯虽凭借《公民凯恩》成名，但因其倔强性格与制片厂频繁冲突，导致职业生涯坎坷。为筹集独立拍摄资金，他接下大量低于自身才华的商业工作，包括为廉价葡萄酒品牌保罗·马森拍摄广告，其著名广告语是“我们绝不售卖未熟的酒”（We will sell no wine before its time）。

拍摄现场的日常工作流程
据英国商业制片人兼导演彼得·希林福德回忆，他曾担任威尔斯拍摄保罗·马森广告时的场记和副导演。常规拍摄中，威尔斯会准时抵达好莱坞豪宅场景，化妆就座后与衣着考究的临时演员完成拍摄。希林福德为避免干扰，亲自控制场记板并阻止广告公司人员过度接近威尔斯，因其常擅自修改台词，易引发冲突。威尔斯欣赏希林福德的协调方式，二人关系融洽，常共进午餐听他讲述好莱坞往事。

1980年醉酒事件始末
在一次计划于洛杉矶豪宅拍摄的广告中，威尔斯迟到至中午才抵达。他提前致电称前夜在拉斯维加斯拍摄至黎明，服用安眠药后药效发作，导致言语含糊、衣衫不整。希林福德为获取保险理赔证据，仍安排尝试拍摄。三次尝试均因威尔斯严重醉酒失败：他无法记住台词、发音不清，甚至在开拍时困惑演员动作。

应急处理与最终完成
拍摄失败后，希林福德安排威尔斯在豪宅保姆房休息两小时，并为其妥善保管衣物。广告公司人员震怒欲起诉解雇威尔斯，但希林福德坚持等待。下午三点，威尔斯恢复状态，完美完成拍摄，并于五点前收工。离场时，他向愤怒的广告公司人员得意一笑。

后续与影响
此次醉酒拍摄的幕后花絮多年后通过盗版录像带流传，成为威尔斯商业广告中最著名的轶事。尽管威尔斯最终仍被广告公司解雇，但希林福德与其建立了友谊，次日受邀共进午餐。此事件亦折射出威尔斯生涯后期为维持创作而不得不妥协的困境。

出版行业关注9岁儿童停止阅读娱乐书籍现象

核心问题：中级读物市场崩溃

目前出版业面临的最严重危机是面向8-12岁儿童的“中级读物”市场急剧下滑：

• 2022年销售下降16%，2023年前三个季度再降10%
• 这是唯一一个未恢复至2019年水平的出版细分领域
• 自2016年《内裤超人》系列后，再无现象级中级读物出现
• 巴诺书店因新政策减少此类书籍库存，专注于“保证畅销”的图书

“9岁衰减”现象

研究显示儿童阅读娱乐书籍意愿在9岁出现断崖式下降：

• 8岁儿童中57%每天为乐趣阅读
• 到9岁这一比例降至仅35%
• 这一年龄段被视为培养终身读者的关键期
• 疫情加速了这一趋势，但问题在疫情前已显现

原因分析

屏幕时间影响

• 疫情期间儿童屏幕时间增加，部分影响持续至今
• 但8-9岁儿童手机持有率稳定在约30%，并非主因

发现机制断裂

• 传统图书发现途径（家长、图书管理员、同伴推荐）在疫情期间萎缩
• 缺乏类似BookTok的中级读物推广平台
• 儿童没有手机，出版商难以直接营销

教育体系变化

• 阅读课程日益侧重应试和标准化测试
• 课堂阅读从整本书转向片段阅读和回答问题
• 阅读日志、积分制度降低了阅读乐趣
• 图书馆资金削减，图书管理员岗位减少

社会环境因素

• 图书禁令影响课堂和图书馆
• 图书管理员面临政治压力

出版业应对策略

• 转向图画小说和插图小说：2023年占中级读物销售的四分之一
• 强调轻松幽默的图文结合故事
• 编辑寻求更短篇幅、更多插图、更多幽默冒险内容
• 严肃文学新作家（尤其是有色人种作家）面临更大出版压力

潜在影响与担忧

1. 多样性倒退：新锐有色人种作家可能被排挤出严肃文学市场
2. 文学质量担忧：经典严肃儿童文学作品的生存空间可能缩小
3. 系统性风险：若无新的现象级作品出现，整个市场可能持续萎缩

业界期望

• 多数业内人士希望出现《哈利·波特》级别的突破性作品
• 一些人担忧已进入“后现象级作品时代”
• 业内呼吁建立更多元化的“支柱作品”生态，而非依赖单一系列

文章标题指出，Helldivers 2的PSN账户链接更新将不会继续推进。文章内容显示了一个错误消息，提示在访问x.com时出现了问题，可能是由隐私相关的浏览器扩展引起的，建议用户禁用这些扩展后重试。

PiFex: 基于树莓派的 JTAG 硬件黑客工具

概述

PiFex 是一款专为树莓派设计的硬件扩展板，旨在简化嵌入式设备逆向工程和硬件黑客的初始设置过程。它解决了基于 Armbian 的单板计算机（SBC）在配置和可用性上的门槛，将常用接口（如 UART、SPI、I2C、JTAG、SWD）通过双向电平转换器引出，使开发者能够利用 Linux 下丰富的工具（如 Python、Rust、C 甚至 Bash）与目标设备交互。

硬件特性

• 接口支持：通过 GPIO 引出 UART、SPI、I2C、JTAG、SWD 接口及额外 8 个 GPIO 引脚。
• 电平转换：集成两个 TXB0108 双向电平转换器，支持连接低于 3.3V（如 1.8V、1.2V）逻辑电平的设备，可通过外部电压源灵活配置。
• 逻辑分析仪接口：内置连接器，简化信号调试接线。
• I2C OLED 屏幕：可通过 Adafruit CircuitPython 库自定义显示内容。

软件配置

• 预配置镜像：提供开箱即用的树莓派镜像，通过 USB-Ethernet 技术实现即插即用的网络连接，用户只需设置 IP 即可远程访问。
• 开发友好：接口以字符设备形式暴露于 /dev/，支持多种编程语言直接调用。
• Jupyter Notebook：提供模板笔记本，涵盖 JTAG 扫描、低级访问（UrJTAG 绑定）及 OpenOCD 脚本操作，便于学习和复用。
• 远程访问：支持 SSH 和 FTP。

实战演示：逆向未文档化的 SSD JTAG

1. 硬件分析：

   • 目标为一块基于 SM2259XT 主控的廉价 SSD，其 10 针调试接口未文档化。
   • 通过万用表识别接地引脚和电压参考（3.28V），利用示波器监测上电/断电波形区分 VCC 引脚。

2. JTAG 引脚枚举：

   • 使用 go-jtagenum 工具进行 IDCODE 和 BYPASS 扫描，尝试所有可能的引脚组合。
   • 成功识别出 JTAG 引脚功能：TCK、TMS、TDI、TDO 及可能的 nTRST。

3. CPU 识别与工具链构建：

   • 通过 UrJTAG 获取设备 ID（0x100434B1），确认 CPU 为 ARCompact 架构。
   • 在 OpenOCD 中配置对应的 JTAG TAP 和调试目标，并编写树莓派 GPIO 引脚配置文件。

4. 内存读取与调试：

   • 使用 OpenOCD 的 mdw 和 dump_image 命令成功读取 SSD 内存，发现可读字符串（如“SM2259BT”）和中断向量表。
   • 通过 GDB 连接 OpenOCD 的 GDB 服务器，实现单步执行、寄存器查看和内存区域分析。
   • 利用 Ghidra（含 ARCompact 扩展）反汇编导出的固件，识别代码区域和内存布局。

5. 成果：

   • 获得对 SSD 固件的完整读写、执行流控制及寄存器访问能力，为后续漏洞挖掘、固件修改或逆向更新机制奠定基础。

总结

PiFex 通过整合开源软件与商用硬件，降低了嵌入式设备评估的入门难度。其预配置镜像和模板笔记本显著提升了 JTAG 等协议的实操效率。文章演示了如何利用该工具链逆向一个未文档化的 SSD JTAG 接口，最终实现对设备内存和 CPU 的完全控制。相关设计和软件计划在完成最终测试后开源。

资源与致谢

• 开源计划及购买渠道将在后续公布。
• 感谢 Nash Reilly 在硬件设计初期的帮助与审核。
• 相关资源链接：fpgajobs.com、firmwarejobs.com。

这篇文章探讨了软件工程中生产力度量的难题，并提出了作者作为工程副总裁的具体解决方案。

核心问题

作者面临来自CEO的压力，需要衡量并提升工程生产力，但传统观点（如Martin Fowler、Kent Beck所述）认为软件生产力无法精确度量。

解决方案的探索

1. 初期尝试（2023年9月）：作者与CEO、CTO、CPO进行了一次“理想的工程组织是什么样”的讨论，归纳出六个类别（包括盈利能力），并为每个类别确定了指示指标。整个过程巧妙地避开了直接定义“生产力”。
2. 产品押注机制：为了引入基于价值的度量，作者团队推行了“产品押注”流程。每个重大工程举措需提交提案，包含预期价值、投入和验证方法。理论上，这能计算出投资回报率作为生产力指标，但实际测量价值存在困难。
3. 当前采用的指标：价值增加能力：在缺乏可靠ROI数据的情况下，作者采用了 “价值增加能力” 作为代理指标。它衡量工程团队在为用户/客户创造价值的工作上投入的时间比例，剩余时间为“无价值消耗”（如修bug、维护、应急响应等）。

指标应用效果

• 在向领导层汇报时，作者用堆叠条形图直观展示了“无价值消耗”及其构成。
• 这成功将讨论焦点从“为什么交付慢”转向了 “如何减少无价值消耗、提升价值增加能力”。
• 作者将个人职责明确定义为：在未来三年内，在不增加投入的情况下，将价值增加能力翻倍。

关键警告与局限性

1. 古德哈特定律的风险：该指标存在致命缺陷——当它成为目标时，可能通过延迟维护、忽略安全漏洞等损害长期质量的方式来人为“美化”数据。
2. 依赖诚实文化：指标的效用完全建立在团队对数据分类的极度诚实和自律之上。
3. 作者的特定条件：该方案能实施，部分源于作者对数据真实性的坚决态度以及积极的管理措施（如引入XP实践和教练）。

总结

作者认为，衡量软件生产力极其困难，任何指标都需谨慎使用。在缺乏理想度量的情况下，“价值增加能力”提供了一个有价值的对话框架，但需警惕被操纵的风险。最终目标应聚焦于：持续、高质量地交付有价值的软件。

X.org 在 NetBSD 上的现状

1. 与典型发行版的差异

• 打包方式：NetBSD 将 X.Org 作为一个可选的单一整体包发行，而非模块化的独立包。这意味着所有驱动都包含在系统中，但需要精细调整以确保正确的驱动在正确的硬件上加载，并提供合理的回退机制（例如，为旧系统上的新型 GPU 回退到通用帧缓冲）。
• 代码库：NetBSD 使用名为 xsrc 的仓库，它实质上是一个定期从上游 freedesktop.org 拉取更新的 X.Org 分支（但不会推回上游），这使得 X 的开发成为 NetBSD 的一部分。
• 构建系统：NetBSD 使用基于 BSD makefiles 的自定义构建系统，而非 X.Org 基于 GNU autotools 的系统，这与其 build.sh 交叉编译系统兼容良好。

2. NetBSD 独有的驱动与加速支持

• 独有驱动：包含多个未上游化的驱动，例如：
  • xf86-input-ws：源自 OpenBSD，是支持内核所支持的任何指向设备的通用输入驱动，可处理高级触摸板和触摸屏功能。
  • xf86-video-pnozz、xf86-video-mgx、xf86-video-crime 等显卡驱动。
• 加速支持：NetBSD 维护者为 SPARC 和 PowerPC 硬件上的加速器维护驱动，并将过时的 XAA 加速模型迁移到了更简单、更现代的 EXA 模型。此外，还更新了开源的 Nvidia 驱动以支持 EXA 加速，以服务于使用嵌入式 Nvidia 芯片的旧平台。

3. 客户端程序与集成问题

• 程序保留：NetBSD 包含了历史上 X.Org 发行版中的所有程序，如 xterm、xbiff、bitmap（1位像素绘图工具）和 xmh（邮件前端）等，其中一些程序可能已不常用。
• 拼写检查集成：X 内置的文本编辑器 xedit 的拼写检查功能依赖于外部的 ispell，配置过程繁琐。NetBSD 自带的基本拼写检查器 spell(1) 未与 xedit 集成，流程有待优化。

4. 字体与界面元素

• 字体：提供点阵和可缩放字体，且字体大小可根据屏幕尺寸自动缩放，以支持 HiDPI 显示和小型移动设备。
• 不足：目前缺少可缩放的光标主题，也缺乏用于日文的高分辨率字体。

5. 未来展望

• 硬件支持：新硬件通过通用内核驱动（如 modesetting 或 wsdisplay）即可自动获得支持。
• 挑战与选择：
  • 应用程序运行依赖更大的开源生态系统，而该生态变化频繁且易分散注意力。
  • 将代码上游化到 X.Org 是一个持续过程，但某些内容可能永远不适合上游。
  • 用户在 NetBSD 上也有其他选择，例如通过 pkgsrc 安装原版模块化 X.Org，或使用其他图形环境。

使用智能插座、Prometheus和Grafana监控能耗

本文介绍了作者如何利用智能插座、Prometheus和Grafana搭建家庭能耗监控系统，实现对多种电器设备长期功耗的观察与分析。

核心组件

• 智能插座：采用athom.tech的EU V3型号，预装Tasmota固件，可通过网页界面管理并更新固件。
• 数据收集：在家庭服务器上为每个插座运行tasmota-power-exporter实例，由Prometheus每秒抓取一次数据。
• 可视化：复用已有的Grafana实例，创建图表展示功耗数据，并将图表的最小步长设置为1秒以获取详细数据点。

关键观察与发现

• 电热水器：功耗最高，典型日耗电量为4.51千瓦时，范围在0.56至11.1千瓦时之间。
• 家庭服务器：
  • Zimaboard功耗极低，空闲约2瓦，典型负载约7瓦。
  • ISP提供的路由器/调制解调器功耗恒定较高（12-14瓦）。
  • ASRock Deskmini X300的空闲功耗（15-20瓦）远高于Zimaboard。
• 电压变化：监测发现电压存在季节性趋势，在用电高峰时段普遍下降。大功率电器（如电热水器、电水壶）运行时也会导致所有插座的电压短暂下降。
• 工作站设置：包括显示器、扩展坞等，典型功耗45-60瓦，峰值可达90-110瓦。
• 充电模式：大多数设备充电初期速度快，后期速度减慢并进入涓流充电。电动自行车电池的充电模式略有不同。
• 系统稳定性：智能插座偶尔会出现数据上报延迟或完全断网的情况，可能需要重新启动。

未来计划

作者计划利用智能插座的远程开关功能（如通过API或HTTP），结合Home Assistant或脚本，实现根据电价自动开关设备。

总结

该监控系统提供了可靠的长期能耗测量，帮助作者量化评估设备能效，消除了猜测。文章推荐了相关的FOSDEM 2024演讲以供进一步参考。

研究摘要

研究背景
本研究由NASA喷气推进实验室的Kasthuri Venkateswaran博士主导，获得Ames太空生物学资助，聚焦于从国际空间站（ISS）分离的细菌菌株。研究对象为对多种抗生素具有耐药性的Enterobacter bugandensis细菌。

关键发现

1. 菌株分离与突变：从ISS中分离出13株E. bugandensis菌株。这些菌株在太空环境（微重力、辐射、高二氧化碳水平等压力下）发生基因和功能突变，与地球上的同类细菌显著不同。
2. 存活与共存：突变后的菌株能在ISS环境中长期存活并保持较高丰度，同时与其他微生物共存，甚至可能协助其他微生物生存。
3. 环境适应性：封闭人造环境（如ISS）的极端条件迫使微生物适应并演化出独特特征，这可能增加其致病性或耐药性风险。

研究意义

• 为理解微生物在极端环境中的演化机制提供新见解。
• 有助于开发针对宇航员健康的预防措施，减少太空任务中的微生物感染风险。
• 对封闭环境（如航天器、空间站）的微生物控制具有重要指导意义。

论文信息

• 标题：Genomic, functional, and metabolic enhancements in multidrug-resistant Enterobacter bugandensis facilitating its persistence and succession in the International Space Station
• 期刊：Microbiome（2024年3月23日发表）
• 资助来源：NASA太空生物学任务编号NNH12ZTT001N（资助号19-12829-26）等。

Supertone Shift是一款基于AI的实时语音变换软件，支持Windows 10及以上（64位）和MacOS 10.14及以上系统。其主要功能包括：

• 提供100多种不同声音效果，用户每月可免费体验，适用于游戏、VTubing和内容创作等场景。
• 支持将用户声音与角色声音混合，并可调节音调、情感等参数，定制独特声音。
• 具有实时处理和低延迟能力，确保最佳沉浸式体验。
• 采用AI进行高质量语音转换，准确捕捉声音细微变化，无需GPU即可实现高性能转化。
• 提供即时角色声音特效，提升趣味和互动性。
• 产品有多种定价方案，包括免费及付费版，分别针对初学者、游戏玩家、VTuber和内容创作者，费用从每月$3.99到购买单独声音$149.99不等。
• 用户可通过官方指南获取详细功能介绍和操作说明。
• 平台定期推出新声音和新闻更新。

Go 1.22 中的安全随机性

计算机本质上不具备真正的随机性。传统上，编程语言区分统计随机性（用于模拟、采样等非安全场景，如 math/rand）和密码学随机性（用于密钥生成等安全场景，如 crypto/rand）。Go 1.22 的关键改进是将 math/rand（及 math/rand/v2）的默认随机数生成器升级为基于密码学的 ChaCha8Rand，从而在不破坏兼容性的前提下，极大地提升了程序默认的安全性。

传统统计随机数生成器的缺陷

1. 线性同余生成器 (LCG)：如早期Unix的 rand，其内部状态可轻易被单个输出值反推，且低位存在明显规律，完全不具备安全性。
2. Go 1 生成器：基于线性反馈移位寄存器。生成607个随机数后，其全部内部状态将暴露无遗，攻击者可轻松预测后续所有输出，甚至推算历史值。
3. PCG生成器（math/rand/v2 原默认）：更现代、统计质量更好，但本质上仍是可预测的统计生成器，其内部状态仍可能被逆向工程。

这些生成器的设计初衷并非用于安全敏感场景。开发者若在需要密码学安全的地方（如生成密钥）误用了 math/rand，将导致严重的安全漏洞。

Go 1.22 的解决方案：ChaCha8Rand

Go 1.22 引入了一个基于 Daniel J. Bernstein 的 ChaCha 流密码的新生成器 ChaCha8Rand（实现为 rand.ChaCha8），作为 math/rand 和 math/rand/v2 的默认源。

• 设计基础：采用8轮ChaCha算法（ChaCha8），在安全性和速度之间取得平衡。
• 关键特性：
  • 种子与初始化：使用操作系统提供的32字节密码学安全熵作为种子。
  • 密钥轮换：每生成16个块（1024字节）后，使用当前块末尾的32字节作为下一个16块的新密钥。这提供了前向安全性：即使当前内存状态被泄露，攻击者也无法解密之前的输出。
  • 优化：对标准ChaCha8进行了微调，如移除部分重复计算，并定义了更适合随机数生成的数据序列。
• 实施与影响：
  • Go运行时为每个CPU核心维护一个独立的ChaCha8Rand状态，避免了锁竞争，性能良好。
  • math/rand/v2 的函数始终使用新的生成器。
  • 在未调用 rand.Seed 的 math/rand 包中，默认自动使用ChaCha8Rand，立即提升了现有代码的安全性。
  • 用于初始化Go map 的哈希种子也改用ChaCha8Rand生成，以防御哈希碰撞拒绝服务攻击。

带来的益处

1. 消除重大安全隐患：将开发者误用 math/rand 生成密钥等敏感数据的风险，从“严重安全事件”降级为“普通错误”。即使意外使用了非密码学接口，其输出现在也具备了很强的不可预测性。
2. 解决其他不可预测性需求：在生成通用唯一标识符（UUID）或实现负载均衡等场景，即使攻击者知道算法，也无法通过观测输出来预测或操纵后续结果，因为生成器已从内部状态可推算变为密码学安全。
3. 性能可接受：虽然比旧生成器慢，但在现代服务器上，差异通常仅为纳秒级别，极少成为瓶颈。在某些32位系统上甚至比PCG更快。

结论

Go 1.22 通过将 math/rand 的默认随机数生成器升级为密码学安全的 ChaCha8Rand，在不改变现有代码的前提下，大幅提升了程序默认的安全性。它有效地缩小了“统计随机”与“密码学安全随机”之间的鸿沟，减少了因常见编程错误导致的安全漏洞。Go 语言鼓励其他编程环境也考虑采用类似策略，将密码学强伪随机数生成器作为默认选项，以从根本上增强系统安全性。

年度Braun收藏家集市见闻

活动背景与Braun的设计历史

Braun+Design Börse（Braun集市）是德国科隆贝格Braun总部举办的年度盛会，始于1982年，旨在为全球Braun产品收藏家提供交流平台。Braun自1955年与乌尔姆设计学院合作，在迪特·拉姆斯领导下成为设计界标杆，其经典设计深刻影响了苹果等品牌。如今在现任设计总监奥利弗·格拉贝斯的带领下，Braun重获关注。

集市现场体验

集市于上午10点至下午4点开放，门票仅需4欧元，现场提供咖啡点心，户外有街头小吃摊。场地紧凑密集，主要展售60至80年代的Braun产品，同时也涵盖苹果、赫曼米勒、Vitsoe等其他设计品牌。

可找到的产品种类繁多：包括Hi-Fi音响、吹风机、风扇、手表（如作者评测过的AW50）、海报、榨汁机、剃须刀等。这里既是寻找特定藏品的宝地，也能发现未知产品。例如作者遇见了《Soft Electronics》一书作者贾罗·吉伦斯，并获得了签名。

现场亮点包括：

• 经典产品堆叠展销，如全新状态的Braun SK1收音机（经修复翻新）
• 意大利设计经典Brionvega Algol电视机
• 儿童电子实验套件
• 迪特·拉姆斯1961年设计的T52便携收音机（启发了Teenage Engineering 2022年的OB-4）
• 1963年肯尼迪总统法兰克福演讲中使用的Braun HL1台扇

作者采购收获

作者现场选购了多件物品：

• 手表与配件：Braun AW 20、AW 10手表及米兰尼斯不锈钢表带
• 家用电器：罕见的橙色Braun 550吹风机、Braun Citromatic MPZ2榨汁机
• 收藏品：白色限量版Braun ET66计算器、《Braun五十年设计与创新》书籍、《Soft Electronics》签名书、汉斯·古格洛特相关德文书籍、Braun手表宣传单
• 其他：menu.as品牌的胡桃夹、不锈钢小酒杯

价格依据产品状况浮动：使用痕迹明显的约30-40欧元，保存完好的价格更高。

评价与展望

初次参观的作者对活动氛围、参与者及现场能量印象深刻，认为这是Braun和迪特·拉姆斯爱好者的理想聚集地。他建议现场需要多次巡视才能发现所有展品，并计划明年带着更明确的购物清单再次参加，与更多收藏同好交流。

这篇文章介绍了在Clojure中利用Java虚拟线程管理吞吐量的方法，重点是如何在虚拟线程环境下控制并发请求速率，以及实现无序并行处理。文章的主要内容包括：

1. 虚拟线程与吞吐量控制背景

• Java 21引入虚拟线程后，传统的线程池（如claypoole）不再适用，因为虚拟线程不应被池化（它们不是稀缺资源）。
• 如何在使用“无限”线程的同时限制吞吐量？文章使用Java的Semaphore类实现基于令牌桶的速率限制。

2. 虚拟线程与无序并行

• 使用Executors/newVirtualThreadPerTaskExecutor创建虚拟线程执行器。
• 结合ExecutorCompletionService实现无序并行处理：任务按完成顺序返回结果，而非提交顺序，有助于减少延迟。
• 通过自定义的upmap函数（类似无序的pmap）演示如何提交任务并获取已完成结果。

3. 使用信号量实现速率限制

• 通过Semaphore控制并发许可数，例如创建公平信号量以防止任务饥饿。
• 实现rate-limited-sem-release函数：任务执行前获取许可，完成后启动新虚拟线程在指定时间后释放许可，模拟令牌桶的速率限制。
• 注意Thread/sleep的精度可能略有误差，但在大多数场景下足够准确。

4. 优化结果获取流程

• 最初实现中，信号量阻塞了任务提交循环，导致结果无法及时获取。
• 解决方案：将任务提交循环放入单独的虚拟线程中执行，这样即使提交循环阻塞，主程序仍能通过CompletionService及时获取已完成任务的结果。
• 最终实现的upmap函数能在限速的同时，实时返回任务结果，提升用户体验。

5. 关键点总结

• 虚拟线程避免使用线程池，转而通过信号量控制吞吐量。
• 无序并行处理能减少整体延迟。
• 该方案完全基于Clojure与Java的紧密集成，无需外部依赖。
• 示例代码展示了如何结合虚拟线程、ExecutorCompletionService和Semaphore实现高效的并发控制。

整体而言，文章提供了一种在Clojure中利用Java虚拟线程进行吞吐量管理的实用方法，兼顾速率限制和处理效率。

简单性是优势，但复杂性往往更受追捧（2022）

本文探讨了简单性与复杂性在工作评价和系统设计中的不同境遇。作者引用Dijkstra的名言指出，尽管简单性是一种美德，但复杂性往往更受青睐。

复杂性更受追捧的原因

• 象征努力：复杂作品被视为投入了更多心血，因此被认为更具挑战性和价值。
• 象征 mastery：复杂系统暗示设计者精通各个部分并具备整合能力，难以理解的内容则显得专业。
• 象征创新：与复用现有组件相比，从头构建的系统或全新架构被认为更具新意。
• 象征功能丰富：拥有更多可混合搭配组件的系统显得更灵活、更能应对变化。

这导致了一种复杂性偏见，使我们过分推崇复杂的构想和系统。

简单性的优势

• 易于理解与使用：更容易被采纳并产生影响，便于沟通和获取反馈。
• 易于构建与扩展：需要更少组件，便于实现、维护和扩展。例如，Instagram在2012年被收购时，仅用13人团队就通过坚持使用经过验证的成熟技术（如PostgreSQL和Redis）服务了数千万用户。
• 运营成本低：部署后的维护成本更低，寿命更长。
• 更可靠：活动部件更少，不易出错，也更容易修复和升级。

在机器学习领域，简单技术并不一定表现更差。例如，在表格数据上，树模型常优于深度神经网络；在推荐系统中，点积方法常常胜过深度学习方法。

奖励复杂性的问题

• 激励不必要的复杂化：人们为了获得奖励而将事情过度复杂化。
• 助长“非我发明”心态：倾向于从零开始构建而拒绝复用，浪费资源且效果不佳。
• 晋升和论文评审流程过于强调工作产物的复杂性。

如何正确看待复杂性

• 目标应用简单方案解决复杂问题：简单方案体现了对问题的深刻洞察。
• 考虑多个聚焦方案：而非一个全能的复杂方案，后者往往耦合度高，难以维护和弃用。
• 运用奥卡姆剃刀原则：最简单的方案或解释通常是最优的。在引入复杂性前，应权衡其成本与收益。

附录讨论

回应指出，“非我发明”心态存在一种对立偏见：人们可能因熟悉而偏好复杂组件，同样浪费资源。有时，为了真正简化，确实需要构建新方案，但必须谨慎以避免引入新的复杂性。一些库和框架为了“开发者体验”而过度增长，这也反映了复杂性偏见。

Java 22 Foreign Function API 调用 C 库指南摘要

本文介绍了如何使用 Java 22 的 Foreign Function and Memory (FFM) API (java.lang.foreign) 来调用 C 标准库函数（如 fopen, fgets, fclose）。该 API 旨在替代传统且复杂的 Java Native Interface (JNI)，允许开发者无需编写 C 代码即可从 Java 调用外部函数。

API 核心概念与优势

• 目的：提供一种更安全、更 Java 化的方式调用现有 C 库，尤其适用于无法用 Java 重写的库。
• 对比 JNI：避免了编写 C 代码的风险和复杂性，虽然代码量可能较大，但更安全。
• 关键组件：
  • MemorySegment：相当于 C 指针，用于表示内存地址。
  • Arena：内存分配器，管理 MemorySegment 的生命周期和内存释放，有助于避免内存泄漏。
  • Linker：用于链接本地库和创建函数调用句柄。
  • SymbolLookup：查找库中函数的地址。
  • FunctionDescriptor：描述 C 函数的签名（返回类型和参数类型）。
  • MethodHandle：用于实际调用外部函数。

使用步骤（以调用 C 标准库为例）

1. 初始化基础设置：

   • 创建一个 LibC 类，初始化 Arena、Linker 和 SymbolLookup。

   Linker linker = Linker.nativeLinker();
   SymbolLookup lib = linker.defaultLookup();
   

2. 描述与绑定函数：

   • 查找地址：使用 lib.find("函数名") 获取函数的 MemorySegment（地址）。
   • 描述签名：用 FunctionDescriptor.of 定义函数的返回类型和参数类型（如 ADDRESS 表示指针，JAVA_INT 表示整数）。
   • 创建句柄：使用 linker.downcallHandle(address, descriptor) 创建 MethodHandle。

   // 示例：描述 fopen
   MemorySegment fopenAddress = lib.find("fopen").orElseThrow();
   FunctionDescriptor fopenDesc = FunctionDescriptor.of(ADDRESS, ADDRESS, ADDRESS);
   MethodHandle fopen = linker.downcallHandle(fopenAddress, fopenDesc);
   

3. 创建公共方法：

   • 为每个 C 函数创建 Java 方法，通过 Arena 分配内存（如字符串参数），然后调用对应的 MethodHandle。

   MemorySegment fopen(String filePath, String mode) {
       MemorySegment pathPtr = allocator.allocateFrom(filePath);
       MemorySegment modePtr = allocator.allocateFrom(mode);
       try {
           return (MemorySegment) fopen.invoke(pathPtr, modePtr);
       } catch (Throwable e) {
           return MemorySegment.NULL;
       }
   }
   

完整示例：读取文件

文章通过一个完整的示例演示了流程：

1. 在 LibC 类中分别绑定 fopen、fgets 和 fclose 函数。
2. 在 Runner 类的主方法中：
   • 使用 try-with-resources 创建并自动管理 Arena。
   • 调用 fopen 打开文件。
   • 分配一个缓冲区 MemorySegment，循环调用 fgets 读取内容并打印。
   • 调用 fclose 关闭文件。
3. 运行时需启用预览特性：java --enable-preview --source 22 Runner.java。

重要注意事项

• 内存管理：几乎所有通过 API 创建或从 C 获取的内存段都必须与一个 Arena 关联，以确保内存安全和自动释放。
• 工具：文中提到 jextract 工具可以从 C 头文件自动生成绑定代码，可大幅减少手动编码工作。
• 适用场景：FFM API 最适合调用无法在 Java 中实现的外部库。对于已存在于 Java 标准库中的函数，直接使用 Java 方法更高效。

该 API 提供了一种强大且相对安全的机制来集成现有的 C 代码库，尽管需要一些样板代码，但通过 jextract 等工具可以缓解此问题。

文章摘要

本文作者基于个人多次面试失败经历（包括两次申请同一家公司的经历）以及担任面试官的经验，对编程面试的有效性提出质疑。

核心观点：

1. 模式化面试的局限性：作者作为面试官，已进行过上百次套路化的编程面试，自己也曾通过类似面试，但认为这种评估方式效果有限。他指出，在一小时面试中考察候选人是否掌握数据结构和算法，可能不如直接教授这些知识更有效。
2. 理论与实践的脱节：面试要求候选人在短时间内提出最优解，但实际工作中，解决问题的过程往往比立即给出完美答案更重要。然而，由于人类偏见，候选人若未能接近正确答案，往往会处于不利位置。
3. 真实经验 vs 面试表现：作者分享了一个实例：他曾花费一个月时间，成功整合SQL Server的CDC流数据与表快照，实现了线程安全、并发优化、容错等复杂功能。该成果完全符合某公司面试题的要求，但在面试中，他却未能有效展示类似能力，这凸显了面试题目可能无法真实反映候选人解决实际复杂问题的能力。
4. 对面试文化的批评：作者认为当前许多公司（尤其是大公司）的面试方式存在“货物崇拜”心理，盲目照搬他人做法。虽然理解公司因惧怕招错人而采取谨慎措施，但他质疑现有方法是否真正有效。
5. 特殊经历与吐槽：作者提及两次申请StackOverflow均告失败。尤其对第二次面试中“将十进制数转换为负二进制”这一题目耿耿于怀，认为其过于注重技巧性，属于他所遇到的最“套路化”的问题。

结论：作者表示将继续练习以通过面试，但内心对现有编程面试模式能否准确筛选人才持怀疑态度。

文章讲述了作者为房屋建造设计家具时，如何利用CSS Grid布局技术开发了一个名为“Squareplanner”的在线工具，从而避免使用专业CAD软件或手工绘图的繁琐过程。

背景与问题

作者在建房过程中需要设计厨房、浴室橱柜和卧室衣柜等MDF板材家具。传统方式依赖专业设计师使用3D CAD软件，但作者希望自行掌控设计，以更高效地沟通想法。其妻子尝试用Adobe Illustrator手工绘图，但修改困难、耗时且容易出错。作者意识到，家具设计本质上是将多个矩形排列在有限区域内，且矩形尺寸需按特定规则响应修改。

解决方案：利用CSS Grid

作者决定借助现代浏览器的CSS Grid布局能力，它能够高效地处理矩形排列。他设计了一种自定义的简洁文本描述语言，用于定义家具的尺寸、布局和模块划分。例如：

• cabinet 200cm x 95cm top 3cm bottom 14cm scale 5 定义柜子的整体尺寸。
• 使用 * 表示自动适配，<、>、^ 表示延续相邻模块。
• 支持注释（#开头）和颜色标记（如drawer:red）。

用户编写这段文本后，工具会将其转换为HTML和CSS，通过浏览器渲染出可视化的2D布局图，并能实时编辑和预览。

工具特点与功能

1. 实时编辑与预览：用户可在文本输入框中直接修改描述，布局图会即时更新。
2. 共享与锁定：设计状态可存储在URL中（利用hash），便于分享；通过快捷键Ctrl+Alt+L可锁定编辑器，防止误改。
3. 格式化与打印：支持代码格式化（Ctrl+Alt+F），并优化了打印样式，方便导出PDF用于现场施工。
4. 轻量级实现：纯前端实现（HTML、JavaScript、CSS），无框架依赖，代码简洁（约550行），适合静态托管。

实际应用与价值

该工具成功用于作者的家具设计，并协助了橱柜制造商、台面供应商以及施工过程中的管线定位。它显著降低了设计迭代的成本和时间，使作者能够快速原型测试各种方案。作者认为，利用现代浏览器的技术能力，即使没有专业软件，也能高效解决复杂设计问题，并希望该工具对类似需求者或CSS Grid学习者有所帮助。

总结

文章展示了如何将Web前端技术（特别是CSS Grid）创造性应用于实际生活问题，通过开发一个简单而有效的文本转图形工具，实现了家具设计的自主化、可视化和低成本协作。

Grace 版本控制系统摘要

核心概念与设计目标

Grace 是一款为人工智能时代设计的版本控制系统。其核心理念是对人类保持友好（kindness to humans），同时为AI 代理（agents）提供速度（velocity），旨在帮助开发者在以代理速度交付代码时，保持冷静、可控和心流状态。

它不仅包含传统版本控制系统的基本功能，还引入了原语，用于监控代理、捕获其工作内容，并支持使用确定性检查和可自定义的 AI 提示进行实时审查。Grace 假设 AI 应深度集成到版本控制系统中，能够响应事件、审查变更并生成所需内容。

除代码版本管理外，Grace 还设计为能捕获工作项、提示词、规范、模型版本等构成代理式编码的完整上下文，以便开发者和代理能更成功地完成工作并自信地进行审查。用户只需指示代理运行 grace agent bootstrap 即可开始会话，Grace 和代理将自动完成其余设置与捕获工作。

核心特性

• 促进而非合并（Promotion over Merge）：使用“提升队列”，根据用户设定的规则和置信度自动解决提升冲突。
• 实时捕获与监控：通过 grace watch 命令，在后台连续监视工作目录变更，在文件保存后约一秒钟内将新版本保存至服务器，为其他命令提供最新状态。
• 持续审查系统：将 AI 评估与人工审查/批准整合在一个流程中。核心概念包括策略快照、第0阶段分析、提升队列、集成候选、检查门、证明书以及易于理解的审查报告包。
• 支持自动化：提供 Webhook 和审批原语，以支持审查和提升工作流的自动化。
• 高速与可扩展性：设计为多租户系统，能支持海量仓库、大量开发者和代理、以及任意大小的超大文件和二进制文件。

技术栈

• 主要语言：F#
• 框架与核心：ASP.NET Core（Web API）、Orleans（虚拟 Actor 与分布式系统核心）
• 云服务（Azure PaaS）：
  • Azure Cosmos DB：用于存储 Actor 状态（仓库、分支、引用、目录版本等），支持超大规模和高速访问。
  • Azure Blob Storage：用于存储对象和工件，包括（理论上）无限大小的二进制文件。
  • Azure Service Bus：用于事件流，支持钩入。
• 其他组件：Redis（用于缓存和 SignalR）、SignalR（用于实时客户端-服务器协调）、Aspire（用于编排本地开发和云部署）、Avalonia（计划用于跨平台 GUI）。

本地运行与设置

Grace 被设计为云原生系统，本地运行相对复杂。它使用 Aspire 来简化流程。

1. 前提条件：需安装 .NET 10 SDK、PowerShell 7+、容器运行时（Docker Desktop 或 Podman）。
2. 基本流程：
   • 运行 Aspire AppHost 项目启动本地模拟器和 Grace 服务器。
   • 使用 Grace CLI 进行操作。
   • 停止 AppHost 会同时停止所有服务。
3. 快速入门（约10分钟）：
   • 克隆仓库，构建解决方案，为 CLI 创建别名。
   • 运行 pwsh ./scripts/dev-local.ps1 启动服务器，会自动生成个人访问令牌。
   • 使用 CLI 命令创建所有者、组织、仓库，并连接到仓库、初始化内容。

重要提示：可以同时使用 Git 和 Grace，但需在各自的忽略文件（.gitignore 和 .graceignore）中忽略对方的目录（.grace 和 .git）。当前版本仍为Alpha 版，不适用于生产环境，建议在非关键仓库中进行测试。

架构设计

1. 服务器与 Actor 系统：基于 Orleans 的 Actor 模型，实现自然、轻松的水平扩展。
2. 事件溯源：将每一次对实体的修改存储为事件，作为真理之源，并据此预计算和缓存投影以提升性能。
3. 对象存储：依赖云对象存储（目前为 Azure Blob Storage）提供安全、无限扩展的存储层。大文件可采用基于清单（manifest）的内容寻址存储，以提高效率。
4. 实时监控：grace watch 提供后台变更跟踪与保存，极大提升会话效率。
5. 审查与自动化：持续审查系统、Webhook 和审批机制共同支持从代码提交到集成的自动化与人工审核流程。

开发流程

Grace 开发遵循“任务记录优先”流程，确保人类和代理的工作均可审查：

• 从阅读 AGENTS.md 文件开始。
• 使用 GitHub Issue 模板创建任务，明确定义目标、上下文、路径、风险、验证标准和完成定义。
• 基于 origin/main 创建独立的工作树。
• 以垂直切片（vertical slices）为单位工作，每次只证明一个公开行为。
• 通过快速、有针对性的命令进行验证，并运行完整的验证脚本。
• 每个切片完成后提交，并保持 PR 聚焦。及时更新文档。

未来路线图

Grace 处于快速迭代中，计划包括：

• 开发原生跨平台 GUI（非 Electron）。
• 继续重写对象存储层，强化基于清单的内容寻址存储。
• 支持多哈希语义（如增加 BLAKE3）。
• 开发 grace cache 功能以用于 CI/CD 和办公场景。
• 改进数据库背压处理。
• 增强代理技能以创建和更新自动审查策略。
• 改善入门体验、默认设置，增加更多测试。

theDesk 桌面环境

项目简介

theDesk 是一个基于 Qt 库构建的桌面环境。

依赖项

核心依赖

• Qt 5：包括 Qt Core、Qt GUI、Qt Widgets、Qt SVG 模块。
• the-libs
• libtdesktopenvironment
• Xlib
• xorg-libinput
• NetworkManager-Qt

推荐依赖

• contemporary-widgets：默认的控件主题。
• contemporary-icons：默认的图标主题。

构建与安装

构建步骤

在终端中执行以下命令：

mkdir build
qmake ../theDesk.pro
make

安装步骤

在 Linux 系统上，使用超级用户权限在终端中执行安装命令。

许可证

本项目由 Victor Tran 于 2021 年创建，基于 GNU 通用公共许可证第三版（GPLv3） 或（根据您的选择）任何更高版本授权。详细信息请查阅项目中的 LICENSE 文件。

如何逃离本田的隐私困境

现代汽车被Mozilla基金会称为“轮上的监视机器”，其在所有25个受评汽车品牌中均未能提供足够的隐私保护。汽车通过传感器、麦克风和摄像头收集的数据远超出运行所需，并且经常在用户不知情的情况下将信息分享或出售给第三方。

数据收集范围

汽车可能收集的数据范围极其广泛，包括性生活数据、生物特征数据、人口统计信息、种族、性取向、性别等。尽管车企不一定都会利用这些数据，但它们都保留了这样做的可能性。这些数据可能带来实际风险，例如：通知保险公司急刹车或加速行为、在用户不知情下向执法部门分享信息、甚至可能被用于追踪个人行踪。

关闭数据收集的困难

以本田为例，作者尝试关闭数据共享的经历异常繁琐：

1. 在车内点击关闭按钮时，收到“网络无效，无法更改设置”的错误提示。
2. 经销商告知必须下载本田官方应用程序（HondaLink），并同意其长达14页的条款。
3. 最终在下载应用后，仍需在车内操作才成功关闭，整个过程耗时一个月。
4. 关闭后，车载屏幕上会永久显示一个醒目的橙色通知，提示数据共享已关闭，这是一种旨在促使用户重新开启的“黑暗模式”。
5. 数据收集只能全开或全关，无法选择性关闭。例如，想要紧急碰撞救援功能，就必须允许收集所有其他数据。

查看与删除数据的限制

作者尝试通过本田的隐私请求页面查看汽车收集的数据，但被告知只有居住在加州、科罗拉多、康涅狄格、犹他或弗吉尼亚州的用户才能行使查看或删除数据的消费者权利。通过电话申请后，请求仍被拒绝。

行业现状与政府行动

• 数据流向：汽车收集的详细驾驶习惯数据（如超速、急刹车）可能通过数据经纪商出售给保险公司，导致保费上涨。
• 专家看法：电子前沿基金会（EFF）的专家将当前汽车数据收集的状况比作2010年左右的智能手机或早期频繁被入侵的物联网设备。
• 立法尝试：美国参议员埃德·马基已向汽车公司询问数据收集详情，并要求FCC调查汽车制造商向警方发送位置数据的行为，政府对汽车数据行业的关注正在增加。

结论

汽车制造商的隐私政策往往冗长晦涩，关闭数据收集功能困难重重，且用户查看自身数据的权利受到地域限制。尽管立法层面开始受到关注，但用户目前仍难以在享受车辆功能的同时真正掌控自己的隐私。

基于Arena的解析器

这是一个关于解析器、内存分配与Arena机制的微型书籍。作者使用Rust编写了一个解析器，用于解析Ruby代码。这一改进使得该解析器的性能从37MB/s提升至80MB/s（约2倍提升）。

通过这一改变，解析器成功完全消除了所有堆内存分配，从而能够在Rust的#[no_std]模式下运行。解析结果完全存储在Arena内存区域中，这意味着底层内存块可以被整体写入磁盘，并在后续通过内存映射（mmap）快速重新加载，从而显著简化了抽象语法树（AST）的缓存过程。

该代码目前处于“实验性”阶段，托管于arena-fixes分支（从Git仓库运行时需启用--features=development标志）。作者表示不会正式发布此解析器，并建议需要Ruby解析器的用户尝试使用Prism（其Rust绑定可在crates.io上找到）。整个工作更像是一次实验，旨在探索此类优化是否具有实际价值。

文章标题： "Meta spent almost as much as the Manhattan Project on GPUs in today's dollars"

内容摘要：
提供的文章内容未能正常加载，显示错误消息："Something went wrong, but don’t fret — let’s give it another shot. Some privacy related extensions may cause issues on x.com. Please disable them and try again." 该错误指出由于隐私相关扩展可能导致问题，建议禁用这些扩展后重新尝试访问。标题暗示Meta公司在GPU上的支出与曼哈顿计划的现代美元成本相当，但实际文章内容未成功获取，无法提供详细信息。

本文探讨了在神经网络大语言模型（LLM）盛行的当下，n-gram语言模型是否仍然有价值。研究给出了肯定的回答，并展示了其在文本分析及改进神经网络LLM方面的作用。为此，作者从两个维度对n-gram模型进行了现代化升级：

1. 扩大训练数据规模：模型在多达5万亿token的数据上进行训练，构建了有史以来最大的n-gram语言模型。
2. 突破n值限制：传统n-gram模型因n值较小而性能受限。作者引入了支持任意长度的∞-gram模型，并带有回退机制。

为高效实现任意n值的概率计算（而非预先计算昂贵的n-gram计数表），研究团队开发了名为infini-gram的引擎。该引擎基于后缀数组技术，能在毫秒级延迟内计算∞-gram及任意n值的n-gram概率。

∞-gram框架和infini-gram引擎使得对人类撰写和机器生成文本进行新颖分析成为可能。研究主要发现包括：

• ∞-gram模型在下一个token预测上具有较高的准确率（47%），并能与神经网络LLM互补，显著降低其困惑度。
• 在分析机器生成文本时，观察到机器与∞-gram模型之间在一致性程度上存在与后缀长度相关的不规则现象，这揭示了神经网络LLM预训练过程及其Transformer位置编码可能存在的不足。

ABI 兼容性测试工具 abi-cafe 的演进与核心挑战

本文探讨了不同编译器生成的代码之间通过外部函数接口（FFI）交互时，应用程序二进制接口（ABI）兼容性测试的复杂性，并介绍了作者开发的工具 abi-cafe 及其 2.0 版本的改进。

1. abi-cafe 的起源与 1.0 版本

• 起因：作者最初因 __int128 类型在 GCC、Clang 和 Rust 的 FFI 交互中表现不一致而开发了 abi-cafe。这导致在 x64 Linux 上，三种编译器对该类型的传递方式各不相同，无法正确互操作。
• 工作原理：abi-cafe 1.0 通过抽象地描述函数签名，为调用方（caller）和被调用方（callee）分别生成 Rust 或 C 代码。代码执行后，双方通过回调“报告”所见的值（例如，将值的字节复制到缓冲区）。测试框架比较双方报告的值，以此判断 ABI 是否一致。该方法无需预知 ABI 应该是什么，而是基于实际运行结果进行判断。
• 局限性：测试用例的格式限制了其表达能力，难以描述枚举、联合和复杂的类型双关（type pun）。生成的代码结构混乱，可维护性差。

2. abi-cafe 2.0 的动机与 kdl-script

• 改进目标：abi-cafe 2.0 旨在彻底重写，以支持更复杂的类型系统测试，特别是标签联合（tagged unions）和类型双关。
• 核心组件 kdl-script：这是一个用于定义类型和函数签名的领域特定语言（DSL）。它允许开发者以声明式的方式描述需要测试的函数签名和数据结构，并能够为不同语言（如 Rust、C/C++）定义不同的类型表示（pun 类型），以便测试它们在 ABI 层面的兼容性。
• 进展：作者已实现 kdl-script 编译器和 Rust 后端，可以成功使用标签联合进行自测试（rustc 对比自身）。

3. 测试中“值一致”的定义与挑战

abi-cafe 的核心思想是比较双方“报告”的原始值。对于复杂类型，报告的是其包含的原始类型字段的值。关键在于双方对字段的报告顺序必须一致，这由测试框架生成的代码顺序来保证。

• 基本类型：报告值的字节。作者使用了一种“涂鸦值”（graffiti values）策略，通过精心设置的字节值来直观发现错误。
• 复合类型（如结构体）：忽略可能不同的填充字节，只报告每个原始字段的值。
• 标签联合：需要额外报告区分具体变体（variant）的标签值。
• 无标签联合与类型双关：这是主要挑战。当两种语言对同一个 ABI 兼容类型的类型结构理解不一致时（例如，Rust 的 #[repr(transparent)] 结构体对应 C 的原始类型，或不同语言对相同数据布局有不同层级的结构定义），简单的顺序遍历字段将失效。测试框架需要知道具体的数据变体，并能够“同步”遍历不同形状的类型树。
• 其他复杂情况：包括 Rust 的 Option<&T> 指针优化、在不同平台上使用 #[repr(C)] 模拟原始类型（如用两个 u64 模拟 u128）等，这些都要求框架具备更高级的类型分析和同步遍历能力。

4. 总结

文章阐述了跨语言 FFI 中 ABI 问题的普遍性和隐蔽性，强调了现有规范往往不完整或不准确。abi-cafe 通过实际编译和运行测试代码来暴力验证兼容性，是一种实用的方法。从 1.0 到 2.0 的演进，特别是 kdl-script 的引入，旨在系统性地解决更复杂的类型双关问题。作者承认，实现能够自动同步不同语言间可能不同形状的“类型树”遍历机制，是当前开发中的最大难点和核心 TODO。

文章标题：在 Microsoft Flight Simulator 中使用 JavaScript 自动驾驶仪飞行飞机 (2023)

文章摘要：

这篇文章详细介绍了如何使用 JavaScript 构建一个自动驾驶系统，用于在 Microsoft Flight Simulator 2020 (MSFS) 中控制虚拟飞机。该项目并非用于真实飞机控制，而是通过网页界面操纵一个在 JS 中运行的自动驾驶仪，进而控制 MSFS 中的飞机。

核心架构

系统由三个主要部分组成：

1. API 服务器：使用 Node.js 通过 msfs-simconnect-api-wrapper 与 MSFS 的 SimConnect SDK 通信，实现查询和设置游戏参数。
2. Web 服务器：使用 socketless 库托管前端页面，并通过 WebSocket 与 API 服务器双向通信。
3. 浏览器界面：基于 Leaflet 地图和自定义仪表盘，实现飞行可视化、自动驾驶控制和航点管理。

关键功能

1. 基础自动驾驶模式：
   • 高度保持 (ALT)：通过调整升降舵配平控制垂直速度。
   • 航向保持 (HDG/航向模式)：通过调节副翼配平或直接操纵副翼控制转向。
   • 水平飞行 (LVL)：保持机翼水平，防止左右偏航。
2. 自动油门 (ATT)：自动调节引擎推力以维持目标空速，防止超速或失速。
3. 地形跟随模式 (TER)：利用 JAXA ALOS 高程数据（30米分辨率），自动探测前方地形最高点，并设定安全飞行高度。
4. 航点导航系统：
   • 用户可在地图上放置、编辑、删除航点创建飞行计划。
   • 自动驾驶仪使用基于投影的算法跟踪路径，在航点间平滑过渡。
   • 支持重复巡逻路径和保存/加载飞行计划。
5. 自动起飞 (ATO)：自动执行起飞前检查、油门控制、方向舵校正，直至飞机爬升至安全高度后移交常规自动驾驶。
6. 自动降落 (ATL)：自动寻找附近机场、规划进近航线，并执行降落程序（包括滑行、制动和停机）。

技术实现亮点

• 约束映射函数 (constrainMap)：将值从一个范围映射到另一个范围并夹紧，广泛用于控制输入的计算。
• 热重载：开发期间服务器和客户端代码支持热更新，无需重启。
• 模拟系统：内置 Mock API 和模拟飞机，可在无 MSFS 环境下测试自动驾驶逻辑。
• 高程服务：通过本地 ALOS 高程服务器（Node.js）提供全球地形数据查询，支持点查询和多边形区域最高点查询。
• UI 优化：Leaflet 地图集成飞机标记（显示高度、速度、航向）、飞行轨迹记录、姿态指示器和实时数据图表。

应用场景

该项目可用于：

• 为无内置自动驾驶的飞机添加自动驾驶功能。
• 增强现有自动驾驶仪的易用性和功能（如航点跟踪、地形跟随）。
• 创建完全自动化的飞行任务（如观光飞行、巡逻任务）。
• 作为学习 SimConnect API 和 JavaScript 实时控制系统的教育项目。

结论

通过分步实现和不断优化（如处理特技飞机、无副翼配平飞机等边缘情况），项目最终达到了 JS 可自主完成起飞、航点飞行和降落的全流程自动化。尽管存在微小抖动等优化空间，但整体展示了 JavaScript 在游戏控制领域的强大潜力。

注：本文为技术实现总结，未包含原文中所有代码细节和测试示例。完整代码和教程见 GitHub 仓库 "are-we-flying"。

这篇文章探讨了1995年动画电影《攻壳机动队》如何从一个日本亚文化产品转变为全球性热门作品，并分析了其成功背后的商业策略。

核心背景： 20世纪90年代，动漫在欧美经历了第一次“热潮”。《阿基拉》（1988）在海外的意外成功让日本动画产业意识到国际市场存在商机。万代公司的制作人渡边�的繁雄因此决定，要基于写实风格动画的趋势，有意识地打造面向全球市场的作品。

战略合作伙伴： 渡边繁雄认识到，单靠日本方面难以建立有效的海外发行系统。与此同时，英国的Manga Entertainment公司通过翻译和销售动画录像带，已在欧美市场取得成功，并建立了“草根”式的发行网络。该公司由唱片行业出身的管理层运营，擅长用音乐营销策略（如针对漫画店、唱片店和大学社团进行推广）来销售动画。

《攻壳机动队》的诞生与制作：

• 万代与Manga Entertainment在1993年合作，计划制作《攻壳机动队》，使其成为《阿基拉》的继承者，一部明确瞄准日本及全球市场的动画电影。
• 导演押井守因其作者风格被选中，尽管有人担心这与漫画原作风格不符。编剧伊藤和典撰写的剧本经过了Manga Entertainment长达25页的详细评估和讨论，进行了一些修改以更符合西方观众的口味，但押井守本人表示在角色和故事上并未做特别改变。
• 影片制作周期仅10个月，预算约300万美元。

发行与成功：

• 影片在日本本土票房表现平平，西方影评人最初也因其复杂性而认为它难以获得大众认可。
• 然而，在Manga Entertainment的精心运作下，影片于1996年通过限量影院放映和录像带发行取得了巨大成功。其策略包括：先通过有限的影院放映（尤其在纽约反响热烈）预热市场；利用已建立的零售网络（特别是唱片店）重点推广；以及持续数年的市场教育铺垫。
• 结果，《攻壳机动队》成为首部登上《公告牌》每周录像带销售榜榜首的动画电影，五个月内仅在美国就售出超过20万盘录像带。到2001年，其录像带销量估计超过50万盘。

影响与意义：

• 《攻壳机动队》的商业成功证明，有策略地合作可以将日本动画推向主流西方市场。它帮助动漫走出了之前的“邪教”地位，促进了动漫在欧美零售渠道的“主流化”。
• 这部电影的成功为押井守等创作者的后续项目争取资金创造了条件，对整个日本动画产业的国际化产生了深远影响。

文章末尾的动画新闻简讯涵盖了全球多个地区的动画动态，包括古巴动画遗产的数字化保存、匈牙利动画110周年庆祝活动、中国动画展览、澳大利亚网络动画的热播、巴西为保护配音演员权益发起的运动，以及《你想活出怎样的人生》等影片的发行信息。

锥形切片：3D打印的新角度

当前切片器的局限性

现有的3D打印切片器本质上是2.5D的，通过堆叠二维层来构建部件，缺乏真正的三维运动。G代码指令中几乎不存在三个轴同时移动的情况，导致斜表面出现阶梯效应，并需要支撑结构。尽管近年来切片器在易用性和速度上有所改进，但基本方法未变：将3D模型切割为二维层，绘制轮廓并填充内部。唯一显著的进化是CURA中的Arachne轮廓生成器，它动态调整挤出宽度以提高细节和减少间隙，但所有操作仍局限于二维平面。

锥形切片的概念与优势

锥形切片是一种非平面切片方法，起源于瑞士温特图尔应用科学大学的RotBot项目。该技术将打印层围绕中心轴倾斜成锥形，允许在打印极端悬垂时（甚至水平悬垂）仅外层轮廓在空中挤出，并由相邻轮廓支撑，从而无需支撑结构。这种方法可在常规3轴打印机上实现类似效果，并开源提供Python脚本供用户自行尝试。

实现方法

锥形切片通过两个Python脚本实现：

1. 预变形STL模型：第一个脚本将STL网格点根据其到中心轴的距离向上移动，生成反向锥形预变形模型。
2. 切片与G代码转换：使用现有切片器（如CURA、PrusaSlicer）对预变形模型进行切片，然后第二个脚本将生成的G代码反向转换为锥形G代码。 用户可在切片器中调整打印机设置（如床原点居中），并确保锥形轴位于坐标原点。此方法需要手动步骤，但展示了如何在常规切片器中集成锥形切片。

硬件要求

打印机需满足以下条件以支持非平面打印：

• 喷嘴间隙：打印头必须有足够间隙，以避免碰撞较高层的打印部分。许多打印机因冷却系统或探头限制，仅支持小角度倾斜。解决方案包括使用加长喷嘴（如空气刷喷嘴或火山喷嘴）。
• 冷却优化：有效冷却对打印极端悬垂至关重要，但加长喷嘴可能降低冷却效率，需权衡处理。
• Z轴磨损：非平面打印涉及频繁的Z轴移动，可能加速传统丝杠的磨损。

当前限制

• 几何形状限制：锥形切片主要适用于向外悬垂的几何形状。对于向内悬垂，可能需要更多支撑；如果模型同时包含向外和向内悬垂，则无法用单一锥形角度解决，需手动分割和堆叠G代码。
• 手动操作：实现过程需要用户手动调整STL位置、设置角度并运行脚本，存在一定复杂性。
• 软件兼容性：切片器如PrusaSlicer和CURA在部分坐标定位上存在问题，可能影响非对称部件的处理。

未来潜力与社区呼吁

• 算法改进：未来需要开发智能算法，能根据几何形状自动分割部件、设置不同的切片角度和方向，以处理复杂悬垂并实现可变层高。
• 硬件优化：打印头设计、Z轴运动和冷却系统需进一步优化以支持非平面切片。
• 开源与创新：锥形切片开源项目鼓励社区参与和贡献，推动技术发展。作者呼吁软件公司考虑集成非平面切片功能，并认为下一代切片器值得投资。
• 研究机会：该领域仍有大量研发空间，适合作为学生课题或爱好者项目，以避免专利限制并促进开源解决方案。

锥形切片展示了FDM打印切片软件的未开发潜力，尽管目前有局限，但为未来更先进的3D打印技术奠定了基础。