llama.ttf：兼具字体与大型语言模型功能的文件

核心概念
llama.ttf 是一个特殊的字体文件，它同时集成了一个大型语言模型（LLM）及其推理引擎。这意味着在支持 WebAssembly（Wasm）的字体渲染引擎中，该字体可以直接运行语言模型并生成文本，无需依赖外部应用程序或云服务。

技术原理

• HarfBuzz 与 Wasm 支持：该项目依赖 HarfBuzz 字体引擎的 Wasm 着色器功能。HarfBuzz 广泛用于 Firefox、Chrome 等应用中，其 Wasm 着色器允许在字体文件内嵌入并执行任意代码。
• 字体中的 AI 模型：llama.ttf 将 LLM 推理引擎（此处采用 Llama 模型）和训练好的参数打包进字体文件。通过特定文本中的“魔法符号”触发伪“连字”（ligatures），从而初始化模型并生成文本。
• 本地化运行：所有计算均在用户设备本地完成，无需联网，保障了数据隐私。

使用方式

• 文件下载：字体文件大小为 60 MB，基于 15M 参数的 TinyStories 模型。
• 环境配置：需在 HarfBuzz 启用 Wasm 支持（编译时添加 -Dwasm=enabled），并配置 Wasm 微型运行时（-DWAMR_BUILD_REF_TYPES=1）。将生成的动态库（libharfbuzz.so 和 libiwasm.so）通过 LD_PRELOAD 环境变量加载，即可在任何基于 HarfBuzz 的应用（如 gedit、GIMP）中使用该字体。
• 应用场景：用户可在文本编辑器、邮件客户端等任何支持 HarfBuzz 的软件中直接通过字体触发文本生成功能，相当于为现有应用集成本地化 AI 助手。

项目意义
该项目探索了字体技术的创意边界，将 AI 模型以“字体”形式分发，绕过了传统软件集成流程，为本地化、轻量级 AI 集成提供了新思路。文中还提及其他类似创意项目，例如：

• 利用 LLM 实现文本格式化的字体方案。
• 基于 HarfBuzz-Wasm 的可编程字体演示。
• 完全在字体中运行的宝可梦风格游戏。

这些案例共同展示了字体文件作为通用代码载体的潜力。

Ruby：优秀的 Shell 脚本编写语言

本文作者指出，Ruby 常常与其最著名的框架 Rails 紧密绑定，导致许多人忽视了其作为编程语言本身的强大之处。作者个人认为 Ruby 是一门优秀的语言，并特别强调了它在编写 Shell 脚本 方面相较于 Bash 和 Python 的优势。文章并非旨在完全取代 Bash，而是在脚本逻辑变得复杂时，推荐使用 Ruby。

以下是 Ruby 适用于 Shell 脚本的七大核心特性：

1. 调用外部命令：使用反引号 ( ` ) 即可方便地执行外部命令，并将输出赋值给变量。
2. 获取状态码：通过 $? 变量可以获取上一个命令的执行状态码，与 Bash 习惯相似。
3. 强类型与面向对象：Ruby 是面向对象且具有类型的语言（虽然不是静态类型），这比 Bash 中一切皆字符串的做法更安全。例如，可以对命令输出进行数学运算。
4. 函数式构造：内置 map、select、reduce 等函数式方法，可方便地对命令输出的行进行批量处理和转换。
5. 正则表达式支持：正则表达式是语言内置的，使用 =~ 操作符进行匹配并可通过 $1 等变量轻松捕获分组。
6. 简便的多线程：通过 Thread.new 可以轻松创建和管理线程，便于实现并行任务（如同时下载多个文件）。
7. 统一的文件与目录操作：所有文件操作封装在 File 类中，目录操作封装在 Dir 类中，API 设计清晰统一。

作者总结道，当 Bash 脚本变得复杂时，可以考虑使用 Ruby 来替代。尽管 Python、Perl 等语言也能实现，但作者认为 Ruby 是功能最全面且易于上手的 Bash 替代品。该文章在 Hacker News 上获得了第一名，并得到了 Ruby 创始人松本行弘的转发。

总结：为何应停止使用箱线图（2021）

核心观点

作者基于多年教学经验认为，箱线图（箱形图）作为一种经典图表类型，设计存在缺陷，导致其难以理解、易被误解，且传达分布信息时效率低下。尽管箱线图历史悠久，但替代图表类型通常更直观、信息更丰富，能更有效地向非专业受众传达数据见解。

箱线图的三大主要缺陷

1. 视觉设计不符合直觉

• 宽度暗示错误：宽的“箱体”部分看起来比“须线”部分更重要或包含更多数值，但实际上四个部分包含的数据点数量相同。
• 结构误导：两个中间的箱体看起来像一个被中位数分开的单一形状，暗示图表由三部分组成（上须、中箱、下须），而非实际上的四个四分位区间。
• 长度与密度矛盾：较短的箱线图部分实际上表示数据密度更高，但这与“长度代表数量”的直觉相悖，导致与直方图等图表视觉上不匹配。

2. 需要理解不必要的复杂概念

• 箱线图要求观众掌握四分位数等抽象概念，而这些概念在多数日常数据分析场景中并非必需。
• 许多观众需要数分钟的解释才能理解箱线图，而其他图表类型仅需几秒钟。

3. 信息展示不充分

• 箱线图倾向于使所有分布呈现“钟形”，掩盖真实分布形态（如多峰、缺口等）。
• 隐藏了每组数据的具体数量信息。
• 即使对于熟悉箱线图的观众，解读时仍需不必要的认知努力。

推荐的替代图表类型

1. 散点图（Strip Plot）

• 特点：每个点代表一个数据值。
• 优势：直观展示分布形态（高低、集中度、偏态、离群值等），能显示分布缺口和多峰分布，且可在几秒内被理解。
• 适用场景：数据量较少（几十个数据点）时。

2. 抖动散点图（Jittered Strip Plot）

• 特点：通过轻微随机偏移避免点重叠。
• 优势：可容纳更多数据点，同时保持散点图的直观性。
• 适用场景：数据量中等（几百个数据点）时。

3. 分布热图（Distribution Heatmap）

• 特点：将数据分箱（区间）并用颜色表示密度。
• 优势：可处理海量数据，概念（分箱）比四分位数更易理解。
• 适用场景：数据量极大时。

箱线图的有限优势

• 唯一优势：直接显示四分位范围。
• 反驳：大多数需要传达的见解（如分布高低、离群值等）无需展示四分位范围，中位数等信息可轻松添加到替代图表中。

总结与行动建议

• 箱线图的设计缺陷使其在多数场景下不是最佳选择。
• 建议分析人员优先考虑散点图、抖动散点图或分布热图等更直观的替代方案，以提高数据见解的传达效率。
• 即使在某些领域箱线图使用普遍，也值得重新评估其适用性，尤其是当受众对统计图表不熟悉时。

备注：本文作者为独立数据可视化教育者，其观点基于多年教学实践和研究观察，旨在推动更高效的数据沟通方式。

文章总结：《Remembering the LAN (2020)》

一、90年代局域网编程体验：简单、自由与魔法

• 技术环境：作者童年（90年代）在澳大利亚小镇，家庭小企业使用MS-DOS及IPX协议的Novell NetWare局域网，后过渡到Windows NT和TCP/IP。互联网接触较晚且有限。
• 学习与实验：局域网成为安全的“魔法空间”，允许自由文件共享、搭建实验服务器、修改代码而无安全顾虑。技术学习通过实体书籍和有限资源（如从香港购买Slackware Linux）进行。
• 小企业应用：父亲（全科医生）利用廉价286/386/486电脑和Clipper数据库，自行编写了支持约15人并发的医疗记录软件。通过文件锁定、鼠标-less的 curses 界面、优化击键效率及激光打印机精准打印，显著提升诊所生产力，甚至带来额外编程收入。
• 社交与教育：局域网也是社交场景（如朋友家组建临时局域网玩《星际争霸》），技术门槛相对较低，编程充满创造力乐趣。

二、现代编程环境的变化：复杂性、安全与隔阂

• 技术复杂度上升：现代互联网开发涉及更多防御性编程（如XSS攻击防护）、安全协议（OAuth2）、及分布式系统，入门与调试成本高。
• 安全与隐私挑战：开放互联网带来安全风险，法律合规（如HIPAA）增加难度。简单应用难以安全部署于移动设备。
• 社交与体验转变：游戏和协作更便捷，但失去面对面互动与定制化乐趣；学习资源虽丰富，但编程常沦为“防御性苦工”。
• 小企业案例对比：如今父亲若开发类似软件，更可能选择购买/订阅商业方案，而非自制，导致生产效率下降。

三、未来愿景：重建“魔法”局域网

• 核心目标：结合90年代局域网的安全简单与21世纪互联网的优势，创造可信赖的虚拟编程空间。
• 技术方案：通过 Tailscale 等公司推动的现代VPN与身份认证技术（如WireGuard协议、自动密钥管理、基于人的IP映射），在公网之上构建点对点加密的虚拟局域网。
• 期望特性：
  • 使用全局互联网身份系统进行认证，实现IP级加密授权。
  • 自动化密钥生成与轮换，IP地址绑定真实身份。
  • 限制自定义服务器访问权限，基于小群体社交动态保护数据。
• 实现路径：
  1. 优先打造优质用户体验，让客户获得类似90年代的简洁编程环境。
  2. 标准化并公开网格覆盖网络协议，促进广泛应用。
  3. 帮助新一代程序员体验无安全顾虑的创造性编程乐趣，重塑编程作为“花园耕耘”而非“街头战斗”的价值。

本文针对网络应用开发中常见的TCP与UDP选择问题进行探讨，尤其聚焦于对“及时性”有要求的实时场景（如直播视频、在线对话）。作者指出，业界常将“可靠交付”与TCP、“不可靠交付”与UDP简单对应，但开发者实际需求的是及时性（即优先传输最新数据），而非不可靠性本身。传统上，实时行业倾向于直接使用UDP数据报来达成此目的，但这会迫使开发者自行处理重传、拥塞控制等复杂问题，极易出错且效果不佳。

文章核心论点是：应使用QUIC协议及其流（Stream）特性，而非数据报（Datagram），来实现及时性。其优势在于：

1. 避免缓冲区膨胀：通过使用BBR等基于延迟的拥塞控制算法，检测并缓解网络队列延迟，确保数据及时送达。
2. 利用独立的流：将数据（如视频帧）拆分为独立的、有序可靠的流。流之间相互独立，可被乱序接收。
3. 流优先级控制：开发者可为流设置不同优先级，让QUIC栈优先传输高优先级流，低优先级流可被降级甚至关闭以节省带宽。

作者承认，出于兼容性和实验性，QUIC、WebTransport及MoQ协议仍支持数据报扩展，但这主要是为了吸引习惯UDP的开发者。他认为这是一种“陷阱”，对于绝大多数追求及时性的新应用，基于QUIC流的方案已完全足够，无需依赖数据报。最终，作者强烈建议开发者避免基于UDP或数据报设计新的实时协议（如视频协议），而应转向参与“Media over QUIC”（MoQ）等项目。

文章摘要：用SSH替代Sudo

本文探讨了传统特权提升工具（如 sudo、doas）的局限性，并提出了一种使用本地SSH连接作为替代方案的实验性方法。

现有工具的局限：

• 依赖于 setuid 二进制文件和特权提升机制。
• 要求整个用户会话保留执行特权提升的能力。
• 在受限的用户命名空间中无法工作。
• setuid 二进制文件的存在对系统整体安全加固构成限制。

实验目标：

1. 允许授权用户（且仅限授权用户）以 root 身份运行命令。
2. 完全避免使用特权提升机制。

具体实现方案：

1. 专用SSH密钥认证： 为 root 账户创建一个独立的SSH公钥（/root/.ssh/local_keys），而非使用标准的 authorized_keys 文件。
2. 绑定到Unix套接字的sshd实例： 运行一个 sshd 服务实例，使其仅监听一个Unix域套接字（如 /run/sshd/sshd.sock），并严格限制该套接字的文件权限（例如，仅允许 root:wheel 组访问）。
   • 此实例配置为使用上述专用密钥文件，并允许 root 登录（PermitRootLogin=yes）。
3. 禁用标准root登录：
   • 锁定 root 账户密码（在密码哈希前加 !），使 sshd 阻止任何基于密码或常规密钥的 root 登录。
   • 同时，将 /etc/passwd 中 root 的密码字段修改为一个无效值（如 *），此值不被 sshd 解释为“锁定”，从而允许通过上述专用密钥的SSH连接。
4. 客户端连接配置：
   • 使用 ssh 命令的 ProxyCommand 选项和 ProxyUseFdpass 功能，通过一个辅助脚本（如 passfd.py）将套接字的文件描述符传递给 ssh，实现高效连接。
   • 连接命令示例：ssh -o ProxyCommand='passfd.py' -o ProxyUseFdpass=yes -t root@root "command"。
   • 可搭配硬件绑定密钥或需要交互批准的 ssh-agent 以增强安全性。

结论：

• 该方案可行，将敏感的安全细节完全交由成熟的 OpenSSH 处理。
• OpenSSH 拥有良好的安全记录，并支持多种认证方式（如硬件密钥）。
• 在新主机上配置简单，可通过系统服务管理器启动 sshd 实例。
• 文中提供的连接脚本为实验性方案，实际使用建议编写更稳固的可执行文件或包装脚本。

脚本概述：禁用Facebook个性化广告定向

目的
该脚本旨在自动化禁用Facebook的个性化广告定向功能。通过模拟用户交互，脚本逐个取消订阅广告商，减少广告商基于个人数据的定向投放，从而提升用户的“心理安全”。

工作原理
脚本通过浏览器控制台在Facebook的广告设置页面（https://accountscenter.facebook.com/ads/audience_based_advertising）执行。它自动查找并点击页面元素，模拟用户选择“不允许”选项的过程，从而禁用广告商的定向能力。

代码结构与关键功能

• 国际化（i18n）：定义不同语言的界面文本（如英语、葡萄牙语），支持多语言环境。
• 辅助函数：包括延迟函数（delay）、元素查找函数（如通过aria-label、role或文本内容查找元素），以及等待元素出现的异步函数（wait）。
• 核心函数decouple：
  • 接受参数offset（跳过已处理的广告商数量）和lang（语言设置）。
  • 点击“查看更多”按钮展开广告商列表。
  • 遍历广告商条目，依次点击每个广告商、选择“他们上传或使用了列表以触达您”的提示、连续两次点击“不允许”按钮，然后返回上一级。
  • 通过控制台输出进度（如广告商索引和名称），便于监控。

使用指南

1. 在桌面浏览器中打开指定Facebook页面，最大化窗口。
2. 按F12打开开发者工具，切换到“Console”标签。
3. 复制脚本代码，粘贴到控制台并按Enter执行。
4. 执行期间：不要与浏览器交互，以免干扰脚本运行。
5. 监控输出：控制台会显示已处理的广告商编号和名称。
6. 处理大量广告商：如果广告商较多，脚本可能无法一次性全部处理。可以根据控制台输出的最后一个编号（如“250 Dick's Sporting Goods”）指定偏移量重新运行，例如：decouple({ offset: 250 })。
7. 语言切换：通过修改lang参数使用其他语言（如'br'代表葡萄牙语），示例：decouple({ offset: 250, lang: 'br' })。

注意事项

• 脚本针对Facebook界面设计，如果页面结构变化可能失效。
• 执行过程需保持页面稳定，避免点击或滚动。
• 对于非英语用户，可查看i18n对象并添加对应语言键值。

Go Channel的三种理解方式

1. 作为带锁的队列

Go channel在本质上是一个带锁的缓冲队列。发送者向队列添加元素，接收者从队列读取元素。队列大小固定，当队列满时发送者会阻塞等待，当队列空时接收者会阻塞等待。Go运行时会管理发送者和接收者的队列，通过挂起和唤醒机制避免忙等待。

// 发送操作
ch <- w

// 接收操作
w, ok := <-ch

使用select语句可以扩展操作选项，例如在队列满时尝试发送：

select {
case ch <- w:
    return true
default:
    return false
}

还可以通过额外的通道提供“逃生出口”，在需要停止时中断操作：

select {
case ch <- w:
    return true
case <-done:
    return false
}

这种队列抽象有助于理解channel的基本行为：向满队列写入会阻塞，从空队列读取会阻塞，从已关闭队列读取会持续获取值直到为空，而向已关闭队列写入则是错误。

2. 作为并发原语的一部分

channel通常不是孤立使用的，而是Go并发生态系统的一部分。要编写正确的并发代码，需要理解其他并发原语：

Goroutine：轻量级线程，用于并发执行。channel常与goroutine配合使用，在单独的goroutine中进行发送和接收操作。

go recv(ch)
go send(w, ch)

超时和定时器：通过select语句结合时间逻辑，实现限流或超时控制。

// 定时器示例
ticker := time.NewTicker(1 * time.Second)
select {
case <-ticker.C:
    ch <- w
}

// 超时示例
select {
case <-time.After(1 * time.Second):
    ch <- w
}

WaitGroup：用于协调线程关闭，阻塞主进程直到一组并发线程完成。

var wg sync.WaitGroup
wg.Add(1)
go func() {
    work <- i
    wg.Done()
}()
wg.Wait()
close(work)

错误组（Error Group）：比WaitGroup更灵活，能处理未知数量的工作和提前终止的情况。错误组可以协调多个发送者，当上下文取消时优雅地关闭所有goroutine。

eg, ctx := errgroup.WithContext(ctx)
eg.Go(func() error {
    // 发送工作
    select {
    case c.work <- i:
    case <-ctx.Done():
        return context.Cause(ctx)
    }
})

选择合适的并发模式需要根据具体场景，有时需要组合多种原语来实现优雅的关闭和错误处理。

3. 作为消息传递机制

channel的设计灵感来源于CSP（通信顺序进程）模型，其核心理念是“通过通信共享内存，而非通过共享内存通信”。

从实现角度看，Go channel不仅仅是用户实现的队列。Go运行时深度集成了channel实现，能够智能地管理goroutine的上下文切换，根据工作负载暂停和恢复线程，这使得channel性能优于用户自实现的队列。

嵌入到语言运行时中也使得编写高度并发的代码更容易。虽然channel生态系统增加了学习难度，但它也提供了更强大的能力。例如，复杂的并发协调（如多个channel上下文协调进行表更新下载）能够简洁地实现，同时保持高性能。

总结

三种理解方式各有侧重：

• 队列抽象：帮助编写和阅读channel代码
• 并发原语：确保channel代码正确停止和协调
• 消息传递：理解channel的性能优势和设计哲学

在实际开发中，这三种视角都很有用，但适用于不同场景。channel不仅是简单的队列，更是Go并发模型的核心组件，通过与运行时深度集成，提供了高效且安全的并发编程方式。

首个无需氧气即可生存的动物发现

2020年，科学家发现了一种类似水母的寄生虫Henneguya salminicola，这是首个被发现的缺乏线粒体基因组的多细胞生物。这意味着它不需要呼吸氧气，完全摆脱了对氧的依赖。

生物背景与发现

• 这种寄生虫属于刺胞动物门（与珊瑚、水母同属一门），寄生在鲑鱼体内，形成肉眼可见的囊肿，但对鱼类和人类无害。
• 研究人员通过深度测序和荧光显微镜对其DNA进行分析，发现它不仅失去了线粒体基因组，还丧失了有氧呼吸能力及相关核基因。
• 作为对照，对同类寄生虫Myxobolus squamalis的研究则显示其存在完整的线粒体基因组。

科学意义

1. 挑战传统认知：此前认为多细胞生物必须依赖氧气生存，但该发现证实适应无氧环境并非单细胞生物独有，多细胞动物也能演化出专属的无氧代谢。
2. 演化轨迹：该寄生虫经历了基因简化过程，从自由生活的水母祖先逐渐演化为结构简单的寄生生物。它保留了类似水母刺细胞的结构（用于附着宿主），但丢失了大部分原始基因。
3. 对外星生命探索的启示：该发现拓宽了生命存在形式的认知，可能影响寻找地外生命时的假设条件。

研究应用与展望

• 该研究有助于渔业管理改善应对寄生虫的策略。
• 为理解从有氧代谢向无氧代谢的演化过渡提供了关键案例。

相关成果于2020年2月发表在《美国国家科学院院刊》（PNAS）上。

华盛顿大学研究人员发现，ChatGPT在简历筛选中存在对残障相关资历的系统性偏见。

研究发现

• 偏见表现：当简历中包含残障相关荣誉或资历（如“汤姆·威尔逊残障领导力奖”）时，ChatGPT（GPT-4模型）一致将其排名低于内容相同但无此类资历的简历。
• 偏见解释：系统在解释排名时表现出对残障者的刻板印象。例如，它认为带有自闭症领导力奖的简历“对领导角色的强调较少”，暗示自闭症者不擅长领导；将抑郁症候选人的DEI参与描述为“分散了对核心技术和研究方面的注意力”。
• 定制指令的效果：通过GPTs Editor工具，研究人员向ChatGPT发出明确指令，要求其遵循残障正义和DEI原则，避免“能障歧视”偏见。定制后，六种残障（耳聋、失明、脑瘫、自闭症、抑郁症及泛称“残障”）中的五种在排名上有所改善，但仅有三种的排名高于未提及残障的对照简历。
• 关键数据：
  • 原始实验：增强型简历（含残障资历）在60次试验中仅25%排名第一。
  • 定制后：提升至37次（61.7%），但对自闭症（30%）和抑郁症（20%）简历的改善有限。

研究背景与意义

• 随着AI工具（如ChatGPT）被用于招聘中的简历筛选和排名，其潜在偏见可能放大现实中的歧视。
• 该研究质疑了AI筛选在残障相关场景下的安全性与有效性，并指出残障求职者长期面临是否披露残障资历的困境。
• 研究强调，即使是经过定制的AI系统，其偏见也可能持续存在，提醒使用者需保持警惕。

未来研究方向

研究人员建议未来应：

• 测试其他AI系统（如Google Gemini、Meta Llama）。
• 涵盖更多残障类型。
• 研究AI对残障的偏见与其他属性（如性别、种族）的交叉影响。
• 探索更有效的定制方法以实现跨残障类型的一致公平。

研究团队与资助

该研究由华盛顿大学团队完成，并在2024年ACM公平性、问责制和透明度会议上发表。研究得到美国国家科学基金会、华盛顿大学CREATE中心捐赠者及微软的资助。

该研究通过分析大规模文本数据，探讨了以ChatGPT为代表的大语言模型在生物医学学术写作中的使用规模。

研究利用PubMed数据库中2010至2024年间超过1500万篇生物医学摘要，采用一种无偏的大规模方法：通过追踪风格词汇频率的异常增长来检测LLM的使用痕迹。

主要发现如下：

1. 使用普遍性：LLM的出现导致了特定风格词汇使用频率的突变。基于此“词汇过剩”分析，研究估计至少有13.5%的2024年生物医学摘要在撰写过程中使用了LLM。
2. 使用差异：LLM的使用率因学科、国家和期刊而异，在某些子语料库中比例高达40%。
3. 影响程度：研究指出，LLM对科学写作风格的影响超过了新冠疫情等重大世界事件，显示其对生物医学研究写作产生了前所未有的冲击。

本文档演示了在Unix/Linux系统上使用grep命令，从系统字典（/usr/share/dict/words）中筛选出能够在计算器上通过倒置拼写成数字序列的英语单词。

核心目的与方法： 文档通过一个具体的命令行操作（grep -i '^[izehsglbo]*\([izehsglb]\|[izehsglb]o\)$' /usr/share/dict/words）来实现筛选。该正则表达式匹配仅包含特定字母（i, z, e, h, s, g, l, b, o）的单词，且这些字母在倒置后对应于计算器上的数字（如i→1, z→2, e→3, h→4, s→5, g→6, l→7, b→8, o→0）。单词的结尾被限定为特定的单个字母或“字母+o”的组合。

输出结果： 命令输出了一个长长的单词列表。每个单词后面都附有其倒置后形成的数字序列。例如：

• bee (338)
• beg (638)
• shell (77345)
• besiege (3631538)
• eggshell (77345663)

列表中不仅包含普通单词（如bell, giggle, siege），也包含了一些专有名词（如Belize, Google, Hegel）和数字开头的序列（如38338对应Beebe）。

结论： 该文档是一次技术性的文本处理演示，展示了如何利用正则表达式和字典文件，来查找所有符合“计算器单词”特性的词汇。

LetterDrop 项目摘要

项目背景与目的

由于 Mailchimp 关闭了免费的 TinyLetter 服务，导致作者面临订阅者流失和频繁迁移的问题。为此，作者开发了 LetterDrop，这是一个免费、易用且可靠的 Newsletter（新闻邮件）管理服务，旨在提供安全的邮件创建、分发和订阅管理功能，避免依赖第三方免费服务带来的关停风险。

技术架构与依赖

LetterDrop 深度集成 Cloudflare 生态，核心依赖包括：

• 计算与存储：Cloudflare Workers、KV、R2、D1（关系型数据库）。
• 邮件与消息：Cloudflare Email Workers（处理邮件发送与触发）、Queues（消息队列）。
• 外部服务：目前使用 AWS SES 作为底层邮件发送服务，需配置额外的 Worker 作为通知服务。

核心功能与使用流程

1. Newsletter 管理：通过 RESTful API 创建或下线 Newsletter。API 受 Cloudflare Zero-Trust 安全保护，必须使用 Service Token 进行身份验证。
2. 订阅与退订：用户访问特定的 Newsletter 页面（URL 模式为 /newsletter/:id）点击按钮操作，系统会发送确认邮件，完成确认后即可接收后续推送。
3. 发布 Newsletter：
   • 向配置的特定邮箱发送内容以触发 Cloudflare Email Worker 进行群发。
   • 邮件主题必须严格遵循格式：[Newsletter-ID:<id>]<标题>。
   • 通过环境变量 ALLOWED_EMAILS 白名单控制哪些邮箱地址有权触发发送。
4. 失败处理：利用 Cloudflare Queues 捕获发送失败的邮件，管理员可通过控制台在死信队列（dead-letter queue）中监控并重试。

部署与配置

• 需注册 Cloudflare 账户，并通过 Dashboard 部署 app 目录下的 Worker 脚本。
• 部署前需修改 app/wrangler.toml 文件以填入自定义配置。
• 需参考 app/db/README.md 文档初始化 D1 数据库。

开发模式与未来规划

• AI 辅助开发：项目代码主要由 GPT-4o 模型根据提示词（记录在 CDDR 文件中）生成，作者负责代码审查与测试，大幅提升了开发效率。社区也可通过修改提示词轻松定制代码。
• 未来迭代计划：
  • 增加单元测试和邮件模板。
  • 追踪邮件打开率。
  • 支持 SendGrid、Mailgun 等更多第三方邮件服务商。
  • 增加多租户（multi-tenant）支持和项目落地页（Landing page）。

AMD Bergamo (Zen 4c) 服务器CPU技术摘要

市场定位与核心理念

AMD Bergamo 是面向高核心密度服务器市场的处理器，旨在通过采用专注于密度的 Zen 4c 核心，实现超越传统互连扩展能力的核心数量提升。其设计目标与 Intel 即将推出的 Sierra Forest 和 Ampere 的服务器 CPU 类似，主要服务于按核心租赁算力的云服务提供商，以及需要极高并行处理能力的应用。更多核心允许单台物理服务器服务更多客户或提升并行任务性能。

架构与设计特点

• Zen 4c 核心：采用 Zen 4 相同的架构，但物理实现上通过降低时钟频率来换取更小的芯片面积和更好的低频能效，从而在相同面积内容纳更多核心。
• 缓存调整：每个 Zen 4c CCX（核心复合体）的共享 L3 缓存从 Zen 4 的 32 MB 减半至 16 MB（与移动设计类似）。一个 CCD（核心芯片）可容纳两个 Zen 4c CCX，实现核心数量翻倍。
• 平台复用：完全复用 Zen 4 服务器（Genoa）平台，仅将 CCD 从标准 Zen 4 更换为 Zen 4c 版本，共享相同的 IO 芯片和 Infinity Fabric 互连。

关键性能测试与分析

1. 内存性能

• 带宽：全核心负载下，读取带宽可达约 360 GB/s（读取-修改-写入模式下为 378 GB/s），达到了 768 位 DDR5-4800 理论带宽的 80% 以上，表现优异。
• 延迟：由于 L3 缓存容量减半和主频降低，其 L3 访问延迟高于标准 Zen 4，且服务器平台的 DRAM 延迟也高于客户端平台。16 MB L3 的缓存命中率低于 32 MB 版本。
• 内存访问模式：测试显示，内存带宽的缩放与 CCD 及 CCX 的加载顺序有关，最佳缩放模式是先为每个 CCD 加载一个 CCX。双路配置下，跨路访问存在明显的延迟和带宽惩罚，凸显了 NUMA 感知编程的重要性。

2. 核心间通信与缓存一致性

• 延迟：集群内（同一 CCX 内）核心间通信延迟很低（约30-40 ns）。跨集群（同一 CCD 不同 CCX）延迟升至100-120 ns。跨路通信延迟最高，平均约200 ns。整体延迟特性与 Genoa-X 相当。
• 一致性开销：高核心数增加了缓存一致性管理的复杂性。AMD 通过 L2 影子标签（集群内）和 Infinity Fabric 探针过滤器（跨集群）两级机制进行管理。

3. 应用性能对比

• 与 Zen 4 及 VCache 对比：在相同频率（3.1 GHz）下，对单个 CCD 进行测试：
  • 视频转码 (libx264)：Zen 4c 集群性能略低于标准 Zen 4 集群，但大幅落后于 VCache 集群。然而，由于 Zen 4c CCD 包含两个集群（即两倍核心），其整体 CCD 性能显著优于单个 Zen 4 CCD。
  • 文件压缩 (7-Zip)：VCache 展现出巨大优势。Zen 4c CCD 的多线程性能因核心数优势而反超标准 Zen 4 CCD。
• 结论：Zen 4c 的设计在多线程吞吐量上成功地将更多计算性能封装在单个计算芯片中，但较小的 L3 缓存使其对缓存敏感型应用（如 7-Zip）处于劣势。

技术战略与未来潜力

• 策略优势：通过复用 Zen 4 架构和现有服务器平台，AMD 大幅降低了 Bergamo 的开发、验证和优化成本，并保持了指令集扩展的一致性。
• 扩展潜力：当前 Bergamo 使用 8 个 Zen 4c CCD，而 Genoa 平台最多支持 12 个 CCD，理论上可扩展至 192 核心/路。
• 竞争格局：
  • Intel Sierra Forest：采用独立的 E-Core 架构（与 P-Core 不同），在物理和架构层面可能实现更高的密度（最多144核），但面临额外的开发工作和指令集扩展可能不一致的挑战。
  • Ampere：凭借自研架构提供高达 192 核心的产品，是该领域的另一重要竞争者。

总结

AMD Bergamo 通过 Zen 4c 核心，以模块化方式成功切入高核心密度服务器市场，在提供极高的多线程吞吐量的同时，利用平台复用策略实现了快速上市。其性能优势在于核心数量，但在缓存容量和时钟频率方面做出了妥协。对于云服务和高度并行工作负载，它是具有吸引力的选择，但应用程序需要针对其内存子系统特性（尤其是较小的 L3 和 NUMA 效应）进行优化才能获得最佳效果。

AWS Lambda Web Adapter 摘要

AWS Lambda Web Adapter 是一个工具，允许开发者使用熟悉的 Web 框架（如 Express.js、Next.js、Flask、SpringBoot、ASP.NET 和 Laravel）构建 Web 应用程序（HTTP API），并在 AWS Lambda 上运行。同一个 Docker 镜像可以部署在 AWS Lambda、Amazon EC2、AWS Fargate 和本地计算机上，实现环境一致性。

主要功能

• 支持在 AWS Lambda 上运行 Web 应用程序。
• 兼容 Amazon API Gateway REST API 和 HTTP API 端点、Lambda Function URLs 以及 Application Load Balancer。
• 支持 Lambda 管理运行时、自定义运行时和 Docker OCI 镜像。
• 支持 Lambda 管理实例，处理多并发请求。
• 支持任何 Web 框架和语言，无需添加新代码依赖。
• 自动编码二进制响应。
• 启用优雅关闭。
• 支持响应体压缩（缓冲模式）。
• 支持响应流。
• 通过租户 ID 传播支持多租户。
• 支持非 HTTP 事件触发。

快速开始

Docker 镜像

在 Dockerfile 中添加一行命令：

COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:1.0.1 /lambda-adapter /opt/extensions/lambda-adapter

预编译的多架构镜像（x86_64 和 arm64）可在公共 ECR 仓库获取。

Zip 包

• 附加 Lambda Web Adapter 层到函数：提供 x86_64 和 arm64 的 ARN。
• 设置环境变量 AWS_LAMBDA_EXEC_WRAPPER 为 /opt/bootstrap。
• 将函数处理器设置为启动脚本（例如 run.sh）。

配置

通过环境变量配置就绪检查端口/路径和流量端口，可定义在 Dockerfile 或 Lambda 函数配置中。主要环境变量包括：

• AWS_LWA_PORT：流量端口（默认 "8080"）。
• AWS_LWA_READINESS_CHECK_PORT：就绪检查端口（默认同 AWS_LWA_PORT）。
• AWS_LWA_READINESS_CHECK_PATH：就绪检查路径（默认 "/"）。
• AWS_LWA_READINESS_CHECK_PROTOCOL：就绪检查协议（默认 "http"）。
• AWS_LWA_ASYNC_INIT：启用异步初始化（默认 "false"）。
• AWS_LWA_INVOKE_MODE：Lambda 函数调用模式（"buffered" 或 "response_stream"，默认 "buffered"）。
• 其他变量如 AWS_LWA_REMOVE_BASE_PATH、AWS_LWA_ENABLE_COMPRESSION 等。

弃用通知：旧的非命名空间环境变量（如 HOST、READINESS_CHECK_PORT）已弃用，将在 2.0 版本移除。请迁移到 AWS_LWA_ 前缀版本。注意 PORT 未弃用，可作为 AWS_LWA_PORT 的后备。

示例和迁移

提供多种框架的示例，包括 FastAPI、Flask、Express.js、Next.js、SpringBoot、Nginx、PHP、Rust、Golang、Laravel、ASP.NET 等，按语言组织。

从 0.x 版本迁移到 1.0 版本时：

• 环境变量需更新为 AWS_LWA_ 前缀。
• 健康检查状态配置变更：使用 AWS_LWA_READINESS_CHECK_HEALTHY_STATUS 替代 AWS_LWA_READINESS_CHECK_MIN_UNHEALTHY_STATUS。

类似项目

列出其他类似的语言特定项目，如 Serverless Java Container、Serverless Express、Serverless Python - Zappa 等。

安全和许可

安全漏洞报告和贡献指南请参考相关文件。该项目基于 Apache-2.0 许可证。

城中之城：不属大伦敦管辖的伦敦市

历史起源

• 罗马奠基：公元43年罗马入侵不列颠后，在泰晤士河畔建立了伦蒂尼恩定居点，因其贸易位置优越而迅速繁荣。
• 城墙定界：约两个世纪后，城市人口已超万人，并修建了巨大的伦敦城墙。城墙不仅用于防御，更在随后超过18个世纪中基本框定了该城的边界与规模。

独特的政治地位

• 延续的自治权：诺曼征服时期，伦敦市民通过承认威廉为新国王，换取并保住了其传统自由与自治特权。尽管历代君主曾视其为威胁，但从未能将其彻底臣服。
• 双城格局：附近的威斯敏斯特为与伦敦市竞争而发展，最终形成并包围了古老的伦敦市。1889年，更大的“伦敦郡”成立，但伦敦市依旧独立存在。

现代的“国中之国”

• 持续自治：即使在1965年“大伦敦”行政区划成立后，伦敦市仍由其专属的伦敦市法团治理，拥有独立的市长（称为伦敦金融城市长）、警力和仪仗队。
• 高度自治的体现：该市拥有自己的旗帜、徽章、警察部队。一个令人称奇的传统是：英国君主进入伦敦市前，需事先征得市长的许可。
• 现状数据：根据2011年人口普查，伦敦市面积约1.12平方英里，人口仅8,072人。

总结

文章指出，尽管伦敦市在历史、法律和行政上享有高度独立，仿佛一个“独立国家”，但其本质仍是一个拥有独特历史与治理模式的特殊区域。它是坐落在大伦敦行政区内的一座历史古城，其自治传统可追溯至中世纪，并延续至今。

Nano DIP: 最小完整Arduino板（33 x 10mm）

概述

Nano DIP 是一个 Arduino 兼容开发板，尺寸仅为 33 x 10 mm，相当于 ATmega328P 的 26 引脚 DIP 封装大小，是迄今为止最小的完整 Arduino 板。它基于新一代 8 位 ATtiny3217 处理器，替代了传统的 ATmega328P，同时保持与 Arduino Nano 的兼容性，并增强了功能。

关键特性

• 尺寸与封装：DIP26 封装，尺寸 33 x 10 mm，便于集成到小型项目中。
• 处理器：采用 ATtiny3217，取代旧版 ATmega328P，提供更小尺寸和更强功能，如内置 DAC。
• 兼容性：完全兼容 Arduino Nano，可使用相同代码和生态系统。
• 电气规格：
  • 供电电压范围 1.8V 至 5.5V，V+ 引脚最大输入电压 18V。
  • 使用 MOSFET 代替二极管，实现 0V 电压降（对比传统 USB 供电的 0.7V 降）。
• 附加功能：
  • 额外的 2 极接头（连接到 D2 引脚），可用作跳线。
  • D0 引脚上的 LED 可通过跳线禁用。
  • 引脚布局简单直观，便于接线。

设计与挑战

• 设计动机：ATmega328P 尺寸过大，不适合某些小型 PCB 设计；ATtiny3217 封装更小，且功能更丰富（例如具有 DAC，而 ATmega328P 无）。
• PCB 设计挑战：在 DIP26 大小的 PCB 上集成所有组件，并保持坚实的接地层。为控制成本，采用以下设计约束：
  • 迹线宽度/间距：6/6 mil。
  • 过孔钻孔/外径：12/24 mil。
  • SMD 元件尺寸：0402 或更大（避免使用更小的 0201 零件以确保生产经济性）。

使用与配置

• 上传草图：
  1. 在 Arduino IDE 中添加额外板管理器 URL：http://drazzy.com/package_drazzy.com_index.json，并安装 "megaTinyCore by Spence Konde"。
  2. 选择板为 "ATtiny3217 (Optiboot)"，时钟速度设置为 16MHz。
  3. 上传代码（注意：板已预烧录引导加载程序）。
• 引导加载程序：板出厂时已烧录；如需自行烧录，可参考相关文档。
• 时钟速度检查：必须在软件中设置正确的时钟速度（通过 Tools > Clock Speed），否则可能导致功能异常。例如，在低功耗应用中，若时钟设置错误，可能引起过热问题。代码示例可用于验证时钟速度。

ATtiny3217 优势与对比

• 内存与功能：ATtiny3217 拥有 32KB 程序内存和 2048B SRAM，与 ATmega328P 相当，但封装更小。相比旧版 ATtiny 系列（如 ATtiny85，内存较小），解决了内存限制问题。
• 与 ATtiny3227 对比：ATtiny3217 为 1 系列，具有 DAC；ATtiny3227 为 2 系列，无 DAC 但提供 12 位 ADC、3KB RAM、差分 ADC 和 2 个 UART。
• 振荡器校准：内部 RC 振荡器出厂校准精度在 ±4%（适用于 0-70°C 和 1.8-3.6V）。可进行二次校准以达到 ±1% 精度，并校正温度系数。

补充信息

• 资源链接：提供论坛讨论、原理图和 ATtiny3217 数据手册链接，方便进一步参考。
• 演示：早期版本（无 USB 连接器）可通过视频查看，展示其控制 21 个 LED 的能力。

该论文提出了一种新型的异步拜占庭共识协议，其核心创新在于不依赖任何可信初始化设置或公钥密码学（如数字签名）。

主要贡献与成果：

1. 协议基础：协议的安全性仅基于密码学哈希函数，并将其建模为随机预言机。这不仅极大简化了密码学假设，也使得该协议具备后量子安全性。
2. 性能指标：所提出的异步公共子集协议具有O(κn³) 的总通信复杂度和期望 O(1) 的轮次复杂度。密码学工具的最小化使用和极低的轮次使其具有很高的实用性。
3. 实验验证：研究团队实现了该协议，并在最多 128 台机器的地理分布式环境中进行了评估。实验结果表明，其性能优于目前唯一已实现的、同样无需可信设置的共识协议。
4. 新原语：在构建异步共识协议的过程中，论文引入了两个新的密码学原语：异步密钥共享和覆盖收集，这些原语本身可能具有独立的研究价值。

总结：该工作通过摒弃对可信设置和昂贵公钥操作的依赖，设计了一个基于简单哈希函数、安全且高效的异步共识协议，为分布式系统在后量子时代下的共识问题提供了一个更实用的解决方案。

根据提供的内容，原始文本显示为加载错误信息，提示“出现错误”，并建议用户禁用可能导致问题的隐私相关扩展后重试。因此，无法获取关于“visionOS基于麦克风感知风扇声音进行热节流”这一技术主题的实际论述或详细信息。摘要内容仅为对该错误提示的直接复述。

Pi Gazing 项目概述

项目目的 Pi Gazing 是一个利用树莓派（Raspberry Pi）连接朝上的监控摄像头（CCTV）来构建流星相机的项目，旨在持续记录和分析夜空现象。

核心功能

• 实时视频分析：树莓派对视频流进行实时处理，搜索并记录移动物体的轨迹。捕捉目标包括流星、卫星、飞机，以及闪电、烟花和航天器太阳能板反射产生的铱星闪光等罕见现象。
• 长曝光摄影与系统校准：摄像头每晚会自动拍摄一系列长曝光静态照片。软件利用这些图像来确定摄像头的精确指向，并校准镜头可能存在的畸变。
• 天文现象记录：生成的静态图像还可用于观测星座随时间推移和季节变化的运动轨迹，以及记录月相变化和行星在星空中的位移。

资源与数据访问

• 观测档案：项目官网提供了完整的观测记录数据库，用户可以在线浏览所有摄像头捕捉的历史档案。
• 开源生态：该项目使用的所有程序代码和硬件设计均为完全开源，相关资源均托管在 GitHub 平台上供公众获取和使用。

文章概述

作者在开发X11合成器picom时，发现了一个存在至少8年的Xorg服务器bug。文章详细描述了bug的发现过程、技术背景、调试方法和原因分析。

背景：X服务器锁机制

• picom需要从X服务器获取完整的窗口树信息，但由于无法一次性获取，必须分段获取。
• 为避免在获取过程中窗口树变化导致混乱，使用GrabServer命令锁定整个X服务器，该命令根据X协议规范应禁用所有其他连接的请求处理和关闭事件。

问题发现

• 作者在代码中使用断言检查，发现在持有X服务器锁期间，已知存在的窗口突然消失。
• 具体场景：收到窗口创建事件后，锁定服务器并查询窗口，但窗口有时不存在，这违反了GrabServer的协议行为。

调试与分析

• 怀疑是Xorg服务器bug，但需进一步验证。
• 使用eBPF和uprobe工具进行非侵入式调试，无需修改X服务器代码或中断其执行。
• 通过挂钩GrabServer和窗口销毁函数，收集日志发现：窗口销毁是由客户端断开连接触发的（CloseDownClient），而按协议这应该在锁定期间被禁用。

Bug原因

• 根本原因是epoll的错误使用。Xorg服务器使用epoll处理多客户端连接，当GrabServer被调用时，服务器停止监听其他客户端的可读事件。
• 但epoll会在连接错误时（如EPOLLERR事件）始终通知服务器，即使没有主动监听，导致客户端关闭事件在锁定期间仍被处理。
• Git日志显示此bug已存在至少8年。

为何长期未发现

• Compositor在系统中处于特殊位置：普通应用程序只关注自身窗口，窗口管理器通常控制窗口销毁时机，因此不会遇到此竞争条件。
• 只有合成器需要监控所有窗口但无法控制其销毁，因此依赖GrabServer锁，但bug触发概率较低（作者通过Wine安装.NET Framework时才重现）。

结论与建议

• 作者认为这是一个简单的bug，但因系统特殊性而被忽视。
• 推荐学习eBPF和uprobe工具，它们在调试中有广泛应用。
• 提到可能通过替代方案避免使用锁，但仍在探索中。

为什么你的大脑比GPT-4高效300万倍：向量数据库与AI基础原理

本文以作者为项目选择向量数据库的经历为线索，深入浅出地解释了支撑大语言模型（LLM）运作的核心技术概念——向量与嵌入，并对比了人脑与GPT-4的效率差异，最后对多种主流向量数据库进行了评估。

一、 核心技术原理：从二进制到向量空间

1. 计算机基础：计算机只能处理二进制（0和1），这些二进制组合代表数字。通过预先约定的编码标准（如ASCII），数字可以映射为字母，从而形成文本。
2. 语义嵌入的诞生：传统编码中，同一个词（如“dust”）无论上下文如何，其数字表示相同，缺乏语义区分。上下文化词嵌入技术解决了这个问题，它能根据词语在上下文中的语义，赋予其不同的数值表示。含义相近的词，其数值（或向量）在“空间”中更接近。
3. 向量与高维空间：这些表示语义的数值被扩展为向量（多维数组）。为了捕捉复杂语义，这些向量存在于具有众多维度的向量空间中（例如OpenAI使用1536维）。维度越多，能表达的语义差异和细微差别就越丰富。
4. 维度灾难与高效搜索：在高维空间中精确搜索相似向量（近似最近邻搜索，ANNS）计算成本极高。HNSW 算法通过构建层级化的小世界网络图来解决此问题。它模拟社交网络中的“六度分隔”现象和组织架构的层级关系，允许在不遍历所有数据的情况下，快速定位到相似的向量，从而高效处理海量高维数据。

二、 大脑与GPT-4的效率对比

作者基于上述原理指出，当前的LLM（如GPT-4）本质上是通过对海量文本进行向量化、嵌入和上下文关联来“猜测”答案的复杂算法，其运作基于数值关系而非真正的“理解”或“意识”。

• GPT-4：其硬件需要庞大的数据中心和约7.5兆瓦的电力来处理信息。
• 人脑：在仅约24瓦的功耗下，于颅骨内完成远比GPT-4复杂的认知活动。根据认知神经科学研究，人脑仅有约5%的认知活动是意识活动。即使保守估算，人脑在处理同等复杂任务时的能效也可能比GPT-4高出超过300万倍。这凸显了生物神经网络在效率和复杂性上的惊人优势。

三、 向量数据库评估实战

基于上述原理，作者为项目评估了多种向量数据库，核心需求是支持生产环境（可扩展、高可用、数据持久化）。

• 初始选择：ChromaDB

  • 优点：易于上手，与应用集成快，适合快速验证概念（PoC）。
  • 缺点：作者采用的集成方式粗糙（与API容器打包），导致构建慢、Git仓库臃肿、缺乏生产级集群和高可用功能（当时）。作者将其类比为向量数据库领域的“SQLite”。
  • 更新：团队已做出重大架构改进（v0.4+），构建速度、性能和资源消耗得到显著优化。

• 快速淘汰的选项：

  • Pinecone：托管黑盒服务，无数据和控制权，不符合隐私与合规要求。
  • FAISS：仅是库，非完整数据库，功能过于基础。
  • Milvus：使用中遇到较多bug和文档问题，体验不佳。作者将其比作“向量数据库领域的旧版Oracle”。
  • pgvector：作为PostgreSQL扩展，性能（尤其并发下）和准确性未达预期，且并非所有环境（如AWS Aurora）都支持，违背了选择它的初衷。
  • Redis：作为键值存储，向量功能非核心业务，特性较单薄。虽然性能可接受，但存在功能被弃用的风险（如Redis Graph）。可作为备选。

• 重点评估与推荐：

  • Qdrant：作者的最终推荐。开源、支持自托管和云服务、具备完整的生产级功能（高可用集群、数据持久化）、性能卓越、文档完善、社区活跃、团队支持响应迅速。被作者称为“向量数据库领域的PostgreSQL”。
  • Weaviate：特性丰富，特别针对LLM应用优化，社区友好，是另一个有潜力的候选方案，但作者未亲自深入测试。

总结：作者认为，在选择生产级向量数据库时，应优先考虑具备完整数据库特性（可扩展性、持久性、高可用）的解决方案。经过综合评估，Qdrant 在性能、功能、易用性和社区支持方面表现最为突出，是最佳选择。

OpenEMR是一款开源的电子健康记录（EHR）和医疗实践管理解决方案，完全免费并始终致力于开放源代码。它由热情的志愿者和贡献者社区维护，强调开放、友善与合作。

主要功能：

• 高级排程：支持重复事件设置、基于患者签到的自动化工作流及患者提醒。
• 电子处方：在诊疗过程中直接录入处方并电子发送至患者药房。
• 医疗计费：集成符合HIPAA ASC X12标准版本的计费系统。
• CMS报告：可快速生成相关报告。
• 实验室集成：自动发送检验订单并整合结果至患者记录。
• 临床决策规则：通过算法引擎辅助复杂诊疗决策，提升医疗质量。
• 高级安全：支持HIPAA友好的精细访问控制、行业标准密码哈希，保障数据安全。
• 多语言支持：提供超过30种语言版本，并可定制扩展。

当前发展需求： OpenEMR正寻求资金以推动新功能开发，惠及门诊和住院用户。计划包括：混合门诊/住院支持、高级计费、FHIR集成、现代化云服务、质量报告能力、低成本医疗设备连接等常见需求。社区致力于根据用户反馈确定优先级。

部署方式： 支持本地服务器部署或云端部署。

漏洞概述

GNU Emacs 的 Org Mode 中存在一个任意 Shell 命令执行漏洞。攻击者可通过构造恶意的 .org 文件，在受害者使用 Emacs 打开或预览该文件时，未经任何确认提示直接执行任意系统命令。

漏洞复现

攻击者可构造包含以下内容的 .org 文件：

#+LINK: shell %(shell-command-to-string)
[[shell:touch ~/hacked.txt]]

当该文件通过邮件发送并在 Emacs 中预览，或直接作为文件在 Emacs 中打开时，系统会无提示执行 touch ~/hacked.txt 命令。

修复情况

该漏洞的修复补丁已包含在 Emacs 29.4 和 Org 9.7.5 版本中。补丁主要修改了 lisp/ol.el 文件中的 org-link-expand-abbrev 函数。

补丁技术细节

补丁的核心目的是防止在展开链接缩写时执行任意不安全的 Emacs Lisp (Elisp) 代码，具体结构与关键功能修改如下：

1. 清除危险文本属性：使用 substring-no-properties 清除返回链接中的所有文本属性（如 modification-hooks），以消除通过属性注入任意 Elisp 代码的潜在攻击向量。
2. 严格的安全函数校验：在处理 %(...) 链接缩写时，弃用 Emacs 内置的 unsafep-function（因为诸如 getenv 等函数虽被 Emacs 视为安全，但可能向攻击者泄露系统私有数据）。新逻辑要求目标函数符号必须显式具有 org-link-abbrev-safe 或 pure 属性才允许执行。
3. 拦截与警告机制：若检测到不安全的函数，系统将执行以下操作：
   • 拒绝展开该链接缩写。
   • 弹出警告信息，并提示用户可通过 (put '函数名 'org-link-abbrev-safe t) 手动将其标记为安全。
   • 从本地和全局的链接缩写列表（org-link-abbrev-alist-local 和 org-link-abbrev-alist）中动态删除该缩写配置。
   • 直接返回未展开的原始链接字符串。

创意工作者不应被迫在剥削者之间选择

Spotify与音乐产业的利益冲突

Spotify与三大唱片公司（环球、华纳、索尼）的合作关系揭示了创意工作者面临的困境。三大唱片公司控制着全球超过70%的音乐录制和60%的音乐创作，它们在Spotify早期获得了股权作为授权条件。这导致了根本性的利益冲突：作为Spotify股东，三大公司希望授权费越低越好；但作为代表音乐家的唱片公司，又应该争取更高费用。

实际结果是三大公司选择了极低的单次播放费率，同时通过协议获得了每月最低保证付款。例如，索尼可能每月从Spotify获得3000万美元保证付款，但按照极低费率计算的实际播放量可能只值1000万美元。剩余的2000万美元索尼可以自由支配，无需分配给艺术家。这种结构使得三大公司可以从Spotify获得巨额收入，而艺术家获得的收入却极其微薄。

内容巨头与科技巨头的共谋

三大唱片公司还获得了“最惠国”待遇，这意味着其他独立唱片公司也必须接受同样的极低费率，却没有获得相应的股权、月付保证或推广资源。

作者指出，这种模式不仅限于音乐产业。在人工智能训练版权诉讼中，内容公司（如《纽约时报》、Getty Images）起诉科技公司使用其内容训练AI，但内容公司本身也是创意工作者的剥削者。例如，好莱坞制片厂在去年演员罢工期间试图用一次性费用获取演员的全身扫描，以便永久使用而不再付费；环球音乐一边抗议TikTok用其音乐训练AI克隆声音，一边自己开始使用相同技术。

创意工作者的真正出路

作者认为，创意工作者面临的不是在“已知的魔鬼”（内容巨头）和“未知的魔鬼”（科技巨头）之间选择的问题，而是如何对抗剥削体系本身的问题。

增加版权保护并非解决方案，因为过去40年版权扩张的同时，创意工作者收入占比却持续下降。当创意工作者只能与少数强大卡特尔谈判时，更多版权如同给被霸凌学生更多午餐钱——霸凌者只会夺走一切。

作者建议创意工作者将自己视为劳动者而非企业家，通过组织工会和罢工争取权益，如去年编剧工会所做的那样。美国版权局已明确AI生成作品不享有版权，这实际上有利于创意工作者。美国联邦贸易委员会也拥有权力防止AI劳动剥削。

真正的解决方案是创意工作者与其他劳动者团结，争取共同的劳动权利，而不是支持自己的老板去起诉其他大公司。

SquirrelFS: 利用 Rust 编译器检查文件系统崩溃一致性

本文介绍了一种构建持久性内存上崩溃安全文件系统的新方法。该方法的核心是利用 Rust 语言的类型状态模式，在编译时强制执行特定的操作顺序。

主要贡献与方法

• 新颖的崩溃一致性机制：提出了“同步软更新”机制，将崩溃安全性问题简化为对文件系统元数据更新之间顺序的强制执行。
• 构建 SquirrelFS 文件系统：基于上述机制，构建了一个名为 SquirrelFS 的新文件系统，其崩溃一致性保证可在编译时进行检查。
• 实现路径：通过将正确性保证直接融入类型状态本身，SquirrelFS 避免了对单独形式化证明的需求。成功编译即表明系统满足崩溃一致性；若编译出错，则错误信息可为定位和修复缺陷提供起点。

技术实现与优势

• 编译时检查：利用 Rust 编译器的强大功能，在编译阶段（耗时通常仅数十秒）就能验证文件系统的崩溃安全性，将安全性保障左移到开发早期。
• 性能评估：在多种基准测试和应用场景下，与当前先进的文件系统（如 NOVA 和 WineFS）进行对比评估，结果显示 SquirrelFS 能够实现相当或更优的性能表现。

周末项目演变为三年旅程

项目背景

作者Anthony最初希望开发一款跨平台（Windows/Mac）的Markdown安全笔记工具，用于记录密码保护的秘密内容。项目始于一个简单的文本编辑器需求。

初期开发挑战

• 技术选型：采用Electron/React实现跨平台，最终选用Monaco编辑器库（VSCode所用）。
• 发布流程：遭遇重大障碍。Apple商店需要严格的证书审核；Windows商店要求注册企业、建立网站以证明合法性；法国网络安全机构ANSSI需对加密功能进行政府审批。整个过程耗时数月，作者呼吁尊重免费应用开发者。

功能演进：从编辑器到可执行笔记本

• 代码执行：项目开始存储代码片段后，作者决定增加直接执行代码块的功能，使应用转变为“可执行笔记本”。
• 技术复杂性：引入现代语法支持需集成Babel；需编写自定义插件管理NPM依赖；需集成打包工具生成完整依赖包；还需实现代码补全功能。
• 深度定制：对Monaco编辑器进行深度修改和分叉，以修复错误并添加必要功能。用户反馈推动开发者持续添加功能，历时多年。

在线部署：设计集群系统

• 新需求：允许用户将创建的应用、仪表盘和自动化流程部署到线上。
• 复杂性：涉及多服务器扩展、执行环境隔离及应用访问安全。
• 自研解决方案：作者未采用现成方案（如Kubernetes），而是自行设计集群，通过智能代理管理和Docker容器隔离实现，以优化资源利用和安全性。

现状与反思

• 项目能力：当前应用已具备丰富的笔记功能，包括图表创建、通过代码块执行任务，并可部署仪表盘、API和定时任务。
• 个人感想：作者坦言项目规模远超最初设想，作为个人开发者独自承担与有团队和资金支持的竞争产品类似的工作量，但仍充满热情。用户积极反馈是其持续动力。
• 建议：鼓励开发者敢于追梦，但提醒避免选择过于复杂的路径，以保护自身精力。