文章摘要：作者为患有顺行性健忘症的母亲设计了一个持久可靠的电子墨水信息屏，以减轻其因记忆缺失产生的焦虑。

背景与需求 作者的母亲因手术后遗症患有永久的顺行性健忘症，无法形成新的长期记忆，但并非痴呆症。她独居时常因记不住子女近况而焦虑，并频繁尝试联系子女。纸质便条等传统提醒方式无效，因此作者需要一个能持续显示最新信息、无需复杂交互的可靠设备。

设计目标 作者设定了一系列关键目标：设备需能持续数月运行；允许家人远程发送并保持消息显示；屏幕尺寸大、易读；无需唤醒操作；能应对网络故障；无夜间背光；无需硬件改装；开机即显示信息；不依赖订阅或专有应用；价格合理且外观家居化。

硬件选择 作者选择了BOOX Note Air2电子墨水显示屏（约500美元）。该设备具备Wi-Fi和浏览器，屏幕清晰易读，背光可关闭，外观家居化。作者通过一个金属支架将其放置为类似相框的样式。

软件实现 作者开发了一个简单的双页面网站：

• 信息板页面：设备开机后自动显示，每5分钟从网络服务获取最新消息并刷新。为确保可靠性，采用分层结构：外层框架每小时尝试重新加载内层页面，内层页面负责显示消息并尽量减少依赖。
• 编辑页面：家人可通过手机友好的网页表单撰写和保存消息，可保存为手机主屏幕快捷方式。 整个网站轻量、静态，仅使用原生HTML、CSS和少量JavaScript。为适配不同长度的消息，作者编写了一个自动调整字体大小的函数。为减少电子墨水屏烙印，消息位置和界面元素会随机变化。

服务与部署 作者使用JsonStorage服务存储消息数据（初始免费层，后升级至付费层）。设备于2022年11月12日安装在母亲的公寓窗台上，并立即受到欢迎。

效果与回顾 两年来，该显示屏工作稳定可靠，成为唯一成功改善母亲生活质量的干预措施。母亲记住了设备的存在和用途，并期待看到子女的更新。设备无需母亲学习新操作，软件保持简单也减少了故障风险。作者已将MomBoard的源代码发布在GitHub上供他人参考。

这篇文章讲述了作者按照AWS Amplify官方指南集成OpenSearch后，意外产生高额账单的经历。主要问题在于Amplify沙盒环境停止时，OpenSearch域未被自动删除，导致多次创建后累积了多个实例，产生约1100美元费用。

问题经过：

1. 遵循指南操作：作者按照AWS官方文档，使用Amplify Quickstart创建应用，并集成OpenSearch（包括创建域、索引和数据管道）。
2. 意外账单：几周后收到超过1200美元的账单，远高于预期（通常每月约50美元）。
3. 根本原因：当作者停止沙盒环境（按CTRL-C并选择删除）后，DynamoDB被正确删除，但OpenSearch域仍然保留。第二天重新运行npx ampx sandbox会创建新实例，导致多个未使用的OpenSearch域持续计费。
4. 费用叠加：默认的r5.large.search实例类型较贵，多次创建后费用累积。

AWS回应：

• 作者提交支持工单后，AWS进行了账单调整，作为一次性礼遇。
• AWS客服建议设置预算警报以监控支出。
• 文章发布时，官方指南已更新，但问题在作者最初报告时未被解决。

作者反思：

• 承认用户应了解工作原理并检查价格，但认为复杂技术应更注重默认安全设置。
• 推荐使用AWS预算功能预防意外支出。
• 怀疑此问题是文档疏忽，可能因OpenSearch被视为“高级”功能，但指南未充分警告风险。
• 自问OpenSearch是否过度适用（仅因支持地理查询而选择），建议评估是否有更简单替代方案。

总结警示：

• 使用AWS Amplify（尤其集成OpenSearch）时需手动验证资源是否完全删除。
• 技术文档可能包含隐式成本假设，用户应主动监控服务和账单。

本文探讨了当前就业市场中“幽灵职位”现象，即企业发布实际并不打算立即填充的职位空缺。这种现象增加了求职难度，使申请者投入大量时间精力却得不到回应。

“幽灵职位”产生有多重原因：企业可能借此试探市场人才状况、维持对外增长形象、或为未来需求提前储备简历。部分职位也可能是内部已有候选人但流程要求对外公布。这种做法虽利于企业，却导致求职者面临更长的申请周期、更高的竞争压力，以及信息不对称带来的挫败感。

文章指出，识别这类职位困难，但求职者可通过观察职位发布时间、分析公司近期动态等方式进行初步判断。同时建议调整求职策略，注重内部推荐和主动 networking，而非完全依赖公开招聘渠道。

我从首次公司出售中学到的经验教训

交易详情

作者于今年4月出售了其创立并运营四年的自举硬件公司TinyPilot。主要交易数据如下：

• 售价：598,000美元（年利润的2.4倍）
• 经纪佣金：88,900美元
• 法律费用：18,297美元
• 出售净利润：490,803美元
• 付款方式：交割时全额现金支付（无盈利支付或卖方融资）
• 卖方义务：提供30天免费咨询（总时长不超过80小时）
• 公司生命周期总利润：四年约920,000美元

做得好的地方

1. 大力投资文档化：遵循《Built to Sell》的理念，在Notion中建立了详细的操作手册，使团队无需依赖创始人即可运行公司，这使得交割后仅需约25小时咨询即可完成过渡。
2. 创建过渡清单：将过渡任务分为交割前、交割后几天、一周和一个月内必须完成的事项，帮助在混乱的交割周中保持条理。
3. 与信任的经纪人合作：选择了Quiet Light Brokerage的Chris Guthrie，其创始人导向的风格与作者利益一致。虽然佣金占售价15%，但被认为物有所值，因为他们找到了作者无法自行找到的买家。
4. 避免卖方融资：听取其他创始人建议，拒绝分期付款方案，因为这可能使卖家受制于买家，且追讨债务成本高昂。
5. 假设交割后一无所获：将任何交割后收入视为意外之财，避免对后续付款失望。
6. 认识到对交割后公司影响力有限：筛选买家以寻找愿景一致者，但接受一旦交割完成，便无法控制新所有者。
7. 修订经纪人协议：确保经纪人仅在卖家收到付款时才获得佣金，保持了激励机制的一致。
8. 在不请律师的情况下先讨论争议问题：与买家直接一对一谈判以解决合同条款分歧，节省了时间和法律费用。
9. 使用专用账户：业务使用专用邮箱、电话号码和密码管理器（Bitwarden），使所有权交接非常顺畅。

未来会不同的做法

1. 为现金买家提供激励：现金交易能大幅缩短尽职调查周期（可低至30天），减少律师费用。未来会考虑为现金购买提供折扣。
2. 更早讨论关键合同条款：在签署意向书阶段就尝试谈判关键条款（如过渡时间、保密限制、责任上限），避免在投入大量时间后处于被动。
3. 更早聘请律师：在意向书阶段就让律师介入，以审查基础协议并评估合作默契。
4. 与买家创建非正式“小事情协议”：对于低价值资产（如办公室设备），在正式法律文件之外达成简单协议，避免为小额物品耗费大量法律成本。
5. 更晚向团队宣布出售：过早宣布（签订经纪人协议时）会影响管理动态。未来会等到交易确定后，但提前让团队知道收购是可能的。
6. 不要对每次挫折灾难化：尽职调查期间容易过度担忧潜在问题，应学会“睡一觉再说”。
7. 更早透露供应商信息，但在意向书中施加更严限制：隐藏供应商名称使尽职调查极其困难。未来将依赖合同禁止买家滥用内幕信息。
8. 从经纪人佣金中剔除库存价值：库存价值波动大，基于库存计算佣金不合理。
9. 从一开始就假设所有书面内容都不是私密的：确保团队了解电子邮件在收购时会转移，并在出售业务时使用单独的电子邮件账户处理律师和经纪人的通信。
10. 明确定义交割前后资金流向：在合同中明确规定如何处理跨期服务费、未到账收入、退款等。
11. 在过渡期协议中更重视日历日而非工时：较长的日历日过渡期（即使总工时相同）对卖家代价高昂，因为需要持续待命。
12. 在交割前将不可转让账户与业务邮箱脱钩：避免将个人账户绑定在业务邮箱上。
13. 减少对Google的依赖：Google Cloud Platform项目迁移极其复杂，应尽早将相关服务迁移至独立账户。

感到意外的事情

1. 尽职调查是无边界、高压力的工作：远比预期繁琐，需提供两年所有银行报表并创建各种定制报告。非现金买家（如使用SBA贷款）增加了谈判难度，因为银行要求难以拒绝。
2. 准备出售时，一切成本都是4倍：因为出售价格是利润的倍数，任何支出都会使估值成倍下降。
3. 并非严格需要经纪人：经纪人的主要贡献是找到买家，后续关键路径由律师推动。现在有经验后，作者可能考虑在能自行找到买家时省去经纪人。
4. 非竞争条款过于严格则后果严重：在收购协议中，法官对非竞争条款的审查更严格。必须确保条款合理，仅限于相关领域。
5. 责任无上限则后果严重：出售业务会失去有限责任保护。必须在协议中限制责任上限，否则买家可就任何金额起诉卖方。
6. 买方有动机让卖方保持满意：卖方保留的制度性知识和持续需求，形成了一种平衡，使双方都保持合作。

有助于准备的资源

• 书籍与播客：John Warrilow的《Built to Sell》、《The Art Of Selling Your Business》及其播客《Built to Sell Radio》。
• 私下交流：与其他有出售经验的创始人交谈。
• 会议：Microconf创始人会议，适合结识经纪人和其他创始人。
• 博客文章：如Josh Pigford、Kareem Mayan和Laura Roeder分享的出售经历文章。

90年代丛林音乐对电子游戏开发的影响

在90年代早期，丛林音乐在无数游戏中出现。这种音乐诞生于80年代末的英国，以其充满活力的鼓点、优美的贝斯线和快节奏著称，与PlayStation和Nintendo 64时代快节奏的3D游戏完美契合。

音乐背景与技术起源 丛林音乐是电子舞乐演变的一部分。80年代数字合成器和采样器的普及，以及90年代家用电脑（如Commodore Amiga和Atari ST）的多媒体能力，使得独立音乐人能够在家创作音乐。制作人使用采样器（如AKAI系列）从现有唱片中提取并重组鼓点片段，创造新的节奏模式。最著名的例子是“Amen Break”，这个源自1969年歌曲的鼓点被大量采样、加速并应用在丛林音乐中。其他经典鼓点样本还包括“Think Break”、“Apache Break”等。

文化影响与子流派 丛林音乐深受牙买加文化影响，这源于二战后大量加勒比移民进入英国，带来了他们的“音响系统”文化。早期的丛林音乐常融入牙买加风格的Ragga人声和Dub元素。这种音乐通过非法的“海盗电台”在英国广泛传播，并逐渐分化出多个子流派，包括：

• Ragga：强调牙买加Dub和Ragga人声。
• 氛围：使用合成器垫音营造空间感。
• 液态：融合灵魂乐与放克的元素。
• 爵士步：结合原声爵士乐器。
• 黑暗步：营造黑暗、科幻氛围。
• 科技步：去除有机乐器影响，更具工业化色彩。
• 桑巴贝斯：融入巴西桑巴等拉丁音乐元素。 到90年代中后期，为了更贴近主流，丛林音乐逐渐演变为鼓贝斯（Drum'n'Bass），减少了部分根源元素。

与90年代游戏的完美结合 丛林音乐及其子流派与90年代快节奏的3D游戏天然匹配。PlayStation和Nintendo 64等主机能够播放CD品质的音频，使开发者能充分利用丛林音乐丰富的频率和音效。不同游戏关卡常采用不同子流派的丛林音乐来营造特定氛围，如未来感、紧张感或舒缓氛围。

游戏实例 文章列举了多款采用丛林音乐配乐的代表性游戏：

• 《反重力赛车》：由Psygnosis为PlayStation开发，其电子音乐原声带（由Tim Wright创作）深受当时英国锐舞文化影响。
• 《山脊赛车》系列与《王牌空战》：作曲家中西哲和（Tetsukazu Nakanishi）的作品中融入了丛林元素。
• 《Ape Escape》：作曲家寺田尚一（Soichi Terada）热爱丛林音乐，其作品在游戏中根据情境动态变化。
• 《1080°滑雪》（N64）：作曲家永田坚太的作品被认为拥有优秀的丛林配乐。
• 《Gran Turismo》：西方版中使用了带有“Think Break”变体的曲目。
• 其他例子还包括《Soul of the Samurai》、《Bomberman》系列、《Sega Marine Fishing》以及意想不到的《Magical Tetris Challenge》等。

结论 丛林音乐的高能量特质使其成为90年代游戏开发者的首选配乐风格之一，这一趋势持续影响到21世纪初。文章最后推荐了书籍《State of Bass》和相关PlayStation编程课程作为深入学习的资源。

The request was rejected because it was considered high risk

AI工程门槛正快速瓦解

核心观点

作者基于多年在DevOps、MLOps及生成式AI领域的经验，提出AI工程的门槛正在快速降低。如今，只要能够使用IDE并管理YAML配置到Git，就已具备构建AI应用的基本能力。AI应用开发不再需要博士学位，而是可以运用成熟的工程实践来实现。

AI应用的六个构建模块

1. 模型：本质是数学函数，负责将文本转换为数字表示并反之。
2. 提示词：用自然语言明确指示模型任务，需要足够清晰具体。
3. 知识库：为AI提供领域知识的文档、网站等数据源。
4. 集成：通过API将AI连接到企业业务系统，实现实际应用。
5. 测试：确保AI应用在生产环境中稳定运行的关键环节。
6. 部署：例如将整个应用版本化于YAML文件中，通过Flux部署到Kubernetes集群。

工程化实践与工具

作者指出，现有的DevOps工具（如Git、CI/CD管道）同样适用于AI应用开发。在演讲中，他现场演示了如何基于Jira票据描述构建代码生成集成。关键创新点在于AISpec——一种YAML格式的标准规范，能以基础设施工程师熟悉的方式整合所有构建模块。

开源模型与数据安全

使用开源模型可确保数据隐私，避免数据被用于训练其他模型。对于需遵守GDPR等法规的企业而言，可以在本地基础设施上运行全部组件，确保数据完全自主控制。

参考架构与资源

作者提供了完整的参考架构（GitHub仓库：https://github.com/helixml/genai-cicd-ref），并建议访问aispec.org了解AISpec标准规范。

总结

当前AI应用开发所需的工具和模型均已成熟且持续进化。具备版本控制和基础部署能力的开发者，现在就可以构建生产级的AI应用。工程化实践使得AI开发变得可及，无需特殊魔法或博士学位。

SQLite索引可视化探索总结

研究动机与目标

• 作者在学习索引基本结构后，希望深入探索其数据结构、算法以及索引数据在磁盘上的存储方式。
• 选择SQLite作为研究对象，原因包括：广泛使用、易于调试（客户端应用）、代码库较小但使用类似索引结构、开源。

SQLite索引的B-Tree结构

• 核心数据结构：SQLite索引采用B-Tree结构，一种平衡树，每个节点有多个子节点。
• 存储单元：
  • Page：相当于B-Tree中的节点，存储Cell数据并包含指向右子Page的链接。
  • Cell：存储索引数据、rowId以及指向左子Page的链接。默认情况下，每行有唯一rowId（类似主键）。
• 磁盘存储：索引数据在磁盘上按Page-Cell结构存储，每个Page有固定大小（512至65,536字节）。子Page链接使用4字节存储。

源代码分析与自定义工具

• 关键结构：
  • MemPage：包含页码、Cell数量、Cell索引区域指针等。
  • CellInfo：包含有效载荷指针。
• 自定义分析函数：作者编写了函数用于读取和输出索引内容（如页面信息、Cell的leftChildPageNumber、payload、rowId）。
• Docker环境：提供了Docker镜像（mrsuh/sqlite-index）方便测试，并包含脚本（如dump-index.sh）用于生成索引转储文件。

可视化方法演进

1. 初期尝试：使用d3-org-tree库进行可视化，但难以调整间距，图像随树深度增加变得过大。
2. 文本表示：尝试用文本形式展示索引结构，虽直观但控制力有限。
3. 最终方案：使用PHP的ImageMagick扩展生成图像，可精细控制设计和间距。图像包含：
   • 左上角：索引总体信息（总Page数、总Cell数）。
   • 每层：Page总数和Cell总数。
   • 每个Page：显示页码、右子Page链接、首个和末尾Cell详情。
   • 仅展示每层的首尾Page，根Page位于第一层。

• 生成工具：通过命令php bin/console app:render-index --dumpIndexPath=dump.txt --outputImagePath=image.webp将转储文件渲染为图像。

实验分析与发现

• 不同数据量的索引：
  • 1条记录：1级、1页、1个Cell。
  • 1,000条记录：2级、4页、1,000个Cell。
  • 1,000,000条记录：3级、2,930页、1,000,000个Cell。
• 排序方向影响：
  • ASC索引（默认）：第一条记录（rowId=1）位于最左页的首个Cell。
  • DESC索引：第一条记录（rowId=1）位于最右页的末尾Cell。
• 表达式索引：可存储表达式结果（如从JSON提取并格式化的时间戳字符串）。
• 唯一索引与NULL值：SQLite支持包含NULL值的唯一索引，仅存储非NULL值。
• 部分索引：通过WHERE子句过滤，可大幅减少索引大小（如仅索引非NULL值）。
• 多列索引：Cell中顺序存储所有字段数据，字段间用冒号分隔。
• 索引创建时机的影响：
  • 先建索引后插数据：树需不断重平衡，最终索引较大（3,342页）。
  • 先插数据后建索引：更高效，索引较小（2,930页）。
• VACUUM与REINDEX：
  • VACUUM：重建索引和表，优化后页数减少（从3,342降至2,930）。
  • REINDEX：仅重建索引，效果类似。
• 数据类型存储：
  • 文本：短字符串直接存储于Cell；长文本可能单独存储。
  • 浮点数：以8字节IEEE 754格式存储。
  • 混合类型（整数+文本）：按索引定义顺序连续存储于Cell中。

结论

• 通过研究，作者展示了SQLite索引的内部结构，包括B-Tree组织、数据在内存和磁盘中的存储方式。
• 可视化工具帮助分析和比较不同索引类型。
• 提供了可复现的实验环境（Docker）和代码（GitHub仓库）。
• 后续计划：可视化基于索引的搜索过程，并探索有趣的SQL查询。

学生使用ChatGPT写作指南摘要

核心观点： ChatGPT 若被深思熟虑地使用，可成为辅助学生发展严谨思维和清晰写作的有力工具，帮助他们梳理想法、掌握复杂概念并获取草稿反馈。但若使用不当（如让AI代写整篇文章），则会剥夺学生练习、提升技能和深入钻研材料的机会。

积极使用建议： 对于有志于成为更优秀写作者和思考者的学生，文中提供了若干方法，引导学生利用ChatGPT更深入地参与学习过程。

学术诚信与透明使用的关键原则：

1. 目的界定： 当使用ChatGPT是为了深化理解、发展想法或获得意外见解时，这属于可接受的学术实践范畴。
2. 透明必要性： 由于ChatGPT也可能被不道德地使用，教师通常希望清楚了解AI如何具体贡献于学生的思考过程。学术工作要求对来源保持透明（如正确引用），同理，对AI的使用方式也应坦诚。
3. 实践方法： 实现透明的最简单方式是生成可分享的链接，并将其包含在参考文献中。
4. 传递积极信号： 主动为教师提供审查AI使用情况的途径，能表明学生对学术诚信的承诺，并证明AI是用于支持学习的工具，而非逃避努力的捷径。

Apple 网络扩展框架中的内存泄漏

问题描述

Little Snitch 网络扩展消耗大量内存（GB级别）是不正常的。这是 macOS 网络扩展框架中的一个新内存泄漏 bug，该框架是开发者创建 Mac 防火墙所必需的。此 bug 首次出现在 macOS 15.0 Sequoia 中。

检查方法

• 在终端窗口中运行以下命令检查是否受影响：

  sudo leaks at.obdev.littlesnitch.networkextension | grep "total leaked bytes"
  

• 在 macOS 14 Sonoma 上，泄漏通常很小（几KB），但在 macOS 15 Sequoia 上，泄漏可能增长到数百 MB 或更多。

解决方案与建议

• 此问题依赖于苹果在 macOS 更新中修复。
• Bug 已向苹果报告（编号：FB15552991）。受影响用户可通过 Feedback Assistant 提交额外报告（提及 FB15552991），以帮助苹果定位原因并优先修复。

临时解决方法

• 若遇到异常大内存消耗，可强制重启网络扩展：
  1. 打开“活动监视器”应用（位于“应用程序”>“实用工具”）。
  2. 确保在“视图”菜单中选择“所有进程”。
  3. 搜索进程 at.obdev.littlesnitch.networkextension。
  4. 点击工具栏中的“停止”按钮退出进程，扩展会自动重启。

2023年8月，英国空管系统发生严重故障，影响超过70万乘客，导致1500多个航班取消。事故调查揭示，根本原因源于一个技术细节：两个相距约3600海里（Devil's Lake与Deauville）的导航点共享了相同的三字母代码“DVL”。

事故经过如下：

1. 事件起因：法国航空French Bee航班BF371（从洛杉矶飞往巴黎奥利）的飞行计划在28日约08:32被发送至英国空管中心进行处理。
2. 系统处理：NATS的飞行计划接收子系统FPRSA-R负责处理该计划。系统成功识别了航班进入英国空域的切入点APSOV，但在识别其离开英国空域的出口点时出现了问题。
3. 出口点识别错误：系统依次尝试了两个补充添加的航点（SITET和ETRAT），但均因不在原始计划中而被拒绝。随后，系统选择了位于法国海岸附近的Deauville导航信标，其代码为“DVL”。
4. 关键冲突：巧合的是，美国北达科他州Devil’s Lake区域机场的导航点也使用代码“DVL”。该代码已作为航班经美国空域的一部分包含在原始飞行计划中。
5. 系统崩溃：FPRSA-R系统在计划中找到了“DVL”，却将其误判为美国Devil’s Lake，而非法国Deauville。这导致系统计算出飞机将在进入英国空域之前就离开该空域，得出“不可信”的结论，从而触发了严重异常错误。
6. 系统级联失效：主系统按设计断开以防止错误数据传递。备份的二级系统接管后，遇到了完全相同的问题，也随即断开。从接收到问题飞行计划到主备两个系统全部关闭，整个过程仅用了约20秒。
7. 直接后果：所有自动飞行计划处理功能停止，空管员被迫完全依赖手动操作，引发了大规模的航班取消和延误。

独立调查小组指出，此次故障暴露了系统在处理航点代码时存在的漏洞，特别是当相同的三字母代码被分配给地理位置差异巨大的导航点时，可能导致严重的逻辑错误和系统失效。

骑行办公桌 / 使用分体键盘进行Zwift骑行

文章主要讲述了作者尝试在固定骑行台上工作的经历与解决方案。

背景与初始尝试

作者热爱骑行，并习惯使用站立办公桌。他最初尝试将固定骑行台直接置于站立桌下，发现虽然可以观看视频和阅读文章，但键盘操作非常笨拙不便。即使是简单的按键操作也会打断骑行节奏和思考，影响工作效率。

解决方案：分体键盘支架

作者使用的是ZSA的分体键盘（Voybard）。他利用键盘背面的磁吸三脚架支架，配合购买的相机夹，将键盘固定在骑行台的车把上。经过多次实验，他找到了最舒适的打字姿势：键盘向下倾斜约45度，并微微向内指向（指向自行车前轮最前端）。这种姿势允许他将手掌搭在车把上，自然伸展手指按键。虽然手腕仍稍有不适，但整体可行。

工作效果与可行性

此设置显著扩展了他在zone2骑行中可完成的工作类型。作者表示，这篇文章的撰写、资料查阅和超链接添加都是在骑行台上完成的。他还可以进行编程，操作流畅度接近在站立办公桌前。唯一的例外是需要偶尔停下自行车，进行一些需要鼠标操作的任务（如配置摄像头或切换OBS场景）。

个人使用习惯说明

作者强调自己是一个“vim everywhere”的用户，主要依靠键盘进行所有上下文切换和网页浏览，极少需要使用鼠标，这也是此方案对他特别有效的重要原因。

GOG“游戏保存计划”宣布：聚焦经典PC游戏保护

GOG平台宣布启动“GOG游戏保存计划”，旨在投入重要资源保护面临兼容性问题的经典PC游戏市场。该平台指出，经典游戏仅占其目录的20%，且许多小型游戏因技术老化或停止销售而逐渐被弃用。

计划内容：

• 首批涉及100款游戏，由GOG开发团队负责确保其在当前及未来操作系统上的兼容性。
• 所有游戏将保持DRM-free（无数字版权管理）状态，并提供持续的技术支持。
• 符合条件的游戏将获得“Good Old Game: Preserved by GOG”认证标识。

背景与动机：

• GOG强调此举并非放弃其DRM-free核心使命，而是回归其原始定位“Good Old Games”。
• 该计划部分受《阿尔法协议》相关工作的启发，平台认为聚焦经典游戏能更有效推动资源利用，而非一味追求新3A大作。

首批游戏示例： 计划包含《铁血联盟》《网络奇兵2》《魔兽争霸I&II》《地下城守护者》《主题公园》《模拟城市3000》《银河飞将》系列等经典作品。目前游戏主要支持Windows平台，其中34款已支持Mac，另有19款原生支持Linux，未来可能通过Proton兼容性扩展Linux支持范围。

DC-ROMA RISC-V主板早期访问计划启动

DeepComputing 面向行业与商业客户，正式启动了 DC-ROMA RISC-V 主板的独家早期访问计划。该计划旨在为早期用户提供体验顶级模块化 RISC-V 开发硬件的机会，同时收集反馈以塑造未来产品方向。

计划核心内容：

• 目标客户： 专门面向企业与商业用户。
• 硬件： DC-ROMA RISC-V 主板，专为 Framework Laptop 13 或联名机箱设计，搭载 StarFive JH7110 SoC 与 SiFive U74 核心。
• 用户权益：
  • 提前将先进技术集成到开发工作流程中。
  • 享受未来下一代量产主板（2025年）的折扣升级优惠。
  • 为提供有价值的反馈获得额外折扣。
  • 有机会影响产品开发与改进。
• 产品与价格： 提供完整的桌面迷你电脑套件，起价199美元，并有不同硬件配置、配件及 Linux 系统（如 Ubuntu 24.04、Fedora 41）的套餐选项。

业界支持与反响： 多位行业领袖对该项目表示支持：

• DeepComputing CEO 梁裕宁表示，该计划体现了公司致力于创新和与客户协作的承诺。
• Framework CEO Nirav Patel 欢迎此举，并提及 Framework 的模块化可升级硬件平台为此提供了支持。
• RISC-V 国际董事会成员兼 Fedora 社区成员 Jeffrey Osier-Mixon 认为，该计划为早期用户主动塑造开源计算未来打开了大门。
• Canonical 硅联盟总监 Gordan Markuš 强调，此合作将 RISC-V 技术更贴近开发者，并展现了对开源和强大 Linux 支持的共同承诺。
• Linux 基金会研究员 Greg Kroah-Hartman 指出，此类合作对于推动 Linux 和 RISC-V 发展至关重要。

关于合作方：

• Framework：专注于通过可升级、可维修和可定制的高性能产品重塑消费电子行业。
• DeepComputing：成立于2022年的 RISC-V 先驱，致力于连接开发者社区、供应商与 RISC-V 世界，通过各类产品推动 RISC-V 生态系统发展。

该计划旨在结合软硬件社区及开源力量，共同推进 RISC-V + Linux 的发展。感兴趣的企业可访问指定链接进行注册。

Go-Safeweb 项目摘要

项目概述

Go-Safeweb 是一个旨在帮助开发者编写默认安全的 HTTP 服务器的 Go 语言库集合。它并非 Google 官方支持的产品，目前处于早期阶段，暂不接受外部贡献。项目的核心目的是通过提供安全的 API 设计，消除常见的 Web 安全漏洞类别。

设计目标与原则

主要目标

1. 默认安全：安全机制默认启用（opt-out 模式）。
2. 易于审查与限制：所有对安全机制的禁用（opt-out）都必须是显式的，并尽可能被限制在易于审查的包或选项内。
3. 支持安全需求演进：设计允许通过 AST 操作和静态分析来实施新的安全措施并迁移现有用户。
4. 高兼容性：尽可能保持与 Go 标准库及现有开源框架相似的 API 布局、函数签名等，以促进广泛采用。

非目标

1. 不追求 API 的完整性：不为所有边缘情况创建安全 API。
2. 不追求完全兼容：不为了兼容所有开发者场景而牺牲默认安全性。
3. 不添加非安全关键功能：仅专注于帮助创建安全的 HTTP 服务器，不添加其他无关功能。

计划解决的安全漏洞

项目计划为以下安全问题提供解决方案或基础设施：

• XSS 与 XSSI：通过控制响应生成方式。
• XSRF：支持基于 Fetch Metadata 策略和令牌的防护。
• CORS：管理跨源资源共享响应头和预检请求。
• CSP：自动为 HTML 响应添加脚本 Nonce，并设置相关安全头。
• 传输安全：强制支持 HSTS。
• IFrame 限制：设置相关 HTTP 头以限制框架嵌入或提供服务端的源选择支持。
• 认证（访问控制）：提供统一、可审计的访问控制逻辑插件基础设施。
• HTTP 请求解析缺陷：实现严格且文档清晰的解析行为。
• 错误响应：提供统一的错误处理基础设施，防止信息泄露或 XSS。
• 其他安全相关 HTTP 头的强制实施。

安全需求演进示例

文档通过一个访问控制规则的例子说明如何支持安全需求的平滑迁移。例如，当需要禁止用户 "frombulator" 时：

• 对于新服务，通过 API 默认添加 DENY 规则。
• 对于旧服务，可提供一个 unsafe.LegacyFrombulatorAccess 选项来仅添加 REPORT 规则，以便观察和迁移。
• 这种设计使得依赖不安全配置的服务能够被监控，并在观察期后逐步安全地更新，且大部分过程可自动化。

许可证

项目源代码（包括可能提供的 JS/CSS 文件）均包含 Apache 2.0 许可证头，以明确版权和许可信息。

网站安全拦截信息摘要

该内容并非关于“Wonder收购Grubhub”的新闻文章，而是一段常见的网站安全服务拦截提示页面。

核心内容

• 状态说明：网站使用了安全服务来防护自身，用户触发的安全机制导致访问被阻断。
• 可能触发拦截的行为：包括提交特定词语、SQL命令或格式错误的数据等。
• 提供的解决方案：建议用户通过电子邮件联系网站所有者。邮件中需包含触发拦截时的操作描述以及页面底部提供的Cloudflare Ray ID。

总结

此文本实质是一则技术性错误/拦截通知，旨在告知用户访问受限的原因并提供寻求帮助的途径。它不包含任何与商业收购相关的实质性信息。

PyPI 现在支持数字认证

PyPI（Python Package Index）现已支持包维护者在发布时发布签名的数字认证，以进一步增强项目供应链的安全性。此外，为消费者和安装器提供了一个新的API，用于验证已发布的认证。目前已有超过20,000个认证被发布，许多项目已开始采用此功能。

此举最终实现了PyPI对PEP 740的支持，并基于先前添加的Trusted Publishing支持以及PGP签名的弃用和移除。数字认证相比传统加密签名（如PGP）具有三大优势：

1. 认证由身份签名，而非密钥对：类似于Trusted Publishing，数字认证依赖OpenID Connect（OIDC）身份进行签名，减少了因密钥丢失或泄露导致的失败风险。
2. 提供与上游源代码存储库的可验证链接：通过使用源存储库的身份（如GitHub Actions构建的项目），认证在PyPI上的文件与源存储库、工作流甚至提交哈希之间建立了强可验证关联。此外，将认证发布到透明日志有助于缓解PyPI和项目自身的安全威胁。
3. 认证在上传时验证，必须可验证才能上传：PyPI仅允许具有可验证签名的认证上传和分发，确保所有认证对用户都是可验证和有用的。

如何查看文件的认证

消费者和包安装器可以通过两种方式访问PyPI上文件的数字认证：

• 新的Integrity API：提供对PEP 740实现的程序化访问，收集给定文件的所有已发布认证并作为单个响应返回。
• 新的Web UI页面：显示单个文件的详细信息，包括认证的存在。例如，可在https://pypi.org/project/sampleproject/#sampleproject-4.0.0.tar.gz查看示例。

如何开始使用

对于满足以下条件的项目，认证的生成和发布默认发生，无需更改：

• 从GitHub Actions发布；
• 通过Trusted Publishing；
• 使用pypa/gh-action-pypi-publish动作进行发布。

计划支持其他Trusted Publisher环境的自动认证生成功能。虽然不推荐，但维护者也可以手动生成和发布认证。

致谢

PEP 740的作者和设计工作得到了Sovereign Tech Agency和Google Open Source Security Team的支持。PEP 740的实现资金由Google Open Source Security Team提供，大部分开发工作由Trail of Bits完成，特别感谢贡献者William Woodruff、Facundo Tuesca和Alexis Challande。此外，感谢Sigstore项目推广基于身份的签名、托管公共透明日志以及对Python客户端的持续支持。同时，感谢Sviatoslav Sydorenko对pypa/gh-action-pypi-publish动作的支持和维护，以及在该动作中实现PEP 740的贡献。

Dustin Ingram是Python Package Index的维护者之一。

FireDucks: 比Pandas快100倍的高性能替代库

背景介绍 作者作为对冲基金专业人士，日常大量使用Pandas处理金融数据。尽管后来出现的基于Rust编写的Polars以速度优势震动了Python生态，但作者拥有约3万行Pandas代码，因重写工作量巨大而一直犹豫迁移。他一直认为，Pandas的底层引擎基于C和Cython，理应存在优化空间。

FireDucks的出现 FireDucks于2023年10月由拥有30多年超级计算机开发经验的NEC公司团队推出，被作者称为其寻求的“速度魔怪Pandas库”。其官方基准测试显示：

• 平均速度比Pandas快50倍。
• 性能甚至超越Polars。
• 在部分测试中击败了DuckDB。

作者的自行验证 为验证官方数据，作者在自己的机器上进行了四项基准测试（使用150MB虚拟数据）：

1. 创建数据：FireDucks显著快于Pandas。
2. 读取数据：FireDucks同样表现更优。
3. 计算平均值：FireDucks比Pandas快约130倍。
4. 计算总和：FireDucks比Pandas快约200倍。

测试结果证实了标题“快100倍”并非夸张。

核心优势 FireDucks最突出的特性是100%兼容现有Pandas代码，用户无需修改任何Pandas代码即可直接替换使用，从而获得巨大的性能提升。

结论 作者总结，FireDucks满足了Pandas用户的所有期望：

• 巨大的速度提升。
• 与现有Pandas代码完全兼容。
• 无需代码修改。
• 极其易于使用。

同时，这也证明了通过像FireDucks、Codon、Cython这样的优化工具，Python生态完全可以突破“纯Python慢”的刻板印象，利用其背后的C引擎实现高性能计算。

404错误页面总结

该页面显示一个404错误，表明请求的文件未找到。错误信息指出，网站在指定地址上配置存在问题，可能由于文件名大小写不匹配或文件权限设置不当。建议网站所有者确保文件名与URL大小写一致，并检查文件权限。对于根URL（如http://example.com/），必须提供一个`index.html`文件。更多信息可参考GitHub Pages的官方文档。页面还包含GitHub状态链接（@githubstatus）和GitHub Pages的相关参考。整体内容是关于网站配置错误的提示，而非文章《An alternative construction of Shannon entropy》的实际内容。

自九月初以来，我一直在找工作，此前我于六月底被上一家公司解雇。就业市场非常艰难，充斥着许多虚假职位，因此连获得面试机会都相当具有挑战性。尽管如此，我还是设法参加了几次面试。我想分享其中两个特别的例子，一个体验良好，一个则不尽人意——尽管这不完全是因为我的表现。

一次不错的经历 我申请了一家有趣的初创公司的设计工程师职位。凭借个人项目经验、使用Figma的工作经历以及对设计的热爱，我认为自己有机会。首先，我与招聘人员进行了一次深入的面谈，他询问了许多关于我的经历和动机的问题，显得真诚希望了解我。之后，我很快有机会与未来的经理进行了一次出色的对话，涵盖了工作态度、职业道德以及过往的正面与负面经验。一周后，我与一名高级工程师的进行的技术面试也很顺利。最终，我进入了终面环节，需要向团队展示我的项目。展示本身进行得不错，但我感觉有些不对劲。几天后，我收到了带有反馈的拒信。公司对我的技术能力感到满意，但他们在寻找设计经验更丰富的人选。这令人失望，但可以理解。这次经历至少让我明确了未来需要改进的方向。总的来说，我对该公司留下了积极的印象，如果有机会，未来仍希望在那里工作。

一次糟糕的经历 我申请了一个网页工程师职位。几天后，招聘人员发邮件说：“你好Sergey，我在职位描述中添加了一个任务。请重新申请并完成该任务。”这个任务看起来像是需要我破译一行代码——听起来有趣但耗时。更值得注意的是，描述中列出的薪资降低了三万美元。我随后询问招聘人员这是错误还是实际薪资，他回复说并非错误。这是第一个危险信号。但职位本身仍很有趣，任务也像是有趣的挑战，于是我花了几个小时解决了它并提交了。几天后，招聘人员回复说一切没问题，下一步是初步面试。我在他的日历上预订了时间，等了一周，就在面试开始前两小时，他发消息说公司有现场活动，无法安排时间，要求改期。这是第二个危险信号。我预订了新的时间，又等了一周，在改期当天的早晨，他再次发消息说自己身体不适。于是我们又尝试了一次。在此期间，我发现薪资被改了回来，但团队也发生了变化，这让我对需要完成的任务感到困惑。最终，我们进行了会谈，尽管他迟到了。他道了歉，我们进行了一次尚可的交谈。招聘人员说下周会联系我安排技术面试。但相反，三天后，我收到了拒信，理由是申请者过多。那是几周前的事了，而那个职位至今仍然开放。我不清楚整个流程到底出了什么问题，但觉得没有加入那里或许是幸运的。

是的，市场很艰难。我经历过其他好的（和不那么好的）面试，但这两个例子确实很特别。我仍在寻找下一份工作，希望很快能有结果。如果你正好在寻找一位出色的网页开发人员或前端工程师，请告诉我。

本文探讨了私人书房（studiolo）作为一种精神空间的兴起及其历史演变，重点关注尼可罗·马基雅维利、米歇尔·德·蒙田和W.E.B.杜波依斯三人如何利用这种空间与书籍中的古人进行对话，从而实现自我认知与超越。

马基雅维利与书房的仪式性
文章始于马基雅维利1513年的流放经历。被放逐至家族农庄后，他通过描述日常来信中，构建了一个理想的书房场景：白天与农夫为伍，晚上则更衣进入书房，与古人“对话”四小时。这种阅读被比作“招魂术”，读者通过想象力使古代文本复生，并从中汲取智慧。马基雅维利在此期间写成了《君主论》，书房成为他从卑微现实中进行精神超越的“替代神殿”。

书房作为自我塑造的空间
书房从修道院的抄写室（scriptorium）和图书馆（bibliotheca）演变而来，成为个人用于阅读、沉思和培养自我的私人角落（studiolo）。它不仅是物理空间，更是一个“时空体”，将过去、现在与未来凝聚于读者当下的体验中。文艺复兴时期，贵族和人文主义者如伊莎贝拉·德·埃斯特都拥有自己的书房，但文章也指出这种空间与早期现代的知识、权力和资本积累相关，并隐含了性别与社会不平等。

蒙田与自由的“后屋”
蒙田在波尔多附近的塔楼书房中，将天花板梁柱刻满格言，使建筑本身成为其思想的物质延伸。他在《论独处》中提出了“后屋”（arriereboutique）的概念，主张每个人都应为自己保留一个完全自由、用于真正独处和反思的空间。这体现了现代自由个体对隐私和自主权的追求，同时也强调了积极生活与沉思生活的共存关系。

杜波依斯与跨越界限的对话
W.E.B.杜波依斯在《黑人的灵魂》中表达了与莎士比亚、巴尔扎克等白人古典作家精神共处的体验。对于他，书房提供了一片超越种族分裂和时代隔阂的领域，使他能够与追求真理的伟大灵魂平等交流，暂时摆脱现实中的隔离与偏见。

书房的双重性与现代意义
文章最后指出书房具有“药与毒”的双重性。它既可作为自我修养的圣地，也可能因过度封闭而导致孤立和妄想。从人文主义者到现代社会，书房始终是一个中介空间，帮助个体通过文字与世界和自我建立联系，尽管这种联系可能带来解放，也可能引发幻觉。

Konga Beat：大金刚2和3的自定义音轨编辑器

项目简介
Konga Beat 是一个为游戏《大金刚2》和《大金刚3》设计的自定义音轨编辑器，允许玩家创建并游玩自定义游戏曲目，将喜爱的音乐带入这两款经典游戏中。

核心功能

• 音轨创建与播放：基于 WAV 或 MP3 音频文件，通过用户友好的界面创建全新的自定义音轨并即时试听。
• 游戏兼容性：可导出游戏所需的 .MID 和 .DSP 文件，这些文件能直接加载到《大金刚2》和《大金刚3》中进行游玩。
• 多难度与模式支持：支持在同一项目中管理不同难度（猴子、黑猩猩、大猩猩）和游戏模式（标准、战斗、挑战），灵活满足不同玩家的需求。

技术特点

• 提供简单易用的操作界面，降低音轨制作门槛。
• 生成的游戏兼容文件可直接用于目标游戏，实现无缝导入。

文章总结：使用 io_uring 同时等待多个事件

本文讨论了 Linux 系统编程中同时等待多个事件的需求，并介绍了 io_uring 如何作为通用框架解决这一问题。

传统等待机制的局限性

• 系统编程常需等待事件发生，如数据到达、锁释放、进程终止等。
• 等待多个事件时，常见方案（如 epoll_wait）仅适用于文件描述符。部分等待（如 futex 用于用户空间同步）无法通过文件描述符表达，导致无法统一对待各类等待。

io_uring 的解决方案

• io_uring 通过共享内存的提交队列与完成队列，将多个等待请求批量提交给内核，并等待任意一个完成。
• 核心优势：
  1. 批量处理：减少系统调用次数，提升性能。
  2. 统一多路复用：支持等待任意类型事件，包括传统无法通过文件描述符等待的 futex。
  3. 用户空间与内核共享缓冲区：减少数据拷贝开销。

futex 支持与异步框架

• io_uring 近期增加了 futex 支持，使其能覆盖用户空间同步原语（如锁、队列）的等待需求。
• 结合 futex 与 io_uring，可构建通用异步框架：
  • 代码风格类似阻塞式系统调用，但实际通过 io_uring 异步提交与完成。
  • 实现 IO 与用户空间同步的无缝交互。

应用场景示例

• 同时等待多个套接字可读/可写。
• 等待多个队列中有元素出现（通过 futex 实现队列）。
• 混合等待 IO 事件与同步原语事件。

总结

io_uring 通过批量提交和统一等待机制，解决了 Linux 中同时等待多类事件的问题，尤其通过支持 futex 实现了对用户空间同步的通用异步化，为构建高性能并发系统提供了新范式。

请求的文章内容不可用。提供的内容显示了一个"404 - File not found"（文件未找到）的错误页面，表明托管在GitHub Pages上的该页面或文件不存在。

错误信息指出，对于根URL，必须提供一个index.html文件。它建议检查文件名大小写是否与URL匹配，并检查文件权限，同时提供了GitHub Pages文档的链接以获取更多信息。页面末尾还提供了指向GitHub状态页面（@githubstatus）的链接。

简而言之，所提供的材料并非一篇关于Windows、SMB速度或Tailscale的技术文章，而是一个网页访问错误的提示页面。

Francois Chollet 正式离开谷歌，开启职业生涯新篇章

谷歌近日宣布，深度学习框架 Keras 的创始人、人工智能领域的重要人物 Francois Chollet 将离开谷歌，开启其职业生涯的新篇章。尽管谷歌对他的离开感到遗憾，但对其所做出的巨大贡献感到无比自豪，并期待他未来的成就。

Keras 凭借其简化复杂工作流、推动尖端技术普及化的能力，已成为 AI 开发的基石，拥有超过两百万用户。它支撑着谷歌乃至全球的众多应用，包括 Waymo 自动驾驶汽车，以及 YouTube、Netflix 和 Spotify 等平台的日常推荐系统。

Francois Chollet 本人将继续致力于 Keras 的未来发展，并负责监督其项目路线图。他将继续为 Keras 项目做出贡献，确保其对 JAX、TensorFlow 和 PyTorch 的持续支持。谷歌的 Keras 团队也将继续与 Francois 在开源社区中保持合作。

谷歌对 Keras 3 的持续投入体现了其对支持主要机器学习框架、为开发者提供框架选择权的承诺。近期推出的 Keras Hub 是推动强大 AI 工具普及化、加速创新多模态应用开发的重要一步。

谷歌感谢 Francois 的全部贡献，他的工作在机器学习框架和更广泛的 AI 领域留下了不可磨灭的印记。公众可通过其 GitHub 和社交媒体账号继续关注他的工作及 Keras 项目动态。谷歌承诺将继续巩固其对开放 AI 生态系统的支持。

本文证明掩码语言模型（如DeBERTa）也能涌现上下文学习能力，这一能力通常与因果语言模型（如GPT）相关。通过一种简单的推理技术，研究人员使现有掩码模型无需额外训练或架构更改即可执行生成任务。实验评估显示，掩码和因果语言模型在不同任务类别上表现各异，各自具有互补优势。这表明，领域过度关注因果模型可能限制了潜力，因为两种架构都能发展上下文学习能力，但各有特点，这指向了结合两者优势的混合方法的前景。

DeepL Voice：实时语音翻译，助力全球协作

产品概述

DeepL Voice 是基于 DeepL 语言 AI 技术的实时语音翻译解决方案，旨在帮助用户跨越语言障碍实现无缝沟通。该产品服务于超过 20 万家企业，主要包含三个应用场景：Voice for Meetings、Voice for Conversations 和 Voice API。

核心功能

1. DeepL Voice for Meetings（会议语音）

• 功能：为虚拟会议提供实时字幕，支持包容性与高效沟通。
• 平台支持：集成于 Microsoft Teams 和 Zoom Meetings。
• 语言覆盖：支持超过 100 种语言，包括英语、法语、德语、西班牙语、日语和中文。
• 安全性：具备企业级安全与数据隐私保护。
• 即将推出：语音对语音翻译支持。

2. DeepL Voice for Conversations（对话语音）

• 应用场景：赋能前线员工进行面对面的客户交流，实现即时跨语言沟通。
• 隐私与速度：设备端语音翻译，快速且保护隐私。
• 使用形式：支持一对一或小组对话。
• 可用平台：适用于 iOS、Android 及网页端。

3. DeepL API for Voice（语音API）

• 集成能力：为企业团队提供语音通道及企业工具中的嵌入式语音翻译和实时口译。
• 业务扩展：支持多语言客服、销售及业务流程外包（BPO）工作流。
• 优势：帮助企业基于专业能力而非语言覆盖招聘人才，扩大人才库，同时控制成本，并在关键时刻提供可靠翻译覆盖，加速业务扩展。

技术优势与特点

• 高准确性：由专门构建和调优的 LLM（大语言模型）技术驱动，即使在技术语境下也能保证翻译准确。
• 提升效率：通过无缝实时协作减少沟通反复，实现更快、更高价值的成果。
• 支持全球扩张：消除实时沟通障碍，帮助企业应对成本上升、弥补人才缺口并推动全球化发展。
• 专业术语定制：支持添加行业特定术语、缩写和产品名称，确保技术对话的准确性。新推出的质量优化功能能实时准确捕捉说话者意图，即使面对快速、技术性或上下文依赖的表述。

安全与合规

• 数据隐私：DeepL Voice 不会使用用户数据训练其语言模型。
• 审计与认证：通过独立审计和全面文档保障安全，持有 ISO/IEC 27001:2022 和 SOC 2 Type 2 认证，并符合 GDPR 及 HIPAA 合规要求。

客户见证

国际协调员 Christine Aubry（Brioche Pasquier）表示，在使用 DeepL Voice 之前，主要挑战是维持国际站点在公司项目中的参与度，该产品有效解决了这一问题。

总结

DeepL Voice 提供安全、准确的实时语音翻译，旨在帮助企业与全球同事、客户及合作伙伴无阻碍沟通，实现即时、精准的交流，支持业务扩展与全球化战略。

视频页面摘要：Smaller Than Pixel Art: Sub-Pixel Art!

基本信息

视频简介

这是一个关于**子像素艺术（Sub-Pixel Art）**的视频。创作者探索了如何利用像素内的红、绿、蓝（RGB）各个分量进行操控，从而创作出极其精细和微小的图像作品。该技术展示了如何通过颜色来表示空间信息，并揭示了字体平滑和图像感应中所使用的技巧。

内容说明

• 视频并非关于子像素的终极教程，更多是为了趣味性
• 作者承认在2:33处有一个错误（将红色误标为白色）
• 作者说明没有特别理由将所有图形保持为1位而非使用"灰度"
• 标签：#pixelart #subpixel #japhyriddle

推荐相关视频

页面推荐了多部相关视频，涵盖：

• 1x1像素图像创作
• 子像素蛇游戏在不同屏幕上的表现
• 像素艺术抗锯齿与子像素动画
• 子像素渲染技术
• 更小像素艺术为何更难等主题

JSON for Classic C++ 库概述

这是一个为C++设计的JSON解析与序列化库，旨在作为 nlohmann/json 的替代方案，强调高性能、编译速度快和代码简洁。

核心优势

1. 性能卓越：在特定测试环境下，其解析速度比nlohmann库快2到3倍。
2. 编译极快：编译时间比nlohmann库快约10倍，大幅降低了开发开销。
3. 代码精简：总代码行数（头文件与实现文件）仅为nlohmann库的十分之一，结构简单（json.h 233行，json.cpp 1303行），易于理解、修改和定制。
4. 标准符合性高：完全通过了权威的 JSONTestSuite 测试套件，而nlohmann库未能完全通过。

技术特性与依赖

• 依赖项：除了标准库头文件（<string>, <map>, <vector>）外，还依赖Google的 double-conversion 库。
• 浮点数处理：利用 double-conversion 库的优秀方法，能精确序列化32位浮点数（float），避免自动转为双精度（double），从而生成更高效、可读的JSON输出（例如，保留float的精度，避免输出冗余数字）。

用法示例

库的使用流程简单：

1. 包含 json.h。
2. 包含 json.cpp 源码。
3. 链接 Google 的 double-conversion 库。

文章展示了在llamafile项目（兼容OpenAI API）中的实际应用代码片段，演示了如何：

• 解析请求：从HTTP请求体中解析JSON，并进行字段验证和提取。
• 构建响应：动态创建JSON对象以构建API响应，支持流式和非流式输出。

性能与合规性测试

1. 性能测试：在特定硬件和编译器设置下，对多个JSON操作（如解析、序列化、深拷贝）进行了基准测试，该库在所有项目中均显著快于nlohmann的ordered_json。
2. JSONTestSuite 结果：
   • 有效JSON：所有 y_* 测试用例均通过。
   • 无效JSON：所有 n_* 测试用例均被正确拒绝。
   • 未定义行为：在处理一些边界情况（如异常编码、超大数值）时，库会选择接受（标记为 IMPLEMENTATION_PASS）或拒绝（标记为 IMPLEMENTATION_FAIL），并给出了具体的错误原因（如 illegal_utf8_character， depth_exceeded）。

历史与背景

该JSON解析器最初于2022年由Justine Tunney和Gautham Venkatasubramanian用C语言为Lua编写，用于Redbean项目。2024年，在Mozilla的赞助下，被转换为C++并用于llamafile项目。