Ladybird 浏览器项目总结

项目简介

Ladybird 是一个从零构建的全新、真正独立的网页浏览器引擎，由 501(c)(3) 非营利组织支持。它不是任何现有引擎（如 Blink、WebKit 或 Gecko）的代码分支。项目计划于 2026 年发布针对 Linux 和 macOS 的首个 Alpha 版本，主要面向开发者和早期采用者。

核心特点

• 真正独立与专注：基于 Web 标准从头构建，唯一目标是打造网页浏览器。
• 零用户变现：拒绝默认搜索交易、加密货币、数据收集和广告等任何形式的用户变现。
• 绝对独立性：资金仅来自无限制捐赠，赞助商无权干涉技术路线图或产品方向，不售卖董事会席位或影响力。

技术栈与开发进展

• 编程语言：项目源于 SerenityOS，最初使用 C++。现已采用 Rust 作为后继语言，并利用 AI 代理加速子系统的代码迁移。
• 近期功能：实现了 Rust 编写的 HTML 解析器、WebAssembly JIT、异步滚动、进程外合成器、原生内容拦截、CSS 新特性（如 @container、@scope）及基于 pdf.js 的内联 PDF 查看器等。
• 架构调整：脱离 SerenityOS 独立后，项目开始引入第三方库处理音视频、加密和图形等通用功能，不再强制所有代码从头编写。

平台支持与规划

• 桌面端：当前全职团队聚焦 Linux 和 macOS。JavaScript 引擎已支持 Windows CI 构建与测试，完整的 Windows 浏览器支持将在后期推出。
• 移动端：暂非开发重点，待桌面版完善后再投入 Android 和 iOS 版本的开发。
• 团队运营：由小型全职工程团队主导开发，并致力于始终维持 18 个月的运营资金储备。

资金与社区参与

• 资金支持：完全依靠个人捐赠（通过 Donorbox）和企业赞助（分为铂金至铜牌五个等级）。
• 开源协作：代码在 GitHub 开源，提供简单的本地克隆和运行脚本。鼓励社区通过提交 Bug、简化复现步骤、测试网站、报告安全问题等方式参与建设，社区交流主要通过 Discord 进行。

摘要：OpenSSH服务器信号处理器竞态条件漏洞（CVE-2024-6387）

核心漏洞

这是一个在基于glibc的Linux系统上的OpenSSH服务器（sshd）中发现的信号处理器竞态条件漏洞。当客户端未在LoginGraceTime（默认120秒）内完成认证时，sshd的SIGALRM处理器会被异步调用，但该处理器调用了异步信号不安全的函数（如syslog()）。攻击者可利用此竞态条件，以root权限实现远程代码执行（RCE）。

漏洞本质与影响版本

该漏洞是CVE-2006-5051的回归，由2020年10月的一个提交意外引入。受影响版本为：

• OpenSSH < 4.4p1：若未修补CVE-2006-5051。
• 8.5p1 ≤ OpenSSH < 9.8p1：因修复CVE-2006-5051的补丁被意外移除而重新暴露。

OpenBSD系统不受影响，因其使用了异步信号更安全的syslog_r()函数。

利用方法概述

研究人员通过在不同OpenSSH版本和操作系统上演示利用技术，证明了漏洞的可利用性：

1. Debian 3.0r6 (OpenSSH 3.4p1)：中断free()调用以破坏堆状态，在信号处理器中利用unlink()技术执行代码。平均需约1万次尝试，耗时约1周。
2. Ubuntu 6.06.1 (OpenSSH 4.2p1)：中断PAM库中的pam_start()调用，利用未初始化的结构体字段，通过“House of Mind”技术执行代码。平均需约1万次尝试，耗时1-2天。
3. Debian 12.5.0 (OpenSSH 9.2p1, i386)：中断malloc()调用，在syslog()内部通过精心构造的堆布局和FILE结构体漏洞执行代码。平均需约1万次尝试，因ASLR需猜地址，总耗时6-8小时。

攻击的关键在于精确时序控制，以赢得竞态条件。研究人员开发了基于网络延迟和服务器反馈的时序调整策略。

补丁与缓解措施

• 升级：升级至OpenSSH 9.8p1或更高版本。该漏洞通过提交81c1099修复，将不安全的代码移至同步处理的监听进程。
• 临时缓解：若无法升级，可在sshd配置中设置LoginGraceTime 0（但会导致拒绝服务风险）。
• 代码修复：可注释掉sshsigdie()函数中的异步不安全代码，仅保留_exit(1)。

后续工作

针对amd64架构的利用仍在研究中，因更强的ASLR而更具挑战性，但基于glibc地址的固定模式和堆原语，认为利用是可行的。

这篇文章以约翰内斯堡为例，阐述了城市大量种植树木带来的多重益处。

约翰内斯堡历史上因金矿开采产生了大量有毒的粉尘山丘。为抑制粉尘，该市大规模种植了数百万棵树木。这些树木最初是为了防尘而种，通常是枝叶茂盛的大树，从而带来了多种后续好处：

1. 遮荫与降温：树木形成的城市林荫道能有效提供遮荫，缓解由沥青和混凝土导致的城市“热岛效应”。
2. 噪音屏障：树木能有效降低交通噪音，并为人行道上的行人提供保护。
3. 提升美观与亲生物性：树木丰富了城市景观，符合人类亲近自然的天性。
4. 增加生物多样性：树木为鸟类、昆虫等城市野生生物提供了栖息地和避难所。

作者通过个人体验对比了有无树木的城市，指出绿荫街道更能吸引人们步行、停留和消费。尽管在非城市环境中大规模植树作为碳汇策略效果不一，但在城市环境中，种植树木被认为是几乎只有益处（除鸟类排泄物外）的举措。文章最后倡导人们欣赏并重视城市中的树木。

Pikimov：免费、无需注册的网页端After Effects替代方案

这是一个名为Pikimov的运动设计与视频编辑器，旨在成为Adobe After Effects和CapCut等软件的替代品。它具有以下核心特点：

主要优势：

• 免费且无需注册：立即开始使用，没有付费墙或账户要求。
• 完全在浏览器中运行：支持Chrome或Edge浏览器，无需安装任何软件，兼容Windows、macOS、Linux和Chromebook。
• 注重隐私的本地编辑：所有编辑都在本地进行，用户文件不会上传至任何服务器，项目也不会被用于AI训练。
• 功能全面且无冗余：支持高达4K分辨率，集成了主流视频编辑功能，没有不必要的AI功能堆砌。

核心功能与编辑器： Pikimov集成了三个主要编辑模块：

1. 经典编辑器：提供传统视频剪辑功能。
2. 2D合成编辑器：用于二维动态设计。
3. 3D合成编辑器：支持三维动态设计，可导入GLB格式的3D模型。

关键特性包括：

• 丰富的视觉效果：颜色校正、模糊、故障、绿幕抠像、变形（弯曲、扭曲、自由变形）等。
• 动态设计工具：强大的关键帧动画系统，可对几乎所有属性进行动画设置。
• 创作灵活性：支持导入图像、视频、音频文件；提供多种文本效果预设和转场效果；支持手动或自动抠像（Rotoscoping）。
• 高级功能：运动跟踪、背景移除、字幕生成器。
• 代码驱动动画：支持使用类似After Effects的JavaScript表达式语法进行动画创作。

其他信息：

• 该项目受到Photopea成功的启发。
• 它已被一些科技媒体报道。
• 开发者通过Patreon接受支持，支持者可获得桌面离线应用版本（适用于Windows、macOS和Linux）。

Edna: 面向开发者的“超能力”笔记应用

应用定位
Edna 被定义为一个具备“超能力”（super powers）的笔记应用程序。这一定位暗示它不仅仅是简单的文本记录工具，而是集成了增强型功能，旨在超越传统笔记应用的基础范畴。

目标用户
该应用明确面向开发者（for developers）群体。这意味着其功能设计、交互逻辑或集成特性很可能围绕编程、代码片段管理、技术文档、项目笔记等开发者特定的工作流程与需求展开。

核心特点
根据描述，Edna 的核心卖点在于其“超能力”。虽然具体内容未详细展开，但这通常可能代表如下一种或多种能力：

• 代码友好性：如语法高亮、代码块执行、版本控制集成。
• 高级组织方式：如双向链接、知识图谱、标签体系，以连接和结构化技术知识。
• 自动化与智能功能：如基于内容的自动分类、代码补全建议、API 集成。
• 无缝的开发环境集成：可能与 IDE、终端、Git 等开发者日常工具深度结合。

总结
Edna 是一款专为开发者打造的笔记工具，其核心价值在于通过所谓的“超能力”功能，解决开发者在记录、组织和管理技术知识与工作笔记时面临的特定挑战，旨在提升开发者的知识管理与工作效率。

本文探讨了多项式乘法与傅里叶变换及卷积之间的联系，并提出了一种比传统高中方法（O(n²) 复杂度）更高效的多项式乘法算法，其复杂度为 O(n log n)。

1. 多项式及其传统乘法

• 多项式 P(x) 定义为：P(x) = Σ a_k x^k，其中 a_k 为系数。
• 两个多项式 P(x) 和 Q(x) 相乘的传统方法涉及系数间的逐项相乘并合并同类项。
• 例如，计算 (2x²+3x+4)*(5x²+6x+7) 会产生 9 项乘法运算，最终合并为 10x⁴+27x³+52x²+45x+28。
• 该方法的计算复杂度为 O(n²)，其中 n 为多项式的阶数，对于高阶多项式效率很低。

2. 卷积与多项式乘法的等价性

• 卷积定义：两个离散信号 p 和 q 的卷积定义为 y[n] = Σ p[k] * q[n-k]。
• 计算过程：通过翻转其中一个信号并滑动计算重叠部分的乘积之和。
• 关键联系：对上述多项式 P(x) 和 Q(x) 的系数向量 p=[2,3,4] 和 q=[5,6,7] 进行卷积，得到的结果 [10, 27, 52, 45, 28] 与多项式乘法的结果完全相同。因此，多项式乘法等价于其系数的卷积。

3. 傅里叶变换与快速傅里叶变换 (FFT)

• 傅里叶变换 (FT)：将信号从时域转换到频域，揭示其频率成分。
• 离散傅里叶变换 (DFT)：针对离散信号的傅里叶变换。
• 快速傅里叶变换 (FFT)：高效计算 DFT 的算法，将复杂度从 O(n²) 降至 O(n log n)。
• 核心优势：在时域中进行的卷积运算，等效于在频域中进行的点乘（逐元素相乘），而点乘的复杂度仅为 O(n)。

4. 利用 FFT 加速多项式乘法

基于上述原理，多项式乘法的快速算法分为三步：

1. 转换到频域：使用 FFT 将两个多项式的系数向量从时域转换到频域，复杂度 O(n log n)。
2. 频域点乘：在频域中进行逐元素乘法，复杂度 O(n)。
3. 转换回时域：使用逆快速傅里叶变换 (IFFT) 将结果转换回系数表示，复杂度 O(n log n)。

总体复杂度为 O(n log n)，显著优于传统的 O(n²) 方法。

5. 实现与性能

• 文章提供了 Python 代码示例，分别实现了传统乘法（multiply_naive）和基于 FFT 的乘法（multiply_fft）。
• 性能对比测试（使用优化后的 multiply_convolve 作为基准）表明：
  • 对于低阶多项式，FFT 的额外开销可能使其不如传统方法快。
  • 但随着多项式阶数的增加（例如超过数千阶），FFT 方法展现出巨大的速度优势，其增长趋势符合 O(n log n) 的理论分析。

总结

• 传统多项式乘法是 O(n²) 的卷积运算。
• 通过傅里叶变换，可以将时域卷积转化为频域点乘。
• 利用快速傅里叶变换 (FFT)，可以在 O(n log n) 时间内完成多项式乘法，这是对传统方法的重大效率改进。

这篇技术文章记录了作者调试一个性能问题的过程。

作者发现其服务中，基于TCP的“gopher”比基于TLS的“gemini”消耗了更多的CPU资源（28:37 vs 6:02），这违反了直觉，因为TLS本身运行在TCP之上且产生更多数据包。通过性能分析无法找到原因后，作者开始仔细比对两套代码的实现。

经过反复检查和测试，作者发现TCP实现中有一段额外的代码。这段代码最初是为了解决Linux下Unix域套接字的竞态问题（在发送数据后立即关闭连接可能导致数据丢失）而添加的。该代码通过检查内核发送队列并在队列非空时主动让出协程，确保数据发送完成。

问题在于，这段代码虽然对Unix域套接字有必要，但对于IP套接字（TCP）却是多余的，并且带来了性能开销。其检查操作实际包含两次ioctl系统调用，会导致协程频繁地在“可写”和“可读”事件监听状态间切换，造成无意义的CPU消耗。

作者将这段代码移除后，测试显示“gopher”的CPU时间从18秒骤降至0秒，与“gemini”的CPU时间相符，问题得到解决。

文章核心观点：

1. 问题现象：TCP服务CPU占用异常高于TLS服务。
2. 根本原因：TCP实现中混入了一段专为Unix域套接字设计的同步等待代码，该代码对IP套接字不必要且会引发不必要的系统调用和事件循环，导致CPU浪费。
3. 解决方法：移除这段多余的代码（共四行）。
4. 总结：作者指出，此类性能缺陷（或bug）的发现过程往往困难，但修复方案却通常很简单。

bgammon.org 首万个游戏总结

bgammon.org 是一个开源的在线西洋双陆棋服务，在运营约九个月后，其游戏局数达到了10,000局。以下是这一历程的关键回顾。

运营现状

该平台目前每天托管约100局游戏，玩法包括西洋双陆棋、acey-deucey和tabula。

社区重要贡献

开发过程中得到了社区的积极推动，文中特别感谢了两位成员：

• f-a：提出了大量改进建议，例如在棋盘外以堆叠方式可视化显示已离场的棋子，并协助审阅博文。
• EGYT：推动并实现了客户端与服务端的完整国际化支持，同时提出了其他有益建议。

技术优化

官方客户端 Boxcars 及其内置的西洋双陆棋引擎 Tabula 经历了广泛优化，主要提升了：

• 应用启动速度
• 文本框的排版与渲染
• 使用Tabula计算棋步的速度 这些优化对Web和Android用户尤为明显。

引擎接口协议

作者起草并实现了西洋双陆棋引擎接口。

• 应用现状：目前仅在bgammon.org中实现，作者希望与其他开发者合作，使其成为行业标准。
• 重要作用：bgammon.org上所有由Tabula驱动的机器人通过该协议与服务器上的单个引擎实例通信，显著降低了运行多个机器人的资源消耗。
• 开发工具：该协议还被用于通过 bgammon-benchmark 工具进行开发测试。该工具能方便地让不同引擎对弈并评分，每次对Tabula进行更改后，都会通过与另一个引擎（如wildbg）的基准测试比对后才上线。

总结

作者对bgammon.org的发展方向感到满意，并对其未来（迈向下一个万局游戏）充满期待。

文章总结

作者在多年使用静态网站生成器（SSG）后，开始认为手动编写HTML可能比调试SSG更容易。核心问题是SSG在新机器上设置时，由于旧机器的配置差异，即使设置相同，SSG也可能无法正常工作，这种状况被称为“我们陷入的混乱”。

作者指出，调试SSG需要处理编程语言安装、包生态系统和部署模型等复杂问题，迫使开发者成为系统管理员，管理大量依赖关系，只为避免输入少量代码。相比之下，如果网站仅由HTML文件夹组成，通过“git clone”就能快速启动，使用Emacs的nxml模式或tpope的ragtag等工具，并结合xmlformat自动格式化，从而简化维护过程。

总结来说，作者强调长期维护的便利性在于偏好静态数据（以指定验证格式维护），而非不断变化的动态代码（可能失控且易损坏）。

与熊生物学家观看《灰熊人》的对话摘要

文章记录了《背包客》杂志编辑与野生动物生物学家韦斯·拉森一起观看纪录片《灰熊人》时的对话，探讨了影片主人公蒂莫西·特雷德韦尔在卡特迈国家公园与灰熊互动的经历、其致命错误，以及从中得到的安全启示。

卡特迈灰熊的行为特点

拉森解释，卡特迈沿海地区食物资源丰富，灰熊密度高且对同类及人类容忍度较高。它们通常不会主动攻击，这使得特雷德韦尔能够近距离接触。但他指出，特雷德韦尔的距离仍过于接近，这种“以人类充当熊保姆”的现象虽存在，但绝不应被效仿。同样的熊若在食物竞争更激烈的国家公园（如黄石），行为会更具攻击性。

特雷德韦尔的致命误判

特雷德韦尔忽视了灰熊多次发出的威胁信号，将其误解为自己“占据支配地位”的证明。拉森认为，这最终将招致灾难，因为熊迟早会选择升级冲突。特雷德韦尔自认是生态系统中的“主导熊”，已深陷“上帝情结”，拒绝接受外界意见。其营地环境从开阔的哈洛湾转移到茂密的桤木丛（灰熊迷宫），增加了意外惊吓熊的风险，可能促成了最终的悲剧。

死亡事件与争议

拉森推测，杀害特雷德韦尔及其女友的熊可能并非后来被击毙的那只，而是另一头更强壮的个体霸占了他们的遗体。他引用导师（当时在卡特迈工作）的观点支持这一判断。特雷德韦尔的死亡过程被录音记录，极其暴力痛苦，持续约10-15分钟，绝非理想的“殉道”。拉森断言，其最后时刻的想法必然是“我搞砸了”，而非殉道式的满足。

对特雷德韦尔行动与动机的评价

拉森认为，特雷德韦尔的保护使命自相矛盾：卡特迈的灰熊本就处于极佳的保护状态，无需人类干预；他的存在反而导致至少两头熊被杀，更多熊因习惯人类而面临风险。其行为本质是“为了自己”，而非真正利于熊。虽然意外地通过纪录片提升了公众对灰熊的理解，但其方式有害且自我毁灭。

安全建议与反思

拉森强调，在任何熊活动区域，携带并准备好使用防熊喷雾至关重要，这能将互动的主动权掌握在人手中。他将以不带喷雾比作“开车不系安全带”。最后，他直接指出：若想与野外动物共同生活，养条狗或寻求其他健康爱好；除非是进行科学研究，否则擅自与熊共居通常无益且有害。

文章总结了作者对一系列微调大语言模型在结构化数据提取任务上性能的评估，并将其与OpenAI的GPT-4等基础模型进行对比。核心任务是从ISAF新闻稿中提取特定字段信息，如事件类型、省份、伤亡人数等。

评估在包含724条未见过测试数据上进行。作者首先将数据转换为Pydantic模型进行结构化，并使用异步请求批量获取GPT-3.5-turbo、GPT-4-turbo和GPT-4o的预测结果。随后，加载了包括TinyLlama、Mistral、Llama3、Solar LLM以及通过OpenPipe和Predibase微调的模型预测。

评估指标包括JSON有效性、缺失值以及13个具体字段的准确性（如开始日期、省份、目标群体、事件类型、最小伤亡数等）。结果显示：

• 微调模型总体优于OpenAI模型：在省份、目标群体、事件类型等关键字段上，多个微调模型的准确率显著高于GPT-4系列。
• JSON格式处理：所有OpenAI模型均能生成有效JSON，而部分微调模型（如TinyLlama-sharegpt）存在无效输出或缺失。
• 具体字段表现：在日期预测上，Solar和微调GPT-3.5表现最佳；在数字估计上，模型间差距缩小，Mistral微调版略微领先；在布尔字段上，所有模型表现普遍良好，但微调模型仍略胜一筹。
• 聚合评分：微调模型的平均准确率明显超过OpenAI模型。表现最好的微调模型是Mistral-7B、Solar LLM和Llama3-7B，它们均超越了GPT-4o。

文章也指出了微调过程的挑战：评估实现复杂且耗时，管理部署在不同环境的多个模型不便，凸显了对统一评估框架和MLOps工具的需求。然而，评估体系为后续优化提供了关键基准。

作者总结，微调模型在特定任务上确实能超越通用大模型，并列举了数据隐私、控制力和潜在成本优势。未来计划包括评估非准确性指标、改进模型服务并深入分析失败案例以进一步提升性能。

FreeDOS 项目30周年经验总结

FreeDOS 是一个开源 DOS 操作系统项目，于1994年6月29日启动，旨在在微软停止开发 DOS 后，保留命令行环境与 DOS 应用生态。该项目即将迎来30周年，其协调人分享了维护开源社区的核心经验。

核心经验：

1. 社区重于代码：开源项目的根基是开放、包容的社区。应积极接纳新想法，即使它们偏离最初目标，也可能催生创新功能。
2. 保持用户参与：通过公开致谢、发布访谈、电子书及举办线上聚会等方式，持续认可和 engagement 社区成员的贡献。
3. 建立项目网站：网站是项目的虚拟“家”，需提供清晰的项目介绍、新闻动态和截图，并建议每年进行刷新以保持组织性。
4. 积极分享信息：利用多种渠道（如 YouTube 视频、技术文章）宣传项目，提升熟悉度和吸引力。
5. 维护开放沟通：设立官方的沟通渠道（如邮件列表）进行开发讨论和决策，同时可辅以其他平台提供用户支持。
6. 倡导相互尊重：制定并公开行为准则，为社区内的互动设定明确、尊重的底线。
7. 代码与许可是根本：项目必须拥有可自由获取、修改和分享的源代码，并选用符合目标的知名开源许可证（如 GNU GPL）。

文章最后庆祝了项目里程碑，并感谢了历史上所有关键的开发者与贡献者，强调 FreeDOS 的延续离不开整个社区的共同努力。

GoodWatch – 业余无线电腕表
GoodWatch是一款为卡西欧现代计算器手表设计的替换电路板，在保留手表原有功能和三年电池寿命的基础上，新增了对70cm和33cm业余无线电频段的支持。其核心采用德州仪器的CC430F6147芯片，手表表带同时充当非调谐随机线天线。源代码和CAD文件已公开于GoodWatch GitHub仓库，详细文档见其Wiki页面。

主要功能与应用

1. POCSAG接收器：内置小程序可接收来自DAPNET项目的2FSK 1200波特信号包，便于业余无线电爱好者使用。
2. 频率计数器：无需额外设备即可快速识别附近发射器的频率。例如，作者曾用此功能测定一台中国进口对讲机的频率，并通过电台验证结果。
3. CW调制与莫尔斯电码：支持无线电发射的CW调制；按住“+”键时，手表会以莫尔斯电码播报时间。

技术实现与扩展

• 内部无线电模块基于CC1100核心，使用C语言编程。
• 目前支持2FSK及4FSK调制，但无法实现相移键控（PSK）或LoRa调制。不过，通过适当的测试设备，仍可尝试实现其他调制方案。
• 社区提供了OOK发射器编写指南，便于进一步开发。

项目资源
完整文档、源码及硬件设计文件均已在GitHub和Wiki公开，鼓励爱好者参与使用与扩展。

Jujutsu 高级合并工作流摘要

简介与核心特性

Jujutsu (jj) 是一款兼容 Git 的现代版本控制系统。本文介绍了一种高级合并工作流，旨在通过灵活操作合并提交，实现在同一工作目录中同时激活多个分支。其核心特性包括：

• Change ID 与 Commit ID 分离：修改（amend）提交时 Change ID 保持不变，便于持续追踪逻辑变更。
• Revsets 语言：提供强大的表达式，用于精准过滤和选择提交图节点。
• 无暂存区设计：摒弃 Index 概念，代码修改直接更新“工作副本提交”。

核心工作流理念

该工作流的核心是将多个功能分支或提交合并为一个“超级合并提交”，并将其保留在工作目录中。

• 主要优势：开发者无需频繁切换分支或使用 stash，即可整体测试多个开发中（WIP）的功能，或在当前上下文中快速修复 Bug。结合 Jujutsu 的一流冲突处理和 undo 功能，操作提交图极其安全。

关键操作与命令

• 创建与修改合并提交：使用 jj new 指定多个父节点创建合并提交；通过 jj rebase 结合 Revsets 的集合运算符（如并集 | 和差集 ~）灵活添加或移除父节点。
• 批量变基：利用 roots() 等函数（如 all:roots(main..@)），可一键将所有功能分支的根部提交变基到主分支（如 main）上。
• 重组提交：在合并提交上产生新变更后，使用 jj rebase -r 将其提取到独立分支；或使用 jj new --after 结合 jj squash 将变更精确移入特定的分支臂中。

冲突处理机制

• Jujutsu 记录完整的冲突元数据。移动提交引发冲突时，系统会生成包含差异（Diff）和快照（Snapshot）的特殊冲突标记。
• 手动解决子分支冲突后，若导致上层合并提交因丢失合并元数据而显示冲突，可通过 jj restore 从变更前的状态恢复文件，从而消除合并提交中的冲突。

总结

该工作流极大提升了多分支并行开发的效率，避免了传统 Git 在分支切换时的繁琐操作。其“在同一工作目录处理多个逻辑分支”的理念与 GitButler 等现代工具的“虚拟分支”功能不谋而合，是处理复杂提交图的强大方案。

Google Arts & Culture 网站功能概览

该网站是一个综合性数字文化平台，主要提供以下内容和功能：

1. 艺术探索与发现

• 按主题探索：提供“今日精选”、“从档案馆”、“为你推荐”等板块，展示全球艺术品与文化珍宝。
• 按颜色探索：支持通过颜色发现超过10万件艺术品。
• 按时间探索：涵盖从古代文物到当代艺术的各时期作品。
• 按地点探索：包括那不勒斯街头艺术、芝加哥博物馆等特定地点或机构的文化内容。

2. 博物馆与藏品浏览

• 虚拟博物馆参观：例如费城艺术博物馆的线上藏品展示。
• 机构与文化主题：涵盖庆祝LGBTQI+文化的组织（从悉尼到旧金山）以及世界博物馆巡礼。
• 特色收藏：如“摇滚艺术”（史前艺术）和“太空图像”（哈勃望远镜拍摄的图片）。

3. 交互体验功能

• 增强现实（AR）口袋画廊：通过AR技术虚拟步入画廊。
• 街景视图：支持从巴黎歌剧院后台到泰姬陵顶部的虚拟漫游。
• 3D探索：提供立体视角欣赏艺术品。
• 音乐与音频导览：由知名音乐人解说名画，或收听大师作品的音频导览。
• 机器学习连接：通过算法揭示不同文化间的关联（如Kara Walker与帆板运动的联系）。

4. 特色内容板块

• 文化挑战：如猜谜游戏“哪个不是非洲‘五大’动物？”。
• 居家旅行推荐：提供沙发旅行指南和世界各景点虚拟访问。
• 日常生活与艺术关联：例如“从艺术到现实”通过熟悉名画探索文化，或全球帽子文化展示。
• 个性化订阅：用户可订阅“文化周刊”获取定制内容更新。

5. 社区与艺术家聚焦

• 推荐全球艺术家，帮助用户发现新喜好。
• 提供“街头艺术”、“隐藏细节”等专题，从新视角解读绘画。

总结：该网站通过多元化的主题分类、交互技术（如AR、3D、街景）和个性化推荐，让全球用户在线探索艺术、历史与文化藏品，并连接现实与虚拟的文化体验。

该研究构建了一个名为“Newswire”的大型结构化数据库，旨在重现美国过去一个世纪的新闻电讯社历史档案。数据库通过一个定制的深度学习流程处理了数千种地方报纸的数百TB原始图像扫描件，最终包含270万篇于1878年至1977年间撰写、且属于公共领域的独特美国新闻电讯文章。

数据库不仅包含文本，还提供了丰富的结构化元数据：文章中的地理位置经过地理参照；主题通过定制的神经网络主题分类器进行标记；使用命名实体识别技术识别人名等实体；并通过一种新颖的实体消歧模型将人物信息链接到维基百科。

构建过程主要包括几个关键步骤：首先从原始扫描件中识别报纸版面并转录出约1.38亿条结构化文章文本；然后利用定制的神经网络双编码器模型对被复制的文章进行去重，即便存在大量删节和噪声，也能量化每篇文章的传播范围；接着使用文本分类器确保仅收录历史上属于公共领域的新闻电讯文章。

该数据集附带了关于刊登这些文章的报纸的美国国会图书馆元数据信息。其结构化数据为研究提供了关于新闻事件的“人物”、“主题”和“地点”的丰富信息。

该Newswire数据集具有双重重要性：一方面，它可以扩展大型语言模型的训练数据，超越现代网络文本的范畴；另一方面，它为计算语言学、社会科学和数字人文学科的多领域问题研究提供了宝贵资源。

程序员不应信任任何人，包括他们自己

本文阐述了程序员为何应对代码正确性保持怀疑态度，并探讨了抽象概念的本质、局限性以及应对策略。

代码正确性验证的困难

编写正确的代码很难，验证其正确性则近乎不可能，主要原因包括：

• 普遍性：代码即使在某次运行正确，也无法保证在所有情况下、所有机器上、所有时间都正确。
• 假性通过：测试失败表明存在缺陷，但测试通过并不能保证没有缺陷。
• 缺乏确定性：为代码正确性编写形式化证明后，还需验证该证明本身是否正确，此验证链永无止境。

追求代码正确性的绝对确定性是徒劳的，但可以通过加深理解和尽职调查来降低缺陷风险。

抽象的认知本质

抽象是一种心智模型，是将事物A视为事物B的思维过程，类似于大脑的数据压缩或“只见森林，不见树木”。在编程语境中，它特指认知层面的简化视图。

示例：

• 将银行存款视为银行仅为我们保管资金（而实际上银行会贷款或投资大部分存款）。
• 将时间视为对所有人匀速流逝（而实际上相对论的时间膨胀效应存在，GPS卫星需每日校时约38微秒）。
• 驾驶员将汽车简化为：点火启动、油门前进、刹车停止、方向盘转向、需要燃油。

编程语言本身就是抽象：它们隐藏了硬件细节（如CPU指令、寄存器）和操作系统细节（如调用栈、内存管理），并提供了跨平台移植性。

抽象的失败与“泄漏”

抽象并非完美，所有非平凡的抽象都在一定程度上存在泄漏。这意味着简化模型在特定情况下会失效。

在编程中的体现：

• 关心性能时，必须了解硬件和操作系统细节。
• 移植有外部依赖的程序时，需额外配置。
• 仅了解最低限度的驾驶员，可能因疏于保养而损坏汽车。

当抽象失败时，有时会导致程序崩溃（易处理），有时则引发未定义行为或性能下降（难排查）。

应对策略：信任但验证

程序员应采取“信任但验证”的策略：

1. 信任信息，但用文档核实。
2. 通过尝试证伪来测试自己的信念。例如：
   • 为代码修改编写测试且首次通过后，尝试在不修改代码的情况下运行测试，检查测试本身是否总能通过。
   • 重构代码（应为无效操作）后所有测试仍通过，需确认是否有测试覆盖了重构的代码。
   • 优化服务后资源利用率下降，需确认当前是否只是请求量减少了。
   • 提交代码修改后未发现问题，需确认当天是否实际进行了部署并包含了你的代码。
3. 优化代码时务必测量实际影响，理论上的加速可能因底层抽象因素而变慢。

警惕“未知未知”

程序员面临的最可怕认识论问题是“未知未知”（即自己不知道自己不知道什么）。它们是抽象失败的根本原因，也是项目工期无法准确预测的根源。

示例（如果你从未听说过）：

• 输入净化：使用用户提供的字符串直接进行SQL查询可能导致SQL注入攻击。
• 字符编码：处理文本数据时必须考虑编码（ASCII， UTF-8等），否则可能导致随机访问效率差异或输出乱码。
• Java堆大小：堆内存不足可能导致程序变慢，但需要知道如何配置最大堆尺寸。

应对未知未知：无法确保完全捕获，但应至少探查一层抽象之下的情况。特别是学习新技术时，应学习超出即时需求的内容。

具体方法：

• 阅读超出最低需求的文档。
• 观看会议演示等高质量视频。
• 阅读博客和源代码。
• 深入了解所用抽象：学习编程语言的新特性、浏览库的所有公共函数、查看CLI工具的所有参数。
• 学习至少一层更底层的抽象：了解编译器优化、编排平台（如Kubernetes）、JVM或Python解释器等。

结论

抽象是思维效率的必要工具，但它们具有欺骗性，会让人误以为已了解“足够多”。肤浅学习的程序员将难以应对需要多领域专业知识且无现成解决方案的难题。

然而，这一理想需与现实平衡：时间紧迫时无法学习一切，初学者也难以做到如此全面。理想应与实际考量相权衡，但我们也应愿意为彻底的学习和验证付出短期成本——这不仅是为了编写正确的代码，更是为了成为有能力、有原则的工程师的长期旅程的一部分。

文章总结：停止在面试中提问“你为什么想为我们工作”

本文针对面试中常见的“你为什么想为我们工作”这一问题提出了批评，并阐述了其观点：

• 普遍现象：作者在求职过程中多次遇到该问题，认为这已成为一个惯例性提问。
• 核心观点：作者指出，人们想要为一家公司工作的首要且压倒性的原因是金钱。即为了支付账单、房租/房贷、偿还债务、养家糊口以及获得更好的生活。虽然技术栈、产品或工作与生活的平衡可能是吸引力，但经济保障始终是根本驱动力。
• 论证：作者提出一个思想实验：如果将一位最具热情的工程师的薪酬减半，他是否还会留下？答案几乎是否定的，这用以证明薪酬的核心地位。
• 呼吁坦诚：作者认为，既然所有人心知肚明，继续提问这个问题只会导致候选人不得不说谎或给出套话（如“想和优秀的人共事”、“寻求成长机会”）。而作者自身申请工作的主要动机（99%）也是为了赚钱生活。
• 结论与建议：作者认为，受金钱驱动是正当且普遍的，不仅个人如此，公司本身也以盈利为目的。因此，他建议在申请和面试流程中停止提出这个问题，并呼吁双方进行更真诚的沟通。

文章最后提到此讨论在 Hacker News 上进行。

这篇文章《What Goes Around Comes Around... And Around...》回顾了自2005年以来近二十年数据库领域的演变，核心论点是关系模型（RM）与SQL作为主导范式依然稳固。尽管期间不断涌现试图取代它们的新技术和数据模型（如NoSQL、向量数据库等），但SQL通过吸收这些创新思想而不断扩展，大多数非关系系统要么已消亡，要么服务于小众市场，要么正朝着与关系系统融合的方向发展。

主要分析内容如下：

1. 数据模型与查询语言的演变 文章分析了八类非关系系统，结论均指向SQL和RM的持续主导：

• MapReduce系统：曾因大数据热潮兴起（如Hadoop），但因性能、灵活性和生态问题而式微，已被更现代的系统取代。
• 键值（KV）存储：作为简单缓存或嵌入式存储有价值，但功能有限。许多KV存储已演进为支持更复杂数据模型，或被功能全面的关系数据库在性能上超越。
• 文档数据库：（如MongoDB）曾以NoSQL之名挑战SQL，但现在几乎都添加了SQL接口和ACID事务支持，与关系系统的差异正在缩小。
• 列族数据库：（如Cassandra）源自Google BigTable，是一个小众市场，其SQL接口（如CQL）也逐渐普及。
• 文本搜索引擎：（如Elasticsearch）在全文检索方面专业，但主流关系数据库也具备了相应能力，常作为多存储架构中的一部分。
• 数组数据库：主要服务于特定科学计算领域，关系数据库通过SQL标准（如SQL/MDA）的扩展正逐步增强对此类数据的支持。
• 向量数据库：为AI嵌入向量的相似性搜索而兴起，但其核心是专用索引技术。主流关系数据库已迅速集成向量索引功能。
• 图数据库：关系数据库通过SQL扩展（如SQL/PGQ）能够有效模拟图操作，性能测试显示其往往更优，专用图数据库的市场预期有限。

2. 系统架构的创新 近二十年在数据库实现层面有重大变革，主要受应用需求和硬件发展驱动：

• 列存储系统：彻底革新了OLAP（数据仓库）市场，因其在压缩、向量化执行和存储效率上的优势，已成为数据仓库的标准架构。
• 云数据库：云计算（尤其是对象存储的普及）促使数据库架构从共享内存/磁盘转向存算分离的“无服务器”模式，实现了弹性扩展和按需付费。
• 数据湖/湖仓一体：数据存储从专用数据仓库转向基于廉价对象存储的开放格式（如Parquet、ORC），并发展出“湖仓一体”架构来统一管理。
• NewSQL系统：试图融合NoSQL的扩展性与关系模型的ACID事务，虽推动了分布式SQL数据库的发展，但整体市场影响不及前两者。
• 硬件加速器：利用GPU、FPGA等加速查询的想法持续存在，但因成本、集成难度和云经济的可行性，其成功可能仅限于大型云厂商。
• 区块链数据库：被视为效率低下的技术，目前仅加密货币等极少数去信任场景是其合理用例，企业级应用难以接受其性能代价。

总结与预测 作者强调，历史教训值得注意：要警惕过度营销的次级产品、大型非数据库厂商开源的不成熟系统，并需重视数据库的“开箱体验”。AI/ML（尤其是大语言模型）将对数据库产生深远影响，但自然语言查询不会取代SQL，而更多会作为探索性分析的辅助工具。

文章最后预测，未来几十年仍将循环上演类似剧情：新的开发者会宣称SQL和RM不足，并提出新模型。探索新思想有价值，但关系模型不会被取代。作者呼吁社区致力于开发可重用的开源组件，以加速下一代数据库的发展。

OpenSSH 9.8 版本发布摘要

核心安全修复

1. 严重漏洞 (sshd 竞态条件)：

   • 影响范围：Portable OpenSSH 8.5p1 至 9.7p1 版本。
   • 风险：可能导致以 root 权限执行任意代码。
   • 利用情况：在 32 位 Linux/glibc 系统（开启 ASLR）上已被证实可利用，平均需要 6-8 小时持续连接。理论上 64 位系统也可能受影响，但尚未演示。OpenBSD 不受影响。
   • 致谢：由 Qualys 安全团队发现并报告。

2. 次要漏洞 (ObscureKeystrokeTiming 逻辑错误)：

   • 影响范围：OpenSSH 9.5 至 9.7 版本（客户端）连接 9.5 及以上版本服务器时。
   • 问题：ObscureKeystrokeTiming 功能（默认开启）失效，被动观察者可区分真实和虚假按键数据包，从而检测按键时序。
   • 附带影响：该漏洞还破坏了自 OpenSSH 2.9.9 起用于隐藏密码输入时序（如 su/sudo 场景）的虚假回声机制，虽信息粒度有限（约 20 毫秒）。
   • 致谢：由多位研究人员独立发现并报告。

未来弃用计划

• 算法：计划在 2025 年初完全移除 DSA 签名算法支持。
• 原因：DSA 算法强度弱（160 位私钥，SHA1 摘要，安全级别仅等效于 80 位对称加密）。
• 当前步骤：本版本已在编译时默认禁用 DSA。如需启用，OpenBSD 需在 Makefile.inc 中设置 DSAKEY=yes，Portable 版本需配置时使用 --enable-dsa-keys 选项。

不兼容变更与重要改动

1. DSA 默认禁用：如上所述。
2. sshd 客户端地址惩罚机制：
   • 新增 PerSourcePenalties 配置（默认启用），服务器将自动惩罚反复认证失败、连接后不认证或导致服务器崩溃的客户端地址。
   • 惩罚机制会阻止来自该地址（及同一 CIDR 范围内）的后续连接，直至惩罚时间结束。重复违规将增加惩罚时长。
   • 可通过 PerSourcePenaltyExemptList 豁免受信任地址。
3. sshd 架构变更：
   • 拆分为监听器 (sshd) 和每会话处理程序 (sshd-session)，以减小监听器二进制文件体积。
   • 移除了禁用特权分离和重新执行 sshd 的支持。
4. 日志变更：部分日志消息的来源进程将显示为 sshd-session。
5. ssh-keyscan 输出变更：原先输出到标准错误的注释行现输出至标准输出，新增 -q 选项可静默输出。
6. PAM 服务名：（仅限 Portable 版）sshd 不再使用 argv[0] 作为 PAM 服务名，新增 PAMServiceName 配置指令（默认为 sshd）。
7. 版本控制：（仅限 Portable 版）自动生成的文件（如 configure）将被提交到 Git 发布分支，以确保与签名发布包内容一致。

新功能

1. PerSourcePenalties 惩罚机制：如上所述，旨在增强暴力破解和漏洞利用防御能力。
2. HostkeyAlgorithms 指令增强：允许禁用从证书主机密钥到普通主机密钥的隐式回退。

缺陷修复与可移植性改进

• 缺陷修复：涵盖文档校正、整数解析、信号处理、密钥验证、提示刷新、主目录扩展、输入流处理、重协商测试等多个方面。
• 可移植性改进：
  • 无条件向 PAM 认证模块暴露 SSH_AUTH_INFO_0。
  • 修复 OpenSSL ED25519 支持检测。
  • 允许 WAYLAND_DISPLAY 环境变量触发 SSH_ASKPASS。
  • 改进编译器标志检测和 OpenSSL 版本检查。
  • 为 systemd 集成添加独立通知支持。

校验和与资源

• 提供了 openssh-9.8.tar.gz 和 openssh-9.8p1.tar.gz 的 SHA1 及 SHA256（Base64 编码）校验和。
• PGP 签名密钥可从镜像站点获取。
• 安全漏洞报告应直接发送至 openssh@openssh.com。

本文提出一个受AI语言模型启发的数字心智概念模型，旨在解释或实现类似人类心智的关键功能。模型的核心是一个行动模型，它接收上下文信息并输出下一个“行动”（包括说话、身体动作、思考等）。整体架构是一个数据流图，包含多个并行模块：

• 感觉输入与运动控制：分别处理感知输入和执行高层动作指令。
• 情绪状态：代表身体需求和心理状态，影响注意力与记忆存储。
• 近期记忆：存储经过行动模型注意力机制和情绪状态双重过滤后的近期事件（包括外部事件和内部思想）。
• 目标：作为行动模型输出的一部分反馈回自身，指导信息过滤和行为。

模型旨在实现四大功能：

1. 主动性：通过使模型能持续感知外部输入并同时接收自身输出反馈，使其能自主决定何时“倾听”或“行动”，而非被动响应。
2. 学习：分为故事记忆（事件记录）和行动记忆（基于反馈修正行为）。近期记忆模块暂存新经历，避免灾难性遗忘。学习类似于神经网络权重更新或键值对记忆的更新（较难删除“键”，但可更新“值”）。
3. 思考：通过行动模型输出的内部反馈循环实现。可模拟预测未来、创造力（类似稳定扩散的去噪过程）和问题解决。高级思考模式（如模式识别、内部心理词汇、内心语言、元认知协议）从低层机制中涌现。
4. 内省：将思想和感受本身也作为事件记录在故事记忆中，从而能够回顾和报告自己的思维过程。情绪意识并非自动发生，模型可以在有情绪的同时缺乏对该情绪的觉知。

关于意识，作者避免使用其模糊定义，而是将其视为一系列更易定义的功能的集合。他倾向于关注“人格”——使我们成为人的行为与体验。文章通过积极论证回应主观体验的质疑，认为模型内部的向量表示（如对应“红色”感觉的向量）可视为对主观体验的科学解释起点。最后，作者展望了构建具备数字人格、可能更成熟、更有同理心的心智的未来。

《编织者与结论者：两种沟通风格》摘要

核心概念

文章提出在自闭症（及部分其他神经多样性群体）社区内部，存在两种主要的沟通风格：结论者 和 编织者。

结论者

• 占大多数。
• 沟通时带有明确的目的或观点。
• 风格多样：可以是直接坦率的，也可以是间接含蓄的，或像讲故事一样迂回，但最终都旨在表达一个“要点”。
• 当对方发言时，预期对方也在推进某个明确的观点。

编织者

• 占少数。
• 沟通时没有预设的目的地，并非为了得出一个结论。
• 目的是共同编织一幅多维度的图案。他们通过陈述事实，希望对方也以事实回应，这些事实作为“锚点”交织在一起，形成模式。
• 他们的交流像是开放式邀请：“你的经历和我的经历有什么关联？”
• 很少提问（除了事实澄清），因为提问可能会干扰对方想编织的图案。他们更倾向于陈述自己的事实，来含蓄地邀请对方分享。
• 当对方回应另一个事实时，这被视为一种情感上的共鸣和连接，而非冷漠或转移话题。

核心差异与冲突

• 结论者 习惯寻找对话的“要点”和终点。
• 编织者 寻求建立连接和模式。
• 当两种风格的人交流时，容易产生严重误解：
  • 结论者可能认为编织者“说话没有重点”、“以自我为中心”或“缺乏同理心”。
  • 编织者可能觉得结论者的问题过于侵入性、单刀直入，或打断了他们试图构建的图案。
• 这种差异导致社交中的“错过连接”，造成情感伤害和长期的孤独感。

编织者的特点

• 可能与自闭症、注意力缺陷多动障碍（ADHD）、阅读障碍等神经多样性特征相关。
• 作者推测他们可能是右脑主导的语言学习者，擅长以模式和联系而非线性逻辑来处理语言。
• 通常拥有出色的情景记忆，能记住对个人有特殊意义的小细节和过往互动。
• 沟通中大量使用引用（电影、书籍、歌曲、历史事件等）作为事实的锚点和共享理解的基石。

理论说明

• 该理论基于作者的个人观察和经验，并在神经多样性社群中经过数年非正式验证，并非经过科学实证研究验证的理论。
• 文章强调，即使这两种风格存在，也可能有其他混合或不同的沟通风格。
• 作者提出此理论旨在帮助人们理解沟通差异，减少误解，并引发社群内的讨论。

后量子密码学：量子计算机并非关键

后量子（PQ）密码学的重要性常被误解为仅与量子计算机相关，但实际上，即使量子计算机从未出现，后量子标准也比传统密码学更安全、更具弹性和灵活性。当前公钥密码学面临多重风险，而后量子密码学通过多样化设计、现代改进和灵活用例提供了更稳健的解决方案。

当前公钥密码学的脆弱性

• 问题集中：主流公钥算法（如RSA、Diffie-Hellman、ECDH/ECDSA）均基于隐藏子群问题，量子计算机可能高效破解，但即使无量子进展，这种集中也带来风险。
• 历史教训：过去40年，整数分解和离散对数算法的进展迫使密钥长度不断增加（如RSA从664位增至2048-4096位），早期“安全”密钥现已被破解。
• 实现陷阱：现有算法实现复杂，易受侧信道攻击、参数选择错误等影响，开发者常需依赖高质量库以避免“自伤”。

后量子密码学的优势

• 多样化基础：NIST标准化的后量子算法基于多种数学问题，如格问题（CRYSTALS-KYBER）、哈希函数（SPHINCS+）和编码理论，降低单一问题被破解的风险。
• 现代设计：新算法融入实践教训，注重常数时间实现、减少随机数生成器依赖、确定性输入以避免随机数重用问题，并预定义安全参数。
• 用例灵活：不同算法提供权衡选项，如哈希签名密钥小但签名大，编码系统密钥大但解密快，适用于嵌入式设备、服务器农场等多样场景。

不确定性与权衡

• 潜在风险：后量子算法较新，可能像RAINBOW和SIKE一样被破解，但当前算法也无数学安全证明，类似突破已发生在传统密码学中。
• 过渡方案：可采用混合密码系统，结合后量子和传统方法，确保两者均安全时数据受保护。

总结

后量子密码学不仅是量子抵抗的工具，更是密码学的多样化和现代化努力。它通过多元问题基础、改进设计和灵活应用，解决了当前密码学的集中风险和实现难题，为未来提供更稳健的加密基础。

2020年初，Target旗下的即时配送公司Shipt悄然更改了其零工工人的薪酬算法，导致众多工人收入下降。此前，Shipt采用的公式透明（每单5美元基础费+订单金额的7.5%），但新算法基于包括订单金额、预估购物时间、行驶里程在内的“努力程度”来计算薪酬，且具体细节不公开，形成了一个“黑箱”。

工人们（以Willy Solis为首）并未默默接受，而是开始通过Facebook等社群组织起来，收集工资截图以调查薪酬变化。为解决手动收集数据效率低下的问题，他们与非营利组织Coworker及MIT媒体实验室的数据科学家合作，开发了一个名为“购物者透明度计算器”的短信工具。

该工具利用光学字符识别（OCR）技术解析工人通过短信发送的工资截图，自动提取薪酬、小费、时间地点等数据并存储分析。通过收集超过200名工人提供的5600多张截图进行分析，项目发现：新算法导致40%的工人工资下降，其中半数减薪幅度达10%或以上；约三分之一的工人收入低于其所在州的最低工资标准。

工人们利用这些数据引起了媒体关注，并组织了罢工、抵制和在Shipt及Target总部的抗议活动，要求恢复透明的薪酬公式。然而，Shipt公司仅给出了关于算法基于“努力程度”的模糊回应，未与工人直接对话，抗议活动的最终效果尚不明确。

此案例展示了零工工人如何通过集体行动、数据收集和技术工具，挑战算法管理的不透明性，争取自身权益。文章进一步指出，算法管理已成为更广泛的职场问题，欧盟已出台《平台工人指令》等法规尝试规范，纽约市也为零工设定了最低工资。作者认为，零工工人争取数据权利和算法透明的斗争，是关乎所有工作者未来权利的前沿阵地。

Conway生命游戏在曲面上的扩展：平滑生命游戏（SmoothLife）

经典生命游戏（GoL）简介

康威的生命游戏是一个著名的元胞自动机。其世界是一个无限的矩形网格，每个细胞有两种状态：存活或死亡。每个细胞的邻居是其周围3x3的网格。系统按照离散的同步时间步进，规则如下：

1. 存活细胞：若邻居数为2或3，则继续存活；否则死亡。
2. 死亡细胞：若邻居数恰好为3，则复活；否则保持死亡。

尽管规则简单，生命游戏能产生如“滑翔机”等复杂且持久的模式。它是图灵完备的，理论上可以在其中模拟任何计算机。

平滑生命游戏（SmoothLife）的核心思想

平滑生命游戏是康威生命游戏在连续域上的推广，其主要目标是消除离散网格，实现旋转和平移不变性。该推广基于Stefan Rafler的论文，包含两个核心概念：

1. 有效网格（Effective Grids）

• 概念：用定义在连续平面上的标量场f(x,t)替代离散网格。细胞具有一个有限的半径h（类似于“普朗克长度”）。
• 细胞状态：一个点x处的“有效细胞”状态M(x,t)是f在以x为中心、半径为h的圆盘上的平均值。
• 邻居数量：一个细胞的有效邻居数N(x,t)是f在以x为中心、内半径h、外半径约3h的圆环内的平均值。
• 优势：M和N在连续平移和旋转下保持不变，为系统的对称性奠定了基础。

2. 平滑过渡函数（Smooth Transition Functions）

需要将离散的生命规则平滑化为适用于连续M和N值的函数。

• 离散规则表示：经典规则可表示为一个依赖于M（细胞状态）和N（邻居数）的二元函数S。
• 平滑化方法：使用sigmoid函数（特别是逻辑sigmoid函数）来创建S的平滑近似。
  • 定义阈值：细胞状态M > 0.5视为存活，M < 0.5视为死亡。
  • 使用sigmoid在存活/死亡状态间进行平滑切换。
  • 使用sigmoid对N的特定区间进行平滑阈值处理，以选择不同的行为。
• 最终过渡函数：构造一个平滑的S(N, M)函数，它根据M当前的存活/死亡状态，在对应于存活和死亡行为的N的参数区间之间进行选择。此过程引入了控制生死区间边界和sigmoid锐度的多个参数。

时间推进与离散化实现

时间步进方案

• 离散时间步：最简单的方法，但破坏了连续性精神。
• 微分方程：将更新规则写为微分方程df/dt = S(N,M) - f，实现连续时间演化。但直接应用可能导致数值不稳定。
• 实用方案：采用指数松弛法f(t+1) = f(t) + (S(N,M) - f(t)) * Δt，将场值推向目标状态S(N,M)，通常效果更稳定。

场离散化与数值计算

为在计算机上实现，必须将连续场f离散化。

• Galerkin方法：将f近似为一组正交基函数φ_k的线性组合，系数为c_k。目标是求解下一时间步的系数。
• sinc插值基函数：对于周期性场，使用归一化的sinc函数（Dirichlet插值）作为基函数非常有效。根据奈奎斯特采样定理，系数c_k直接对应场在均匀网格点上的采样值。
• 利用傅里叶变换加速：计算M和N的卷积操作在傅里叶域中变为乘法。因此，高效的计算流程为：
  1. 对场f进行快速傅里叶变换（FFT）。
  2. 在频域中与预先计算好的、依赖于h的Bessel函数相关滤波器相乘。
  3. 进行逆FFT得到M和N的网格值。
  4. 应用平滑过渡函数S(N,M)得到新状态。
  5. 进行下一时间步的计算。

边界条件

为了使无限空间的计算可行，通常施加周期性边界条件，将模拟限制在一个矩形区域内，并在边界处重复该区域。

演示与展望

作者提供了基于傅里叶方法和基于GPU的WebGL实现的在线演示。文章预告了后续内容将涉及如何为曲面实现平滑生命游戏。

根据提供的内容，该文本是一个错误消息，表明在访问x.com时出现了问题。主要点是：网站显示错误，可能由于隐私相关扩展导致，建议用户禁用这些扩展后重试。

Python编程用于任天堂8位游戏机（2018）

本文介绍了PyNES项目——一个旨在将Python代码编译为任天堂8位游戏机（NES）可执行程序的工具。作者以传奇的口吻开场，将早期游戏卡带制作比作在“末日火山”中锻造，其秘密被核心程序员群体所掌握。作者童年时期对游戏制作充满好奇，渴望体验先驱们面临的挑战，并决定通过创建自己的工具来追随他们的脚步。

PyNES最初是一个普通的6502汇编器。然而，作者认为直接用汇编语言编写游戏不够有趣，于是尝试利用AST（抽象语法树） 技巧，探索将Python代码转换为6502汇编代码的方法。这被形容为一项疯狂的任务，因为要将像Python这样高级的语言编译到6502这样有限的处理器上。

0.1.x版本作为一个概念验证发布，但存在多项限制，包括：

• 精灵碰撞检测
• 屏幕滚动
• 精灵动画
• 更好的手柄支持
• 难以扩展

为克服这些限制，0.2.x版本对项目进行了重大重构。项目被拆分为四个独立部分：

1. lexical：词法分析器。
2. nesasm_py：基于NESASM的6502汇编编译器。
3. pyNES：主项目，职责更聚焦。
4. pyNES_StdLib：标准库。

新版本遵循三个核心原则：

1. 不再使用模板。
2. 缩小所写代码与编译器行为之间的差距。
3. 更易于扩展。

文章最后通过一个waitvblank函数的示例，展示了高级函数（使用@asm_function装饰器定义）如何被转换为对应的6502汇编指令。

安装与使用：用户可通过克隆仓库并运行sudo python setup.py install来安装。示例位于pynes/examples目录，可使用pynes py pynes/examples/helloworld.py -o helloworld.nes命令进行编译，生成的.nes文件即可在模拟器中运行。

核心概述

Nintendo Switch 搭载的 Tegra X1 SoC 配备了独立的硬件视频编解码引擎，支持 H.264 和 HEVC 格式。测试基于 Linux 环境及 Nvidia 定制的 ffmpeg 进行。与桌面级 Maxwell 架构相比，Tegra X1 的视频引擎在设计和功能上有显著差异，专为低功耗移动设备优化。

解码性能 (Decode)

• H.264：Tegra X1 支持 4K 60FPS 解码，但吞吐量不及桌面 Maxwell，推测是为缩小芯片面积而做出的妥协。
• HEVC：Tegra X1 具备硬件 HEVC 解码能力，弥补了桌面 Maxwell（如 GTX 980 Ti）缺失该功能的遗憾。

编码性能 (Encode)

• H.264：Tegra X1 不支持恒定量化（CQ），仅支持可变比特率（VBR）。其比特率控制非常精准，而桌面 Maxwell 和 Intel QuickSync 常低于目标值。在编码效率上，Tegra X1 略逊于后两者，但转码速度不受目标比特率影响。最高画质下均可满足 4K 30FPS 编码，对 Switch 的 720P 屏幕已绰绰有余。
• HEVC：在 HEVC 编码中，Tegra X1 同样保持了精准的比特率控制。在修正实际比特率差异后，其压缩效率与桌面 Maxwell 相当，且编码速度更具优势。相比之下，Intel QuickSync 的 HEVC 表现较差。

画质表现对比

• Tegra X1：文字边缘清晰，但高对比度边缘有轻微光晕；倾向于保留细节，但在平滑渐变区域（如蓝天、岩石）易产生压缩伪影。
• 桌面 Maxwell：高对比度边缘有色彩伪影，但倾向于牺牲部分细节以换取画面的平滑，减少渐变区域的伪影。
• Intel QuickSync：画质最差，存在明显的块状效应、模糊和细节丢失。

架构差异与结论

Tegra X1 并未直接复用桌面 Maxwell 的视频模块，而是采用了全新设计的视频引擎。它削减了部分解码吞吐量和 H.264 编码特性，但大幅优化了 HEVC 支持（编解码更全面且速度更快）。这种差异化设计很可能是为了将功耗严格控制在 10W 左右。Nvidia 为移动端和桌面端分别研发两套视频引擎，且均展现出优于同时期 Intel 核显的压缩效率，体现了其强大的工程研发实力。

LuggageLosers.com 是一个实时追踪各航空公司行李丢失情况的网站，由 @levelsio 创建。其核心数据基于对全球社交媒体和网站上海量用户讨论的持续抓取与分析（覆盖100多种语言），并结合历史行李丢失数据进行估算，以提供相对排名。数据最后更新于文章发布前5天，来源数量超过3.8万个。

网站的主要内容和功能包括：

1. 航空公司行李丢失排名

• 排名指标：包括行李丢失/延误的概率估计、与过去7天的变化对比、行李评分（满分5分）、过去30天的投诉数量以及估计的丢失行李数量。
• “最大输家”：英国航空（British Airways）位列榜首，其次是靛蓝航空（IndiGo）和香料航空（SpiceJet）。丢失概率最高。
• “最大赢家”：全日空（ANA）表现最佳，其次是阿祖尔航空（Azul）和日本航空（JAL）。丢失概率最低。

2. 机场行李丢失排名

• 同样基于估算概率对机场进行排名。印度孟买的希瓦吉机场（Shivaji）丢失概率最高，其次是德里的甘地机场（Gandhi）和比利时布鲁塞尔机场。

3. 按地区与国家分类的统计

• 地区：非洲的行李丢失概率最高，大洋洲最低。
• 国家：印度的行李丢失概率远超其他国家，日本最低。

4. 网站背景与方法论

• 起源：源于作者个人经历——其女友的行李箱被Vueling航空丢失后，经历艰难寻找过程。
• 目的：帮助旅客选择行李处理可靠的航空公司，并鼓励表现良好的航空公司。
• 工作原理：通过自动化爬虫程序全天候扫描网络讨论，评估并估算各航司的行李丢失情况，并已考虑航空公司与机场的规模差异。
• 局限性：航空公司不公布实时数据；社交媒体数据仅为代理指标，估算值可能与官方后期发布的实际数据有出入。
• 后续计划：随着数据积累，未来计划增加图表和增长率等趋势分析功能。

5. 行李丢失原因与行业背景

• 网站解释，行李丢失问题在很大程度上源于航空公司和机场为追求利润和廉价机票，而压低地勤人员薪资，导致人手短缺、工作质量下降。同时，航班负荷创历史新高，使得行李处理环节易出错（如贴错标签、装错飞机）。
• 寻回丢失行李的服务体系同样因人手不足和过劳而效率低下。

6. 其他信息

• 网站确认，长期未被认领的行李（通常在21天后）确实会被航空公司拍卖。
• 给旅客的建议是：参考此网站的排名，选择行李丢失率低的航空公司以规避风险。
• 网站声明其信息仅供参考，使用者需自行承担风险。

LLVM 19对集成汇编器（MC层）进行了重大优化和重构，旨在提升性能、降低内存消耗并简化代码结构。主要改进包括内部表示优化、布局算法改进、符号与节处理优化、目标特定功能整理以及新功能支持。

核心改进：内部表示与性能优化

• 合并MCAsmLayout：将紧密耦合的MCAsmLayout类合并到MCAssembler中，移除了额外的间接调用和参数传递开销，简化了代码并降低了编译时间。
• 优化Fragment管理：
  • 减小了MCDataFragment和MCRelaxableFragment等关键数据结构的内存占用。
  • 将Fragment列表从双向链表改为单向链表，移除了不必要的反向迭代器。
  • 引入“当前Fragment”概念（MCStreamer::CurFrag），加速了新Fragment的追加操作。
• 改进布局算法：用主动（eager） Fragment松弛和偏移量计算替代了原有的懒惰（lazy）算法。新算法按节逐个处理，当某节的松弛不再变化时便跳过后续迭代，避免了各节等待最慢收敛节的问题，显著降低了全程序优化（LTO）的编译时间。
• 优化符号处理：移除了对未命名符号名称的不必要求值，并通过重构“待处理标签”系统直接调整现有Fragment的偏移量，消除了易出错的复杂逻辑（如flushPendingLabels），减少了超过100行代码。

结构简化与代码清理

• 节处理改进：利用“当前Fragment”概念简化了节栈（用于.push_section/.pop_section）的使用，减少了间接调用和空值检查。同时，重新设计了节符号（Section Symbol）的处理方式，使其更一致。
• 表达式求值简化：移除了复杂的惰性求值算法和递归检测逻辑（如MCFragment::IsBeingLaidOut标志），使布局过程更可靠。
• 目标特定功能整理：将大量混杂在通用代码中的目标特定逻辑（如Mach-O、ELF、XCOFF的特性）迁移到各自的目标实现文件中（如MachObjectWriter、AArch64TargetELFStreamer），并清理了类层次结构。

新功能与扩展支持

• 支持ELF的CREL（紧凑重定位）：集成汇编器现已支持实验性的CREL格式，可通过特定选项启用。
• 汇编解析器增强：.irp/.irpc/.rept宏现在支持每次调用的计数器（\+）。.altmacro模式支持参数扩展。增加了对.cfi_label指令的支持。

性能提升数据

通过对预处理后的SQLite Amalgamation进行编译测试，LLVM 19的改进带来了明显的编译时间下降，尤其在-O0和-g选项下效果显著：

• -O0 编译时间减少约7%。
• -O0 -g 编译时间减少约10%。
• -O2 和 -O2 -g 编译时间也有2-3%的降低。

此外，针对AsmPrinter的每指令开销优化和MC层的全面改进，也使得重度使用MC的工具（如BOLT）性能提升了约8%。

未来工作方向

• 改进符号重定义的诊断。
• 增强Mach-O汇编器的健壮性（如常量折叠条件和兼容性hack）。
• 探索其他架构（如XCOFF）的节符号处理统一化。

这些全面的优化为LLVM 19带来了显著的性能增益、更低的内存使用和更整洁的代码库，为后续改进奠定了坚实基础。

本文是一篇详细的Python编程教程，旨在通过创建一个粒子运动的动画来模拟气体扩散现象。文章从作者受费曼物理学讲座的启发讲起，重点在于使用Python的turtle模块实现物理概念的可视化，并探讨了代码优化的方法。

核心目标与简化假设 该模拟旨在直观展示气体分子在封闭二维容器中的随机运动、碰撞以及最终达到均匀分布的过程。为了简化实现，做出了以下关键假设：

1. 粒子被简化为二维平面上的完美球体。
2. 所有粒子质量相同。
3. 粒子间的碰撞被简化为完全弹性正碰。
4. 物理过程被简化为基于每帧移动的离散步骤。

代码结构与关键功能 教程通过面向对象编程（OOP）构建了两个主要类：

1. SimulationArea类：表示二维模拟容器。它初始化turtle屏幕，定义边界，并管理屏幕更新和事件循环。后期版本增加了将容器划分为网格单元的功能。
2. Particle类：表示单个粒子。每个粒子拥有位置、速度、颜色等属性。核心方法包括：
   • move()：根据速度更新位置，并处理与容器边界的反弹。
   • check_collision()：通过计算中心点距离判断是否与另一粒子发生碰撞。
   • collide()：处理粒子间的弹性碰撞，通过交换速度实现，并管理碰撞状态以避免同一帧内重复处理。

主要实现步骤与优化

1. 基础动画：首先创建一个SimulationArea，然后生成多个随机位置和速度的Particle对象。在一个主循环中不断调用每个粒子的move()方法并更新屏幕，实现粒子运动动画。
2. 边界碰撞：在move()方法中加入边界检测，当粒子触及容器边缘时反转其速度分量，使其“弹回”。
3. 粒子间碰撞：实现碰撞检测和响应。为了解决同一帧内A→B和B→A重复碰撞导致的“结块”问题，为每个粒子增加一个in_collision_with列表来记录本帧已发生的碰撞。
4. 性能优化（网格法）：基础方法的碰撞检测是O(n²)的，当粒子数量增多时会导致动画缓慢。文章引入了关键的优化：将模拟区域划分为一个网格（例如10x7）。Particle类被修改，使其能够根据位置被分配到特定的网格单元中。在动画循环中，碰撞检测只在每个网格单元内部进行，而非在整个容器内。性能测试表明，此优化将500个粒子的模拟运行时间从87秒大幅降低到约3秒。
5. 扩散可视化与量化：为了演示扩散，教程开始时将容器左半部分粒子设为绿色，右半部分设为橙色。动画显示了两种粒子逐渐混合的过程。最后，通过计算并显示所有绿色和橙色粒子的平均x坐标（其值逐渐趋向0），对扩散过程进行了量化监控。

总结与价值 本教程不仅仅是一个物理模拟，更是一个优秀的Python实战项目。它展示了如何用OOP封装复杂行为，如何逐步构建功能，以及如何通过算法优化（空间分区）显著提升性能。最终实现了一个既能直观演示物理扩散现象，又运行流畅的交互式动画。