2024-12-17

39 篇热帖

1. Getting to 2M users as a one woman dev team [video] (brightonruby.com)

Nadia Odunayo是The StoryGraph的创始人兼首席执行官,该应用帮助用户追踪阅读进度,并根据情绪和偏好主题推荐书籍。她是一名独立开发者,以“一人开发团队”的模式将该社区发展至超过一百万的书籍爱好者规模。

Nadia此前在Pivotal Labs担任软件工程师,最初在伦敦的Makers Academy学习编程。她的故事体现了坚持、洞察力以及执行“一个人框架”所需的技术见解。业余时间她热衷于上舞蹈课和阅读。

2. Lfgss shutting down 16th March 2025 (day before Online Safety Act is enforced) (www.lfgss.com)

LFGSS论坛宣布将于2025年3月16日关闭,即英国《在线安全法》生效前一天。关闭的核心原因是该法律的广泛适用性给个人运营的公益社区带来无法承受的合规负担与法律风险。

关闭原因

  • 法律范围过宽:《在线安全法》适用于所有“与英国相关”且允许用户生成内容和互动的网站,不论规模大小,均被纳入监管。LFGSS作为用户可相互交流的平台,明确处于该法律管辖范围内。
  • 合规成本过高:该法律要求运营者完成风险评估并采取措施降低风险(如扫描上传内容、处理举报等)。对于由个人慈善运营、捐赠仅能勉强覆盖服务器成本的论坛而言,进行法律、技术和人员上的合规改造所需成本(可能达数万英镑)是不可承受的。
  • 个人责任风险过高:作为唯一负责人,Dee将承担最高可达1800万英镑的法律责任。历史上曾因论坛管理遭受网络骚扰、死亡威胁等经历,使其认为此责任易被恶意用户利用,构成不可控的巨大个人风险。

论坛概况与影响

  • 历史与规模:Dee自1996年起运营论坛,近29年间共运营约500个论坛,服务近50万用户。LFGSS是其中最具代表性的社区之一,月活用户峰值曾超过5万。
  • 社区价值:论坛不仅促成了许多线下连接与互助(如骑行、工作支持、寻回失窃自行车),更被用户多次指出帮助他们度过心理健康危机、避免自我伤害。关闭意味着一个长久以来支持许多人的特殊社区的终结。

后续安排与影响

  • 关闭时间:计划于2025年3月16日删除服务器,终止所有运营的社区。
  • 临时替代方案:已设立Discord作为“救生筏”,供用户在过渡期间保持联系。但原论坛域名在关闭后将仅显示Discord邀请链接。
  • 更广泛影响:此事件并非个例,已有其他小型网站(如GamingOnLinux论坛)宣布关闭,或采取地理封锁措施(如Lobsters对英国用户封锁)。《在线安全法》被批评为对独立运营的小型网站和社区构成不成比例的负担,可能产生“寒蝉效应”。

更新说明 文章最后提及,尽管有提议寻求在海外运营等替代方案以保留部分国际论坛,但运营者仍认为个人风险过高,默认立场仍是按计划关闭。同时,为协助归档,已取消网站被爬虫索引的限制。

3. Veo 2: Our video generation model (deepmind.google)

Veo 3 是一款先进的视频生成模型,具备原生音频生成扩展视频时长等增强创意控制功能。

核心能力与提升

  • 更高的真实感与保真度:得益于对真实世界物理和音频的建模。
  • 更强的提示遵循能力:能更精确地响应用户指令。
  • 增强的创意控制:在音频和视频内容上提供了前所未有的控制力、一致性和创造力。

性能表现: 模型在多项基准测试(如 MovieGenBench、VBench I2V)中表现领先。

  • 文本转视频:在整体偏好、文本对齐和视觉质量上优于其他模型。
  • 图像转视频:在整体偏好、文本对齐和视觉质量上同样领先。
  • 文本转视频与音频:在音视频整体偏好和音视频同步对齐方面表现最佳。
  • 物理真实性:生成的视频具有视觉上真实的物理效果。

特色功能: “素材转视频”系列功能在人类评估中取得了领先结果,包括:

  • 整体偏好与视觉质量
  • 场景扩展(整体偏好、提示对齐、视觉质量)
  • 首尾帧过渡(整体偏好、提示对齐、视觉质量)
  • 对象插入(整体偏好、视觉质量)

实际应用

  • Promise Studios:利用 Veo 3.1 增强生成式故事板和预可视化,实现导演驱动的制作级叙事。
  • Volley:在其 AI 驱动的 RPG 游戏《Wit‘s End》中使用 Veo 3.1 来生成过场动画和动态叙事资产。
  • OpusClip:在其 Agent Opus 工具中利用 Veo 3.1 提升动态图形效果,为中小企业创建逼真的宣传视频。

相关创作工具

  • Google Flow:为创作者构建的 AI 电影制作工具。
  • Google Vids:用于工作的 AI 驱动视频创作工具。
  • Google AI Studio / Gemini API:用于快速原型开发和集成 AI 模型的平台。
4. MIT study explains why laws are written in an incomprehensible style (news.mit.edu)

文章摘要

核心发现:法律文本之所以晦涩难懂,并非仅仅因为其复杂性,而是因其独特风格传达权威感的作用,类似于魔法咒语的特殊语言模式。

关键研究内容

  1. 法律语言特征:法律文本大量使用“中心嵌套”结构(即在句子中间插入冗长的定义和限定),这显著增加了理解难度,即使是律师也觉得繁琐复杂。
  2. 主要假设
    • “复制编辑”假设:认为复杂结构源于在简单初稿上不断添加条件。
    • “魔法咒语”假设(研究支持的观点):认为这种刻意复杂的风格本身就是为了象征和传递权威,与日常语言区分开来。
  3. 实验验证
    • 研究人员让非法律专业人士撰写法律条文和叙述故事。
    • 结果显示,无论是否需要事后修改,参与者在写法律条文时都普遍使用了中心嵌套结构,但在写故事时则使用简洁语言。
    • 进一步实验中,参与者在撰写给外国人看的法律解释时也不使用此结构,表明这种复杂风格是法律文本的专门“信号”
  4. 研究意义与未来方向
    • 该研究揭示了法律语言晦涩的具体机制,为推动法律文件“通俗化”改革提供了依据。
    • 研究团队计划进一步追溯这种写作风格的历史起源(例如分析早期英国法律甚至《汉谟拉比法典》),以探究其是否是一种偶然形成的传统。
    • 尽管法律通俗化倡议已存在数十年,但收效甚微。研究人员希望基于最新发现,能更有效地推动改变。
5. How I used linear algebra to build an interactive diagramming editor (medium.com)
6. Blackmagic Debuts $30K 3D Camera for Capturing Video for Vision Pro (www.macrumors.com)

Blackmagic推出了专为苹果Vision Pro打造3D内容的URSA Cine Immersive摄像机,售价3万美元,现可预购,预计2025年第一季度末发货。该摄像机号称是全球首款商业级此类设备。

其核心是定制的立体3D镜头系统,配备双8K传感器,能够以高达每秒90帧的速度捕捉180度视野的视频,并支持空间音频。单眼分辨率达8,160 x 7,200像素,拥有16档动态范围,以确保每一帧的细节与色彩准确性。

机身搭载双5英寸HDR触摸屏和一个外部色彩状态LCD屏幕。连接选项丰富,包括12G-SDI输出、10G以太网、USB-C、XLR音频端口以及用于供电的8针Lemo连接器。

包装内含8TB的Blackmagic Media Module,可存储约两小时使用Blackmagic RAW格式录制的8K立体视频,并支持Cloud Store以实现媒体的快速上传与同步。

7. What did Ada Lovelace's program actually do? (2018) (twobithistory.org)

阿达·洛夫莱斯的程序究竟做了什么?

核心概述

阿达·洛夫莱斯(Ada Lovelace)于1843年发布的程序被广泛认为是世界上第一个计算机程序,但其历史地位存在争议。该程序为查尔斯·巴贝奇设计的、从未建成的“分析机”编写,旨在计算伯努利数。尽管程序从未实际运行,但其技术设计展现了超越时代的严谨性与创新性。

程序的目标:计算伯努利数

伯努利数是一个数学序列,由雅各布·伯努利在18世纪初提出,用于求解自然数幂次和的通用公式。例如,计算前n个正整数的k次幂之和需要利用前k个伯努利数。洛夫莱斯的程序具体计算了序列中的第八个伯努利数(B₇),通过组合已知的伯努利数和帕斯卡三角形系数来实现。

运行平台:巴贝奇的分析机

程序设计为在巴贝奇的“分析机”上运行,这是一台从未建成的机械通用计算机。分析机通过穿孔卡编程,具备存储、处理和输出能力,可执行加、减、乘、除运算。其前身“差分机”仅能执行加减法并用于制表,而分析机则更灵活,理论上可解决更复杂的问题。

程序的技术特点与创新

洛夫莱斯的程序包含25个操作步骤,并引入了以下关键编程概念:

  • 循环结构:程序将重复的操作分组,并指定循环执行条件,实现了早期的循环设计。
  • 状态跟踪:通过上标索引清晰标注变量在程序执行过程中的值变化,便于理解数据流。
  • 模块化设计:将复杂计算分解为可重复的步骤,展现了结构化编程思想。
  • 调试实践:程序中被发现存在一个除法顺序错误(v5/v4应为v4/v5),这被认为是“最早的程序错误”,也反证了程序的实践真实性。

历史意义与评价

尽管此前巴贝奇和梅纳布拉已编写过简单操作序列,但洛夫莱斯的程序在复杂性、结构性和创新性上远超前人。她不仅详细注释了程序,还在笔记中预见分析机可用于处理音乐、图形等非数值对象,展现了非凡的洞察力。尽管关于她是否应被称为“第一位程序员”仍有争论,但其程序作为第一个公开发布的、包含循环和复杂逻辑的计算方案,在计算机科学史上具有里程碑意义。

8. In Search of a Faster SQLite (avi.im)

《寻找更快的SQLite》文章摘要

技术背景与问题

  • SQLite现状:SQLite已很快,但研究人员探索进一步优化可能,特别是针对无服务器边缘计算场景。
  • 核心问题:在无服务器运行时中,数据库延迟是关键瓶颈。将数据置于边缘可消除网络延迟,但SQLite使用同步阻塞I/O,在多租户环境中会成为资源竞争和延迟增加的源头。

关键技术方案:异步I/O与存储解耦

1. io_uring机制

  • Linux内核提供的异步I/O接口,通过用户态与内核态共享的环形缓冲区减少数据拷贝开销。
  • 工作流程:应用提交I/O请求至提交队列,调用io_uring_enter()不阻塞线程,可并行执行其他任务,通过轮询完成队列获取结果。
  • 相比传统POSIX的阻塞式read()/write()调用,能显著提高并发效率。

2. SQLite原有执行模型

  • 查询执行包括sqlite3_open()(打开数据库文件)、sqlite3_prepare()(生成字节码)、sqlite3_step()(执行字节码)。
  • 当B树页不在缓存时,需通过同步I/O从磁盘读取,阻塞内核线程,迫使应用使用更多线程处理并发。

3. Limbo的解决方案

  • 用Rust重写SQLite,支持异步I/O:将同步字节码指令替换为异步版本(如NextAsync)。
  • 核心改进:I/O操作提交后立即返回控制权,允许应用并行处理其他任务,消除阻塞。
  • 存储解耦:进一步将查询引擎与存储引擎分离,支持分布式存储架构。

实验结果与评估

  • 模拟多租户环境:测试从1到100个租户,每个租户运行独立嵌入式数据库。
  • 关键结果:在P999尾延迟上,Limbo比SQLite降低100倍
  • 性能对比:SQLite的查询延迟随线程数增加而恶化,Limbo保持稳定;但P90/P99性能改善不明显(可能与单查询测试有关)。
  • 当前状态:工作仍进行中,未来将测试多读写场景。

项目意义与开放资源

  • 该研究为Limbo项目(SQLite的Rust重写版)奠定基础,已开源并纳入Turso官方项目。
  • 核心理念:通过异步I/O存储解耦,可在边缘/无服务器场景中实现高性能嵌入式SQL数据库。
9. ISO 8583: The language of credit cards (increase.com)

ISO 8583:信用卡通信的标准语言

ISO 8583是卡网络中收单行与发卡行之间进行实时消息通信的标准。无论是实体店刷卡还是在线点击“购买”,交易最终通常会转化为ISO 8583消息,在商户的收单处理方、卡网络和银行的发卡处理方之间传递。

历史与演变

该标准于1987年首次定义,确立了消息规范的整体结构及核心字段的名称与长度(如字段2的卡号、字段4的交易金额)。消息以4位消息类型指示符(MTI)开头,标识消息类型(如授权、冲正等),后跟位图(bitmap)表明哪些字段存在。早期标准允许各卡网络使用私有字段,导致网络规范迅速分化。后续版本增加了字段数量以减少网络特定行为,但为保持向后兼容性,主要网络规范仍基本遵循1987年的原始规则。字段的序列化方式(如EBCDIC、压缩BCD等)也因网络而异,进一步加剧了规范差异。

基本格式

ISO 8583消息需基于共享规范解析,不包含字段名,仅含数值。基本结构包括:

  • 消息类型指示符(MTI):4位代码,标识消息类型(如0100为授权请求)。序列化方式多样(如压缩BCD、ASCII等)。
  • 位图(Bitmap):指示哪些字段存在(1为存在,0为缺失)。首字节的第一位表明是否包含第二个8字节位图(用于超过64个字段的情况)。序列化格式因网络而异(十六进制、二进制、ASCII等)。
  • 数据元素(Data Elements):按位图顺序序列化各字段。字段分原始类型和复杂类型(含嵌套子字段)。原始字段的序列化涉及以下因素:
    • 编码:可选EBCDIC、ASCII、压缩BCD(用于整数)或二进制格式。
    • 长度:固定长度字段需填充(如金额字段常为12位右对齐、左补零);变长字段以长度前缀开头。
      • 变长指示符的编码方式可能因字段内容而异(如数字字段用压缩BCD编码长度)。
      • 长度通常指位数而非字节数,可能导致奇数长度整数的解析复杂性。

嵌套消息

原始标准的预定义字段有限,卡网络通过保留的“私用”字段序列化自定义数据,导致规范差异显著。嵌套消息主要有三种序列化方式:

  1. 表格(Tables)

    • 简单表格:所有子字段固定长度且始终存在,空间利用率低。
    • 可变表格:允许省略后续子字段(需变长指示符),或通过将可变长度子字段置于末尾来减少填充。
    • 半字节表格(Nibble tables):全数字字段用压缩BCD编码,每个子字段占半字节(4位)以节省空间。
  2. 嵌套位图消息(Nested Bitmap Messages):类似顶级消息,用位图指示子字段存在,无需序列化空值,节省空间且解析明确,但添加新字段被视为重大变更。

  3. 标签-长度-值消息(Tag-Length-Value, TLV):源自ISO 8825标准。每个字段为(标签、长度、值)元组,无序且灵活,能优雅处理新字段。标签和长度的编码可变,便于扩展。通常采用两层结构:顶层数据集(dataset)标签/长度固定,下层字段采用可变格式。

消息传输与解析

  • 成帧(Framing):ISO 8583消息通常通过持久TCP套接字传输,需在消息前加4字节长度指示符以界定消息边界。
  • 网络特定头部:如Visa在成帧头与消息体间加入元信息头部。

构建解析器

解析核心ISO 8583消息相对直接(实现位图解析和字段长度定义即可),复杂性主要来自各网络差异化的嵌套子消息处理。有效方法是声明式定义核心构建块来组合消息,而非命令式实现各种字段类型。文章以Ruby和Sorbet类型系统为例,展示如何通过T::Struct类声明字段属性(索引、编码、长度、转换等),实现类型安全的解析。错误处理需考虑不同层级的恢复策略:

  • 嵌套子字段内:记录部分错误并继续解析下一个字段(需确保序列化时能回写合理值)。
  • 整个子消息层:解析出错后保留已解析部分,丢弃后续内容。
  • 顶级消息层:无法恢复的错误(如字段长度指示符解析失败)则不应尝试使用部分结果。

总结

ISO 8583标准因历史原因及网络演化存在复杂性,其核心在于字段的存在标识、灵活的编码方式和多样的嵌套结构。解析器设计需兼顾灵活性、错误恢复及跨网络兼容性。

10. Go Protobuf: The New Opaque API (go.dev)

Go Protobuf: 新的 Opaque API 摘要

Go Protobuf 发布了针对生成代码(.pb.go 文件)的新 Opaque API。这是对现有 Open Struct API 的补充,不会移除任何现有功能,且 Go 语言对向后兼容的承诺同样适用于此。

核心区别

  • Open Struct API (现有):生成的结构体字段是公开的,可以直接读写。例如 logpb.LogEntryBackendServer *string 字段。
  • Opaque API (新):生成的结构体字段被隐藏(如 xxx_hidden_BackendServer),强制通过 getter、setter 和 cleaner 方法访问。

Opaque API 的主要优势

  1. 更高效的内存布局

    • 对于基本类型字段(整数、布尔、枚举、浮点)的 presence(是否设置),用位域代替指针,显著减少内存占用和分配次数。
    • 基准测试显示,对于基本字段较多的消息,解码时的分配次数可减少 46%-58%,解码时间也有相应提升。
  2. 支持延迟解码

    • 通过使字段私有化,可以安全地实现延迟解码:子消息的内容在首次访问时才解码,而非在 Unmarshal 时。
    • 这避免了对未访问字段的解码开销。微基准测试显示,延迟解码可减少超过 50% 的工作量和 87% 的内存分配。
  3. 减少编程错误

    • 避免指针比较错误:禁止直接比较字段地址,强制使用 getter 获取值。
    • 避免意外共享错误:setter 接受值而非指针,防止不同消息意外共享同一底层数据。
  4. 修复实现细节泄露问题

    • 防止开发者误用 Go 的 reflect 包(如用 encoding/json 编码 protobuf 消息),引导他们使用正确的 Protobuf 反射 API(如 protojson)。
  5. 为未来优化铺路

    • 解耦了生成的代码与内存表示,使得未来可以基于特定工作负载的性能剖析(类似 PGO)进行内存布局优化(例如将不常设置的字段移至溢出结构)。

迁移与采用

  • 现有 API 不会删除,但新 API 提供了性能优势。
  • 推荐新项目使用 Opaque API。未来的 Protobuf Edition 2024 将将其设为默认。
  • 提供了混合 API 作为过渡方案:生成的代码同时具有公开字段和新访问器方法,通过构建标签(protoopaque)选择使用 Opaque API 版本。
  • 对于发布生成代码的库(如 Google Cloud Client Libraries),强烈建议采用混合 API,这样下游消费者可以自行决定迁移时机。
  • 可使用 open2opaque 工具辅助代码迁移。

启用延迟解码

迁移到 Opaque API 后,需在 .proto 文件中为消息类型的字段添加 [lazy = true] 注解以启用延迟解码。

现状

Google 内部已通过自动化工具将绝大多数 .proto 文件和 Go 代码迁移到 Opaque API,并持续基于生产工作负载改进其性能。

11. Waymo will bring autonomous vehicles to Tokyo (waymo.com)

Waymo 将在东京推出自动驾驶车辆

主要公告
Waymo 与日本合作伙伴日本交通(Nihon Kotsu)和 GO 合作,将自动驾驶车辆带到东京,作为其首次国际路演。此举旨在让 Waymo 的自动驾驶系统(Driver)学习和适应左行交通以及东京作为全球人口密集城市的驾驶环境。

合作与目的

  • Waymo 将与当地合作伙伴、政府官员和社区团体紧密合作,了解东京的交通生态系统,以便更好地服务居民。
  • 目标是评估自动驾驶技术在新环境中的表现,并融入东京的城市交通系统。
  • 采用严格方法验证技术和性能的安全性。

技术与安全框架

  • 遵循 Waymo 的安全框架,该框架已在美国成功应用数百万英里。
  • 通过东京的试点项目,加速开发 Waymo Driver,评估 AI 驾驶员在新环境中的通用性,包括通过模拟技术。

与日本交通愿景的契合

  • 日本国家和东京都政府一直推动采用创新技术来增强交通安性和流动性。
  • Waymo 正与日本政策制定者、监管者和安全官员合作,确保负责任的技术实施。

实施细节

  • 首批全电动 Jaguar I-PACEs 将于 2025 年初到达东京。
  • 合作伙伴 Nihon Kotsu(东京最大的出租车公司)将负责车辆的管理和服务。
  • 最初阶段:Nihon Kotsu 司机将手动操作车辆,绘制东京关键区域地图,包括港区、新宿区、涩谷区、千代田区、中央区、品川区和江东区。
  • 通过这一阶段,Waymo 将收集经验,改进自动驾驶系统。

未来展望
Waymo 期待与东京居民分享更多进展,并逐步推进自动驾驶技术在东京的应用。

13. Developing Developers (2015) (felleisen.org)

东北大学计算机科学学院(2015年)提出了一种独特的编程教学核心课程体系,其核心理念是“显式与系统化的程序设计”,并强调编程是一种“人际交流的学科”。该体系旨在为学生(无论未来是否从事编程工作)打下坚实的系统化问题解决基础,并培养其团队协作与沟通能力。

1. 核心教学理念:显式设计

  • 与传统方法对比:传统教学依赖模仿和“修到能用”的试错法,往往导致学生仅学会复制和修改代码片段。该课程则推行一套明确、系统的程序设计流程。
  • 结构化设计方法:课程以《How to Design Programs》为教材,教授一套六步设计流程:理解问题与数据、撰写目的声明、设计功能示例、编写程序大纲、填充代码、将示例转化为测试。该流程与数据类型(从原子数据到复杂结构)的复杂性维度相结合。
  • 设计过程的普适性:这种系统化方法不仅适用于编程,也可类比应用于新闻、商业、工程、法律、科学乃至外科手术等领域的问题解决。
  • 语言与工具选择:主张使用“安全”(类型安全)的编程语言,因为不安全的语言(如C/C++)会引入额外的依赖和复杂性,增加调试负担。

2. 人际能力培养:编程是人的学科

  • 编程的本质是向他人传达思想。编译器等工具仅提供浅层反馈,真正的洞察力来源于与人交流。
  • 从第一门课开始,学生就以结对编程形式完成所有作业。角色在“驾驶员”(负责键盘和设计)与“领航员”(依据设计流程提问和检查)间定期轮换。
  • 后续课程进一步要求学生向小组或全班展示设计方案,并学习评估他人展示,锻炼演讲与倾听能力。

3. 核心课程结构(课程依赖关系见原文图7)

  • Fundamentals I(基础 I):面向新手。使用一系列精心设计的教学语言(统称SL)和专为此优化的*教学IDE(DrRacket)。语言从基于高中代数的简单语法开始,逐步引入列表、高阶函数等概念。教学目标是通过显式设计流程消除学生对问题的恐惧。结对编程是核心实践。
  • Fundamentals II(基础 II):过渡到工业语言(如Java)。目标是在真实语言环境中应用设计原则,引入类型检查面向对象编程,以及如何组合现有库和框架进行设计。学生继续结对编程,并首次进行简单的代码审查。
  • Logic in Computer Science(计算机科学中的逻辑):探讨程序验证。教学逻辑(命题与一阶逻辑)和结构归纳法,这与Fundamentals I的设计流程天然契合。课程使用证明辅助工具ACL2,该工具能自动验证通过显式设计编写的程序,从而强化设计规范。
  • OOD(面向对象设计):在Java基础上扩大项目规模。重点从编写完整小程序转向设计可组合的程序组件,学习定义和使用接口、协议及逻辑断言。学生需向全班展示设计方案。
  • Software Development(软件开发):作为顶点课程。学生选择语言,参与一个复杂项目(如超过5000行代码)。核心任务是维护他人代码,这迫使学生理解设计文档和逻辑断言的重要性。课程引入更正式的代码审查流程(如IBM“白室”模式),并进一步强化团队演讲与评审能力。

4. 体系的优势与推广

  • 这套课程体系经过长期实践检验,毕业生在就业市场上受到认可。
  • 文章指出当前体系仍缺乏对以下方面的培养:自主探索、性能调试(连接算法与工程)、不安全语言编程以及更深入的软件工程专题(如测试、团队编程、软件建模)。
  • 文末提到了其他高校(如布朗大学、滑铁卢大学、英属哥伦比亚大学、智利大学等)对该教学理念的适应与本地化实施情况,证明其影响力。
14. Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps (github.com)

Langfuse:开源LLM工程平台

概述

Langfuse 是一个开源的LLM工程平台,旨在帮助团队协作开发、监控、评估和调试AI应用程序。它可以在几分钟内完成自托管部署,并经过实战检验。

核心功能

  1. LLM应用可观测性:通过插桩应用并摄入跟踪数据到Langfuse,追踪LLM调用及其他相关逻辑(如检索、嵌入、智能体操作)。支持检查和调试复杂日志及用户会话。
  2. 提示词管理:集中管理、版本控制和协作迭代提示词。利用强大的服务器和客户端缓存,可在不增加应用延迟的情况下迭代提示词。
  3. 评估:支持多种评估方式,包括LLM-as-a-judge、代码评估器、用户反馈收集、手动标注以及通过API/SDK的自定义评估流程。
  4. 数据集:用于评估LLM应用的测试集和基准测试。支持持续改进、部署前测试、结构化实验、灵活评估,并与LangChain、LlamaIndex等框架无缝集成。
  5. LLM游乐场:用于测试和迭代提示词及模型配置的工具,缩短反馈循环并加速开发。当在跟踪中看到不良结果时,可直接跳转到游乐场进行迭代。
  6. 全面API:通过API提供构建块,常用于支持定制的LLMOps工作流。提供OpenAPI规范、Postman集合以及Python、JS/TS的类型化SDK。

部署方式

  • Langfuse云:由Langfuse团队管理,提供慷慨的免费套餐,无需信用卡。
  • 自托管:可在自有基础设施上运行。
    • 本地部署(Docker Compose):使用Docker Compose在5分钟内于本地机器上运行。
    • 虚拟机(VM):使用Docker Compose在单个虚拟机上运行。
    • Kubernetes(Helm):使用Helm在Kubernetes集群上运行,是推荐的生产部署方式。
    • Terraform模板:提供AWS、Azure、GCP模板。

集成生态

主要集成

  • SDK:Python、JS/TS,提供手动插桩的灵活性。
  • OpenAI:Python、JS/TS,通过替换OpenAI SDK实现自动插桩。
  • Langchain:Python、JS/TS,通过传递回调处理器实现自动插桩。
  • LlamaIndex:Python,通过LlamaIndex回调系统实现自动插桩。
  • 其他:支持Haystack、LiteLLM、Vercel AI SDK、Mastra等框架,以及直接调用公共API。

已集成的包

  • :如Instructor、DSPy、Mirascope。
  • 模型(本地):Ollama。
  • 模型(云):Amazon Bedrock。
  • 智能体框架:AutoGen、CrewAI、Inferable、Goose、smolagents。
  • 聊天/智能体UI:Flowise、Langflow、Dify、OpenWebUI、LobeChat、Gradio。
  • 工具:Promptfoo(开源LLM测试平台)。
  • 平台:Vapi(开源语音AI平台)。

快速入门

  1. 创建新项目:创建Langfuse账户或自托管,新建项目,并在项目设置中创建新的API凭证。
  2. 记录首次LLM调用
    • 安装langfuseopenai库。
    • 设置环境变量(密钥和基础URL)。
    • 使用@observe()装饰器并结合Langfuse的OpenAI集成(或其他框架集成)来自动捕获模型参数和调用详情。
    • 示例代码展示了如何跟踪一个OpenAI聊天完成请求。
  3. 在Langfuse中查看跟踪:可在Langfuse界面中查看语言模型调用和其他应用逻辑的跟踪数据。

支持与贡献

  • 支持:文档是首要资源,设有FAQ和“Ask AI”功能。通过GitHub Discussions提问、请求功能,通过GitHub Issues报告错误。紧急问题可通过应用内聊天窗口联系。
  • 贡献:欢迎在GitHub Discussions上对想法投票、在Issues中提出和评论、以及提交PR。

许可与安全

  • 许可:除ee文件夹外,仓库采用MIT许可证。
  • 安全与隐私:重视数据安全与隐私,详见专门的安全与隐私页面。
  • 遥测:默认情况下,自托管实例会向中心服务器报告基本使用统计,以帮助改进功能和跟踪使用情况。遥测不包含原始跟踪、提示词等内容。对于OSS版本,可通过设置TELEMETRY_ENABLED=false选择退出。

生态系统

文章列出了一些使用Langfuse的顶级开源Python项目及其星标数,展示了其在社区中的广泛应用和集成,例如langflowopen-webuillama_indexlitellm等知名项目。

15. Documented and annotated source code for Elite on the Commodore 64 (github.com)

《Elite》Commodore 64 版本文档化及注释源代码

概述

本仓库包含由 Ian Bell 和 David Braben 创作的经典游戏《Elite》在 Commodore 64 平台上的原始源代码。每一行代码都经过文档化和(绝大部分)解释。源代码是原始版本,仅添加了大量注释。它是配套网站 elite.bbcelite.com 的资源库,网站以更易读的版式呈现了仓库中的所有代码。用户可以从源代码构建出可运行的游戏。

仓库内容与结构

  • 核心内容:完全注释的原始 Commodore 64 Elite 源代码。
  • 目录结构
    • 1-source-files:所有源文件(汇编源码、图像二进制、字体、引导文件等)。
    • 2-build-files:构建相关脚本(校验、加密、CRC32验证脚本)。
    • 3-assembled-output:汇编过程的输出文件。
    • 4-reference-binaries:每个变体的正确参考二进制文件,用于验证。
    • 5-compiled-game-disks:最终输出的 d64 磁盘镜像,可在模拟器或真实硬件上运行。
  • 主要源文件
    • elite-source.asmelite-data.asm:游戏主代码和数据。
    • elite-loader.asm:加载器代码,主要涉及设置和版权保护。

无闪烁版本

仓库包含一个 flicker-free 分支,该分支整合了来自 BBC Master 版本的改进的无闪烁飞船绘制例程以及行星无闪烁修复。修改代码已集成到原始源文件中,被移除的原始代码以注释形式保留。所有修改可通过搜索 Mod: 标签找到。

构建指南

要求

  • BeebAsm:汇编器(需下载,Mac/Linux用户需自行构建)。
  • Python:用于脚本(主要测试版本为 3.x)。
  • c1541:来自 VICE 模拟器的工具,用于创建磁盘镜像。
  • make:构建工具(Windows 版已包含在仓库中)。

构建过程

使用仓库中的 Makefile(Mac/Linux)或 make.bat(Windows)。

  1. 配置:编辑构建脚本,设置 BEEBASMPYTHONC1541 变量指向本地可执行文件路径。
  2. 运行:在终端/命令提示符中进入仓库文件夹,执行 make(Mac/Linux)或 make.bat(Windows)。
  3. 输出:默认生成 elite-commodore-64-gma85-ntsc.d64 文件。

构建选项

可通过参数修改构建行为:

  • variant=<name>:指定构建变体(默认为 gma85-ntsc)。
  • commander=max:使用接近满级的指挥官存档开始。
  • encrypt=no:禁用加密和校验例程(便于修改)。
  • match=no:不尝试匹配原始二进制文件(省略工作区“噪音”)。
  • verify=no:禁用 CRC32 验证。

验证

默认构建过程会输出所有生成文件的校验和,并与原始参考文件进行比较,以确认构建正确性。可通过 verify=no 禁用。

支持的变体

仓库支持构建四个不同变体:

  1. Firebird GMA85 NTSC:1986 年第二个官方发行版。
  2. Firebird GMA86 PAL:与 GMA85 版本基本相同,仅针对 PAL 系统进行小修改。
  3. 源磁盘构建变体:运行原始源磁盘上的构建过程产生的文件。
  4. 源磁盘文件变体:直接使用原始源磁盘上的二进制文件。
  • 变体差异:主要通过条件编译标签(如 _GMA85_NTSC_SOURCE_DISK)在源码中查找。差异包括加载器、数据地址、音乐、操纵杆读取方式等。详情请见配套网站。

版权与许可

  • 本仓库未提供许可证文件,适用默认版权法。
  • 原始代码版权归 D. Braben 和 I. Bell (1985) 所有。
  • 注释内容版权归 Mark Moxon 所有。
  • 根据 GitHub 规则,用户仅可阅读和 fork 本仓库,不得进行其他使用。项目基于教育和非营利目的提供,但保留被版权持有者要求下架的可能。

在 IDE 中浏览

  • 最重要的文件位于 main-sources 文件夹。
  • 可搜索特定标签(如 Type: SubroutineName: SCAN)来查找例程和变量。
  • 游戏主代码入口点为 BEGIN 例程。
  • 建议使用 80 列宽度和等宽字体查看源码。
  • 配套网站包含“深度探索”文章,对游戏机制有详细解释。

关于原始源文件与字节精确构建

原始 BBC Micro 源代码通过递增程序计数器创建工作区,导致工作区包含内存中随机的“噪音”。为了生成字节精确的二进制文件以匹配原始发行版,构建过程需要包含此“工作区噪音”(通过 match=no 可禁用,将工作区初始化为零)。仓库中的示例展示了如何将这些噪音数据嵌入源文件。

16. Running NetBSD on IBM ThinkPad 380Z (luke8086.dev)

这篇文章详细描述了作者在1998年的IBM ThinkPad 380Z笔记本电脑上安装并使用NetBSD操作系统的完整过程和体验。以下是主要内容:

硬件准备与兼容性

  • 硬件升级:为提升性能,将原装硬盘更换为通过mSATA转PATA适配器连接的16GB mSATA SSD。需注意BIOS对磁盘大小的8GB限制会影响引导程序,因此采用了较小的根分区。
  • 网络连接:笔记本无内置网卡,作者通过CardBus插槽的Edimax WiFi卡(RT2561S芯片组)和USB口的RTL8153网卡成功联网。
  • 安装引导:由于不支持USB引导且光驱故障,作者利用380Z支持CardBus磁盘引导的特性,将NetBSD安装镜像写入CF卡,并通过CF转CardBus适配器成功启动安装程序。

NetBSD系统安装与配置

  • 安装过程:NetBSD的文本模式安装程序引导流畅。作者选择了自定义安装,排除了源码和调试文件,系统占用约1.6GB。
  • 内核与驱动
    • 成功启用了VESA控制台帧缓冲支持,以获得更好的文本显示效果。
    • 所有硬件(包括NeoMagic显卡和Crystal CS4237B声卡)均被自动识别并正常工作,无需额外调试。声卡驱动冲突通过禁用其中一个驱动解决。
  • 性能优化
    • 节省内存:通过禁用inetdpostfixcron等非必要服务,并减少虚拟控制台数量,大幅降低了系统内存占用。
    • X窗口系统:系统自带轻量的CTWM窗口管理器。作者替换为同样轻量的EMWM,并使用XTerm作为终端模拟器。
  • 软件安装与配置
    • 网络服务:NetBSD原生支持WireGuard VPN,配置简单,可通过rc.local实现持久化。
    • 本地化:需手动在/etc/profile或用户配置文件中设置LANG等环境变量。
    • Shell:从软件包安装了功能更完善的bash以替代默认的ksh。
    • 网页浏览:使用轻量级的Dillo浏览器,适合浏览静态文档和基础网页。
    • 音乐播放:使用mpg123播放在线低音质电台流,CPU占用约10-20%。

最终用途与评价

  • 适用场景:这台经过改造的380Z笔记本,凭借其经典键盘和4:3屏幕,非常适合进行无干扰的终端工作,例如SSH远程操作、UNIX学习、C/汇编编程、笔记写作等。
  • 系统评价:作者高度评价NetBSD,认为它是一个轻量、精巧且工程优秀的操作系统。它在老旧硬件上运行顺畅,提供完整的软件仓库,且系统行为可控,不会预装大量冗余服务。虽然不适合日常主流使用,但它是在备用或资源受限机器上运行的理想UNIX系统
17. Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches (verdagon.dev)

《内存安全魔典,第一部分》摘要

本文是作者Evan Ovadia关于内存安全技术的系列文章引言,通过一个虚构的考古探险故事作为引入,系统性地梳理了他所总结的14种(实际列出了17种)内存安全技术方法。其核心观点是,内存安全并非仅有垃圾回收(GC)、引用计数(RC)和借用检查这几种主流方案,而是一个广阔且尚未被充分探索的领域,各种技术之间可以相互混合,创造出新的范式。

背景与目的

作者自称收藏了一本“内存安全魔典”,其中记载了多种内存安全技术。本文旨在公开这份清单,展示内存安全领域的多样性,并启发开发者探索新的混合技术,以设计出更优的编程语言。

传统技术的局限与混合可能性

文章首先简述了三种传统技术的特点与不足:

  1. 垃圾回收(GC):简单灵活、吞吐量高,但内存能耗大、有非确定性暂停。
  2. 引用计数(RC):简单、内存占用少,但速度慢且可能因循环引用导致泄漏。
  3. 借用检查:速度快、可安全地使用内联数据,但可能导致代码复杂性,且难以支持观察者模式、侵入式数据结构等模式。

作者认为,玛雅古人(故事中的隐喻)可能掌握了更底层混合这些技术的方法,以取长补短。

17种内存安全技术清单

文章核心部分逐一简要介绍了以下技术,多数技术都在寻求混合或改进:

  1. 仅移动编程:对象一次只能有一个所有者,所有权可转移。它是仿射类型和线性类型的基础,Rust在此之上增加了借用检查。
  2. 引用计数:可与GC共存(如Python),并能与不可变区域借用结合以减少缓存未命中和数据竞争。
  3. 借用检查:确保临时、受限地使用指针。Austral语言通过结合线性类型使其不仅安全,而且正确(保证某些未来动作会发生)。
  4. 纯竞技场编程:仅使用竞技场分配内存,不单独调用malloc/free。通过跟踪指针所属竞技场可防止释放后使用错误。
  5. Ada/SPARK的作用域限制:禁止指针指向比自身作用域更深的对象,类似限制性借用检查。
  6. 区域:强大且灵活,可定义对象间的隔离子图或临时打开的不可变视图,能极大优化引用计数和生成式引用的性能。
  7. 栈竞技场:自动为每个栈帧分配竞技场,但目前效率不高,可与其他技术结合提速。
  8. 生成式引用:通过比较指针中的“记忆代数”与目标对象中的“当前代数”来防止释放后使用。结合区域和纯函数可消除比较开销。
  9. 随机生成式引用:生成式引用的快速变体,支持内联数据,性能潜力更高,兼具C++的架构简洁性和Rust的内存安全性。
  10. MMM++:对象从全局数组分配,槽位按类型复用,避免传统释放后使用问题,常见于嵌入式和实时系统。
  11. 追踪式垃圾回收:可通过分离执行单元(如Pony的Actor)避免全局停顿,结合区域和约束可进一步控制。
  12. 交互网络:一种高效管理纯不可变数据的方式,无需GC或RC,如HVM运行时所示,本质上是自动借用和克隆的混合。
  13. 约束引用:混合了引用计数和单一所有权。对象有单一所有者和引用计数,销毁时需断言无其他引用。支持比借用检查更多的模式(如侵入式结构、图、观察者等),但检查发生在运行时。
  14. 线性引用计数:一个设想中的概念,旨在编译时消除计数整数,通过线性类型在编译期完成引用计数。
  15. 非MVS:类似只有唯一引用(&mut)而无共享引用(&)的Rust,简单快速,但可能需要更多克隆。
  16. CHERI:硬件-软件混合方案,指针包含地址范围和权限,实现空间安全。结合特定分配器(如Cornucopia)可增加时间安全。
  17. 永不释放:通过永不调用free来避免释放后使用。适用于生命周期短暂或可接受内存增长的程序(如导弹制导软件)。

其他构建模块与思考

文章末尾列举了更多可用于设计内存安全模型的技巧或概念,如类型稳定性(真正的问题是类型混淆后的访问)、唯一引用变更检测器线程隔离胖指针页眉高位忽略等。

结论与展望

作者总结道,内存安全是一个广阔的开放世界。每种范式(如RC、GC、借用检查、线性类型)都有其独特优势,且存在大量可能的混合方式。他鼓励开发者不要陷入“一切问题都已解决”的思维定式,应积极探索新的技术和混合方案,这可能会催生出如Vale语言中的完美可重放性等意外特性,并最终在服务器等领域产生更广泛使用的范式。

(注:文中将玛雅探险作为技术隐喻,部分技术名称如“MMM++”等为作者自拟或待规范化。)

18. Our muscles will atrophy as we climb the Kardashev Scale (solmaz.io)

随着人类在卡尔达肖夫等级上攀升,我们的肌肉将萎缩

核心观点

文章提出一个悖论性趋势:人类文明的总能量产出不断增长(在卡尔达肖夫等级上提升),但作为个体的平均力量却持续下降。这是因为技术发展取代了人类的体力劳动,导致个体无需也无法维持高强度身体能力。

生物力学阶段(BMS)模型

作者将此趋势划分为三个阶段,定义了人类体力与技术发展的关系:

生物力学阶段 技术水平 人类体力劳动需求 生物力学力量状况
BMS-I(前工业) 石器时代至原始机械 几乎所有任务依靠肌肉:农耕、狩猎、建筑 :力量普遍且必需
BMS-II(工业-现代) 蒸汽机至机动车辆 大部分重体力工作由机器完成;锻炼变得可选而非必需 中到低:随着任务机械化,平均力量下降
BMS-III(后生物) 脑芯片、量子遥感、数字化存在 体力劳动可忽略;远程操作取代身体活动 几乎为零:肌肉退化或无关紧要,拥有身体成为极端奢侈

阶段详情

BMS-I:前工业时期人类力量

  • 起始:石器时代,结束于工业革命。
  • 特征:人类完全依赖身体进行狩猎、采集、搬运和建造。金属工具和原始机械(如水车、风车)虽提高效率,但日常工作仍高强度体力劳动。
  • 结果平均人类能产生并维持较高的功率,因为体力活动是生存的必需。

BMS-II:工业-现代人类力量(当前阶段)

  • 起始:蒸汽时代。
  • 特征:工厂、内燃机、机动车辆和自动化减少了体力劳动需求。人类转向服务业或知识型工作。
  • 转折点:锻炼从日常必需转变为个人健康选择或爱好
  • 当前趋势:机器人和AI进一步接管体力任务,进一步降低平均人类基础身体能力。

BMS-III:后生物人类力量(未来场景)

  • 起始:类似《刀剑神域》的神经接口远程控制机器人阶段。
  • 发展:量子纠缠和零延迟控制消除了距离限制,人类可能终生生活在虚拟世界或远程操控机器中。
  • 终极形态:“罐中之脑”——身体成为可选项,神经系统被人工维持,肌肉组织萎缩至不存在。
  • 结果人类生物力学力量的概念不再适用,人类的定义变得抽象。

BMS与卡尔达肖夫等级的对应关系

作者认为两者不会完美对齐,而是交错发展:

卡尔达肖夫等级 对应的生物力学阶段 描述
I型(行星级) BMS-I(前工业) 人均高功率输出,因体力劳动必需;多为猎人-采集者或农民
BMS-II(工业-现代) 平均持续功率下降,但仍受限于单一星球;身体成为可训练的选择
II型(星际级) BMS-III(后生物) 平均肌肉能力崩溃至可忽略;人类定义抽象化
III型(银河级) (未知) 在银河尺度上消耗能量的社会有机体会是什么形态?他们还会像我们吗?

个人反思与担忧

  • 作者动机:源于一种悲伤——技术在提升生活质量的同时,也削弱了人类与生俱来的移动能力。我们进化了数十万年以过上动态生活,却因文明过于成功而可能“无法承担运动的代价”。
  • 过渡期问题:人类生活方式正快速偏离自然状态,进化速度无法跟上。当进化最终追上时,未来有机体将如何生存?他们还能在户外生存吗?
  • 技术的双刃剑:技术可通过分子层面修改细胞来适应身体,但若无需运动就能为经济做贡献,谁又会投资于此昂贵改造?
  • 进化压力的希望:作者希望性竞争和繁殖需求能维持足够的进化压力,保持人类身体的适能。这假设个体仍能控制自己的繁殖并自由选择伴侣——因为“罐中之脑”显然已不再是完整的个体。

结语

文章以Netflix《黑镜》剧集《Beyond the Sea》为例,指出先进的遥感和脑机接口技术可能是星际旅行的唯一途径。人类可能在达到II型文明时就已进入BMS-III阶段。而一个在银河尺度上存在的文明,其身体意义已无法想象。

19. Droste’s Lair (vezwork.github.io)

Droste's Lair 概述

Droste's Lair 是一个在两周冲刺期内构建的、不寻常的编程环境,用于构建和计数数学结构。它同时被描述为一个(类)剑与魔法风格的点击冒险游戏。其核心是一个视觉化、交互式的系统,用户通过直接操作(如在棋盘上放置多米诺骨牌、在列表间拖拽元素)来与数学结构互动。系统的能力建立在两种关键抽象之上:一种允许执行路径分叉的“歧义”(amb)机制,以及支持递归的过程调用机制。

核心功能演示(通过三个旅程)

  1. 命运的逆转(列表反转):演示了基本操作和递归。用户手动移动列表元素以反转顺序,随后系统通过一个名为 ♌︎ 的符号(代表脚本/过程)引入递归咒语。该咒语创建了嵌套的“洞”(递归调用),将任务逐层分解(移动一个元素,然后对剩余列表递归),直至达到基本情况(列表为空),并通过“退出路线”机制将结果返回,从而自动化完成整个反转过程。

  2. 永恒的分支(生成组合):演示了“分支”或“非确定性”计算。任务是生成所有扑克牌花牌。用户通过将“移动项目1”的动作改为“移动任意项目”,使一个步骤同时产生多个输出(即选择所有可能的秩和花色)。这创建了并行的可能性栈,从而一次性枚举出所有12种组合。

  3. 枚举(多米诺骨牌覆盖问题):演示了递归与分支的结合。目标是解决“如何用多米诺骨牌完全覆盖2xN棋盘”的计数问题。用户从一个具体例子(2x4)开始,通过直接放置多米诺骨牌(垂直或水平)进行探索。为了处理一般情况,用户将“放置”操作转化为递归过程,并在过程中引入分支(选择放垂直骨牌或放两个水平骨牌)。递归调用被可视化为深层嵌套的“洞”,系统自动探索所有可能性分支,最终枚举出所有有效的覆盖方式。

设计哲学与灵感

该项目受到此前项目如 Subsequently 的启发,强调“无远程操作”的物理感和基于状态的命令式交互。作者将其编程模型概括为:Subsequently 风格的命令式流程图 + 分支路径 + 递归

  • 分支:通过两种方式实现:1) 从一个面板调用多个动作;2) 调用一个具有多个输出(如“移动任意项目”)的动作。
  • 递归:过程调用被可视化为地板上的物理“洞”,调用者可以选择对整个面板或面板中的子部分(如棋盘子网格)进行操作。为保持“对象永久性”的物理感觉,即使在调用内部,也会显示整体上下文,并用颜色高亮聚焦部分。
  • 条件控制:摒弃了传统的 if-then 条件语句,采用了一种后置的“错误处理”方式。用户可以为任何面板附加一个“退出”面板,当该面板的所有可能动作都导致错误时触发。
  • 美学与“汁液”:项目有意融入了游戏开发中的“汁液”概念,采用了冒险游戏的视觉风格和叙事元素(如地牢、羊皮纸、咒语),旨在使抽象的计算过程更具触感和沉浸感,甚至可能帮助理解递归等概念。

讨论与未来方向

作者承认系统在可学习性和可扩展性上存在挑战。未来的工作方向包括:

  • 更多/混合微世界:探索列表和多米诺骨牌之外的其他状态与动作领域,甚至混合不同领域。
  • 可扩展性:应对更大流程图和数据集的可视化挑战。
  • 可学习性:研究如何引导用户探索,例如借用游戏叙事技术或设计从具体操作到抽象概念的平缓学习坡道。
  • 动作表示:探讨在动作前、动作后、带注释等多种视图之间切换的可能性。
  • 项目用途:思考其作为教育工具、数学实验室、完整游戏或数据集成编程环境的潜力。

项目灵感来源于 Subsequently、Ink & Switch 社区等,并得到了多位人士的反馈与启发。

20. Huge math error corrected in black plastic study; authors say it doesn't matter (arstechnica.com)

黑色塑料制品研究更正重大计算错误,但作者认为结论不受影响

研究背景

  • 该研究由环保组织“无毒未来”(Toxic-Free Future)主导,首席研究员为该组织的Megan Liu。
  • 研究聚焦于塑料电子产品中使用的阻燃剂(特别是溴化阻燃剂)可能通过回收过程,意外进入家用物品,带来健康风险。
  • 核心关注物质为 BDE-209(十溴二苯醚),这是一种常用于电视和电脑外壳的阻燃剂。因其具有致癌性、内分泌干扰、神经毒性和生殖危害,欧盟和部分美国州已分别在2006和2007年禁止使用,中国于2023年开始限制。

主要研究发现

  1. 污染并不普遍

    • 研究对203件黑色塑料家居用品(包括厨房用具、玩具、发饰和餐饮器具)进行了检测。
    • 20件(约10%)的产品检出溴化物含量可能表明受到溴化阻燃剂污染(溴含量>50 ppm)。
    • 其中,仅有14件产品明确检出含有BDE-209。
    • 结论是:“只有少数黑色塑料产品存在溴化物含量超过50 ppm的污染。”
  2. 检出水平远低于安全限值

    • 作者指出,即使在这些受污染的产品中,检出的阻燃剂水平也比公认的安全限值低一个数量级
  3. 具体案例

    • 溴化物含量最高的产品是一个一次性寿司托盘(18,600 ppm)。由于加热会促进化学物质析出,该托盘的暴露风险尚不明确。
    • 在28件被检餐饮用具中,仅该寿司托盘和一个溴化物含量为51 ppm(刚达污染阈值)的快餐托盘检出了溴化物。

作者立场与结论

  • 尽管研究存在计算错误,但作者认为这不影响核心结论:污染是存在的,但范围有限,且检出的风险水平较低。
  • 研究的主要意义在于揭示了塑料废物流中的潜在危害,即有毒阻燃剂可能通过回收链进入日常家居环境。
  • 研究领导Megan Liu强调:“公司不应在塑料电子产品中使用有毒阻燃剂……这些致癌化学物质从一开始就不应被使用。通过回收,它们正以更多方式进入我们的环境和家庭。”

关键信息

  • 关注物质:BDE-209等溴化阻燃剂。
  • 风险来源:电子产品塑料的回收再利用。
  • 核心发现:污染率低(10%),且检出浓度低于安全标准。
  • 未解疑问:高含量一次性用品(如寿司托盘)在加热使用时的具体健康风险。
21. After 3 Years, I Failed. Here's All My Startup's Code (dylanhuang.com)

创业公司Konfig失败后开源代码库概述

背景与创业历程

Dylan Huang于2022年离开全职工作,创办了开发者工具创业公司Konfig,目标是简化API集成。公司使命是通过SDK生成、文档和测试工具,改善开发者与API的交互方式。经过三年努力,尽管获得部分初创公司的采用,但未能实现高增长业务。

失败原因

  • 市场挑战:潜在客户签约困难,价格点过低,尽管产品展示了投资回报率。
  • 转型尝试:后期转向垂直B2B SaaS AI产品,利用生成式AI解决新问题,但经过用户访谈和销售循环后,未能找到足够的市场牵引力,无法构建大规模业务。

开源代码库发布

由于创业失败,作者决定开源整个代码库,包括:

  • 核心产品:SDK生成器、API文档工具等。
  • 失败转型:AI产品实验相关代码。
  • 杂项内容:脚本、部署配置、营销网站、产品文档等。 代码库已发布在GitHub上,原样公开,未经清理或修改,以供他人参考或使用。

主要产品与功能

在三年间,公司构建了四个主要产品:

  1. SDK生成器:基于OpenAPI规范生成多语言客户端库。
  2. Markdown和OpenAPI文档:用于API文档生成。
  3. API Demos:基于Markdown的Jupyter Notebook形式交互式API测试环境。
  4. 公共API的SDKs:为公共API提供客户端库。

其他杂项内容

代码库还包括:

  • Shell脚本(用于生成冷外发消息)。
  • 程序化SEO脚本。
  • 客户部署引用和售前资料。
  • 营销网站和产品文档。
  • 修改后的Changeset Bot(支持自定义单体仓库设置)。
  • 使用Earthly的SDK生成器集成测试。
  • Python代码格式化服务。
  • AI转型实验。
  • Render.com部署配置(render.yaml)。
  • 使用LLMs/HTMX/Django的API文档生成工具。
  • 自定义Notion数据库集成。
  • Python脚本(用于裁剪博客文章图像)。

作者反思与感谢

  • 感谢对象:感谢投资者、客户和队友Eddie与Anh-Tuan的支持与贡献。
  • 个人反思:对失败无悔,认为失败比成功教会了更多,是一次 transformative 的经历。
  • 未来计划:探索新机会,继续学习和成长,可能未来再次创业。

该代码库展示了创业公司从产品开发到失败的全过程,为其他开发者提供了实际参考。

22. Natural Number Game: build the basic theory of the natural numbers from scratch (adam.math.hhu.de)

文章标题:自然数游戏:从零开始构建自然数的基础理论

该文章描述了一个名为“自然数游戏”(Natural Number Game)的在线交互式学习平台,其核心目标是引导用户从零开始,逐步构建自然数的基础数学理论。平台基于 Lean 定理证明器,通过游戏化的方式让用户学习并实践形式化证明。

主要内容与功能:

  1. 目的与概念:游戏旨在提供一个从基础公理(如皮亚诺公理)出发,系统性地学习和构建自然数理论(如加法、乘法、不等式性质等)的环境。用户通过解决一系列递进的关卡(证明练习),最终掌握核心的数学定理和证明技巧。

  2. 技术实现

    • 该网页是一个基于 React 框架构建的单页应用(SPA)。
    • 用户必须启用浏览器 JavaScript 功能才能使用其全部交互功能,因为核心逻辑由 JavaScript 模块 (index-C9aGiXP_.js) 驱动。
    • 页面样式通过外部的 CSS 文件 (index-DKRt-Co4.css) 控制。
  3. 页面结构

    • 网页的主体是一个 ID 为 root<div> 元素,React 应用将挂载于此并动态渲染游戏界面。
    • 包含一个 <noscript> 部分,当用户禁用 JavaScript 时会显示。这部分提供了平台的联系信息(负责人:Marcus Zibrowius,来自杜塞尔多夫大学数学研究所)和数据隐私声明(指出若无 JavaScript,则网站无法使用,因此不会收集或存储个人数据,且服务器位于德国)。

总结:“自然数游戏”是一个教育性质的在线平台,通过互动式定理证明游戏教授数学基础。它是一个技术实现依赖于现代前端框架(React)的网页应用,并在其无法正常运行时提供了备用的静态信息和声明。

23. SeleniumBase: Python APIs for web automation and bypassing bot-detection (github.com)

SeleniumBase 是一个基于 Python 的多用途 Web 自动化框架,主要用于测试、数据抓取、反机器人检测绕过和 CAPTCHA 处理。

核心功能模式

  • CDP 模式:通过 Chrome DevTools Protocol 与基于 Chromium 的浏览器交互,能有效绕过机器人检测。
  • Stealthy Playwright 模式:将 CDP 模式的隐身能力扩展到 Playwright 浏览器,进一步提升反检测能力。
  • UC 模式:使用 Undetected Chromedriver 来规避 Cloudflare 等系统的挑战。
  • MasterQA:结合自动化与手动验证的混合测试解决方案。

主要特点与优势

  • 简化 API:封装了 Selenium/WebDriver,提供了更简洁、强大的方法(如 self.typeself.click),自动处理等待、错误输出等,比原生 Selenium 更易用可靠。
  • 集成测试运行器:支持 pytest、pynose 和 behave,提供测试发现、执行、状态管理和丰富的命令行选项。
  • 自动化与手动结合:包含 GUI 工具(如 SeleniumBase Commander)、测试记录器(Recorder)和用于手动测试的 MasterQA。
  • 全面支持:支持所有主流浏览器(Chrome、Edge、Firefox、Safari)和操作系统(Linux、macOS、Windows),并兼容主要 CI/CD 平台。
  • 内置工具:提供仪表板(Dashboard)生成、测试报告(HTML/XML)、日志管理、截图保存、驱动管理、代理服务器设置、User-Agent 更改、引导式网站游览(Tours)等功能。
  • 反检测与绕过:通过 CDP/UC/Stealthy 模式和内置的 solve_captcha() 方法,用于应对机器人检测和 CAPTCHA 验证。

安装与使用

  • 可通过 PyPI 或 GitHub 仓库安装。
  • 使用 sbase mkdir 命令可快速创建包含配置文件和示例的项目目录结构。
  • 提供大量命令行选项(如 --browser--headless--dashboard--proxy)来定制测试行为。

测试编写示例

  • 继承 BaseCase:适用于 pytest/pynose,使用 self. 调用方法。
  • 使用 SB 上下文管理器:以 sb. 开头调用方法,运行于纯 Python 环境。
  • 使用 Driver 管理器:可直接操作增强版的 Selenium 驱动。

与原生 Selenium 的区别 SeleniumBase 在原生 Selenium 基础上,提供了更智能的元素等待、更简洁的语法、自动的驱动管理、测试结构化运行、友好的错误信息、内置报告/仪表板/截图日志以及录制工具等。

附加功能

  • 支持数据驱动测试、并行测试执行(多线程)。
  • 可集成 MySQL、Amazon S3 用于存储测试结果和日志。
  • 包含 ChartMaker 工具,可从 Python 代码生成 JavaScript 数据图表。
  • 提供可视化测试和布局测试支持。
24. Advent of Code on the Nintendo DS (sailor.li)

这篇文章详细记录了作者在Nintendo DS(代号Nitro)上使用Rust语言实现《Advent of Code 2024》谜题解决方案的嵌入式开发过程。项目的核心挑战在于为没有操作系统和标准库的裸机环境编写代码。

项目动机与系统概述

作者选择Nintendo DS,是因为其相对独特的双处理器架构(ARM9主CPU和ARM7协处理器)和有限的嵌入式开发资源,这为学习嵌入式Rust提供了挑战。文章重点在ARM9处理器上编程,ARM7主要用于I/O控制。

主要技术挑战与实现步骤

  1. 构建最小可执行程序

    • 使用 #![no_std]#![no_main] 属性创建一个不依赖Rust运行时的循环程序。
    • 通过 .cargo/config.toml 配置交叉编译目标为 armv5te-none-eabi,并使用Cargo的 build-std 特性为corealloc库编译目标代码。
  2. 创建可启动的ROM

    • 将编译出的二进制文件转换为原始ARM9代码块。
    • 发现初始程序存在关键问题:入口点错误(代码链接到0x200e4但被加载到0x2000000)、未设置栈指针未初始化.bss
    • 编写链接器脚本 (linker.ld) 定义内存布局(主内存4MB起始于0x02000000),并明确放置代码段(.text)、数据段(.data, .rodata)和BSS段。
  3. 编写C运行时启动代码 (start.s):

    • 用汇编语言编写启动代码 _start,负责:
      • 禁用中断并等待垂直同步。
      • 设置各处理器模式(IRQ, Supervisor, System)的栈指针到DTCM(数据紧密耦合内存)。
      • 清零.bss段。
      • 跳转到Rust的 main 函数。
  4. 配置系统硬件

    • 协处理器15:编写大量汇编代码配置内存保护单元、缓存、TCM(紧密耦合内存)映射等,以设置内存系统。
    • 设置堆分配器:使用talc库作为全局分配器,并利用链接器脚本定义的符号确定堆的起始和结束地址。
    • 支持原子操作:由于平台无原生原子指令,引入portable-atomiccritical-section库,并通过内存映射的IME寄存器实现临界区(禁用/恢复中断)。
  5. 调试与测试

    • 使用支持GDB存根的模拟器(如melonDS、DeSmuME)进行调试。
    • 首先将谜题答案输出到固定内存地址,并在调试器中读取验证。
  6. 实现图形输出

    • 配置NDS的2D图形引擎A为帧缓冲模式,将VRAM A块映射为屏幕帧缓冲。
    • 使用embedded_graphics库和tinybmp在屏幕上绘制文字和图形,显示《Advent of Code》Day 1 Part 1的解答。

结论与现状

作者成功在Nintendo DS上运行Rust程序并显示了谜题解答。尽管项目代码因初始错误无法在真机启动,且部分实现(如锁机制)在最新版Rust中已不再推荐,但整个过程展示了为复杂嵌入式系统从头构建运行时环境的完整工作流。作者指出,相比构建基础系统,解决《Advent of Code》谜题本身反而更简单,并计划未来可能扩展为更完整的SDK。

25. Is stuff online worth saving? (rubenerd.com)

文章探讨了在线内容保存的价值。作者在导出书签时发现,许多早年收藏的链接如今已失效、重定向或被垃圾信息占用,实际存活率极低,这促使他思考是否值得投入精力进行数字存档。

作者自述为一名数字存档者,秉持“若喜欢,便保存”的理念,长期备份了众多已消失的博客、播客、频道等内容。他认为网络具有瞬时性,甚至互联网档案馆也无法完全免受外部影响,因此个人备份具有必要性。

针对“内容是否值得保存”的质疑,作者认为存档的目的最初是分享兴趣,随着时间推移,内容会成为历史记录甚至怀旧载体,如同报纸转变为时代见证。从整个网络社会的角度看,这种保存更具意义。

最终,作者肯定在线内容值得保存,但指出关键问题在于如何高效、经济地实施存档,以及应对存储成本和技术挑战。

27. Torpedo juice: Legendary, illegal WWII liquor drunk in Alaska and the world (www.adn.com)

文章摘要

本文介绍了二战期间美军中流传的一种传奇自制酒精饮料“鱼雷汁”(Torpedo juice)的历史、文化及其在阿拉斯加等地的影响。

起源与制作 二战初期,美军鱼雷使用180度乙醇作为燃料。在酒精供应短缺的情况下,水兵们会偷偷从鱼雷中提取燃料酒精,然后与果汁混合饮用以降低强度。这种饮料因此得名“鱼雷汁”。虽然在二战前就有类似行为,但战时海军的快速扩张使其迅速普及并公开化。

饮用文化与调配

  • 流行程度:主要在太平洋战区流行,因为那里的鱼雷和果汁(如菠萝、柠檬、葡萄柚汁)相对容易获得。其名称后来也泛指任何来源的劣质私酒。
  • 口味与目的:口感极其刺激,并非为了享受,而是为了追求醉酒、社交联结和摆脱战场单调。饮用它有时也被视为一种男子气概的考验。
  • 调配比例:配方不固定,通常按1:3或2:3(酒精:果汁)的比例混合,调整到可入口为止。

相关回忆与轶事 文章引用了多位老兵的口述历史:

  • 鱼雷兵会巧妙地将为鱼雷准备的酒精和果汁转运到自己的舱室。
  • 水手们会通过“渠道”获取果汁罐头等物资。
  • 阿拉莫侦察兵等部队在执行敌后任务后,会饮用鱼雷汁来放松和汇报情况。
  • 鱼雷汁成为舰上乃至不同军种间的硬通货。

风险与应对

  • 健康危害:饮用者常面临剧烈不适、宿醉甚至失明、死亡的风险。文中提到有士兵因饮用被替换为变性酒精(甲醇)的燃料而死亡或失明。
  • 海军的对策:海军后来在鱼雷燃料中添加红色染料、有毒的甲醇或泻药(如巴豆油)以阻止饮用,但这反而促使水手们研究过滤和蒸馏技术。
  • 自制设备:水手们使用面包条(其功效存疑)过滤,并秘密搭建简易蒸馏器(称为“gilly stills”)来提纯酒精。

阿拉斯加战地情况 在阿拉斯加的阿留申群岛等地,由于环境恶劣和物资匮乏,酒精成为“痴迷的追求”。一瓶正规威士忌的价格高达天价。文章附带的1943年照片中,阿留申群岛的战斗机飞行员们就在共饮“鱼雷特西”,并使用了空出的珍贵威士忌瓶来盛装。当地有居民回忆,曾发生因饮用有毒私酒而导致的死亡和失明事件,但相关报道受到军事审查。

战后影响与结语 随着1943年电动鱼雷(Mark 18)的出现,需要酒精燃料的传统鱼雷被淘汰,“鱼雷汁”的原始来源不复存在。但这个名称被保留下来,用来指代任何能唤起战时回忆的烈性私酒。文章最后,作者尝试用现代烈酒Everclear和菠萝汁复刻配方,体验到其强烈的口感,并评论道,这种饮料能让饮用者暂时忘却一切恐惧和烦恼。

28. Ten Thousand Years (99percentinvisible.org)

文章讨论了新墨西哥州废物隔离先导工厂(WIPP)——美国唯一的永久性地下核废料储存库,旨在安全封存来自核武器制造与核能生产的放射性废物长达20万年以上。然而,1990年,一个跨学科专家组面临一个更紧迫的挑战:如何将此地的危险信息有效地传递给一万年后的人类。

核心挑战:跨越万年的沟通 一万年前,人类处于新石器时代,文化与今天截然不同,使得任何基于当前语言或符号的警告都可能失效。语言会演变(如千年前的《贝奥武夫》已难以读懂),符号的意义也会漂移。文章以骷髅和交叉骨符号为例,详细说明其起源(中世纪宗教艺术中象征“重生”),到近代海盗用作死亡威胁,再到纳粹标志,最终演变为通用的危险警告,但如今又频繁出现在流行文化中,削弱了其威慑力。

专家组的探索与困境 专家组考虑了多种方案:

  1. 语言与符号:因其固有的不稳定性而被否定。
  2. 视觉叙事:如用漫画序列表现辐射危险,但若从下往上解读,意思完全相反。
  3. 景观设计:艺术家提议建造充满尖刺的“荆棘景观”以营造不祥之感,但其本身可能成为吸引人探索的地标。

最具创意的方案:文化与基因工程的结合 受1981年另一个核废料项目委员会的启发,两位哲学家提出了一个融合科技与文化的方案:

  • “射线猫”计划:通过基因工程培育一种在辐射环境下会变色的猫,作为活体盖革计数器释放到野外。
  • 创造传说:编写歌曲、故事和民间传说,将这些猫塑造成危险的警示,确保“看到猫变色就立刻逃走”这一核心信息能通过文化传承延续下去。他们认为,文化(宗教、传说、信仰)是人类创造的最持久的事物之一

反思与当代关联 文章最后将焦点拉回现实:负责运营WIPP的洛克希德·马丁公司的子公司,曾因其在佛罗里达州塔勒瓦斯特镇的铍加工厂污染环境,导致当地居民(主要是非裔美国人)健康受损并引发诉讼。这形成了一个强烈的对比:我们在竭尽心力设计保护万年后的陌生人,却可能忽视了当代社区正在遭受的类似伤害。结尾以讽刺的口吻指出,也许保护未来人类最好的方式,就是先照顾好今天的人。

29. HAM radio operators receive signals from Voyager 1 on Dwingeloo telescope (www.camras.nl)
30. When should we require that firmware be free? (mjg59.dreamwidth.org)
# 文章无法访问

提供的链接返回了 **403 Forbidden**(禁止访问)错误,这意味着由于服务器设置权限限制,无法获取到文章《When should we require that firmware be free?》的实际内容。

因此,无法基于文章内容进行总结。如需获取信息,请确认链接的正确性或检查访问权限。
31. Network protocols for anyone who knows a programming language (2017) (www.destroyallsoftware.com)

文章摘要:为懂编程的人解读网络协议

这篇文章系统地解释了网络协议栈如何协同工作,实现了在不可靠的物理网络上进行可靠的数据传输。主要内容可以归纳为以下几个层面:

1. 网络路由与地址

  • 路由:互联网数据并非通过一条独占的物理线路传输,而是由一系列路由器以“接力”方式转发。每个路由器维护一个路由表,根据目标IP地址决定将数据包传递给哪个相邻的路由器。
  • IP协议:负责为网络中的节点提供唯一地址(IP地址)。IPv4地址(32位)已耗尽,IPv6(128位)正逐步推广。
  • BGP协议:负责在不同网络的路由器之间交换和更新路由表信息,确保路由路径的时效性。

2. 分组交换与传输

  • 分组交换:为了在有限的存储和可能故障的网络中传输大数据,数据被分解成许多小数据包(通常约1400字节)进行发送。
  • TCP协议:在不可靠的IP层之上提供可靠传输。
    • 序列号与重组:每个数据包都有序列号,接收方按序列号重新组装,即使到达顺序混乱也能还原原始数据。
    • 确认(ACK)与重传:接收方通过发送ACK确认收到数据包。如果丢失数据包,后续到达的包会触发接收方发送重复ACK。发送方收到三个重复ACK后,会立即重传缺失的数据包(快速重传)。
    • 拥塞控制:通过拥塞窗口(CWND) 机制动态调整发送速率。连接开始时采用“慢启动”,窗口逐步增大;一旦检测到丢包(拥塞迹象),窗口会缩小,降低发送速率。

3. 物理层与链路层

  • 以太网:最常见的物理层和链路层协议,负责设备间直接的数据传输。它将数据封装成(含MAC地址、负载、校验和等),并在外部添加用于硬件同步的前导码包间隔
  • 适应现实物理世界:数字信号本质是模拟的。为解决长串“1”或“0”导致的直流偏置问题,以太网采用8b/10b编码,将8位数据映射为10位符号,以平衡线路电压,确保信号完整性。这体现了软件协议必须考虑底层硬件的物理限制。

4. 协议栈的层级与相互影响

  • 网络协议是一个分层结构:以太网(物理/链路层)→ IP(网络层,解决寻址和路由)→ TCP(传输层,提供可靠性)→ HTTP等应用协议
  • 各层相对独立工作(如路由器只负责转发IP包,不关心TCP重传),但设计上相互依赖。高层协议受到低层协议的约束
    • 关键约束:以太网帧的最大负载为1500字节。这限制了IP包的大小,进而限制了TCP数据的大小(通常约1400字节)。
    • 设计影响:例如,HTTP/2协议引入了头部压缩,其重要目的之一就是将尽可能多的请求装进一个TCP数据包(受限于~1400字节),以提高效率。这个需求最终可以追溯到1970年代以太网设备的内存限制。

核心观点:网络协议栈通过巧妙的分层设计,在不可靠、异构且受物理定律约束的复杂基础设施之上,构建了一个可靠、透明且可扩展的全球数据通信系统。程序员在使用上层协议时,往往不需要关心底层细节,但理解这些层次间的交互有助于更好地构建网络应用。

32. Apple Watch with Android (abishekmuthian.com)

文章摘要:让Apple Watch与Android手机协同工作

个人动机

作者因友人独自在异国他乡猝然离世,深感健康监测设备的重要性。Apple Watch凭借其多年领先的心率、睡眠及运动追踪准确性(甚至四年前的型号仍优于多数新竞品)成为首选。然而,作者因不认同苹果的封闭生态系统、垄断行为、营销策略及反维修立场,一直避免使用苹果产品,转而依靠搭载开源系统(如Lineage OS、microG、F-Droid)的Android手机和由Gadgetbridge支持的智能手表,以掌控数据、保障隐私与自由。

核心挑战与解决方案

作者希望在不牺牲开源设备自由与安全的前提下,使用Apple Watch的健康功能。最终决定通过开源应用、可互操作协议及第三方服务,让Apple Watch与Android手机协同工作,并将代码开源在GitHub上。

1. 设备准备与初始困难

  • 必需iPhone:完全不用iPhone无法实现Apple Watch的核心健康功能(如ECG)。作者曾尝试“儿童版Apple Watch”计划,但因该版本禁用关键健康功能及运营商限制而失败。
  • 折中方案:购买一部二手iPhone用于初始配对和设置,但目标是不必日常携带。

2. 具体功能实现

  • 蜂窝网络:使用同一张SIM卡,在iPhone中激活Apple Watch蜂窝功能。实现了电话的同步接听(Android手机与Apple Watch同时响铃),但短信功能无法使用(因SIM卡在Android手机中)。紧急呼叫功能正常
  • 通知同步:这是实现难度最大的部分。方案是通过Android终端模拟器Termux运行Python脚本读取手机通知,再利用Pushover推送服务将通知发送至Apple Watch。
  • 日历同步:利用CalDAV开放协议,通过自托管的Nextcloud服务器和相关开源应用(如Fossify Calendar, DAVx⁵),将Android日历事件同步至Apple Watch。
  • 联系人同步:同理,通过CardDAV协议和Nextcloud,将Android联系人同步至Apple Watch,使来电能显示姓名而非号码。
  • 任务同步:利用DAVx⁵应用,将任务管理应用(如jtxBoard)中的待办事项,通过CalDAV/CardDAV协议同步到Apple Watch的“日历”和“提醒事项”应用。

成果与现状

作者实现了让Apple Watch与Android手机协同工作的主要目标。iPhone保持在家连接电源和网络,用于维持Apple Watch的配对状态及功能完整性,而无需日常携带。

总结与致谢

作者强调,这一成果的实现完全依赖于开源社区、可互操作的协议(CalDAV, CardDAV)以及专注于社区的小型应用。同时指出,这些开源技术正面临巨大威胁。作者鼓励有兴趣者参与其GitHub项目的讨论,并可通过多个社交平台与其交流。

35. The Night Watch [pdf] (2013) (scholar.harvard.edu)

该文档标题为"The Night Watch [pdf] (2013)",但无法直接访问其内容。系统返回了服务器权限错误提示,表明由于访问限制,无法获取位于"scholar.harvard.edu"域名的指定PDF文件。错误参考代码为#18.b4ca645f.1780032636.61e9edb。因此,无法基于实际内容提供摘要。

36. Using GPS satellites to detect tsunamis via ionospheric ionization waves (www.earthdata.nasa.gov)

文章标题分析:利用GPS卫星通过电离层电离波探测海啸

由于无法访问原文内容,仅能根据文章标题提供推测性摘要。

根据标题“Using GPS satellites to detect tsunamis via ionospheric ionization waves”,可以推断文章可能探讨的是一种利用全球定位系统卫星进行海啸早期探测的先进技术。其核心原理在于,海啸在生成和传播过程中,会引发大气重力波等扰动,这些扰动向上传播至电离层,导致该区域电子密度发生可测量的规律性变化,即所谓的“电离层电离波”。

文章预计会阐述如何通过分析GPS卫星信号在穿越受影响电离层区域时所产生的延迟或畸变数据,来反向探测和追踪这些由海啸引发的电离层扰动。这种方法有望作为一种全新的、覆盖范围广阔的补充监测手段,用于在海啸波抵达海岸前提供预警。

(注:以上内容基于标题推测,具体的研究方法、数据结论及详细技术细节需阅读原文获取。)

37. Microsoft rejects documentation PR because AI chatbots can't display tables (github.com)

本文内容主要涉及 Windows Subsystem for Linux (WSL) 相关文档的一系列更新和修改记录,核心是针对文档仓库的多个拉取请求(PR)的合并与解决。以下是关键更新内容的摘要:

主要文档更新与修正:

  1. 错误修复与澄清:

    • 修正了 networking.md 中关于 hostname 命令地址标志的错误说明(小写 -i 返回环回地址,应使用大写 -I)。
    • 修复了 build-custom-distro.md 中的反引号错误。
    • 修正了 troubleshooting.md 中关于 Azure 虚拟机支持嵌套虚拟化但不能与 Trusted Launch 一起使用的说明。
    • 修正了 wsl-config.md 中 DrvFs 自动挂载的默认 umask 行为描述,使其与实际情况一致。
    • 修正了 systemd.md 中关于 wsl --version 命令可能因版本过旧而报错的说明。
    • 修正了其他多处文档中的拼写错误和格式问题。
  2. 功能与配置说明:

    • 添加了关于 --pre-release 选项的说明。
    • 添加了关于 Microsoft Store 被阻止时的注意事项。
    • 添加了 shortcut.enabledwindowsterminal.enabled 配置项的文档。
    • 更新了 wsl-config.md 的导言部分,以提高清晰度。
    • 添加了 kernelModules 的文档说明及其默认列值。
    • 更新了 WSL 关闭操作的说明,明确要求在执行关闭命令前必须以管理员身份运行 PowerShell。
    • 添加了关于 Docker Desktop 错误的建议。
    • 添加了关于 WSL 管理部分的内容。
  3. 更新与维护:

    • 指出 WSL 的默认行为自 2024 年 5 月起已更改,并更新了相关配置文档。
    • 更新了 Microsoft SQL Server 的安装链接,指向 SQL Server on WSL 2
    • 更新了磁盘空间扩展命令的格式。
    • 移除了未使用的图片文件。
    • 根据法律要求更新了第三方声明文件中的链接和文本。
    • 添加了 WSL 开源链接和概述信息。
  4. 冲突解决与合并:

    • 文档内容记录了多次尝试从主分支(Main)合并到实时分支(Live)的过程,以及为解决合并冲突(尤其是在 wsl-config.md 等文件中)所做的多次努力(例如 PR #2184, #2186, #2188, #2189, #2190, #2193, #2194)。这些冲突的解决确保了文档更新的最终一致性。

总结: 本文实质是 WSL 文档项目的一个更新日志,汇集了多个社区贡献者和微软员工对文档进行的错误修正、功能说明补充、内容优化及维护工作。这些更新旨在提高文档的准确性、清晰度和实用性,反映了 WSL 生态系统的持续演进和维护。标题中提到的“AI聊天机器人无法显示表格”可能是导致某个特定PR被拒绝的技术原因,但文档内容本身主要聚焦于上述具体的修正和更新。

38. Pelicans on a bicycle (simonwillison.net)

这篇文章介绍了作者创建的一个大语言模型(LLM)基准测试,主题是“骑自行车的鹈鹕”。作者选择“生成一个骑自行车的鹈鹕的SVG”作为提示词,因为 a) 他喜欢鹈鹕, b) 他确信目前训练数据中不太可能已有此类SVG文件。

他使用自己开发的 LLM CLI 工具,将该提示词输入了来自 OpenAI、Anthropic、Google Gemini 和 Meta(在 Cerebras 上运行的 Llama)的共 16 个模型。文章展示了部分模型生成结果的对比,包括:

  • Claude 3.5 Sonnet 的两个版本(2024-06-20 与 2024-10-22)
  • Gemini 1.5 Flash 的两个版本(001 与 002)
  • GPT-4o mini 和 GPT-4o
  • o1-mini 和 o1-preview
  • 在 Cerebras 上运行的 Llama 3.1 70B 和 Llama 3.1 8B

此外,文章还特别提到了 Gemini 1.5 Flash 8B 的结果,并说明其余模型的输出已链接至项目的 README 文件。

39. The Power Mac 4400 (512pixels.net)

Power Mac 4400:一台饱受批评的苹果廉价机型

发布与定位

  • 1996年11月发布,起售价1725美元,亦以Power Macintosh 7220名称销售。
  • 定位为面向小型企业的廉价电脑,是苹果在90年代为降低制造成本而推出的产品。

备受诟病的外部设计与做工

  • 采用廉价的通用PC机箱外壳,仅在前端添加了苹果标志性的弧形面板。
  • 内部使用弯曲的金属板材,边缘锋利,做工粗糙,与用户期待的Mac品质相去甚远。
  • 软盘驱动器位于机身左侧,且缺乏其他Mac型号的自动吸入功能,设计怪异。
  • 电源取消了自动电压切换功能,为国际用户带来不便。
  • 因其糟糕的设计,后被列入“苹果史上最差产品”榜单。

内部配置与性能缺陷

  • 基于“Tanzania”主板设计,该架构也用于当时众多的Mac克隆机。
  • 支持PowerPC 603e处理器,最大内存160MB。
  • 只有一条EIDE总线,导致内部仅能连接光驱和硬盘,数据传输速度慢于配备SCSI的Mac。
  • 运行时风扇噪音大,且系统频繁崩溃。

系统兼容性与后续支持

  • 可运行System 7.5.3至Mac OS 9.1,但存在兼容性问题(如System 7.5.5无法启动)。
  • 苹果于1998年发布了针对Mac OS 8.1的专用更新,以修复Tanzania架构导致的启动挂起和ATA管理器死循环问题。
  • 有用户通过硬件升级(如更换CPU、显卡或改用固态存储)尝试运行Mac OS X,但性能极差。

产品线与停产

  • 推出了包括4400/160和4400/200在内的不同型号,后者可选配包含DOS兼容卡的166 MHz处理器模块。
  • 于1998年2月因Power Mac G3桌面机上市而停产。
  • 历史评价极低,常被视为苹果为控制成本而牺牲品质的失败案例。