Tailscale的新互联网愿景

背景与问题

Tailscale团队拥有1990年代局域网（LAN）经验，观察到技术行业虽硬件和语言进步，但日常开发日益复杂。程序员过早关注扩展性，即使大多数任务（如仪表板）无需扩展，导致效率低下，现代软件开发充满繁琐开销。互联网基于错误假设，引入防火墙、NAT等复杂性，连接困难。

新互联网的构建

Tailscale旨在构建新OSI层3（新互联网），基于新假设避免问题。核心是使每个设备获得证书、IP地址、DNS名称和端到端加密，成为对等点，绕过防火墙，消除中心化依赖，降低复杂性。

影响与例子

修复互联网将引发连锁反应：消除云租金，降低开发成本。Taildrop功能示例：通过HTTP PUT直接传输文件，无需云存储，简化过程，展示新互联网的潜力。

採纳与挑战

Tailscale目标是让每个人都使用新互联网，但面临鸡生蛋问题：没有用户就没有应用，没有应用就没有用户。公司策略包括免费提供、推动企业采用和功能优化，以促进全民採纳。

现状与愿景

目前约1/30,000的人使用Tailscale，目标是覆盖所有人。技术世界变化快，新互联网可以像Windows时代一样开启新可能性，使开发更简单、更分布式。

使用 Cloudflare 和定时任务实现免费动态 DNS

本文介绍了一种利用免费 Cloudflare 账户和本地定时任务自动更新 DNS 记录的方案，以替代 NoIP.com 等付费动态 DNS 服务。

核心功能与目的

• 免费替代：完全免费，仅需一个 Cloudflare 账户和运行脚本的机器。
• 自动更新：通过定时任务定期检查并更新本地网络的公网 IP 地址到 Cloudflare 的 DNS 记录。
• IP 变化检测：仅在 IP 地址发生变化时才会向 Cloudflare 发起更新，避免不必要的操作。

配置步骤

1. 准备配置文件

需要在 ~/.cloudflare-noip/ 目录下创建两个 JSON 文件：

• keys.json：存储 Cloudflare API 凭据和区域信息。
  • api_key：通过 Cloudflare 个人资料的 “API Tokens” 创建，需具备 “Edit zone DNS” 权限。
  • email：Cloudflare 账户邮箱。
  • zone_ids：包含网站域名及其对应 Cloudflare 区域 ID 的映射。区域 ID 可在网站概述页面的右下角找到。
• records.json：定义需要更新的 DNS 记录。
  • 一个数组，每个对象包含 record_name (完整子域名)、record_type (如 A 记录)、proxied (是否开启 Cloudflare 代理) 和 website_name (关联的根域名)。
  • 记录的 content 字段将自动由脚本填充为运行机器的当前公网 IP。

2. 设置定时任务

根据操作系统，配置定期运行脚本（main.py）的任务。

• Ubuntu/Debian (使用 cron)：
  • 添加定时任务行，例如：*/1 * * * * cd /path/to/cloudflare-noip && /usr/bin/python3 main.py
  • 可选：重启 cron 服务 sudo systemctl restart cron。
• macOS (使用 launchd)：
  • 在 ~/Library/LaunchAgents/ 下创建 .plist 配置文件。
  • 设置 ProgramArguments 为 Python 解释器和脚本路径。
  • 设置 StartInterval 以秒为单位指定运行间隔 (例如 60 秒)。
  • 使用 launchctl load 命令加载配置。
• Windows (使用任务计划程序)：
  • 打开任务计划程序，创建新任务。
  • 配置触发器 (如每分钟一次)。
  • 配置动作为启动 python.exe 并指向脚本路径。

总结

此方案通过结合 Cloudflare 的 DNS 管理能力和操作系统的定时任务功能，为家庭服务器等动态 IP 环境提供了一个稳定、免费且自动化的域名解析更新方法。用户只需完成初始配置，脚本便会定期检查 IP 变化并自动同步到 Cloudflare，确保域名始终指向正确的 IP 地址。

Stripe 收购 Lemon Squeezy：使数字产品销售更加轻松。

收购背景与公司历程 Lemon Squeezy 创立于 2020 年，旨在简化全球数字产品销售的复杂流程（如税务、防欺诈、退款处理、许可证管理和文件交付）。平台于 2021 年公开推出，九个月内年度经常性收入超过 100 万美元。尽管曾收到多份收购要约和 A 轮融资条款，团队始终坚持寻找合适的合作伙伴以实现长期愿景。

收购原因与协同效应

• 价值观与目标一致：双方均致力于为客户简化销售流程，重视产品质量与用户体验。
• 长期合作关系：Lemon Squeezy 自创立以来一直基于 Stripe 处理支付，收购是双方合作关系的自然深化。
• 互补优势：结合 Lemon Squeezy 的数字产品销售解决方案与 Stripe 的顶级开发者体验、API 标准和支付基础设施，提供更强大的服务。

对客户的影响

• 现有客户将继续获得可靠的产品和服务支持。
• 未来将优化商家记录服务、增强账单支持、打造更直观的用户体验。

未来展望 团队将在 Stripe 支持下继续专注于让数字产品销售变得“轻松简单”，并保持以客户为中心的宗旨。

Linux内核模块编程指南摘要

概述

本指南是学习Linux内核模块编程的综合性教程，以Linux 5.10为基准，涵盖从基础概念到高级主题的完整知识体系。内容分为五大部分：入门指南、核心内核接口、执行上下文、内存时间数据管理和硬件集成。

入门指南（第1章）

• 模块基础：内核模块是可动态加载/卸载的代码片段，用于扩展内核功能而无需重启系统。
• 开发环境：建议在QEMU虚拟机中进行开发，避免破坏宿主系统。指南提供了devtools/目录下的自动化脚本。
• 第一个模块：介绍了"Hello World"模块的编写、编译、加载和卸载流程，强调使用module_init()/module_exit()宏，以及__init/__exit宏优化内存。

核心内核接口（第2章）

• 字符设备驱动：详解file_operations结构体、设备注册（register_chrdev或cdev接口）、/proc文件系统接口。
• /proc文件系统：介绍proc_ops结构体、读写操作、seq_file接口管理大输出。
• sysfs和debugfs：sysfs提供设备模型的用户空间接口；debugfs用于调试信息输出。
• 设备文件通信：涵盖ioctl系统调用、poll/select/epoll接口和异步通知。

执行上下文和控制流（第3章）

• 系统调用：模块可拦截系统调用（需注意现代内核限制）。
• 阻塞与同步：包括睡眠机制、完成量（completions）、互斥锁（mutex）、自旋锁（spinlock）、读写锁和原子操作。
• 中断处理：上下半部机制、线程化中断、工作队列。

内存、时间和数据移动（第4章）

• 内存管理：强调GFP_KERNEL与GFP_ATOMIC的区别，介绍kmalloc、vmalloc、设备管理API（devm_*）。
• DMA操作：DMA映射、散列表（scatter-gather）、所有权规则。
• 时间处理：内核定时器、延迟函数、高分辨率定时器。

硬件集成和高级主题（第5章）

• 硬件交互：GPIO控制、LED和DHT11传感器实例。
• 设备驱动模型：平台设备、PCI驱动、USB驱动、块设备驱动、网络驱动。
• 设备树：设备树与模块交互方式。
• 优化与陷阱：likely/unlikely优化、静态键、常见编程错误（如禁止中断、栈溢出、浮点使用等）。

关键概念总结

• 开发实践：始终在虚拟环境中测试，遵循内核编码风格，妥善处理错误路径。
• 并发控制：根据执行上下文选择合适的同步原语。
• 内存安全：正确区分用户空间和内核空间指针，使用copy_to_user/copy_from_user等函数。
• 现代内核趋势：推荐使用设备管理API、线程化中断、refcount_t等新接口。

本指南通过丰富的代码示例和深入的技术解释，为内核模块开发提供了从入门到精通的完整学习路径。

扩展百万复选框至6.5亿次勾选的技术挑战与解决方案

项目概况

2024年6月26日，作者仅用2天开发并上线了"One Million Checkboxes"网站。该网站包含一个全球共享的百万级复选框状态，任何用户勾选都会即时同步给所有在线用户。上线后意外爆红，吸引了来自Hacker News、Reddit、Mastodon、Twitter以及《华盛顿邮报》、《纽约时报》等主流媒体的关注。尽管最初预期仅数百用户，但上线数小时内即涌人数万用户，两周内累计产生6.5亿次勾选操作。

初始技术架构

网站采用相对简单的技术栈：

• 数据结构：使用100万位（125KB）的位图存储复选框状态
• 前端：React应用，通过react-window虚拟滚动渲染可视区域内的复选框，避免DOM过载
• 后端：两个Flask服务器进程，通过Nginx反向代理提供服务
• 数据存储：Redis存储位图状态，利用其原生位操作（getbit/setbit）和发布订阅功能实现状态同步
• 通信：WebSocket连接实现实时更新，客户端定期接收完整状态快照（每30秒）

核心逻辑通过Redis的Lua脚本实现原子性的位操作和计数器更新，确保数据一致性。

面临的扩展挑战与解决方案

第一天：流量激增与成本控制

上线30分钟即遭遇严重负载压力。主要应对措施：

1. 水平扩展：快速增加Flask工作服务器数量，最终扩展到8个worker虚拟机
2. 批量更新优化：将单个WebSocket消息合并为批量更新，显著降低连接压力
3. 连接管理：引入Redis连接池，减少连接开销
4. 带宽控制：
   • 优化更新消息格式，将字典列表压缩为两个索引数组
   • 使用Linux tc工具硬性限制出口带宽至250Mbit/s
   • 发现实际带宽消耗远低于恐慌性计算结果

第二天：输入验证与稳定性问题

1. 输入验证缺陷：用户提交了超出百万范围的复选框索引，导致状态异常。通过截断Redis数据并添加严格验证快速修复
2. 读取负载：添加Redis只读副本分担主库压力
3. 进程稳定性：编写监控脚本自动重启崩溃的Flask进程，配合Nginx健康检查提升可用性

第三天：状态同步问题

发现经典的"旧更新覆盖新状态"问题，通过以下方案解决：

1. 为所有状态快照和更新添加时间戳
2. 客户端丢弃时间戳早于最新快照的更新批次
3. 批量更新包含最大时间戳用于客户端校验

后端重写与性能飞跃

在朋友协助下，用一天时间将整个后端从Python Flask重写为Go语言版本：

• 性能提升显著：CPU使用率大幅下降，处理能力显著增强
• 需要调整策略：由于处理能力过强，需要重新实施更精细的速率限制
• 安全性加固：遭遇DDoS攻击后，引入Cloudflare防护

网站优雅关闭

在上线两周后实施渐进关闭策略：

1. 冻结机制：如果复选框在特定时间内未被取消勾选，则自动冻结
2. 技术实现：
   • Redis哈希表记录每个复选框的最后勾选时间
   • 新增"冻结位图"存储已冻结的复选框状态
   • 所有关键操作封装在Lua脚本中保证原子性
   • 定期任务扫描并冻结超时的复选框

经验总结与技术反思

1. 快速迭代的价值：初始版本无需追求完美，应在验证需求后再优化
2. 技术选型：Redis和Nginx证明了其可靠性；自托管方案虽增加运维工作，但提供了更大的控制权和调试便利
3. 成本效益：总运行成本约850美元，通过捐赠基本覆盖
4. 用户需求洞察：匿名、受限的集体互交体验具有强烈吸引力
5. 关键学习点：
   • 高强度低风险环境是绝佳的学习场景
   • 带宽和连接管理往往是扩展中的隐藏挑战
   • 状态同步需要严格的时间戳和版本控制
   • 有时"足够好"的临时解决方案比完美但耗时的方案更实用

项目最终于7月11日成功关闭，第491915号复选框成为最后一个被冻结的状态，为这个意外的互联网实验画上了句号。

基于经典卡西欧F-91W的可编程智能手表项目：实现TOTP令牌与自定义表盘

项目概述

作者通过Sensor Watch项目提供的替换逻辑板，将经典卡西欧F-91W石英手表改造为可编程智能设备。新板卡采用ARM Cortex M0+处理器，保留原表LCD显示器、按钮和蜂鸣器，实现低功耗长续航（数月）且无蓝牙连接。项目提供易修改的表盘和工具应用，并支持基于WebAssembly的模拟器进行开发测试。

主要功能实现

TOTP双因素认证令牌

• 通过替换逻辑板和编程，将Google、GitHub等账户的TOTP（基于时间的一次性密码）密钥集成到手表。
• 操作方式：按MODE键进入TOTP表盘，用ALARM键切换不同账户的验证码。
• 配置流程：
  1. 从目标网站获取TOTP密钥或二维码
  2. 通过在线工具提取Base32编码的密钥并转换为十六进制
  3. 在totp_face.c源文件中添加密钥数据、设置密钥数量和标签
  4. 重新编译烧录固件

自定义速率计表盘

• 用于划船节拍或踏频测量，通过定期按ALARM键记录时间间隔自动计算每分钟频率。
• 显示逻辑：实时显示计算速率（0-500范围），超出范围显示"Hi"或"Lo"。
• 开发实现：通过ratemeter_face_loop主函数处理按钮事件和计时器，利用watch_display_string函数格式化输出到七段显示器。

其他功能与资源

• 预置表盘包括：世界时钟、日出日落计算、月相指示、温度传感器读数、24小时设置器、时间日期设置等。
• 项目提供完整源代码和开发文档，用户可进一步开发如脉搏计、太阳系仪等更多应用。
• 作者推荐通过Oddly Specific Objects获取Sensor Watch套件，并提及已计划将板卡移植到橙色表壳中。

本文深入探讨了操作系统的技术本质、商业模式、文化内涵及其演变历程，主要观点如下：

1. 操作系统的历史与隐喻

• 起源与商业化： 作者回顾了苹果（Macintosh）和微软（Windows）在操作系统领域的开创性商业尝试，指出操作系统作为一种无形“产品”的非凡之处。
• 汽车比喻： 用生动的汽车比喻概括主要操作系统：
  • Microsoft Windows：庞大、笨重但成功的“旅行车”或越野车（Windows 95/NT），市场占有率高，但技术美学不佳。
  • Apple Macintosh：精致、封闭的“欧式轿车”，设计优雅但价格昂贵、硬件垄断，形成特定用户文化认同。
  • Linux：免费、强大、高度可定制的“坦克”（由志愿者在“营地”免费分发），技术优越但使用门槛高。
  • BeOS：技术先进、设计新颖的“蝙蝠车”，但市场份额小，面临挑战。

2. 操作系统的技术本质与抽象层次

• 命令行（CLI）到图形界面（GUI）的演变： 从电报机、打字机式的命令行界面（如Unix、DOS）到图形用户界面（Mac, Windows）的革命性转变。
• GUI的本质是隐喻： GUI通过“桌面”、“窗口”、“文件”、“保存”等隐喻简化交互，但这些隐喻并非精确，可能引发“隐喻失真”（如“保存”实为覆盖旧版本）。
• 底层仍是“电报”： 无论界面多华丽，计算机底层处理的仍是线性字节流（类似电报），GUI是站在这个底层之上的复杂抽象层。

3. 商业模式与市场格局

• 操作系统市场的“死亡陷阱”： 作者认为操作系统技术本质是通用库，应趋向免费（如Linux）。商业模式依赖生态绑定（应用软件、硬件）和持续添加新功能（如集成浏览器）来维持。
• 微软的统治与潜在危机： 微软凭借Windows的市场主导地位（“心智份额”）建立了庞大生态，但面临开源系统（Linux）免费且技术强大的根本挑战。其应用软件的优越性可能被其操作系统地位下滑所拖累。
• 苹果的封闭与困境： 苹果的硬件垄断策略曾被视为优势，实则限制了市场扩大，是其衰落的原因之一。其设计文化和美学吸引力形成了独特的用户忠诚度。
• 新兴系统（BeOS）的挑战： BeOS代表了从零开始、避免历史包袱（“cruft”）的技术理想，具备现代内核和优秀GUI，但面临驱动支持、市场份额和可持续性的严峻挑战。

4. 文化观察：莫洛克与埃洛伊

• 用户群体的分化： 作者将用户分为两类：
  • 莫洛克（Morlocks）： 理解技术、追求控制力的“黑客”或技术人员，偏好命令行、开源系统（如Linux）或底层控制。
  • 埃洛伊（Eloi）： 大众用户，依赖直观的界面（GUI），希望技术被简化、包装好，追求便利而非理解。GUI和主流OS的成功很大程度上服务于埃洛伊的需求。
• 界面即文化： 操作系统界面（如GUI、迪士尼主题公园）是强大的文化媒介，能塑造认知和价值观（如对简洁、选择和隐喻的依赖）。命令行代表更直接、更底层的沟通方式。

5. 技术哲学与反思

• “隐喻失真”的代价： GUI的便利性伴随着信息隐藏和理解的模糊性，可能导致用户在系统出错（如文件丢失）时感到困惑和无力。
• 命令行的价值与宇宙操作系统隐喻： 作者推崇命令行提供的精确控制和强大功能（类比Unix），并上升到哲学高度，设想了一个使用命令行创造宇宙的“神级黑客操作系统”，强调了底层控制的根本力量。
• 未来展望： 尽管GUI主导，但命令行界面（在终端窗口中）仍不可或缺。理想的操作系统可能结合了GUI的易用性和CLI的底层强大功能（如BeOS的设计理念）。操作系统市场的未来格局取决于技术本质、商业模式、用户文化和开源运动的共同作用。

总结： 本文超越了单纯的技术评测，将操作系统置于历史、技术、商业和文化的多维透镜下审视。作者认为，GUI的流行反映了大众对简化的需求，但命令行所代表的底层控制和精确性依然具有根本价值。市场由微软的生态主导，但面临着以Linux为代表的免费、开源模式的根本挑战，新兴系统如BeOS则试图在技术理想与市场现实间寻找出路。最终，操作系统不仅是工具，更是塑造我们与技术互动方式乃至思维方式的“隐喻”和“文化”。

PCI-e 驱动初始化与内存映射

文章介绍了如何通过编程方式获取并映射 PCI-e 设备的内存地址。通过定义 pci_driver 结构体（包含设备 ID 表和 probe 探测函数），在 probe 中启用设备、请求 BAR（Base Address Register）区域，并使用 ioremap 将物理地址映射为内核虚拟地址，从而建立内核与设备内存的访问通道。

字符设备与用户空间接口

为允许用户空间与设备交互，驱动注册了字符设备（cdev），并实现 open、read 和 write 文件操作。利用 container_of 宏，在 open 中获取驱动状态结构体并存入 file->private_data。初期的读写操作依赖 CPU 逐字（DWORD）进行数据拷贝，该方式在传输较大数据（如图像帧）时会导致 CPU 占用高且速度极慢。

DMA 加速数据传输

为解决 CPU 拷贝的性能瓶颈，文章引入了 DMA（直接内存访问）机制。通过 MMIO（内存映射 I/O）将特定地址作为寄存器，用于传递 DMA 参数（方向、源地址、目的地址、长度）并下发执行命令。内核驱动使用 dma_map_single 映射内存后触发硬件 DMA，使数据传输耗时从约 800ms 大幅缩减至 300us。

MSI-X 中断与阻塞写入

由于 DMA 是异步执行的，为实现阻塞式写入，文章配置了 MSI-X（消息信号中断）。在 QEMU 和内核中初始化 MSI-X 向量表，分配 IRQ 并注册中断处理函数。通过调用 pci_set_master 授予设备 Bus Master 权限，使其能直接向 CPU 发送中断消息。结合内核等待队列（wait queue），在 DMA 完成并触发中断时唤醒休眠的写进程，实现了高效的同步阻塞写入。

QEMU 图形输出集成

最后，文章演示了如何将设备的帧缓冲区（framebuffer）与 QEMU 图形控制台集成。通过初始化 QemuConsole 并实现 vga_update_display 回调函数，将设备内存中的像素数据实时同步到 QEMU 的显示表面（DisplaySurface），从而在 QEMU 窗口中直观渲染并验证用户空间写入的图像数据。

gg 图表编辑器概述

gg 是一款免费开源的图表编辑器，用于创建流程图、组织结构图、思维导图、过程图、网络图、数据库图表等多种类型的图表。它旨在通过简洁的用户界面和创新的布局方法，帮助用户轻松制作复杂图表。访问 https://gg-charts.com 即可开始使用。

核心特性

• 免费开源：可免费使用并查看源代码。
• 移动友好：适用于移动设备。
• 隐私友好：注重用户数据隐私。
• 离线优先：支持离线使用。
• 本地文件支持：可以打开和保存本地文件。
• 辅助布局：提供布局辅助功能，简化图表排版。
• 快速UI与渲染：界面响应迅速，渲染流畅。
• 演示模式：支持将图表用于演示展示。
• 多选操作：可同时选中多个图表元素。
• 导出为PNG：支持将图表导出为PNG图片格式。
• 暗色模式：提供深色界面主题。
• 无限画布：编辑空间无边界限制。
• 撤销/重做：支持操作历史的回退与前进。
• 复制/粘贴：支持元素的复制与粘贴。
• 其他更多功能。

使用方式

可以通过嵌入 iframe 来将 gg 查看器集成到网页中。示例代码如下：

<iframe
  width="640"
  height="480"
  src="https://gg-charts.com/viewer.html#file=...">
</iframe>

开发信息

参与开发需克隆代码仓库并运行。具体步骤为克隆仓库后运行相应的命令（原文此处未完整列出命令）。

英特尔13/14代CPU崩溃问题：损伤不可逆，补丁仅为预防

英特尔已确认，其第13代和第14代桌面CPU的崩溃问题源于高电压造成的永久性物理损伤，且此损伤无法通过软件或固件修复。英特尔计划于8月中旬发布的微码补丁旨在预防该问题，防止电压过高，但对于已出现症状的CPU，该补丁无法修复已发生的损坏。

问题核心与影响范围

• 根本原因：CPU长期暴露于过高电压导致不可逆的性能衰退。此外，英特尔社区经理透露，部分不稳定报告可追溯至去年已修复的氧化制造问题。
• 影响型号：任何功耗65W或以上的第13代和第14代桌面CPU都可能受影响，不仅限于高端i9型号，包括K/KF/KS系列及65W非K变体。
• 损坏性质：处理器一旦出现降级或崩溃，即表示已发生永久硬件损坏。

英特尔的回应与措施

1. 补丁发布：微码更新计划在8月中旬前发布，旨在通过限制电压来预防问题。该补丁将通过BIOS更新提供给最终用户。
2. 延保政策：英特尔宣布对24款特定型号的第13/14代CPU提供额外两年保修。此前曾因RMA请求被拒的客户，被要求重新联系客服寻求补救。
3. 召回与销售：英特尔明确表示不会召回这些CPU，也不会暂停销售或撤回渠道库存。
4. 诊断方法：目前，英特尔建议用户使用Robeytech测试（发布于Reddit的视频）来识别CPU是否存在问题，并表示正在研究更便捷的识别方法。
5. 建议措施：在补丁发布前，英特尔建议用户确保将主板BIOS更新至最新版本，并使用英特尔默认设置。

待解答的问题与用户行动建议

英特尔在面对如何联系受影响客户、如何简化RMA流程等关键问题时，尚未给出具体答案。

对于用户而言：

• 已出现症状：如果CPU已出现崩溃，应联系英特尔客服申请更换，因为损坏是永久性的。
• 尚未出现问题：应尽快更新主板BIOS以应用即将到来的预防性补丁，并考虑将BIOS设置调整为英特尔默认配置，以降低风险。
• 移动平台：英特尔表示正在调查为何笔记本电脑的移动版CPU似乎未受相同问题影响。

CIE 1931色度图的形状源于人类视觉系统感知颜色的方式。该图通过实验确定，展示了不同波长光色在色度坐标中的位置。其核心机制如下：

1. 颜色匹配函数：1931年的实验通过让观察者调节红、绿、蓝光（波长700、546、435纳米）的强度，来匹配单色光（光谱色），从而得到RGB颜色匹配函数。这些函数描述了混合RGB光以匹配特定波长光所需的强度比例。

2. XYZ色彩空间转换：由于RGB颜色匹配函数存在负值（表示某些光谱色无法用纯正RGB光再现），CIE通过线性矩阵变换将RGB数据转换为XYZ色彩空间，使所有值均为正。XYZ空间是设备无关的标准色彩表示方式。

3. 色度图生成：通过归一化XYZ值（x = X/(X+Y+Z), y = Y/(X+Y+Z)）得到二维色度坐标(x, y)，并丢弃明度信息Z。将所有可见光谱色的(x, y)坐标绘制后，即形成色度图的舌形轮廓。

4. 图内颜色填充：通过光谱采样与积分近似生成图内颜色。具体方法是：生成光谱分布曲线，分别与XYZ和RGB颜色匹配函数相乘并积分，得到XYZ和RGB值，再将RGB值映射到色度坐标。图中白点位于中心，边缘对应光谱单色光，内部为混合色。

5. 形状本质：色度图的形状直接由XYZ颜色匹配函数（源于人类视觉实验）决定。通过改变这些函数，可生成不同形状的色度图，从而验证该形状反映了人眼对红、绿、蓝光的相对感知特性。

文章还指出，实际显示的颜色受RGB色域限制，色度图边缘颜色在普通显示器上无法精确再现，但可通过广色域显示技术（如Display P3）扩展可显示范围。

Linux 网络性能终极指南

核心概念：Linux 网络协议栈

Linux网络性能优化基于对其网络协议栈的深入理解。协议栈处理数据包从硬件到应用的完整生命周期。本文详细剖析了数据包接收和发送的内部流程，并提供了从硬件到软件各层的调优方法，以及突破内核性能瓶颈的高级技术。

数据包接收流程

数据包接收是一个复杂的多阶段过程：

1. 硬件阶段：网卡（NIC）通过DMA将数据包写入环形缓冲区，并触发硬件中断（HardIRQ）。
2. 内核处理：
   • 驱动处理中断，禁用该中断并调度NAPI（新API）开始轮询。
   • 内核通过ksoftirqd内核线程执行软中断（SoftIRQ, NET_RX_SOFTIRQ），从环形缓冲区批量收割数据包。
   • 数据包经过通用接收卸载（GRO）聚合，然后通过netif_receive_skb进入协议栈。
3. 协议处理：数据包依次经过网络过滤器（Netfilter）、路由决策、传输层协议（如TCP/UDP）处理，最终到达用户空间套接字的接收缓冲区。

数据包发送流程

发送流程相对简单但关键：

1. 应用程序写入数据，内核将其封装并放入套接字发送缓冲区。
2. 经过TCP/IP协议栈构建报文头、执行Netfilter过滤、路由选择和分片。
3. 最终交给设备驱动，通过软中断（NET_TX_SOFTIRQ）控制，将数据包放入网卡的发送环形缓冲区，并由DMA发送。

网络性能调优技术

1. 监控基础工具

• /proc/net/softnet_stat：监控每个CPU核心的网络数据包处理情况，如接收总数、因backlog队列满而丢弃的包数、因软中断预算耗尽而需要重新调度的次数。
• /proc/net/sockstat：查看各类套接字的使用数量和内存占用。
• ss -m：查看套接字的详细内存使用情况（接收/发送缓冲区、缓存等）。
• sysctl：查看和临时/永久修改内核网络参数。

2. 网卡（NIC）层调优

• 环形缓冲区：使用ethtool -G增大接收（RX）和发送（TX）环形缓冲区，以应对突发流量，减少丢包。
• 中断聚合：通过ethtool -C调整硬件中断触发条件（如rx-usecs、rx-frames）。在吞吐量和延迟间权衡：更高的聚合可减少CPU中断开销，但会增加延迟。
• IRQ亲和性：将特定硬件中断绑定到指定CPU核心，减少跨CPU缓存失效。可通过写/proc/irq/<IRQ>/smp_affinity实现。

3. 负载均衡与多队列

为解决单CPU处理瓶颈，利用多核CPU并行处理数据包：

• RSS：网卡硬件特性，通过哈希将数据包流分配到多个接收队列，每个队列中断可绑定到不同CPU。
• RPS：软件实现的RSS，在驱动提交数据包后，通过哈希将其分配到不同CPU的backlog队列进行后续处理。
• RFS：在RPS基础上，将数据包流导向正在处理该连接的用户线程所在的CPU，提高缓存局部性。
• aRFS：RFS的硬件加速版本，由网卡直接实现流导向。

4. 内核子系统调优

• 软中断预算：调整net.core.netdev_budget（每次软中断处理的最大包数）、net.core.netdev_budget_usecs（最大时间）和net.core.dev_weight（每CPU权重），防止软中断占用过多CPU。
• 输入队列：调整net.core.netdev_max_backlog（每个CPU的输入数据包队列长度），应对高包速率。
• 输出队列与调度：调整txqueuelen（每个网络设备的发送队列长度）和net.core.default_qdisc（默认排队规则，如fq_codel），管理发送缓冲和流量控制。
• TCP缓冲区：调整net.ipv4.tcp_rmem（接收缓冲区最小、默认、最大值）和net.ipv4.tcp_wmem（发送缓冲区），并可能调整net.core.rmem_max/wmem_max作为上限，以优化TCP吞吐。
• 连接管理：调整net.core.somaxconn（监听队列最大长度）、net.ipv4.tcp_max_syn_backlog（SYN队列长度）、net.ipv4.tcp_fin_timeout（FIN等待超时）以及拥塞控制算法（net.ipv4.tcp_congestion_control）。

5. NUMA架构优化

在NUMA系统中，确保网络设备及其中断绑定的CPU位于同一NUMA节点，以减少跨节点内存访问延迟。可使用numad守护进程或numactl工具辅助管理。

高级数据包处理技术

为追求极致性能，可绕过或改造内核协议栈：

1. 零拷贝与内核旁路

• AF_PACKET v4 & PACKET_MMAP：提供高性能的原始套接字接口，通过内存映射（mmap）在用户空间和内核间共享环形缓冲区，减少系统调用和数据拷贝。
• DPDK：一个完全在用户空间运行的库和驱动框架。它将网卡从内核驱动解绑，使用轮询模式驱动（PMD）直接收发包，避免了内核协议栈开销，实现极高性能，但需要专用CPU核心且开发复杂。

2. 可编程数据路径

• XDP：eXpress Data Path。它在网卡驱动层，甚至在内核分配sk_buff之前，通过eBPF程序对“原始”数据包页进行处理。它不是旁路内核，而是在内核中添加了一个高速路径。
  • 动作：支持丢弃、转发、重定向（到内核栈、另一个XDP程序或AF_XDP套接字）、修改等。
  • 优势：高性能、可编程、无需专用硬件、与内核集成。
  • AF_XDP：一种新的套接字类型，配合XDP程序，可实现零拷贝地将特定队列的数据包直接传递到用户空间应用，性能介于传统AF_PACKET和DPDK之间。
• PF_RING：一个内核模块和用户空间框架，通过NAPI和环形缓冲区实现高速数据包捕获，并提供零拷贝（ZC）等模块。

SQLite文件系统 (sqlite-fs) 项目概述

项目简介 sqlite-fs 是一个允许在Linux和MacOS操作系统上将SQLite数据库文件（.sqlite）挂载为标准文件系统的工具。它通过FUSE（用户空间文件系统）实现，使得用户可以使用常规的文件操作命令（如cat, echo, cp）来管理存储在SQLite数据库中的数据。

系统要求

• 编程语言：需要最新版本的 Rust（≥ 1.38）。
• FUSE依赖：底层依赖于fuse-rs库，因此在Linux上需要安装libfuse，在MacOS上需要安装osxfuse。

使用方法

• 挂载文件系统：通过命令行执行 sqlite-fs <挂载点> [<数据库文件路径>]。
  • 若指定的数据库文件不存在，程序会自动创建该文件及所需的表结构。
  • 若不指定数据库文件路径，则使用内存数据库。所有数据将在文件系统卸载时被永久删除。
• 卸载文件系统：
  • Linux：使用 fusermount -u <挂载点> 命令。
  • MacOS：通常使用 umount <挂载点> 或系统提供的相应命令。
• 示例：
  1. 后台挂载：sqlite-fs ~/mount ~/filesystem.sqlite &
  2. 创建文件：echo "Hello world\!" > ~/mount/hello.txt
  3. 读取文件：cat ~/mount/hello.txt 将输出 Hello world!

功能实现状态 该项目已实现以下核心文件系统功能：

• 目录操作：创建、读取、删除目录。
• 文件操作：创建、读取、写入、删除文件。
• 属性修改。
• 文件管理：复制和移动文件。
• 链接支持：创建硬链接和符号链接。
• 扩展属性：读写扩展属性。

待实现功能 以下功能尚未完成：

• 文件锁操作。
• 严格的错误处理机制。

Zen 5的2-Ahead分支预测器是AMD对Zen架构进行彻底重新设计的核心创新之一，其技术根源可追溯至三十年前的学术研究。该设计旨在提升现代超标量处理器中至关重要的前端取指效率，以应对因指令流水线深化和分支密集带来的性能挑战。

分支预测的重要性 在流水线处理器中，分支指令会导致前端取指单元无法及时获知下一条指令地址，可能引发流水线停顿。为维持高吞吐，处理器必须准确预测分支方向和目标。传统预测器通过记录分支历史与地址来提升准确率，但面对更宽发射宽度和深流水线，仍存在带宽瓶颈。

2-Ahead预测器的核心思想 该技术最早由Seznec等人在1990年代提出，其关键突破在于每周期可预测两个分支目标，而非传统的一个。这允许前端在遇到第一个分支后，能立即跨越到下一个基本块继续取指，甚至提前获取第三个预测窗口的信息。为实现这一点，研究论文建议对指令取指单元、分支目标缓冲区进行双端口化。

x86架构的特殊受益 文章特别指出，x86变长指令集架构的解码需要线性解析指令边界，难以并行处理。2-Ahead预测器通过预测连续的基本块起点，帮助前端“跳过”一部分解码工作，实质上减轻了非并行解码阶段的压力，这对追求多发射的x86核心尤为重要。

AMD在Zen 5中的具体实现

• 双取指管线：从32KB L1指令缓存中引出两条每周期32字节的取指管线，分别馈送两个4宽度解码簇。
• 双端口操作缓存：操作缓存改为双端口、6宽度设计，可向操作队列输送12个操作数。
• 改进的BTB结构：L1分支目标缓冲区容量增至16K条目，并采用双端口；L2 BTB（8K条目）作为受害者缓存，容纳从L1 BTB换出的条目。
• 预测窗口管理：通过附加的5位长度字段界定第二个预测窗口，从而为第三个预测窗口提供起始位置，避免解码或操作缓存资源过载。

性能影响 该设计使Zen 5每周期能处理两个非连续分支，显著减少了遇到分支时的取指带宽损失，并允许前端提前获取更远的指令流。在双线程模式下，双取指管线可静态分配给两个线程，结合双端口操作缓存，维持双取指管线的持续供给。

历史背景与未来展望 随着工艺节点进步，单核性能重新成为焦点，这些早期学术思想得以在商业设计中落地。Zen 5的2-Ahead预测器不仅是对历史研究的实践，也为后续架构（如Zen 6）奠定了基础，体现了AMD在微架构前沿的探索。

Windows 部署镜像定制工具包

该工具是一款基于命令行的原生Windows镜像部署工具，旨在以精简的体积（约200KB）创建Windows恢复环境和可启动USB驱动器。

核心特性与用户反馈

从用户评价中可以提炼出该工具的主要特点：

• 功能强大且集成度高：被比作集Rufus、NTLite、RebootPro、WinUtil和WinBackup等多款知名工具功能于一身，且被认为更强大。
• 高效简洁：用户认为它比以往使用的任何工具都更简便，但这种简便性建立在用户具备相关知识的基础上，体现了“专业”而非“傻瓜化”的设计理念。
• 功能全面：用户称赞其“可以做任何事”，覆盖了从镜像定制、部署到创建恢复环境的广泛需求。
• 获得业界关注：有评论指出其更新和底层理念被其他大型软件借鉴，显示了其在该领域的影响力。

资源与支持

该工具在多个主流软件下载平台提供镜像下载，并拥有详尽的文档和官方技术资源支持，包括GitHub上的文档仓库、微软技术百科的相关指南以及官方YouTube频道。

BiVACOR研发的全磁悬浮钛合金人工心脏首次成功植入人体，这是一项重大医疗技术突破。该设备采用类似高速磁悬浮列车的技术，核心是一个由磁场悬浮的转子，作为唯一的活动部件，取代病变心脏的两个心室进行泵血。其钛合金结构和无摩擦设计避免了传统人工心脏中柔性聚合物隔膜易磨损的问题，理论上可显著延长使用寿命。设备能以每分钟12升的速率泵血，足以支持成年男性进行运动，并由外部可充电控制器驱动。

此次植入是美国食品和药物管理局监督下的一项早期可行性研究的一部分。目前，该人工心脏仅作为终末期心衰患者等待心脏移植期间的过渡支持装置。全球心衰患者超过2600万人，心脏移植需求在过去三十年间翻了一番，目前有超过3400人在等待移植。如果临床试验成功，这项技术有望为更多等待移植的患者提供生命支持。

接下来，该设备将植入另外两名患者体内，进行更密切的监测和下一阶段临床试验。

Bril：用于编译器教学的中间语言

Bril（Big Red Intermediate Language）是作者为支持编译器课程实践项目而创建的中间语言。它并非为工业级编译器设计，而是专门为教学量身定制，优先考虑以下目标：

• 快速上手：降低初始学习门槛。
• 易于组合：方便学生混合使用各种工具，包括同学编写的组件。
• 语义简单：避免过多复杂性干扰学习核心概念。
• 语法高度规整：保证一致性和可预测性。

设计选择与权衡

1. JSON 作为规范格式

Bril 程序以 JSON 文档形式存在。这种设计有以下教学优势：

• 语言无关：学生可以使用任何熟悉的编程语言进行处理。
• 无需框架：无需学习额外的 API 即可开始工作。
• 支持管道组合：可通过 Unix 管道（如 cat code.json | my_opt | brilck）串联工具，便于学生共享和组合代码。
• 生态系统灵活：虽然存在针对特定语言的库，但并非强制依赖，保持了入门的简便性。

尽管 Bril 也提供了文本形式（@main { v0: int = const 1; ... }），但作者强调文本形式仅为便利的第二选择，JSON 才是语言本身。这种权衡换取了生态系统的高度模块化和可组合性。

2. 语言特性与教学考量

• 核心操作码包含 print：便于编写和验证小型示例程序。
• 严格的 A 范式：常量必须单独声明并命名（如 one: int = const 1;），而非直接作为操作数。虽然代码稍显冗长，但简化了对操作数来源（变量或常量）的处理，增强了规整性。
• 可扩展但松散：基于 JSON 的格式易于添加新操作码和类型。现有官方扩展包括手动内存管理、浮点数、JIT 教学用的推测执行、模块导入和字符类型。但缺乏系统化的扩展管理机制。
• 对 SSA 的支持反思：Bril 初始设计不要求静态单赋值形式，包含可变变量。这有三个教学目的：
  1. 让学生体验非 SSA 程序的痛点，理解 SSA 的价值。
  2. 实现到 SSA 和脱离 SSA 的转换练习。
  3. 易于从含可变变量的前端语言生成代码。 然而，后期添加的 phi 指令带来了持续的正确性问题（如未定义行为和脱离 SSA 转换的错误）。作者反思认为，将 phi 仅视为普通指令而非对语言的根本性扩展是一个设计失误，需要彻底重构（可能借鉴 MLIR 的基本块参数）。

生态系统与演变

Bril 最初由作者在 2019 年秋季课程前匆忙构建。得益于课程的“开源”性质，学生已贡献了众多工具和语言扩展（如内存、函数调用、浮点数）。生态系统包含解析器、优化器、验证器、代码生成器以及一个网络演示平台。工具和扩展分布在多个代码库中，体现了协作开发的成果。

总结

Bril 是一个以教学为中心的中间语言，通过 JSON 格式、简洁规整的语法和特定的设计选择（如严格的 A 范式、初始非 SSA），降低了编译器实现的入门难度，并鼓励学生通过实践和协作学习核心概念。尽管在某些设计（如 SSA 的后期集成）上存在教训，但其成功的教学实践和不断发展的生态系统证明了其在教育领域的价值。

朗兰兹纲领几何版本获证：三十年奋斗的数学里程碑

一个由九位数学家组成的团队成功证明了几何朗兰兹猜想，这是现代数学中最为宏大的理论框架——朗兰兹纲领——的一个关键组成部分。该证明历经三十年研究积累，是数学界期待已久的重大突破。

朗兰兹纲领：数学的“罗塞塔石碑” 朗兰兹纲领由罗伯特·朗兰兹于1960年代提出，本质上是傅里叶分析的一种深远推广。在经典傅里叶分析中，复杂的波可以分解为纯正弦波（频率）的组合，反之亦然。朗兰兹猜想在数论、几何和函数域这三个数学领域中存在类似的“波”与“频率”之间的对应关系，这三个领域通过一系列深刻的类比（被比作“罗塞塔石碑”）相互联系。

几何版本的特殊性 在几何栏（涉及紧黎曼曲面，如球面、环面等）中，“波”被更为抽象的“特征层”所替代，而其“频率”则与黎曼曲面的基本群的表示相对应。尽管在1980年代，德林菲尔德提出了这一几何对应的想法，但如何系统地构建特征层以及精确表述对应关系，长期悬而未决。贝林松和德林菲尔德后来利用共形场论构造了一类特殊的特征层，并提出了关于对应关系应如何保持重要结构的“最佳希望”猜想。

证明的历程与关键突破 丹尼斯·盖茨戈里自1990年代中期便致力于几何朗兰兹猜想，他与合作者逐步发展出庞大的工具体系。2012年，他与阿林金将“最佳希望”猜想精确化。2013年，盖茨戈里制定了证明蓝图。

证明的核心在于建立类似于“白噪声”的对象——庞加莱层，它应由所有特征层以相同权重构成。2022年，萨姆·拉斯金及其学生证明了每个特征层确实贡献于庞加莱层。随后，团队解决了最棘手的部分：处理基本群的不可约表示。拉斯金在个人生活的忙碌期间通过与盖茨戈里讨论，找到了将问题简化为三个可证命题的方法。

最终，由盖茨戈里、拉斯金、阿林金、罗森布柳姆等九位数学家组成的团队，在2024年2月在线发布了完整的证明，论文总计超过800页。证明不仅实现了最初的设想，还引入了许多新的简化和发展。

影响与未来展望 该证明的完成被认为是朗兰兹纲领几何栏的全面胜利，其深度和完整性超越了其他栏的已有结果。数学家们需要时间消化这一庞大成果，但对其核心思想的正确性普遍有信心。

这一突破预计将对数学其他领域产生深远影响。研究者正积极尝试将思想从几何栏“翻译”到函数域和数论栏。盖茨戈里和拉斯金等人已在函数域方面取得进展。尽管在数论中缺乏对应的共形场论工具，且翻译过程充满挑战，但2021年法尔格斯和舒尔策发现的“虫洞”为将几何栏的想法直接引入数论朗兰兹纲领的特定部分提供了新路径。

几何朗兰兹猜想的解决，不仅标志着一个重大数学目标的实现，更被认为是一个充满新可能性的开端，其影响有望像“上涨的潮水”一样，渗透并推动相关数学领域的进一步发展。

谷歌修复Workspace账户邮箱验证绕过漏洞

谷歌近期修复了一个认证漏洞，该漏洞允许恶意行为者绕过创建Google Workspace账户所需的电子邮件验证步骤，并利用此缺陷在支持“使用谷歌登录”的第三方服务上冒充域名持有者。

漏洞详情

• 发现时间：恶意活动始于6月下旬。
• 规模：涉及数千个未经域名验证创建的Workspace账户。
• 手段：攻击者通过构造特殊请求，在账户注册流程中绕过电子邮件验证。具体而言，他们使用一个邮箱地址尝试注册，却用另一个不同的邮箱地址来验证令牌。一旦邮箱验证被绕过，这些账户便可被用于通过谷歌单点登录（SSO）访问第三方服务。
• 影响：虽然这些恶意账户未被用于滥用谷歌自身服务，但攻击者借此冒充合法域名持有者，入侵其在其他平台的账户。例如，有报告显示，未经授权的Workspace账户被用于登录受害者的Dropbox账户。

谷歌的应对

• 修复速度：谷歌在发现问题后72小时内完成了修复。
• 防护措施：公司增加了额外的检测机制，以防范未来类似的认证绕过行为。
• 澄清说明：谷歌强调，此次受影响的域名此前均未与Workspace账户或服务关联过。此外，该漏洞与近期一起涉及Squarespace接管的谷歌域名（包括加密货币相关域名）的劫持事件无关，后者是由于Squarespace自身的OAuth登录弱点导致，并已在其声明中确认修复。

Opslane是一个开源工具，旨在改善on-call体验，通过自动化PR的质量检查来减少手动测试负担。它是一个自服务质量保证工具，开发者粘贴工票后，它会驱动真实浏览器（通过Playwright MCP）检查本地开发服务器，验证每个验收标准（AC），并提供带截图的通过/失败报告，直接在Claude Code中内联显示，无需推送代码。

工作原理

1. 规格解读：运行 /verify 时，工具读取工票，提取具体验收标准，并对模糊内容进行澄清。
2. 浏览器验证：像真人一样操作实际应用（点击、输入、导航），根据页面状态判断每个AC是否通过，并记录视频和跟踪信息（仅针对失败案例）。
3. 报告生成：生成机器可读的 verdicts.json 和包含截图、视频的 report.html，并在Claude Code中显示通过/失败摘要。

安装与设置

• 前提：需使用带OAuth登录的Claude Code。
• 安装步骤：在Claude Code中注册市场并安装插件，无需额外配置MCP服务器。
• 初始化设置：运行 /verify-setup（一次），自动检测开发服务器端口、索引路由和选择器，生成 .verify/ 配置文件。

使用流程

1. 运行验证：执行 /verify（自动发现工票）或指定工票路径。
2. 预检查：确认开发服务器运行，并处理登录会话（复用 auth.json）。
3. AC提取与验证：基于 .verify/app.json 中的路由和选择器，提取可测试AC，并逐项在浏览器中验证。
4. 结果输出：每个AC的判定结果（通过、失败、阻塞等）及截图保存在 .verify/runs/<run_id>/ 中，失败项保留视频和跟踪记录以便调试。

核心优势

• 无需编写测试代码：直接基于工票意图操作，自动维护选择器。
• 真实环境测试：在本地开发服务器上运行，非模拟环境。
• 调试友好：失败案例提供视频重放和Playwright跟踪，快速定位问题。

最新更新（v1.1.0）

• 失败AC增加视频和跟踪证据。
• 内联 /verify-setup 技能（无需CLI二进制文件）。
• 基于Playwright MCP的 /verify，一键安装。

常见问题

• 与Playwright区别：Playwright需手动编写测试；Opslane基于工票自动执行意图级检查。
• 认证处理：首次运行引导登录，复用会话文件。
• 选择器稳定性：通过辅助功能树（如“提交按钮”）操作，减少对CSS选择器的依赖。

该项目采用MIT许可证，旨在将手动验证流程自动化，减少因人工疏忽导致的PR问题。

《机器学习面试导论》书籍概要

作者背景与写作动机

本书作者Chip Huyen在机器学习面试领域拥有双向经验：

• 作为候选人，曾参加数十家大型公司和初创企业的面试，并获得过Google、NVIDIA、Snap、Netflix等公司的机器学习职位录用通知。
• 作为面试官，曾在NVIDIA和Snorkel AI参与设计并执行招聘流程，涵盖从简历筛选、技术面试到录用决策的全过程。
• 作为朋友与导师，曾帮助多人准备机器学习面试，并提供模拟面试。
• 此外，作者曾为多家初创公司提供机器学习招聘流程的咨询，观察到行业在评估候选人方面仍存在挑战。

本书凝聚了众多拥有双方面试经验者的集体智慧，主要面向候选人，但招聘经理也反馈其有助于了解行业招聘实践并优化自身流程。

书籍结构与核心内容

全书分为两部分：

第一部分：机器学习面试全景

• 概述机器学习面试的整体流程。
• 介绍当前常见的机器学习岗位类型及各岗位所需的核心技能。
• 分析面试中常见的问题类型及相应的准备方法。
• 阐述面试官的评估视角及其寻找的候选人信号。

第二部分：200余道知识问题

• 包含超过200道机器学习核心概念及常见误区相关题目。
• 每道题目均标注难度级别，指出更高阶的职位通常会遇到更难的问题。

附赠内容：开放式系统设计问题

• 书中包含30道开放式问题，旨在考察候选人整合知识、解决实际挑战的能力。
• 这类问题常被称为**“机器学习系统设计”问题**，也是多数公司在面试中采用的题型，通常被候选人认为难度最高。
• 作者指出该主题复杂且独立，更深入的探讨可参考其在斯坦福大学的课程 CS 329S。

本书定位与使用建议

• 本书并非机器学习教材的替代品，也不是应付面试的捷径。
• 它是一个工具，用于帮助读者：
  • 巩固已有的机器学习理论与实践知识。
  • 识别自身知识体系中的盲区或薄弱环节。
• 每个主题均附有相关学习资源，以辅助读者深化理解。

相关资源

• 本书的网络友好版本可在指定网址阅读。
• 书中问题的源代码存放于GitHub。
• 针对书中问题的讨论社区设在Discord平台。

版权信息

本书由Chip Huyen在朋友协助下完成，版权归作者©2021所有。反馈、勘误及建议可通过指定渠道联系作者。

文章标题：Driving Compilers 摘要

本文是《Driving Compilers》系列文章的引言部分。作者首先对比了学习C/C++语言与学习使用编译工具的不同体验：学习语言本身过程愉快且资料丰富，而学习将代码转化为可执行文件的过程却充满痛苦与挫败，主要原因是缺乏关于编译工具使用的系统文献。大多数编程教材仅在开头简单提及编译命令（如 $ cc hello.c），之后便不再深入。

作者撰写本系列的目的正是为了填补这一空白。本系列不教授编程语言、库、SDK，也不讲解如何编写编译器或链接器。其核心目标是帮助读者超越单文件示例，理解创建可执行文件的核心概念，并提供探索相关工具的“心智地图”。文章将基于可复现的步骤，使用 binutils 和编译器驱动程序的详细模式（-v）来支撑所讲述的内容。

文章的示例环境以 Linux 平台为主，主要使用 gcc 或 clang 编译器驱动程序。文中也提供了 Linux、Mac OS X 和 Windows 平台下的工具链等价关系对照表，涉及目标文件格式、动态库、静态库和可执行文件等。

本系列文章的结构规划如下：

1. 编译器驱动程序：统领整个编译流程的组件。
2. 预处理器：将源代码转换为翻译单元。
3. 编译器：将翻译单元处理为可重定位的目标文件。
4. 链接器：将多个目标文件组合成一个可执行文件。
5. 加载器：进一步理解链接器的输出，探讨程序是如何被加载执行的。

本引言部分之后，文章将首先深入探讨编译器驱动程序。

事件概述

Intel 正式回应了关于第 13 和 14 代酷睿桌面处理器（Raptor Lake）的不稳定问题，明确表示不会召回相关产品，且即将推出的微代码（microcode）更新无法修复已经出现不稳定症状的 CPU。

影响范围

• 桌面端：不稳定问题不仅限于 K/KF/KS 系列解锁处理器，还可能影响基础功耗在 65W 及以上的非 K 系列桌面处理器。
• 移动端：Intel 仍在持续调查，目前不再明确断言移动端（笔记本）处理器完全不受该问题影响。

召回与修复政策

• 无召回与停售：Intel 不会发起产品召回，也未暂停销售或进行渠道库存召回。
• 不可逆损坏：已受不稳定问题影响的 CPU 被视为遭受了不可逆的损坏，微代码补丁无法修复这些已受损的单元。

微代码更新与预防措施

• 发布时间：Intel 计划于 8 月中旬或更早向 OEM/ODM 合作伙伴发布生产版微代码更新。
• 预防作用：该补丁主要作为预防性解决方案，可有效防止尚未出现症状的在用处理器发生退化。对于已受损的处理器，补丁可能提供有限的稳定性改善，但无法根治。
• 应用方式：尚未发货的新处理器将在补丁发布后预装微代码；已投入使用的处理器需通过主板 BIOS 更新来应用补丁。

售后与 RMA（退货授权）支持

• 遇到不稳定症状的用户应直接联系 Intel 客户支持寻求帮助。
• 若用户此前因该问题提交的 RMA 申请被拒绝，可再次联系 Intel 客服寻求补救和换货支持。
• Intel 承诺与零售和渠道客户合作，确保所有受影响用户（包括 13 代产品停产后）的换货流程得到妥善保障。针对晶圆氧化（Via Oxidation）相关报告，Intel 也将全力支持换货。

用户建议

• 在微代码更新发布前，建议用户在桌面处理器上遵循“Intel 默认设置（Intel Default Settings）”，并确保 BIOS 处于最新状态。
• Intel 正在研究相关技术方案，以便在终端用户系统上更轻松地识别已受影响或存在风险的处理器。

Patchwork 是一个开源框架，通过自托管的 CLI 代理和用户选择的 LLM，自动化开发中的重复性工作（如 PR 审查、Bug 修复、安全补丁等）。它支持本地 CLI/IDE 运行或集成到 CI/CD 流水线中。

核心组件

• Steps：可复用的原子操作，例如创建 PR、提交更改或调用 LLM。
• Prompt Templates：针对特定任务（如库更新、代码生成、漏洞修复）优化的自定义 LLM 提示模板。
• Patchflows：通过组合 Steps 和 Prompts 构建的 LLM 辅助自动化流程，例如 PR 审查、代码修复、文档生成等。

安装与使用

• 可通过 pip install 'patchwork-cli[all]' 安装，支持可选依赖组（如 security、rag、notifications）。
• CLI 用法：patchwork <PatchFlow> <?Arguments>，参数以 key=value 格式覆盖默认配置。
• 支持多种 LLM 提供商（如 OpenAI、Google、Groq、Hugging Face）及本地模型（通过 llama.cpp、ollama 等）。

示例

• 运行 AutoFix Patchflow：patchwork AutoFix openai_api_key=<YOUR_OPENAI_API_KEY> github_api_key=<YOUR_GITHUB_TOKEN>
• 可通过配置文件（如 config.yml）或 CLI 参数指定自定义模型和参数。

内置 Patchflows

• GenerateDocstring：为代码方法生成文档字符串。
• AutoFix：基于 Semgrep 扫描生成并应用漏洞修复。
• PRReview：在 PR 创建时提取代码差异、总结变更并评论。
• GenerateREADME：为指定文件夹创建 README.md 文档。
• DependencyUpgrade：将依赖项从易受攻击版本升级到修复版本。
• ResolveIssue：识别需更新的文件以解决 Issue 或 Bug，并创建修复 PR。

Prompt Templates

• 模板中的占位变量（用 {{}} 包围）会在每次运行时由 Steps 或输入数据替换。
• 每个 Patchflow 提供默认优化模板，用户可通过 prompt_template_file 参数自定义。

贡献与路线图

• 欢迎贡献新的 Patchflows、Steps 或对核心框架的改进。
• 短期路线：扩展 Patchflow 库和集成选项、添加调试器/验证模块、优化性能和文档。
• 长期路线：支持大规模代码嵌入、并行化/分支、自托管微调模型和开源 GUI。

许可证

• 核心框架采用 AGPL-3.0 许可证。
• 自定义 Patchflows 和 Steps 可在 patchwork-template 仓库中以 Apache-2.0 许可证创建和共享。

文章标题：Taking a Radio Camping

核心摘要

本文记述了一位业余无线电爱好者为满足早年露营时的通信愿望，携带HF电台与自制天线前往省立公园露营的经历。重点描述了天线制作、野外架设、通信操作及最终成果。

主要内容

1. 动机与准备

   • 作者回忆早年露营时渴望拥有电台，现持照后决定携带HF电台出行。
   • 面临无可用天线的问题，提前一周参考WB3GCK的设计自制了一个使用扬声器线的“终馈半波”天线变体，但因购买不到原规格线材，改用24英尺“灯线”替代，并自行调整了设计。
   • 露营前在超市停车场对天线进行了初步测试，尽管天线尺寸不准、调试粗糙且仅2瓦功率，仍取得了令人鼓舞的结果。

2. 露营操作

   • 在森林营地中，利用树木和帐篷钉架设了约100英尺长的天线，将其环绕营地。
   • 体会到森林环境中电磁噪声极低（低于S2），通信体验极佳。
   • 计划使用FT8和CW模式，但意外发现并享受FT4模式，主要在14080 kHz、10136 kHz和7074 kHz频段操作。

3. 通信成果

   • 在蜂窝网络覆盖之外，无法实时查看信号报告。
   • 成功完成多个通信联络，覆盖多个频段（主要集中在20米波段）。
   • 创造了新的远距离通信纪录（从加拿大安大略省到西北欧）。
   • 事后查看信号报告，发现收到了有史以来最佳的报告，且所有操作均在7瓦功率下完成。

关键细节与感受

• 天线制作的挑战：面对材料短缺，作者灵活应变，使用现有线材并调整设计，体现了DIY精神。
• 环境优势：森林环境带来的极低噪声 floor 显著提升了通信质量。
• 操作体验：野外架设和操作过程充满乐趣，成果（包括新纪录和最佳信号报告）带来了巨大满足感。

米哈游盈利模式解析

本文深入剖析了米哈游（《原神》与《崩坏：星穹铁道》开发方）的盈利策略，探讨了其收入模型、游戏设计如何与商业化目标协同，以及如何避免“enshittification”（产品体验劣化）。核心观点如下：

1. 抽卡游戏公司的收入逻辑

• 基本收入公式：收入 = 玩家消费欲望（抽卡、体力购买等） - 免费资源收入。
• “慷慨”的本质：免费资源是一种精心计算的补贴，旨在驱动特定水平的基准收入。通过分析不同玩家群体（超级氪佬、中度氪金、零氪）的消费弹性，公司设定最优补贴水平，以最大化总收入。例如，《崩铁》提供更多抽卡资源，但其更快的角色推出节奏抵消了这部分“慷慨”，实际导致中氪及以上玩家的总支出远高于《原神》。

2. 游戏设计与盈利目标的融合

• 设计必须支撑商业化：为了创造持续的消费冲动，游戏的核心设计（如角色强度、战斗机制、内容更新）必须与商业化模式（如角色抽卡频率）紧密配合。如果两者冲突，将破坏玩家体验。
• 两款游戏的策略差异：
  • 《崩铁》：商业化更侧重于角色。其设计削弱了玩家操作技巧、装备等对力量的影响，迫使玩家通过抽卡获取更多角色来应对不同战斗场景（如模拟宇宙、末日幻影等模式，要求特定角色技能如群攻、破盾）。角色培养相对容易，但强度迭代更快。
  • 《原神》：由于玩家操作技巧、圣遗物品质等因素对力量影响更大，存在更多“力大砖飞”的可能。因此，其商业化设计需采用其他手段刺激抽卡，如通过深境螺旋的元素盾、敌人波次结构来构建“角色构建难题”，或推出“幻想真境剧诗”等强制限制角色使用次数的模式。
• “诱饵命座”与跨游戏协同：为消耗玩家的免费资源储备、刺激冲动消费，米哈游为高投资玩家设计了具有极高吸引力的命座/星魂（如那维莱特的1命）。同时，在多款游戏并行的环境下，公司通过差异化角色设计（如主流爆款 vs. 小众高强度设计）来错开各游戏的重大更新，避免内部竞争，并细分玩家群体以最大化边际收入。

3. “Enshittification”（体验劣化）的避免

• 根源：体验劣化常源于公司过度追求收入，通过改变价值分配方式（而非创造新价值）来攫取更多“消费者剩余”，或因追踪了错误的绩效指标（如日活、点击率）而非真实的玩家满意度。
• 米哈游的应对：
  • 明确的设计愿景与坚定领导：对玩家的要求有所取舍，避免为短期收入增加破坏长期体验的系统复杂性。
  • 专注于核心体验：将绝大部分开发资源投入开放世界、剧情和战斗等核心内容，而非过度依赖多种变现渠道。
  • 谨慎对待皮肤系统：皮肤收入面临多重挑战（玩家预算挤占、开发资源分配、与角色获取模式的冲突、在单机玩法中社交价值低、以及玩家易饱）。米哈游将皮肤作为点缀而非主要收入源，宁愿将资源用于提升游戏本体质量（如打造更精彩的国家），体现了其维持产品品质、避免体验劣化的决心。

结论

米哈游的盈利模式建立在深度整合的游戏设计之上，通过精密计算的免费资源、与角色推出节奏匹配的战斗内容设计，以及坚定的产品愿景来驱动持续消费，同时警惕并主动避免因过度商业化导致的体验劣化。其成功并非依赖单一技巧，而是基于对玩家行为、设计杠杆和长期产品健康的系统性理解。

Funtoo Linux 项目宣布关闭。创始人表示，该项目最初是基于一个有趣、由贡献者共建的理念，但如今已不再如此，因此决定终止项目。项目不会寻找或移交继任者，预计将在八月期间逐步停止运行。目前托管Funtoo容器的服务将持续至八月底，以便用户有时间迁移至其他托管解决方案。