FastHTML：用纯Python构建现代Web应用

FastHTML是一个基于Python的Web应用框架，旨在让用户能够快速、灵活地开发从简单仪表板到可扩展应用的各类项目。它建立在坚实的Web基础之上，而非追赶最新潮流。

核心优势与特点

• 极速上手：仅需一个Python文件即可创建完整的Web应用，并支持集成任何Python或JavaScript库。
• 高灵活性：提供对HTTP、HTML、JS和CSS的完全访问，使开发者能够利用Web基础构建任何所需功能。
• 性能与可扩展性：应用程序运行快速、易于扩展，可部署到任何支持Python的托管服务。
• 技术栈：
  • 坚实的根基：构建于成熟的底层技术。
  • 熟悉的工具：拥抱开发者已掌握的工具链。
  • 随处部署：支持部署至Railway.app、Vercel、Hugging Face Spaces、Replit等平台，或任何安装了Python的VPS、服务器及本地机器。

应用场景与FAQ

• 适用应用：通用Web应用（类似React、Django所构建的）、快速仪表板、原型、公司内部应用、交互式分析报告、包含动态内容的自定义博客等。
• 与FastAPI的关系：FastAPI是FastHTML的灵感来源之一。FastAPI专注于构建API，而FastHTML专注于生成HTML（即超媒体应用）。如果偏好主要编写Python，FastHTML通常是更好的选择。
• 支持现代SPA应用：FastHTML专门设计用于快速构建单页应用（SPA）。默认情况下，路由返回轻量的“部分”内容以直接更新DOM，而非整页刷新。
• HTMX集成：HTMX是一个小型JavaScript库，它允许通过单行HTML从Python直接响应网页事件并更新DOM，极大扩展了FastHTML的功能，但非强制使用。
• JavaScript需求：用Python即可编写绝大多数标准Web应用。同时，也可以按需轻松集成现有JS库或嵌入JS代码。
• 性能比较：使用FastHTML和HTMX的应用通常比使用大型JS库的方法更轻量，因此速度可能更快。

文章概要

本文是一名独立开发者的个人经历回顾，讲述其基于Yelp API开发十年的Mac应用“Restaurants”因Yelp突然更改政策而在四天内被迫下架的故事，并总结了经验教训。

1. 应用背景与合作历史

• 应用简介：“Restaurants”是一款2014年发布的Mac应用，专注于餐厅搜索，通过Yelp API提供快速、轻量化的搜索体验，并与macOS功能深度集成。
• 合作开端：开发者在发布前获得了Yelp的明确许可，Yelp甚至主动提供了每日25,000次的API调用限额（尽管应用实际使用量远低于此）。
• 应用价值：应用被定位为Yelp网站的流量入口，因为它仅展示有限的评论和照片，用户需要跳转至Yelp网站获取完整信息。
• 持续运营：应用以一次性购买的形式在Mac App Store销售了十年，虽销量不大，但稳定，且在十年间随Yelp API的更新而迭代。

2. 突然的政策变更与四天通牒

• 无预警通知：2024年7月19日（周五），开发者收到一封语气看似邮件列表的邮件，称其API使用量高于许多开发者，要求提供应用截图等信息，并威胁如不在7月23日（周一）下午4点前回复，将禁用其API密钥。
• 开发者的核心不满：
  1. 关系错位：邮件称其为“试用者”，但实际已有十年正式合作历史。
  2. 信息冗余：邮件要求的信息早已在合作初期提供。
  3. 误导性质疑：邮件暗示其滥用API，但实际使用量远低于Yelp自行提供的限额。
  4. 极度不合理的时限：周末仅给予四天（实际仅一个工作日）的回复窗口，近乎断了开发者任何缓冲或协商的可能。

3. 开发者的应对与最终决定

• 初次回复：开发者立即回复，说明应用的历史、价值（为Yelp导流），并提供了应用信息，表达了对通知方式的不满。
• Yelp的回应：确认API已转为付费模式，开发者必须购买许可证才能继续使用，否则密钥将于下周禁用。
• 最终行动：
  1. 立即下架：由于销售利润无法支撑API费用，且对Yelp的合作伙伴信任崩塌，开发者立即将应用从Mac App Store下架，避免新用户购买后服务失效。
  2. API密钥失效：十天后，Yelp如期禁用了API密钥，导致所有已购用户的应用失效。
  3. 退款指引：由于无法直接联系用户，开发者指引用户通过苹果官方渠道申请退款。

4. 后续更新与Yelp的修正

• 在事件引发关注后，Yelp于2024年8月1日发送道歉邮件，承认过渡期过于仓促，并将免费访问期延长了90天。开发者肯定了道歉和延期，但仍强调问题的核心在于最初恶劣的沟通方式。

5. 开发者总结的教训

1. 核心依赖风险：若应用的核心功能依赖于第三方API，则应用的命脉完全掌握在API提供方手中，面临其单方面更改条款的风险。
2. 付费模式困境：一次性购买的应用模式，与依赖需要持续付费的API服务之间存在根本矛盾。这使得开发者在API成本变化时陷入两难，也损害了用户的购买预期。

总结：该事件典型地反映了独立开发者在依赖大平台API时所处的弱势地位。Yelp虽有权将API商业化，但其最初极具压迫性的执行方式（极短通牒、威胁性口吻）严重损害了长期合作伙伴关系，并最终导致一个十年老应用的消亡。

Healthchecks.io：独立开发者九年的SaaS实践总结

项目背景
Healthchecks.io 于2015年7月上线，是一个专注于监控定时任务（cron jobs）健康状况的SaaS服务。创始人Pēteris作为独立开发者，持续运营至今已满九年。

财务与业务现状

• 目前拥有652名付费客户，月度经常性收入（MRR）为14,043美元。
• 未使用第三方收入分析工具，通过自编脚本和表格制作收入图表，以减少数据处理方。
• 收入缓慢增长，但创始人更注重项目可持续性、个人享受及生活工作平衡，而非最大化收入。

运营模式

• 仍为一人独立业务。自2022年1月起，该项目成为创始人唯一收入来源，但工作时间为兼职状态。
• 无招聘或寻找联合创始人的计划，主要原因是不愿承担管理职责，并享受完全自主的工作方式。
• 认为理想合作者应能独立高效贡献，但现实中难以寻得且成本过高。

增长与产品理念

• 不计划收紧免费套餐限制或提高付费套餐价格，初衷是提供比现有服务（如Dead Man’s Snitch、Cronitor）更实惠的替代方案。
• 主动放弃企业客户（如要求采购订单、电汇、定制协议等），尽管这意味着放弃潜在收入，但创始人更看重减少额外负担。
• 功能范围保持稳定，不打算扩展至主动监控、托管状态页或应用性能监控（APM）等领域。
• 将产品定位为“霍比特人软件”（小而美），业务定义为“生活方式业务”。

技术基础设施更新

• Web服务器升级至Hetzner AX42（AMD 8700GE，8核），以提升性能与效率。
• 数据库服务器升级至Hetzner EX101（Intel 13900，8+16核），在故障切换后趁机优化硬件。
• 采用Maddy自行发送电子邮件，减少对外部邮件服务的依赖。
• Ping数据存储迁移至S3兼容对象存储，以控制PostgreSQL数据库体积，但增加对外部服务的依赖。

总结
Healthchecks.io展现了独立开发者如何通过坚持个人价值观、控制业务范围与保持技术简洁，实现长期可持续的SaaS运营。创始人优先考虑生活平衡与产品核心价值，而非盲目扩张或最大化收入，为小型独立产品提供了另类发展范本。

《若想推动步行出行，必须优先考虑步行者的尊严》摘要

文章指出，人们往往在历史悠久的城市度假时享受步行，但回到以汽车为中心的现代城市后，步行却变成了一件苦差事。这不仅仅是因为城市密度或驾车的便利性，更根本的原因在于，步行设施的设计没有优先考虑步行者的尊严。

为分析此问题，文章提出了一个类似马斯洛需求层次的理论框架，将理想的步行体验分为三层：

1. 合规性：满足《美国残疾人法案》等法规要求。这是基础且必须遵守的，但仅为合规而设计往往不足，甚至可能损害步行体验。例如，为降低合规成本而直接移除人行横道（如Edina市的案例），或只在路口修建新坡道而人行道本身障碍重重，都无法提供真正可用的设施。

2. 安全性：包括实际安全和感知安全。一个设施可能合规但感觉不安全（如在45英里/小时的快速路边仅有坡道却无标识的人行横道）。有时设施设计安全（如带有行人庇护岛的新横道），但整体步行体验（如狭窄、无遮荫的人行道）仍不理想。

3. 尊严：这是最高层次，也是推动步行成为日常选择的关键。文章提出一个简单的测试：如果你开车看到一位朋友正在步行，你的第一反应是“他的车坏了，我得载他一程”（缺乏尊严），还是“他在散步，晚点联系他”（具有尊严）？

实现有尊严的步行体验需关注以下四个核心要素：

• 遮荫与照明：夏季需要持续的树荫或遮阳设施；夜间需要均匀、充足的照明，避免强烈阴影，确保路线清晰安全。
• 便捷性：路线应直观、直接，避免不必要的绕行、急转弯或令人感觉费时费力的迂回设计。
• 围合感与比例：需要营造适度的空间围合感。过于开阔、缺乏边界定义的走廊（如一条宽马路对面是停车场）会让人感到暴露和脆弱；而过度生长的植被或过窄的空间则会带来压迫感。
• 界面趣味性：临街界面应具有吸引力。与单调的围墙或后院栅栏相比，带有门窗、多样建筑立面的传统主街（如Northfield市的Division街）能提供更愉悦、更有趣的步行体验。

结论：仅满足合规性要求（如修建达标的人行道）甚至基本安全性，不足以吸引人们放弃驾车步行。要使步行和轮椅出行成为人们愿意选择的日常活动，必须将合规、安全与尊严三者结合，在所有层面提升步行环境质量。当前社区中已有良好的步行空间范例，但要实现普遍化、真正推动出行方式向步行转变，仍任重道远。

Dark Sky：一个数据可视化杰作的悼词

2023年1月1日，苹果公司正式关闭了其于2020年初收购的天气应用 Dark Sky 的移动版本。尽管苹果已将Dark Sky的预报技术整合到iOS 16的原生“天气”应用中，但许多用户认为，新应用在信息呈现效率和设计哲学上无法替代Dark Sky。本文旨在分析Dark Sky卓越的设计理念及其如何成为信息设计的典范。

核心理念：情境化信息设计

Dark Sky 的设计核心是 “情境敏感的信息图形”。应用并非简单地展示静态数据，而是根据用户所处的具体情境和即时需求，动态、智能地呈现最相关的天气信息。作者引用Bret Victor在《Magic Ink》中的定义，指出优秀的信息设计应能响应用户环境。Dark Sky 团队深入思考了用户在不同生活场景下使用天气应用的具体目标（例如：出门前是否需要带伞？一周的户外计划如何安排？），并将几乎所有的界面元素都转化为情境化的信息图形。

设计卓越之处解析

1. 未来12小时预报：聚焦当下最相关的事件

   • 默认视图从**“现在”**开始显示，而非过去，因为用户通常更关心当前和未来的天气。
   • 界面会根据当天的天气特征智能调整信息重点：
     • 若有风暴经过，会突出显示风暴状态、风力警报和体感温度下降。
     • 若即将下雨，会将未来一小时的降水概率和未来数小时的持续降水置于视觉中心。
     • 若天气平稳，则侧重展示全天的温度分布。
   • 这种设计让用户无需思考，一眼就能把握天气的“形态”和关键变化。

2. 每周预报：超本地化与快速洞察

   • 提供具体地址或地标级别的超本地化预报，而不仅仅是城市级别，帮助用户理解微观天气差异。
   • 周视图允许用户快速识别：哪些天可能下雨、哪些天昼夜温差大、以及整体天气的趋势变化。

3. 精妙的数据可视化细节

   • 温度范围可视化：在显示一周温度时，采用保持原始数据幅度的“温度药丸”设计，而非所有天都标准化为相同长度的条形图。这使用户能更直观地跨日比较温度的实际变化。
   • 用粗略分类取代精确数字：对于降雨/降雪量，应用常使用“小雨”、“中雪”等粗略类别而非精确数值。这既有助于用户快速做出生活决策（如是否需要叫铲雪服务），也避免了因预报固有的不确定性而产生的虚假精确感。
   • 直观的风暴地图与风向表示：使用简洁的颜色梯度与箭头清晰传达风暴信息；用箭头而非文字（如“西北风”）表示风向，更符合人身体的直观感受。

用户反馈与遗产

许多忠实用户强烈怀念Dark Sky。他们指出，苹果原生天气应用的信息呈现效率较低，尤其缺乏像Dark Sky那样清晰、整合的降水概率图和详细的云量覆盖等关键信息，而这对于日常决策（如户外活动安排）至关重要。

结论与启示

Dark Sky的成功在于，它始于公开数据，通过情境化预测进行增强，经过对数据可视化设计的严格迭代，最终将这一切打包成一个贴合用户日常需求的情境化体验。它证明了，数据本身并不足够，需要通过卓越的设计和工程来将其“人性化”，使其真正改善生活。

作者最后呼吁，世界需要更多像Dark Sky这样的体验，以帮助人们改善消费习惯、睡眠质量等生活各方面。对于从事信息软件设计的人来说，Dark Sky开创性的设计与工程实践无疑是一座灵感宝库。

计算谷歌DeepMind论文的成本

核心结论

文章作者对谷歌DeepMind的论文《Scaling Exponents Across Parameterizations and Optimizers》进行了计算成本估算。该论文进行了超过10,000次大语言模型训练实验以确定最优超参数。作者的分析得出：

• 总计算量：约 5.42e24 FLOPs
• 估算总成本：按每小时3美元的H100 GPU租赁成本计算，总计约 1290万美元
• 所需H100计算节点时间：约747个H100节点月（假设8卡节点）

实验类型与成本构成

论文中的实验可分为以下几类，成本从低到高排列：

1. 对齐实验（Alignment）

• 使用接近最优的单一全局学习率，变化模型维度 D ∈ {1024, 2048, 4096}
• 涉及4种参数化、3种优化器（Adam， SGD+动量， Adafactor）
• 计算量：3.7e20 FLOPs， 成本：约888美元

2. 表E1实验（Table E1）

• 用于获取特定参数化/优化器/设置下的最佳评估损失
• 针对6个较大的模型维度 D ∈ {3072, 4096, 6144, 8192, 12288, 16384}
• 包含4种参数化， SGD（5种设置）与Adam/Adam+PS（各7种设置）
• 计算量：1.63e23 FLOPs， 成本：约39万美元

3. Adam Epsilon变体实验

• 研究Adam优化器中epsilon参数的影响
• 涉及所有14个模型维度，4种参数化，6种epsilon值（包括基础值、小常数、逐层epsilon等）
• 采用学习率扫描，每个图表平均估算15个实验点
• 计算量：7.99e23 FLOPs， 成本：约190万美元

4. Adam Epsilon热图实验（Epslion Heatmaps）

• 对epsilon进行更精细的扫描
• 仅针对6个最大的模型维度 D ∈ {3072, 4096, ... 16384}
• 包含2种epsilon类型（基础与逐层），4种参数化，每张热图平均13个学习率点
• 计算量：1.34e24 FLOPs， 成本：约319万美元

5. 学习率变体实验 - β实验（β-only experiments）

• 扫描基础学习率常数β
• 涉及3种优化器、4种参数化、14个模型维度，全局学习率与逐层学习率两种设置
• 计算量：7.99e23 FLOPs， 成本：约190万美元

6. 学习率变体实验 - γ实验（γ experiments）

• 调优逐层常数乘法因子
• 需额外计算：
  • 对于 D=1024，至少进行800次超参数搜索试验
  • 对于其他14个维度，进行标准学习率扫描
• 计算量：1.35e24 FLOPs， 成本：约322万美元

7. 权重衰减实验

• 对所有模型维度进行4种参数化的基础学习率扫描
• 计算量：1.33e23 FLOPs， 成本：约31.7万美元

8. Adafactor实验

• 比较Adafactor与Adam+PS优化器
• 仅扫描前11个模型维度（至 H=48）
• 计算量：7.92e22 FLOPs， 成本：约18.9万美元

9. 计算最优实验（Compute Optimal）

• 包括固定步数（50k步）实验和计算最优实验
• 计算最优实验使用Chinchilla启发式方法（20倍非嵌入参数量的token数）
• 模型规模上限为 H=32 或 H=48
• 计算量：7.52e23 FLOPs， 成本：约179万美元

成本计算方法

1. 基准假设：所有实验可能使用TPU进行，但为便于计算，作者转换为H100 GPU时数。
2. H100性能：假设平均张量FLOPS为 3.5e14（约35%的峰值利用率），成本为 3美元/小时/卡。
3. 每token计算量：基于标准Transformer架构（M = 6D(L(12D + l_seq) + V)），其中 L=8，l_seq=512，V=32101。
4. 总token数：除计算最优实验外，其他实验每批token数固定为 50000步 * 256批大小 * 512序列长度。
5. 不确定性：学习率扫描的实际点数难以确定，作者基于图表估算为平均15点；某些理论上等效的设置可能未重复实验，此估算可能偏高。

上下文比较

尽管5.42e24 FLOPs和1290万美元的估算成本看似高昂，但作者指出：

• 这仅占Llama 3训练所用计算量的不足15%。
• 一个拥有10万个H100的集群可以在2天内完成所有这些实验。
• 对于大型科技公司或顶级研究机构而言，此成本是可承担的。

四分钟模拟四十亿年 – 在GPU上模拟世界

本文介绍了一个完全用GLSL片段着色器编写的程序化地球模拟，能在几分钟内模拟类地行星的完整历史，并以60帧/秒实时更新。

原行星阶段

模拟从45亿年前开始，地球是一个熔融的岩石球体，经历小行星撞击形成陨石坑。地形高度通过分形布朗运动噪声和多层陨石坑生成算法计算，使用三维网格和随机偏移避免规律性。早期地形类似NASA描述的早期地球。

构造板块

为模拟山脉和大陆的形成，随机生成板块种子点，通过扩散限制聚集模型增长板块。板块以离散时间步移动，边界碰撞导致地壳抬升，结合热侵蚀模型逐渐扩散影响，形成山脉和海沟。

水力侵蚀

使用基于Barnes（2018）的简单水流模型模拟河流盆地。每个像素根据最大斜率方向输送水流，通过水流幂定律驱动侵蚀，形成自然河网。可视化结果类似真实河流盆地地图。

全球气候

通过程序化生成平均海平面压力（MSLP）图近似气候系统。基于陆地/海洋位置和纬度计算MSLP，应用高斯模糊模拟压力扩散。结合季节性变化生成风流、温度和降水，模拟出季风等现象。

生命

使用Lotka-Volterra扩散模型模拟植物、食草动物和捕食者的种群动态。气候影响植物生长，动物随季节迁移，形成类似微生物群落的模式。

人类

模拟末期，人类出现并殖民地表，燃烧化石燃料释放大量碳，增强温室效应，导致全球变暖和宜居区缩小，最终部分人类消失。

该模拟通过GPU实时运行，结合物理模型和程序化生成，展示了从行星形成到人类时代的完整演化过程。

CrowdStrike软件更新对航空业的影响

事件概述

2024年7月19日，网络安全公司CrowdStrike向数百万Windows机器发布了一次传感器配置更新，导致全球历史上最大规模的IT系统中断。约850万台计算机出现蓝屏故障，影响范围涵盖医院、银行、911紧急系统及航空业等关键领域。

对航空交通的具体影响

通过对比2024年7月19日（事件当天）与上一周周五（7月12日）的航班数据，分析显示：

• 事件发生后（UTC时间04:09起），美国全国航班数量整体受影响相对有限。
• 在UTC 06:00至13:00期间，航班数量出现小幅下降，随后时段略有回升。
• 累计数据显示，与前一个周五同期相比，航班总数反而增加了2.6%。
• 影响最显著的时段为UTC 08:00至09:00，航班数量同比下降31%（261架次 vs. 378架次）。

主要航空公司受影响程度差异

对美国四大航空公司的分析表明，其受影响程度存在显著差异：

• 达美航空：受影响最严重，航班减少约1087架次，同比下降46%。
• 联合航空：航班减少约596架次，同比下降36%。
• 美国航空：航班减少约376架次，同比下降16%。
• 西南航空：航班反而增加约101架次，同比上升3%，基本未受影响。

分析指出，西南航空未受影响与其不使用CrowdStrike系统有关，而非因仍使用旧版操作系统。

达美航空恢复缓慢的原因推测

相较于其他航空公司，达美航空在事件后数日内仍持续出现大量航班取消。部分报道认为其依赖于需人工逐一修复的数字终端系统。另有未经证实的网络讨论指出，达美航空可能缺乏健全的灾备计划和IT业务连续性计划，而其他航空公司则在之前的事件后建立了完善的恢复流程并能快速启动。

数据与分析方法

本次分析基于ADS-B Exchange提供的原始数据，通过自定义代码检测飞机起飞事件来估算航班量。尽管该方法可能低估绝对航班数量（如未覆盖区域的航班），但其系统性偏差仍保证了不同时段间百分比变化比较的有效性。

蝴蝶和飞蛾在飞行过程中会积累大量静电，使得花粉能够通过静电力被吸引并跨越数毫米甚至数厘米的空气间隙。这一发现表明，这种机制可能提高了它们作为传粉媒介的效率和效果。

布里斯托大学团队观察到，不同物种的蝴蝶和飞蛾所带的静电电量存在差异，且这些差异与它们的生态特征相关，例如是否访问花朵、是否来自热带环境，或是白天还是夜间活动。这是首次有证据表明，动物积累静电的电量是一种可适应的性状，因此进化可以通过自然选择作用于该特征。

研究涉及11个不同物种的269只蝴蝶和飞蛾，这些物种原产于五大洲，栖息于多种不同的生态位。通过比较它们之间的静电电量与生态因素的相关性，研究确定了静电充电是进化可以作用的一种性状。

这项研究还开启了通过人工增加传粉者或花粉的静电电荷来提高自然和农业环境中授粉率的技术可能性。总的来说，蝴蝶和飞蛾积累的静电使它们甚至无需接触花朵就能完成授粉，这突显了它们对花卉生态系统功能的重要性。

论文信息： 《蝴蝶和飞蛾的静电授粉》by Sam J. England and Daniel Robert，发表于《皇家学会界面杂志》。

这篇文章介绍了作者使用Rust语言重新实现《Crafting Interpreters》一书中Lox语言字节码解释器的垃圾回收器（GC）的经历和思考。主要探讨了在Rust的内存模型下实现mark-and-sweep GC所面临的挑战和可行的解决方案。

文章首先定义了垃圾收集的基本概念：程序运行时存在栈（编译时确定大小）和堆（运行时动态分配）内存。Lox作为托管语言，需要GC自动回收不再使用的堆内存对象。GC通过判断对象是否“可达”来决定回收，不可达的对象即为垃圾。

核心算法是mark-and-sweep。它从“根”对象（如栈、全局变量、闭包捕获的变量）开始，递归标记所有可被访问到的对象（标记阶段），然后释放所有未被标记的对象（清除阶段）。

主要挑战在于Rust的所有权/借用模型与Lox语义的冲突。Rust通过借用检查器在编译时防止数据竞争和内存安全问题，禁止同时存在多个可变引用指向同一数据。然而Lox允许对象被多个变量同时可变地共享（别名），如示例中add(a, a)。

作者探讨了几种在Rust中实现GC的路径：

1. 引用计数（Rc<RefCell>）：利用Rust提供的共享可变引用。优点是简单、自动管理内存。致命缺陷是无法处理Lox允许的引用循环（如两个对象相互引用），会导致内存泄漏，因此单独使用不可行。
2. 对象管理器（间接索引）：将所有对象存放在一个动态数组（对象管理器）中，对象之间通过数组索引而非指针相互引用。这绕过了借用检查，实现了可变共享。缺点是访问数据需要两次内存查找（索引->数组->数据），性能较低；并且为了不破坏索引，数组通常无法收缩，导致无法将空闲内存归还操作系统。
3. 使用unsafe的原始指针：为了追求与C实现相当的性能，作者最终采用了直接模仿C实现的方式。定义了包含元数据和数据的GcData<T>结构，并通过Gc<T>包装非空裸指针NonNull<T>。对象通过next指针形成链表，便于GC遍历。为Gc<T>实现了Deref和DerefMut trait以透明访问数据，虽然这在严格意义上不安全，但在GC保证对象存活的前提下可以接受。同时定义了Heap结构来管理分配、字符串驻留和清除操作。

作者总结，Rust的编译时内存安全模型与运行时mark-and-sweep GC所需的可变共享语义存在根本冲突。虽然使用unsafe和原始指针是最直接、性能最高的实现方式，但放弃了Rust的部分安全保证。文章也提及了利用Pin<T>和生命周期来证明GC安全性的更复杂方法，但未在此实现。最终，除了GC部分，解释器的其他组件用Rust实现是相当合适的。

如何节省13.27美元SaaS账单

作者因网站流量增长导致Vercel免费额度耗尽并开始付费，决定尝试其付费分析产品后，选择自行构建分析API以节省成本。

核心问题与方案

• 问题起源：4年前因使用大量PNG图片导致免费出站流量耗尽，开始向Vercel付费。
• 初期解决：将主要违规图片转换为JPG格式，暂时缓解问题。
• 新增需求：尝试Vercel付费分析产品（Pro计划含25k事件，超出后$14/100k）后，因潜在成本决定自建。

技术方案：Squeeh Stack

• 定义：使用SQLite作为数据库的任意应用组合。
• 选型：Bun（运行时）+ Hono（API框架）+ SQLite。
• 优势：轻量、低成本、易于部署。

开发与优化过程

1. API搭建：创建简单POST端点接收分析数据。
2. 性能测试：
   • 使用hey进行负载测试，单机可达~50k请求/秒。
   • 启用SQLite的WAL模式解决锁问题。
   • 实现批量插入（每20ms一次）提升吞吐量。
3. 部署挑战：
   • DigitalOcean VPS部署，放弃Docker改用裸机。
   • 因负载测试导致IP被封禁。
   • 使用systemd确保服务持续运行，解决进程崩溃问题。
   • 发现Hono静态路由导致崩溃，移除后稳定。

客户端实现

• 数据收集钩子：
  • 跟踪页面视图、离开/返回事件。
  • 使用localStorage存储会话ID以识别唯一用户。
  • 通过浏览器语言推断国家/地区。
  • 实现navigator.sendBeacon优化数据发送。
• 集成：作为React组件添加至Next.js应用，类似Vercel的集成体验。

分析仪表板

• 功能：匹配Vercel基本指标（访客数、页面浏览量、来源、国家等）。
• 开发挑战：尝试多个图表库（recharts, nivo）均与React Server Components兼容性不佳。
• 最终方案：使用纯HTML表格和自定义CSS组件展示数据。

成本与效果比较

• 成本节省：对比Vercel分析支出，月省$13.27。
• 数据准确性：自建系统与Vercel数据大致吻合，略有差异（可能因唯一性判断或未过滤机器人流量）。
• 资源占用：服务运行在$6/月VPS上，CPU/内存使用率低（Bun峰值约50MB）。

结论与展望

• 作者保持自建服务与Vercel并行运行以持续评估。
• 承认更专业的工程师可构建更健壮的服务，但会增加复杂度和成本。
• 探索了SQLite在边缘计算场景的潜力，并计划进一步实验Squeeh Stack。

SAM 2：图像与视频万物分割模型

SAM 2 是由 Meta AI（FAIR）开发的一个基础视觉分割模型，旨在解决图像和视频中的可提示（promptable）分割任务。它扩展了原有的 SAM（Segment Anything Model）能力，通过将图像视为单帧视频，实现了对图像和视频内容的统一处理。

核心特性与设计

• 模型架构：采用简单的 Transformer 架构，并结合流式内存，以支持对视频的实时处理。
• 数据引擎：构建了一个“人在回路”的数据引擎，通过用户交互同时优化模型与数据，并由此收集了 SA-V 数据集——这是目前最大的视频分割数据集。
• 性能：在 SA-V 数据集上训练的 SAM 2 在多种任务和视觉领域中表现出色。

最新更新（摘要）

1. 2024年12月11日：
   • 支持对整个模型进行 torch.compile，通过设置 vos_optimized=True 可显著提升视频对象分割（VOS）的推理速度。
   • 更新了 SAM2VideoPredictor 的实现，支持独立的单对象推理，允许在跟踪开始后添加新对象和进行多对象跟踪。
2. 2024年9月30日：
   • 发布了 SAM 2.1 开发套件，包括改进后的模型检查点（SAM 2.1）、训练代码和 Web 演示。
   • 需使用最新的代码库。

安装与使用

• 环境要求：Python >= 3.10， PyTorch >= 2.5.1， torchvision >= 0.20.1。
• 安装步骤：
  1. 克隆代码库：git clone https://github.com/facebookresearch/sam2.git && cd sam2
  2. 安装：pip install -e . （如需示例笔记本，使用 pip install -e ".[notebooks]"）。
• 检查点下载：支持运行脚本批量下载或单独下载 sam2.1_hiera_{tiny, small, base_plus, large}.pt 模型文件。
• 模型调用：
  • 图像预测：使用 SAM2ImagePredictor 类。
  • 视频预测：使用 build_sam2_video_predictor 函数创建预测器，通过 init_state 初始化视频状态，使用 add_new_points_or_box 添加提示，并通过 propagate_in_video 在视频中传播掩膜。
  • 也可通过 Hugging Face Hub 加载模型（如 facebook/sam2-hiera-large）。

模型描述与性能

SAM 2.1 是改进版模型，相比初版 SAM 2 在性能上有所提升。以下是各版本模型在速度（A100 GPU上）及数据集（SA-V test, MOSE val, LVOS v2）上的表现（指标为 J&F）：

其他资源

• 数据集：详情参见 sav_dataset/README.md。
• 训练：支持在自定义图像或视频数据集上训练或微调 SAM 2。
• Web 演示：提供了前端和后端代码，用于部署本地演示。
• 许可证：模型检查点、演示代码和训练代码采用 Apache 2.0 许可，但演示中使用的 Inter 字体和 Noto Color Emoji 采用 SIL Open Font License 1.1。
• 引用：如在研究中使用，请引用原论文。

互联网是为抵御核打击而创建的吗？

本文考证了一个广为流传的说法：互联网（ARPANET）是美国国防部为在核战争中确保通信而设计的。经过详细的历史文献追溯与分析，作者认为这是一个起源神话，并梳理了该说法的产生、传播与固化过程。

核心结论

1. 神话内容：流行叙事声称，互联网的前身ARPANET是在冷战期间，由国防高级研究计划局（DARPA）资助，旨在创建一个无中心、能抵御核打击、确保军事指挥控制持续的分布式通信网络。
2. 实际历史：根据ARPANET项目亲历者（如鲍勃·泰勒、文特·瑟夫等）的证词以及当时的正式文件，ARPANET的主要设计目标是：
   • 促进大学和研究机构间的研究与信息共享。
   • 通过“分时”系统远程访问和共享昂贵的计算资源（如伊利诺伊大学的ILLIAC IV超级计算机）。
   • 降低成本并提高计算机的利用率。 早期的ARPANET节点位于普通大学办公楼，缺乏加固和备用电源，这与军事核生存设施的特征不符。
3. 神话的混淆来源：
   • 保罗·巴兰的提案：1960年代，兰德公司的保罗·巴兰确实为美国空军提出过一个“分布式、抗毁”的通信网络设想，但该提案从未被军方采纳，也未成为ARPANET的基础。
   • 资助背景：ARPANET的资助方DARPA隶属于国防部，其技术与冷战背景下的许多创新有关，但这并不代表其原始设计目的就是核生存。
   • 叙事简化与误读：将巴兰的独立提案与后来的ARPANET项目按时间顺序并列，容易让不熟悉背景的读者推导出错误的因果联系。记者和非专业作者在传播中简化故事，使其更戏剧化（“对抗核战争”比“共享计算机”更吸引人）。
4. 神话的传播与固化：
   • 起源：文章指出，将ARPANET与核战争直接关联的叙事最早出现在1991年（《Network World》），并在1992至1995年间通过多部技术书籍、文章、杂志（如《TIME》）和纪录片广泛传播。
   • 社会学分析：作者提出“赢家圈理论”解释了这种现象。以DARPA/BBN为代表的“赢家圈”叙事聚焦于自身贡献（ARPANET项目本身），而外部学者（“同行”）倾向于提供更宽广的历史图景（包含巴兰、英国国家物理实验室等其他项目）。当后者简化的版本更符合公众想象时，便逐渐成为“常识”。
   • 持续影响：对Reddit评论的粗略分析显示，约有六分之一的提及互联网历史的评论仍然支持核生存叙事，且这一比例在过去十多年中相对稳定。尽管项目亲历者数十年来一直在试图澄清，但该神话已经根深蒂固。

总结

该文通过严谨的历史考证，确认“互联网为抵御核打击而创建”的说法是一个美丽的错误。它源于对不同时期、不同项目的混淆，以及在传播过程中为追求故事吸引力而进行的简化。互联网（ARPANET）的实际起源是一个关于促进学术合作和共享计算资源的科学故事，而非一个冷战军事生存计划。

透明电视技术：LG与三星在CES 2024的演示

在2024年CES展会上，LG和三星均展示了令人瞩目的透明电视屏幕，其图像仿佛悬浮在空中，但这种技术短期内难以进入普通家庭。两家公司采用了截然不同的技术路径。

LG的透明OLED技术 LG采用OLED（有机发光二极管）技术。OLED材料在电流激发下发光，通过精细的薄膜排列形成像素。实现透明度的关键在于使用透明导电材料（如氧化铟锡）连接像素，并尽可能缩小晶体管尺寸以减少遮光。LG使用了铟镓锌氧化物（IGZO）晶体管，其电子迁移率高于传统非晶硅，允许制造更小的晶体管。然而，OLED材料需防氧防水，必须添加封装层，这阻碍了将小面板无缝拼接成大屏幕。LG的透明原型机透明度约为45%，物体在屏幕后会明显变暗。

三星的透明microLED技术 三星采用无机microLED技术。每个像素由红、绿、蓝三个微型LED芯片组成。这些芯片极小（约12×27微米），遮光少，可实现超过60%的透明度。microLED无需封装，理论上可无缝拼接成大屏幕。但技术挑战巨大：LED芯片的波长有微小差异，导致色彩不均，传统的“分档”筛选方法成本过高。目前需要在组装后对屏幕进行校准，通过调整电流来补偿颜色和亮度差异。此外，将数百万个微型LED精确放置并连接的工艺复杂且良率要求极高，即使达到99.9%的良率，在4K屏幕上仍可能产生数万个缺陷子像素，修复成本高昂。其制造成本远高于OLED，例如三星非透明114英寸microLED电视售价高达15万美元。

应用前景与挑战 两种透明显示技术目前都价格昂贵，不太可能成为主流家用电视。主要原因包括：

1. 高成本：透明版本将比已昂贵的非透明电视更贵。
2. 实用性质疑：观看内容时，背后的物体会分散注意力（LG演示机附带了一个可展开的黑色对比层来解决此问题）。

然而，透明显示在特定领域具有潜力：

• 商业与公共信息显示：如LG在首尔高速地铁车窗上安装的透明OLED面板，用于显示地图等信息。
• 工业与设备：如工程设备的透明触摸屏，可显示数据或作为摄像头取景器。
• 远程会议设备：如将摄像头置于透明屏幕后方，以便在视频通话时保持眼神接触。
• 零售广告：作为吸引眼球的展陈装置。

总结 虽然microLED在亮度、效率和寿命等方面理论上更具优势，且支持无缝拼接，但其制造工艺的复杂性和高成本使其商业化进程缓慢。苹果公司此前投入巨资后又暂时放弃microLED，表明该技术用于消费市场仍面临重大挑战。相比之下，OLED技术目前更成熟、更具成本效益，在透明显示的早期应用中处于领先地位。透明显示的普及仍有赖于未来制造技术的进步和成本的降低。

Embedding.io：将网站转化为 LLM 知识库

项目概述

该工具旨在将任何公开网站转化为大语言模型（LLM）的知识库。通过自动爬取、分块和向量化网站内容，帮助用户快速将网页数据接入 LLM 应用。

核心工作流程

1. 创建集合 (Collection)：通过 API 或 Web 界面创建数据集合，用于存放和管理目标页面或网站。
2. 摄取内容 (Ingest)：将网页域名添加至集合。系统会自动接管后续的数据处理与更新工作。
3. 查询集合 (Query)：数据处理就绪后，用户可通过 API 对集合内容进行语义查询，系统会持续保持数据同步。

关键技术特性

• 智能内容提取：无需目标网站提供 Sitemap。系统结合机器学习与启发式算法，精准提取页面主体内容，自动过滤导航栏、广告等无关信息。
• 广泛的数据源支持：支持嵌入任何公开可用的互联网内容，涵盖网站、博客、技术文档等。
• API 驱动：提供完整的 API 接口与详细文档，支持通过代码实现集合的创建、管理、内容摄取和查询。
• 灵活的更新机制：支持根据订阅计划自动定期更新，同时允许用户手动触发内容更新。企业版还支持定制专属爬虫。

计费模式与套餐

系统采用“积分 (Credit)”作为计量单位，每添加或更新一个页面均消耗 1 个积分。具体套餐如下：

• Free（免费）：每月 500 积分（最多 500 页），限 1 个集合，每月更新。
• Hobby（$20/月）：每月 2,000 积分，最多 5 个集合，每周更新。
• Startup（$100/月）：每月 20,000 积分，最多 10 个集合，每日更新。
• Enterprise（企业版）：无限页面与集合，每小时更新，提供自定义爬虫、SLA 保障及专属客户引导。

补充说明：积分超额需升级套餐以继续添加页面；用户可随时取消订阅，账户在当前计费周期结束前保持有效。

文章总结：从零开始的微预算扩散模型训练

本文旨在解决生成式AI因规模化定律导致模型开发高度依赖大量计算资源的问题，特别是针对文本到图像扩散模型。作者提出了一种极低成本的大规模扩散Transformer模型训练方法。

核心方法与创新点

1. 降低计算成本的策略：由于Transformer的计算成本随图像块数量增加，训练时随机掩盖高达75%的图像块。
2. 延迟掩盖策略：在掩盖前，使用一个混合器对所有图像块进行预处理。此策略显著减少了掩盖带来的性能下降，效果优于通过缩小模型规模来降低计算成本的方法。
3. 架构与数据优化：采用了最新的Transformer架构改进（如专家混合层）以提升性能。研究还发现，使用合成图像对于微预算训练至关重要。

关键成果

• 训练配置与成本：仅使用3700万张公开的真实与合成图像，训练了一个拥有11.6亿参数的稀疏Transformer模型。
• 性能与效率：在COCO数据集的零样本生成中取得了12.7的FID分数，生成质量具有竞争力。
• 成本对比：训练总成本仅为1,890美元。与稳定扩散模型相比，成本降低118倍；与当前最先进的方法（成本28,400美元）相比，成本降低14倍。

意义与展望

该研究有效降低了大规模扩散模型的训练门槛，实现了以微预算进行端到端训练。作者计划发布完整的训练流程，以进一步推动大规模扩散模型训练的民主化。

大型语言模型量化的视觉指南摘要

本文旨在系统地介绍大型语言模型量化的概念、原理和实践，以帮助读者建立对这一领域的直觉性理解。

一、量化的必要性

• 核心挑战：LLM模型参数数量巨大（通常达数十亿），原生精度（如FP32）需要巨大的内存和计算资源，难以在消费级硬件上运行。
• 量化目标：在尽可能保持模型精度的前提下，通过降低模型参数（权重）和中间计算结果（激活值）的数值精度（比特数），来显著减少内存占用并可能加速推理。

二、数值表示与量化基础

• 数值表示：计算机使用“比特”（bit）表示数值，浮点数标准（如IEEE-754）定义了符号、指数和尾数。精度越高，能表示的数值范围（动态范围）越大，精度也越高。
• 内存计算：存储所需内存（字节） ≈ 比特数 × 参数数量 / 8。例如，一个700亿参数的模型使用FP32需要约280GB内存。
• 量化本质：将高精度（如32位浮点数）的数值映射到低精度（如8位整数）表示的过程。这类似于用更少的颜色表示图像，会引入“量化误差”，但目标是最小化误差。

三、常见量化数据类型

• FP16 (半精度)：16位，范围比FP32小。
• BF16 (脑浮点16)：16位，拥有与FP32相似的范围，常用于深度学习。
• INT8 (8位整数)：8位，计算速度通常更快。从FP32映射到INT8是常见目标。

四、核心量化映射方法

1. 对称量化 (如Absmax)：
   • 将原始浮点范围线性映射到以零为中心的量化范围（如[-127, 127]）。
   • 零点始终对应零点。
   • 公式简单，通过缩放因子 s 实现。
2. 非对称量化 (如零点量化)：
   • 将原始浮点范围的最小值和最大值分别映射到量化范围的最小值和最大值。
   • 需要计算一个“零点偏移” z，因为原始空间的零点不一定映射到量化空间的零点。
   • 能更精确地映射非对称分布的数据。

五、处理离群值与校准

• 问题：数据中的离群值会扭曲映射范围，导致大量非离群值精度损失严重。
• 解决方案：裁剪，即人为设定一个动态范围（如[-5, 5]），超出范围的值被截断。这降低了非离群值的误差，但增加了离群值的误差。
• 校准：选择最佳裁剪范围的过程，方法包括选择百分位、最小化均方误差（MSE）或最小化原始分布与量化分布之间的熵/散度。
• 权重 vs 激活值：
  • 权重：静态，训练后已知，可离线校准。
  • 激活值：动态，依赖于输入，必须在推理时或通过校准数据集处理。

六、主要量化途径

1. 训练后量化：
   • 在模型训练完成后进行量化。
   • 权重：直接应用对称/非对称量化。
   • 激活值：
     • 动态量化：在每次推理时，根据每层输入实时计算缩放/零点因子。更精确，但可能增加延迟。
     • 静态量化：使用校准数据集预先确定每层激活值的缩放/零点因子。推理时使用固定因子，速度更快，但精度稍低。
2. 量化感知训练：
   • 在训练过程中模拟量化效应（使用“伪量化”）。
   • 使模型在训练时就适应低精度计算，寻找对量化更鲁棒的参数（位于损失曲面“宽”的极小值点）。
   • 通常能获得比PTQ更好的精度。

七、先进量化技术

1. GPTQ：
   • 目标：在GPU上运行全精度模型的4位量化。
   • 方法：逐层处理，使用非对称量化。
   • 关键：利用模型的海森矩阵逆来评估权重的重要性，并将量化误差重分布到同一行中其他相关性高的权重上，以保持模型输出功能。
2. GGUF：
   • 目标：支持将LLM部分层卸载到CPU运行，实现CPU/GPU混合推理。
   • 方法：采用分层（super-block/sub-block）量化。对子块中的权重使用Absmax量化，但对子块的缩放因子 s_sub 使用上级块 s_super 再次量化。不同量化级别（2-bit, 4-bit, 6-bit）的 s_sub 精度不同。
3. BitNet系列：
   • BitNet (1-bit)：权重仅为{-1, 1}。使用符号函数量化权重，激活值量化为INT8。仅在大模型（>30B）上与FP16差距较小。
   • BitNet 1.58b：权重为三元{-1, 0, 1}。
     • 优势：引入0后，矩阵乘法可简化为加减运算和特征过滤，大幅提升计算效率。
     • 量化：权重使用绝对均值量化，激活值使用范围调整的Absmax量化。
     • 结果：实现极高的效率，13B的BitNet b1.58在延迟、内存和能耗上优于3B的FP16模型。

八、总结

量化是释放LLM在有限硬件上运行潜力的关键技术。从基础的FP32到INT8，再到极端的1.58-bit，量化通过不同的映射策略、校准方法和专用技术（如GPTQ、GGUF、BitNet），在精度与效率之间寻找最佳平衡点。随着研究深入，模型将能在更小的硬件上高效运行。

FTC竞业禁止禁令规则的最新法律进展

美国联邦贸易委员会（FTC）于2024年4月发布了旨在禁止几乎所有员工竞业限制协议的最终规则。该规则迅速在全美多个法院遭到法律挑战。截至目前，联邦法院在两项初步裁决中得出了相反的结论。

1. 首轮裁决：德克萨斯州法院质疑FTC权限

• 时间与法院： 2024年7月3日，德克萨斯州北区联邦地区法院。
• 核心观点： 法院初步认为，FTC可能无权发布如此全面的实质性规则。
• 理由： 法院裁定，FTC的授权法律仅允许其针对“不公平或欺骗性行为或做法”制定实质性规则，而非针对“不公平竞争方法”。由于FTC将竞业禁止归类为后者，该法院认为其越权。

2. 第二轮裁决：宾夕法尼亚州法院支持FTC权限

• 时间与法院： 2024年7月下旬，宾夕法尼亚州东区联邦地区法院。
• 核心观点： 法院初步认为，FTC有权禁止所有员工竞业限制协议。
• 理由：
  • 法院认为《联邦贸易委员会法》授权FTC“为执行本章条款而制定规则和条例”，该法条并未区分“程序性”和“实质性”规则。
  • 法律赋予FTC“预防”不公平竞争方法的权力，这暗示了其在该领域制定实质性规则的权力。
  • 法院驳斥了德克萨斯州法院的解释，认为其“违背逻辑”。
  • 法院拒绝从法律对“不公平或欺骗性行为”的具体授权中，推断出限制其对“不公平竞争方法”制定规则的能力。

3. 后续法律进程与展望

• 目前法律战比分紧接（文中比喻为“1比1平”）。
• 预计佛罗里达州法院将很快做出另一项初步裁决。
• 德克萨斯州法院表示将在2024年8月底前对是否发布最终禁令做出裁决。
• 此后案件将进入上诉阶段，最终很可能需要美国最高法院介入裁决，除非在此之前政治进程阻止该规则生效。
• 该规则原定于2024年9月4日生效。

4. 不遵守规则的潜在后果

尽管FTC的执法权力存在争议，但目前看来，不遵守该规则的直接后果可能有限：

• 关键限制： FTC对违反“不公平竞争方法”规则的行为无权直接处以民事罚款（每次违规最高10,000美元的罚款权力仅适用于“不公平或欺骗性行为或做法”的违规）。
• 执行程序漫长： 即使规则生效，FTC也必须经过一套漫长程序：发出行政投诉、举行听证会、下达停止令、并等待该命令成为最终命令（上诉期届满或所有上诉结束）。只有在雇主违反最终停止令后，FTC才能向法院提起诉讼寻求民事罚款。
• 建议： 持有竞业限制协议的雇主应咨询律师，在动态变化的法律环境中做出最佳决策。

Zig的C宏反射能力：超越C自身的互操作性

本文探讨Zig编程语言在与C语言互操作方面的卓越表现，特别展示了Zig能够实现C预处理器宏的反射，而这在C语言中是不可能实现的。

Zig的C互操作优势

Zig作为面向低层和系统编程的新语言，其与C的互操作能力极为突出。基本调用C外部库虽然在其他语言中也能实现，但Zig能直接导入C头文件并将其视为普通Zig导入使用，例如：

const win32 = @cImport({
    @cInclude("windows.h");
    @cInclude("winuser.h");
});

这种能力使得Zig开发者可以无缝访问大量现有的、经过实战检验的C库，无需手动声明函数原型。

Windows编程示例

文章通过一个Windows应用程序示例展示Zig的实用性。典型的Win32程序包含主函数和窗口过程函数，窗口过程通过switch语句处理各种消息类型。在Zig中，C头文件中的宏（如WM_CLOSE）和函数声明以相同方式访问，都被表示为导入结构体的字段。

Zirg的宏反射核心创新

文章的重点在于Zig的宏反射能力。C语言预处理器宏在编译前展开，编译器无法内省这些宏，因此无法在运行时或编译时获取宏名到值的映射。而Zig通过@typeInfo函数可以列出导入结构体的所有字段和声明，从而在编译时内省C宏。

具体实现中，通过遍历导入的win32结构体的所有声明，筛选以"WM_"开头的字段，创建了一个从消息值到消息名的映射数组：

fn get_window_messages() [65536][:0]const u8 {
    // 遍历所有结构体声明并匹配特定前缀
    for (@typeInfo(win32).Struct.decls) |field| {
        if (field.name.len >= 3 and std.mem.eql(u8, field.name[0..3], "WM_")) {
            const value = @field(win32, field.name);
            result[value] = field.name;
        }
    }
    return result;
}

利用这个映射，窗口过程函数可以输出更有意义的消息名称，而不仅是十六进制代码。

Zig的实用主义哲学

文章总结指出，Zig通过深度集成C互操作解决了语言采用的关键障碍：

• 自带C编译器工具链，实现无缝的C头文件包含
• 为现有C/C++代码库提供向Zig过渡的路径
• 开发者可立即访问数千个现有C库

Zig的设计体现了实用主义哲学：在几小时内就能实现这种C宏反射技巧，同时保持整体的高效生产力。虽然Zig主要定位为C的替代品，但其出色的跨编译能力和直观一致的设计也是重要优势。

作者强调，Zig的C集成能力是吸引其学习的主要原因，但语言的设计哲学是使其长期投入的关键因素。

漏洞概述

CVE-2024-5535（SSL_select_next_proto 缓冲区越界读取）是一个自 2011 年起存在于 OpenSSL 中的内存安全漏洞，被评估为“低”严重级别。该漏洞会导致客户端在特定条件下向服务器泄露堆内存数据。

漏洞原理

当应用程序调用 SSL_select_next_proto 函数，且传入的客户端协议列表缓冲区无效（例如 client_len == 0 的空缓冲区）时，函数缺乏边界检查。它会无条件读取 client[0] 并返回越界指针 client + 1。这导致输出指针指向无效地址，且输出长度包含未定义的值。

漏洞影响

此内存安全故障通常发生在客户端的 NPN（Next Protocol Negotiation）回调中。错误的指针和长度会导致客户端堆内存中最多 255 字节的数据被复制，并作为 selected_protocol 字段放入 NextProtocolNegotiationEncryptedExtension 中，通过加密连接静默发送给支持 NPN 的服务器，造成客户端堆内存泄露。

受影响范围

• 底层加密库：所有版本的 OpenSSL（1.0.x、1.1.x、3.x）均受影响；BoringSSL 受影响但已修复；LibreSSL 包含错误代码，但因 2017 年已移除 NPN 支持而无实际影响。
• 应用程序：影响使用空 NPN 协议列表的客户端，已确认包括 Python <= 3.9、Node.js <= 9 以及 2014 年之前的 Android（OkHttp 曾独立发现并规避此问题）。
• 实际风险：NPN 协议在 2012 年已被 ALPN 取代，现代版本的 Node.js、Python 和服务器端极少使用 NPN，因此当前的实际触发概率极低，主要属于历史遗留风险。

发现与处理时间线

• 2011年11月：漏洞代码引入。
• 2024年4月：在将 OpenSSL 代码重写为 Rust（rustls-libssl）的过程中发现此内存不安全行为。
• 2024年5月：确认 Python 3.9 和 Node.js 9 受实际影响，向 OpenSSL 和 BoringSSL 提交报告，并分配 CVE 编号。
• 2024年6月：发布官方安全公告。

缓解与修复建议

由于已知受影响的程序版本大多已停止维护或移除了 NPN 支持，建议开发者审查历史上对 SSL_select_next_proto 的调用情况。如果评估认为曾经可能触发过此漏洞，建议轮换（Rolling）受影响程序中可能暴露的任何敏感密钥或凭证。

Orca项目旨在通过“反转Web技术栈”来解决当前Web平台作为应用分发基础层的复杂性问题。其核心思想是将Web重新构建为一个本地优先（local-first）的沙盒执行环境，作为新的基础层。在此之上，可以更低成本地实现内容嵌入（transclusion）、超链接和动态文档模型。该项目的目标是大幅简化可移植、可组合应用程序的开发，并赋予用户对其计算机使用更大的自主权和自由度。该项目由Martin Fouilleul领导，并得到社区贡献者和用户的支持。

摘要：DigiCert 证书吊销事件（基于CNAME的域名验证）

事件概述

DigiCert 将吊销一批未经正确域名控制验证（DCV）的证书。在颁发证书前，DigiCert 需通过CAB论坛（CA/Browser Forum）批准的方法验证客户对申请域名的控制权。其中一种方法是要求客户添加包含DigiCert提供的随机值的DNS CNAME记录，随后DigiCert通过DNS查询验证该随机值。

在部分基于CNAME的验证案例中，DigiCert未在随机值前添加下划线前缀（“_”）。虽然添加下划线前缀是为了防止验证子域名与实际域名发生冲突，但根据严格的CAB论坛规则，任何域名验证的不合规都必须在24小时内吊销相关证书。此问题影响了约0.4%的有效域名验证，主要涉及TLS证书，少量S/MIME证书也受影响。

客户行动要求

受影响的客户需在2024年8月9日 20:30 UTC前更换证书。客户应登录DigiCert账户，查看受影响的证书并重新签发/更换。

• 重新签发TLS/SSL证书：登录CertCentral账户，查看受影响证书，生成新的CSR，在证书操作中选择“重新签发证书”，完成验证后安装新证书。
• 重新签发S/MIME证书：在CertCentral中定位受影响证书，选择“重新签发证书”，如需要则上传CSR，选择签名哈希并说明原因后提交申请。

技术细节

CAB论坛基线要求规定了域名验证方法，其中“方法7”（基于DNS的验证）允许通过CNAME、TXT或CAA记录进行验证。对于CNAME记录，添加方式有多种：

1. _randomValue.foo.example.com CNAME dcv.digicert.com （随机值需要下划线前缀）
2. foo.example.com CNAME randomValue.dcv.digicert.com （随机值不需要下划线前缀）
3. _dcv.foo.example.com CNAME randomValue.dcv.digicert.com （随机值不需要下划线前缀）

DigiCert向客户提供的文档未明确说明第一种方式中随机值必须带下划线前缀，导致使用该方法且未手动添加下划线的验证不合规。尽管冲突概率极低，但因存在理论上的可能性，根据CAB论坛规则必须吊销证书。

根本原因分析

2019年，DigiCert开始现代化其验证系统，将旧CertCentral系统中自动添加下划线前缀的功能移至新的服务化架构中。然而，在一个系统路径中，既未自动添加下划线前缀，也未检查客户是否手动添加。此缺陷在部署前的跨功能评审和回归测试中未被发现，因为测试范围未覆盖随机值的具体格式/结构。

2024年6月11日，一项用户体验优化项目将多个随机值生成微服务合并为单一服务，该服务开始在所有随机值前自动添加下划线前缀。此举虽修复了问题，但DigiCert仍未将此变更与旧系统流程进行比对。直到最近，在收到外部问题报告并进一步审查后，DigiCert才确认了此次合规问题。

已采取的预防措施

为防止类似事件再次发生，DigiCert已采取或计划采取以下措施：

1. 已完成：整合并审查所有域名验证中的随机值生成器。
2. 已完成：优化用户体验，使客户无需根据选择的验证方法手动处理随机值格式。
3. 已完成：合规团队成员嵌入所有证书颁发机构（CA）和注册机构（RA）的冲刺团队，参与设计/架构评审。
4. 已完成：在所有验证工作流中增加超出功能测试范围的、基于合规性的自动化测试用例。
5. 进行中：将域名验证代码开源以供社区审查（预计2024年12月1日完成）。

Canarytokens 工具概述

Canarytokens 是一款免费工具，旨在通过让攻击者自我暴露的方式，帮助用户发现系统是否已被入侵。该工具允许用户在其网络中植入各种“陷阱”（即令牌），一旦这些令牌被触发，系统会立即发送通知，从而在安全事件发生时及时告警。

核心功能与用途

1. 入侵检测：通过在网络、文件或凭证中嵌入不起眼的令牌，当攻击者访问或使用这些令牌时，即可判定系统存在未授权访问。
2. 主动防御：用户可在关键区域（如服务器、文档、域名记录等）部署令牌，构建一个轻量级的内部威胁预警系统。
3. 即时告警：令牌一旦被激活，可通过电子邮件、Slack、短信等多种渠道向管理员发送通知，确保快速响应。

工作原理

用户根据需求生成特定类型的令牌（例如：一个伪装成敏感文档的Word文件、一个指向特定URL的链接、一条特殊的DNS记录等）。当攻击者在入侵过程中打开、点击或查询这些令牌时，系统便会收到警报，从而在攻击者意识到被发现之前，为防御者争取到宝贵的应对时间。

关键特性

• 免费：工具本身提供免费使用。
• 多样化陷阱：支持生成多种类型的令牌，以适应不同的监控场景。
• 低误报率：令牌通常设置在不应被正常访问的位置，因此触发警报往往意味着确实存在可疑活动。

Microjs 项目概述

Microjs 是一个致力于发现和推广 JavaScript 微型框架（Micro-frameworks）与微型库的平台。该项目旨在反思现代开发中对庞大单体框架的过度依赖，提倡使用轻量级、高精准度的代码工具，以避免引入大量实际未被使用的冗余代码。

微型框架的核心特征

文章将庞大的单体框架比作带有空调和高级音响的大型拖拉机，而将微型框架比作精准高效的“便携小刀”。微型框架具备以下核心特点：

• 极致轻量：代码体积严格控制在 5KB 及以下，具备极高的可移植性。
• 功能专一：遵循“只做一件事并把它做好”的原则，拒绝代码冗余、功能蔓延（featuritis）和过度设计。
• 高效实用：摒弃不必要的特性，以更精简的代码更快、更灵活地解决特定问题。

网站功能与社区贡献

• 框架发现与选择：Microjs.com 帮助开发者发掘紧凑且功能强大的微型框架，并提供便捷的途径让开发者挑选最适合当前项目的工具，从而替代动辄 50K 到 150K 以上的庞大库。
• 开源协作结构：项目采用开源协作模式。开发者可以通过在 GitHub 上 Fork 该项目，将新的框架信息添加到核心的 data.js 数据文件中，并提交 Pull Request 来收录和推广自己的微型框架。

致谢

项目特别感谢了 Time Zone Converter 提供的支持。

Trayce 项目摘要

项目名称: Trayce
类型: 开发者工具 / API 客户端 & 网络监控器
核心定位: 专为 Docker 容器提供网络流量监控的 API 客户端。

核心特性

1. 开发者优先

• 完全免费开源：无付费版本。
• 纯离线使用：所有文件以本地 git-friendly 的 bruno-lang 格式存储，无需注册账户。
• 与 Bruno 互通：可以打开并编辑 Bruno 集合，且修改后的文件仍与 Bruno 应用兼容。

2. 功能强大的 API 客户端

• 高级 HTTP 客户端：支持身份验证、JavaScript 脚本、变量与机密管理。
• 功能接近 Bruno：已实现 Bruno 的大部分功能，部分仍在开发中。
• 高性能轻量级 GUI：拥有类似原生桌面应用的外观和操作体验，启动和运行速度极快。

3. 独特的网络监控器 (核心亮点)

• Docker 容器的“网络标签页”：用于开发、调试和测试，可查看本地 Docker 容器的网络流量。
• 零配置：无需运行代理或配置 CA 证书。Trayce Agent 使用 eBPF 技术监控网络流量，包括 TLS 加密流量。
• 广泛的协议支持：支持 HTTP, HTTP2, gRPC, MySQL, PostgreSQL, TLS 等协议。

企鹅有膝盖吗？以及其他常见问题

本文以回答“企鹅有膝盖吗？”和“企鹅到底是什么动物？”这两个常见问题为切入点，系统介绍了企鹅作为鸟类的特征、独特的骨骼适应以及进化历史。

企鹅是鸟类

尽管企鹅外形独特、不能飞行，但它们符合鸟类的所有基本特征：恒温、呼吸空气、卵生、全身覆盖羽毛并拥有喙。因此，企鹅毫无疑问属于鸟类。

企鹅的骨骼适应

为适应水下生活，企鹅的骨骼演化出两大关键特征：

1. 发达的龙骨（胸骨）：宽大平坦的龙骨为强大的飞行肌（用于划水）提供附着点，使其能在密度更高的水中有效推进。
2. 实心骨骼：与其他鸟类中空的轻质骨骼不同，企鹅的骨骼沉重且致密。这有助于减少浮力，使它们能够顺利下潜捕鱼。

膝盖的位置与行动姿态

企鹅确实有膝盖，但其膝盖位于身体内部。人们通常误以为企鹅弯曲的“膝盖”实际上是它们的脚踝。

• 结构：企鹅的腿骨结构与人类类似，但膝盖被包裹在身体腔内，仅脚踝和脚部显露在外。
• 功能：这种结构使企鹅身体呈流线型，非常适合水中游泳。在陆地上，这导致了它们标志性的摇摆步态，行动相对笨拙。不过，对许多南极企鹅而言，陆地威胁较小，水域才是更安全的领域。

进化历史

现代研究通过线粒体DNA等证据表明，企鹅并非从其他不能飞行的走禽（如鸵鸟）进化而来，而是独立起源于已灭绝的会飞鸟类。它们与信天翁、军舰鸟等海鸟有亲缘关系，最近的现存近亲可能是鹳形目鸟类（如鲣鸟）。

古生物化石（如生活在约6000万年前的Waimanu）显示，企鹅的谱系非常古老。科学家认为，在白垩纪末期的大灭绝事件后，幸存鸟类快速演化，其中一支逐渐适应了海洋生活，最终形成了今天的企鹅。

总结：企鹅是高度特化的鸟类，其骨骼结构、膝盖位置和运动方式都是长期适应水中捕食生活的结果。尽管外形与典型鸟类差异巨大，但其根本特征和进化根源仍属于鸟类。

Rendley：浏览器端AI视频编辑SDK

• 产品定位：一款基于浏览器的视频编辑工具，拥有超过4000名用户，专为需要高效产出大量视频的营销团队设计。它通过AI代理简化从粗剪到最终导出的整个编辑流程。

• 核心功能：

  • 文本提示编辑：用户只需输入文本提示或提供拍摄脚本，AI代理即可像团队中的视频编辑一样，自动挑选素材、剪辑并组装视频。
  • 素材清理：可快速去除视频中的填充词（如“嗯”）、停顿和空白间隔，适用于短片或长达数小时的录制。
  • B-roll生成：无需手动搜索，Rendley能通过AI生成、内置素材库或动态图形，自动匹配视频节奏提供相关素材。
  • 自动字幕：为视频添加精准、与语音同步的字幕，支持自定义字体、颜色和布局以匹配品牌风格。
  • 内置AI生成：在项目内直接生成视频片段、图像或配音，集成多种模型（如Seedance, Kling, Veo），使用统一的积分池。
  • 品牌套件管理：可为每个客户或产品线设置品牌套件（包含Logo、字体、颜色、音频），确保团队制作的所有视频品牌一致性，且切换方便。
  • 用户审核与导出：AI完成编辑后，用户可进行审阅并导出成品。

• 目标用户与易用性：从个人营销者到专业代理商均可使用。界面设计直观，主要依赖AI代理处理编辑任务，用户仅需描述需求。

• 定价模式（提供多个层级）：

  • 免费版：无时间限制，720p导出，最多10个项目，1小时自动字幕，带水印。
  • 入门版（$15/席位/月）：1080p导出，10GB云存储，500积分/月，2.5小时自动字幕，无水印。
  • 专业版（$30/席位/月）：4K导出，50GB云存储，1200积分/月，4小时自动字幕，支持品牌套件及自定义字体。
  • 商业版（$70/席位/月）：100GB云存储，3000积分/月，5.5小时自动字幕，无限工作空间及AI代理对话。

Fly.io 实现有状态应用无损迁移的技术方案

Fly.io 作为全球公共云平台，采用本地附加NVMe存储来支持有状态应用，这种设计提供了极低的延迟访问，但也导致应用被固定在特定的物理服务器上，给维护和负载均衡带来了挑战。

核心问题

对于无状态应用，服务器排空操作很简单：在新位置启动实例、确认健康后终止旧实例。但对于附加了卷（Volume）的应用，直接迁移会导致数据丢失或服务中断。传统“杀进程、复制数据、启动新实例”的流程因数据量较大而耗时过长，无法接受。

解决方案：异步克隆迁移

Fly.io 实现了 异步克隆（Clone） 操作，取代了同步复制。其核心思路是：

1. 快速创建：在新物理机上快速创建一个“克隆卷”，该卷大部分为空。
2. 延迟加载：当新应用实例读取数据时，如果数据块尚未传输，系统会从原卷通过网络实时获取（称为“水合”过程）。写入操作则直接在新卷进行，不涉及网络。
3. 后台同步：后台线程持续将原卷数据块复制到克隆卷，直到完全同步。

这使“杀进程、克隆、启动”的流程速度接近无状态应用的迁移。

关键技术组件

1. 块级克隆（dm-clone）：

   • 利用Linux内核的device-mapper框架，特别是dm-clone模块。
   • 它在数据块级别工作，维护一个位图来跟踪哪些块已从源设备同步到克隆设备。
   • 对未同步块的读取会重定向到源设备；写入则在新设备上进行，并立即标记该块为“已同步”。后台进程同时进行主动数据复制。

2. 网络协议（iSCSI）：

   • 为了让目标服务器能访问源服务器上的卷，需要通过网络暴露块设备。
   • 起初尝试了更简单的NBD（网络块设备）协议，但遇到网络中断时线程卡死的问题。
   • 最终转向更稳定、Linux原生支持的iSCSI协议，确保了迁移过程在网络波动下的健壮性。

3. 编排系统（flyd）：

   • flyd是运行在每台物理机上的服务，管理其上所有Fly Machine的状态。
   • 迁移流程由flyd实例间协作完成：源机器停止应用并通知目标机器；目标机器创建dm-clone卷，通过iSCSI挂载源卷，启动新应用并监控克隆过程；完成后将克隆卷转换为普通卷并清理。
   • 整个流程被建模为一个有状态机，步骤清晰，便于添加和调试。

实施中遇到的复杂问题

1. 加密与密钥管理：卷使用LUKS2加密，每个卷有独立密钥。迁移时需要处理密钥传递和不同服务器上cryptsetup版本差异导致的LUKS头大小不一致问题。
2. 存储修剪（Trim）优化：许多卷只使用一小部分空间。为了让克隆卷快速识别并跳过未使用块，需要在目标服务器上以明文形式访问源卷文件系统，执行fstrim操作来识别并丢弃空块，这涉及跨服务器的安全处理。
3. 网络地址冲突：Fly.io的私有网络方案（6PN）将路由信息嵌入IPv6地址中。应用配置（如Fly Postgres集群）中直接使用了这些包含物理机信息的地址。迁移后地址变化会导致连接中断，修复此问题需要全平台协调更新配置。
4. 状态一致性：迁移打破了“每台服务器是其上应用状态唯一来源”的假设，与基于SWIM协议的Gossip数据库（Corrosion）产生竞争条件，需要重新设计以保证一致性。

未来方向

• 目前，迁移仍需谨慎执行，未来目标是实现全自动、定期负载均衡的“奢侈迁移”。
• 从本地NVMe存储转向更灵活的日志结构虚拟磁盘（LSVD） 方案。LSVD使用本地NVMe作为缓存，将持久化写入对象存储，结合了高性能和对象存储的可靠性与弹性。与新推出的区域化S3兼容对象存储服务（Tigris）的结合，使LSVD更具吸引力。

总结

Fly.io 通过创新地结合dm-clone块级异步复制、iSCSI网络协议和强大的flyd编排状态机，成功解决了基于本地NVMe存储的有状态应用的无损迁移难题。尽管过程中遇到了加密、网络地址、状态同步等一系列棘手工程挑战，但最终实现了接近无状态应用的迁移速度，为平台未来的自动运维和资源优化奠定了坚实基础。