Dokku 是一个开源的平台即服务（PaaS），可将单台 VPS 服务器转变为类似 Heroku 的强大部署平台，兼具成本效益与易用性。其核心功能与使用方式如下：

核心特性

• 低成本替代方案：用户拥有完全控制权，避免了 Heroku 等商业服务的高昂费用。
• 自动化管理：通过 Let’s Encrypt 自动管理 SSL 证书，支持基本认证（Basic Auth）为网站添加密码保护。
• 灵活部署：支持多种语言（Node、Python 等）及自定义 Docker 容器部署，具备一键扩缩容能力。
• 插件生态：提供丰富的官方插件，扩展性强。
• 简化操作：支持通过 Git 命令直接部署。

主要使用场景示例

1. 部署 Docker 容器应用

   • 在项目根目录添加 Dockerfile 定义应用环境。
   • 在 Dokku 服务器创建应用，本地通过 git push dokku main 部署。
   • 使用 dokku ps:scale myapp web=2 命令快速调整实例数量。

2. 部署静态网站（可带密码保护）

   • 在服务器创建应用，设置 NGINX_ROOT 环境变量指向静态文件目录（如 _site）。
   • 安装并配置 dokku-http-auth 插件，通过 dokku http-auth:enable 命令启用基本认证。
   • 支持通过 Cloudflare 代理管理 HTTPS，若已使用则无需启用内置 Let’s Encrypt 插件。

3. 通过 GitHub Actions 自动化部署

   • 配置 GitHub Action，在代码推送到主分支时自动触发部署。
   • 流程包括：检出代码、安装 SSH 密钥、添加 Dokku 远程仓库并推送。

实用技巧

• 远程管理：直接通过 ssh dokku@<host> <command> 在本地执行服务器命令（如列出应用、清除缓存、重建应用）。
• Docker 缓存管理：使用 repo:purge-cache 命令可清除缓存实现全新构建。
• 无需推送即可重建：通过 ps:rebuild 命令可触发应用重新构建。

总结

Dokku 提供了一种高效、经济的方式管理个人或小型项目的部署，整合了 Heroku 的便捷性与自托管服务器的灵活性，适合需要频繁部署多种类型应用（包括 LLM 工具）的用户。文中通过具体部署案例和技巧，展示了其核心工作流与实用功能。

Linux 管道性能缓慢分析

本文探讨了 Linux 管道（pipe）写入速度低于预期的原因，并分析了 vmsplice 系统调用如何提升性能。作者通过实验和性能剖析，对比了普通写入、内存拷贝及使用 vmsplice 的吞吐量，揭示了性能瓶颈所在。

性能测试对比

• 内存拷贝速度：在用户空间使用 AVX-512/AVX2/SSE2 指令进行内存拷贝，吞吐量约为 167 GB/s，接近 L1 缓存写入速度。
• 普通管道写入：通过 write 系统调用向管道写入数据，吞吐量仅为 17 GB/s，比内存拷贝慢约 10 倍。
• vmsplice 管道写入：使用 vmsplice 系统调用时，吞吐量可达 210 GB/s（在特定测试条件下），远高于普通写入。

普通管道写入缓慢的原因

通过性能剖析（profiling）发现，write 系统调用在内核中主要耗时于以下操作：

1. 内存页面分配（__alloc_pages）：占内核时间的 36%。
2. 锁竞争（__mutex_lock 和 _raw_spin_lock_irq）：占内核时间的 25% 和 5%。
3. 数据拷贝（copy_user_enhanced_fast_string）：仅占内核时间的 20%。

关键发现：内核的数据拷贝函数 未使用 SIMD 指令（如 AVX-512），而是采用了较慢的 REP MOVSB 指令，导致其效率仅为用户空间内存拷贝的一半。此外，内核为避免 SIMD 上下文保存/恢复的开销，通常不使用向量化指令。

vmsplice 如何提升性能

vmsplice 通过将用户空间缓冲区直接映射到内核的管道缓冲区，避免了数据复制。性能剖析显示，vmsplice 的主要耗时点包括：

• 锁竞争（__mutex_lock）：占 37%。
• 页面映射与引用管理（如 iov_iter_get_pages2、add_to_pipe）：占 14% 和 17%。

与普通写入不同，vmsplice 无需分配新页面，也绕过了内核中保守的、标量数据拷贝代码，因此显著减少了开销。

总结

1. Linux 管道写入慢的主要原因是内核中大量的内存管理开销（页面分配）和锁竞争，以及未使用高效 SIMD 指令进行数据拷贝。
2. vmsplice 通过避免数据复制和绕过部分内核代码，能大幅提升吞吐量，使其接近甚至超过理想内存拷贝速度。
3. 尽管 SIMD 指令在内核中因上下文切换成本未被广泛使用，但 vmsplice 提供了一种有效的替代方案来优化管道性能。

注：所有测试基于作者的个人计算机（AMD 7950X3D，DDR5 内存），运行 Debian 12 及 Linux 内核 6.1.0-18-amd64。

洗碗工：餐饮业中不可或缺的关键角色

工作体验：艰辛与挑战

• 记者在休斯顿的高端墨西哥海鲜餐厅Caracol亲身体验了7小时洗碗工作。
• 洗碗工需面对高温喷枪、湿滑环境、复杂餐具（如带凹槽的牛油果碗、烤过生蚝的粗盐铁盘），且工作中常被食物残渣和水溅湿。
• 两人一组轮换工作，主要职责包括：预冲、分类餐具、操作传送带式洗碗机、清洁银器和高脚杯、运送清洁餐具、清理垃圾。
• 每小时工资10美元，提供员工餐、健康保险和带薪休假。

行业认可：顶级厨师的高度评价

• 安东尼·波登（CNN名厨）：洗碗工作是“人生重要课程的开始”，让他首次因工作而自豪。
• 丹尼尔·布鲁德（纽约名厨）：称洗碗是“进入餐饮业的最佳途径”。
• 托马斯·凯勒（法国洗衣房餐厅主厨）：将洗碗工称为“服务员”，给予与厨师相同的尊重和制服，认为没有他们“一切都会崩溃”。
• 埃默里尔·拉格斯（名厨兼餐饮集团老板）：强调“没有优秀的洗碗工，餐厅服务就无法成功”，并专门设计厨房时优先考虑洗碗区域。
• 雷内·雷泽皮（Noma餐厅主厨）：将洗碗工阿里·索科提升为餐厅合伙人，因其从2003年开业起就一直担任洗碗工。

职业发展：从洗碗工到厨师长的晋升之路

• 许多知名厨师从洗碗工起步，包括：托马斯·凯勒、安东尼·波登、迈克尔·施洛（华盛顿多家餐厅老板）、贡萨洛·古兹曼（Nopalito餐厅主厨）、埃默里尔·拉格斯（11岁开始洗碗）。
• 餐厅积极提拔洗碗工：Caracol餐厅估计有100名前洗碗工晋升；意大利餐厅Alta Strada将洗碗工埃德温·比利亚托拉培养为“披萨先生”。
• 职业优势：了解厨房运作全流程、培养团队合作精神、学习“用更少锅具烹饪”的效率理念。

社会意义与行业反思

• 美国约50万洗碗工年薪中位数约2万美元，近十年仅增长约4000美元，但工作责任重大。
• 许多洗碗工是移民，存在语言障碍，部分餐厅（如迈克尔·施洛的餐厅）提供免费语言课程。
• 餐厅顾问保罗·索古尔指出：洗碗经历能帮助理解厨房布局和功能分工，“如果不懂洗碗，就不该当厨师”。
• 工作虽艰苦，但具有纯粹性：安东尼·波登形容其为“非黑即白的工作——脏盘子进去，干净盘子出来”，成就感直接可见。

结论

洗碗工不仅是厨房运转的基础保障，更是餐饮人才的重要培养途径。他们的辛勤劳动、职业素养和晋升潜力正逐渐获得业内尊重，其贡献应得到与之匹配的社会认可与职业回报。正如Caracol餐厅老板雨果·奥尔特加所言，应将他们称为“终结者”（the finisher），以体现其在餐饮服务完成环节的核心价值。

为什么用C编写Rust编译器？

作者近期活动减少，原因包括亲人去世、工作责任增加，以及一个新项目占据了大部分时间。该项目是编写一个纯C语言的Rust编译器，名为Dozer，不使用C++、flex、yacc或Makefile，仅依赖纯C。

动机：引导的重要性

Rust编译器（rustc）本身用Rust编写，但需要之前的版本编译。追溯编译链，最初版本依赖OCaml，而OCaml编译器又依赖C语言等工具。引导构建项目（Bootstrappable Builds）展示了从极小二进制种子（512字节）逐步构建到复杂系统（如Linux和GCC）的过程。

目前，Rust在引导链中引入较晚，依赖mrustc（用C++编写）。作者希望能在C++引入之前就使用Rust，因此开发Dozer，使其能从纯C环境（如TinyCC）引导，无需其他工具。

项目细节与进展

• 技术栈：纯C编写，兼容TinyCC和cproc编译器，使用QBE作为后端。
• 进展：已完成词法分析器和部分解析器，能编译简单Rust代码（如表达式计算）。类型检查仅支持i32，代码生成尚粗糙。
• 目标：使Dozer能编译基本Rust代码，最终编译rustc（特别是Cranelift后端，因假设无C++环境）。

未来计划

1. 逐步推进Dozer，使其编译使用libc的样本、libcore，最后rustc。
2. 创建cargo等价物，用于编译Rust包。
3. 处理rustc中的自动生成代码（根据引导项目规则需移除）。
4. 建立流程：用Dozer编译rustc和cargo，再用编译出的工具重新编译规范版本。

挑战与心态

作者承认这是最困难的项目，部分怀疑能否完成，但坚持尝试。项目进展将逐步更新，并计划分享架构细节。

总结：Dozer旨在实现Rust的早期引导，减少对C++的依赖，通过纯C编译器扩展Rust在引导链中的灵活性。

文章主题：利用人工智能平台帮助用户对抗医疗保险拒赔

核心背景：旧金山技术工作者霍尔登·卡劳（Holden Karau）因个人多次遭遇健康保险拒赔（涉及性别确认治疗和事故医疗），被迫花费大量时间手动撰写申诉信。她凭借不妥协的态度，成功申诉了约90%的拒赔案例（包括为她的狗争取权益）。

关键动机：

• 个人经历驱动：卡劳认为与保险公司的关系更多是对抗性的，其核心矛盾是用户希望公司遵守规则，而公司希望最小化支出。
• 行业痛点：研究显示，《平价医疗法案》患者的拒赔申诉率仅约0.1%。患者倡议专家指出，大多数拒赔本可以通过充分申诉而被推翻，但流程设计复杂且耗时，导致大多数人放弃。
• 医生困境：医生通常没有时间为每一项拒赔进行申诉。

解决方案：Fight Health Insurance 平台：

• 性质：一个开源平台。
• 技术：利用大语言模型（AI）帮助用户快速生成针对医保拒赔的申诉信。
• 操作流程：用户扫描其保险拒赔单后，系统会生成多封申诉信供选择和修改。
• 目标：简化并加速申诉过程，鼓励更多人进行申诉，迫使保险公司更合理地遵循规则。
• 现状：平台已上线，目前免费使用（未来可能对附加服务如传真收费）。已投入约1万美元开发成本，服务了数十位用户，正收集反馈以优化。
• 定位：卡劳认为这是在现有不完美体系下推动“渐进式进步”，使世界“不那么糟糕”。

展望：

• 理想效果：通过提高申诉的可及性，迫使保险公司减少对小额索赔的无理拒赔。
• 业务规划：卡劳目前未打算离开其科技公司全职工作（曾在IBM、苹果、谷歌、Netflix任职），但希望平台能成为可持续的业务，并承载她对改善保险体系的热情。

Lem 是一个用 Common Lisp 编写的类 Emacs 编辑器。它具备内置的 LSP（语言服务器协议）支持，兼容多种编程语言。安装后，用户可以直接使用 Common Lisp 进行开发，并能在编辑器运行的同时对其进行扩展。

该编辑器以键盘操作为主，对于来自 Emacs 或 Vim 的用户来说很容易上手。Lem 在技术上传承了 Lisp 语言的深厚根基。它完全用 Common Lisp 编写并可扩展。

自 2.0 版本起，Lem 提供了 GUI 版本，支持 Webview 或 SDL2 后端，带来了图形界面、鼠标支持、游戏以及超过 180 种配色主题。其中，Webview 版本计划最终取代 SDL2 版本。

Lem 为 Common Lisp 开发提供了完备的支持，拥有功能齐全的 REPL（交互式解释器）和交互式调试器，并支持 Paredit 及第三方的 Pareto（类似 lispy-mode）模式。

其他主要功能包括：

• 项目树视图：可展示当前项目的树状结构，并使用项目感知命令。
• 终端集成、多光标、交互式搜索、目录模式、标签页、Git 界面、键盘宏。

在编程语言支持方面，Lem 兼容 C, Clojure, Scheme, Go, JavaScript, Kotlin, TypeScript, Python, Rust, Elixir, Haskell, Java, Nim, Dart, OCaml, Scala, Swift, Lua, Perl, Ruby, Zig, WAT, shell, asm 以及 Markdown, ASCII, JSON, HTML, CSS, Vue, SQL 等。

UUID不同版本及其使用场景

UUID（通用唯一识别码）共有8个版本（v1至v8），每个版本有不同的生成方式和适用场景。选择哪个版本主要取决于具体需求，其中v4和v7是最常用的两种。

主要UUID版本简介

• UUID v1：由时间戳、单调计数器和MAC地址生成。
• UUID v2：为安全标识保留，具体细节未公开。
• UUID v3：基于用户提供的数据（如DNS、URL）的MD5哈希生成。
• UUID v4：完全由随机数据生成，是最常见和通用的版本。
• UUID v5：基于用户提供的数据（如DNS、URL）的SHA1哈希生成，是v3的改进版。
• UUID v6：生成数据与v1相同，但调整了字节顺序，使UUID按创建时间排序。
• UUID v7：由时间戳和随机数据生成，是对v1和v6的改进。
• UUID v8：完全自定义格式（仅需包含标准要求的版本和变体字段）。

何时使用哪个版本？

• 使用v4：当你只需要一个随机且唯一的标识符时。这是最安全、最通用的默认选择。
• 使用v7：当你需要UUID能按时间顺序排序时。例如，用作数据库主键时，v7因基于时间戳而利于排序和索引性能。
• 使用v5或v8：当你需要将特定业务数据编码进UUID时。v5使用SHA1哈希，比v3更安全；v8则允许完全自定义。这两种情况通常需求明确。

其他版本的状态

• v1和v6：已被v7取代。v7提供了更优的设计，因此通常不建议使用v1或v6。
• v2：为特殊安全用途保留，公开信息极少。
• v3：已被v5取代，v5使用了更强的哈希算法。

总结来说，对于大多数通用场景，在v4（纯随机）和v7（可排序）之间选择即可。仅当有特殊的数据编码或自定义需求时，才考虑v5或v8。

自托管服务器设置基础指南

本文概述了为自托管应用搭建服务器所需的关键基础知识，旨在建立一个安全、可靠且易于管理的环境。

1. SSH 安全登录

核心原则是使用SSH密钥认证，并彻底禁用密码登录和Root直接登录。

• 在服务器上创建非Root新用户并加入sudo组。
• 在本地生成ED25519 SSH密钥对，并使用ssh-copy-id将公钥传输到服务器。
• 编辑/etc/ssh/sshd_config配置文件，设置PasswordAuthentication no、PermitRootLogin no、PubkeyAuthentication yes，并更改默认端口以提升安全性。
• 启用安全加固选项，如限制认证尝试、使用协议2等。

2. 用户管理

遵循最小权限原则，为每个运行的应用创建专用系统用户，以增强隔离性、安全性和可管理性。

• 使用useradd命令创建具有nologin shell的用户，并为其分配应用数据目录（通常位于/opt下）。
• 将应用文件目录的所有权授予该用户。

3. 日志管理

日志对于系统监控和故障排查至关重要，需配置日志轮转以防磁盘空间耗尽并便于管理。

• 编辑/etc/logrotate.conf或为特定应用（如NGINX）在/etc/logrotate.d/下创建配置文件。
• 示例配置包括按周轮转、保留52周、压缩旧日志等。
• 可使用Grafana Loki、Graylog等工具进行更高级的集中日志管理。

4. 备份策略

强调测试备份的重要性。主要备份类型包括全量、差异和增量备份。

• 遵循3-2-1原则：保留3份数据副本，使用2种不同存储介质，其中1份存放在异地/离线。
• 可使用Borg Backup、Syncthing等工具。备份策略应根据数据重要性定制。

5. 基本网络安全

使用防火墙和入侵防御工具来限制访问和防御攻击。

• UFW（简易防火墙）：设置默认拒绝入站、允许出站的策略。然后仅开放必需端口（如SSH自定义端口、80、443）。可设置端口速率限制以防御暴力破解。
• Fail2Ban：自动禁止多次登录失败的IP地址。配置文件位于/etc/fail2ban/jail.local，可设置禁令时间、查找时间窗口和最大重试次数。

6. NGINX 配置

NGINX 用作高性能 Web 服务器、反向代理和负载均衡器。

• 核心配置文件位于/etc/nginx/。建议将站点配置文件放在sites-available目录中测试，然后通过符号链接启用到sites-enabled。
• 文章提供了三种基础配置模板：
  • 静态网站配置：直接服务HTML文件。
  • 反向代理配置：将流量转发至本地应用（如运行在3000端口的服务）。
  • WebSocket升级配置：支持需要WebSocket连接的应用。
• 所有配置均包含基本安全头、日志设置，并预留了SSL（通过Certbot获取）的配置部分。
• 使用Certbot（Python版）免费获取和管理Let‘s Encrypt SSL证书，它支持自动续期。

7. 实用工具推荐

以下可选工具可提升服务器管理效率：

• Btop：终端下的系统资源监视器。
• Neoss：网络连接查看工具，提供清晰的TUI界面。
• GoAccess：终端下的Web服务器日志分析器，可生成实时报告。
• Midnight Commander (MC)：基于文本的双面板文件管理器。
• NCDU：快速的磁盘使用分析工具，用于找出占用空间大的文件。

8. DNS 基础

域名系统是将人类可读的域名转换为IP地址的关键。

• 在VPS上，主要任务是将域名的A记录指向服务器的静态IP。
• 家庭托管常面临动态IP问题，可通过动态DNS (DDNS) 服务解决。DDNS客户端会监测IP变化并自动更新DNS记录。

9. Docker 使用考量

Docker可用于应用隔离和部署，但文章列举了其优缺点以供权衡。

• 优点：环境一致性、隔离性、资源效率高（优于传统VM）、易于扩展、社区支持好。
• 缺点：存在资源开销（高于直接运行）、共享内核的安全风险、持久化存储与备份更复杂、网络配置复杂、可能绕过主机防火墙规则、增加调试复杂度。

总结

本文涵盖了从基础安全加固到应用部署的全方位服务器设置要点，旨在帮助用户构建一个稳固的自托管基础。作者还提到了一个可自动化部分设置过程的个人脚本。

美国司法部对RealPage提起反垄断诉讼

核心指控
美国司法部与八个州于周五对租金设定软件公司RealPage提起民事诉讼，指控其参与非法价格固定计划，通过协调房东之间的定价来减少竞争、人为推高租金并获取利润，同时垄断了此类定价软件市场。

案件背景与调查

• 诉讼源于2022年ProPublica的一项调查，该调查揭示RealPage的软件可能助长类似卡特尔的行为。
• 此后，参议员提出立法提案禁止此类做法，租户发起数十起联邦诉讼，旧金山监事会也禁止房东使用类似算法定价。
• 司法部进行了近两年调查，包括审查内部记录和通过数据科学家分析算法代码，以理解软件如何设定价格。

司法部观点

• 官员指出，RealPage的软件使房东能共享机密数据并采取类似租金策略，算法和人工智能可比传统串通方式更有效地协调竞争对手。
• 副司法部长丽莎·莫纳科强调：“训练机器违法仍是违法行为。”
• 司法部长梅里克·加兰表示，美国人不应因公司设计新的违法方式而支付更高租金。

RealPage的回应

• 公司此前否认不当行为，声称其客户可自由接受或拒绝建议，且其对全国租赁市场的影响被夸大。
• RealPage使用有限的汇总和匿名非公开数据，以支持促进竞争的用途。
• 该公司表示将对反垄断诉讼进行抗辩。

诉讼细节与影响

• 诉讼长达100多页，引用了RealPage高管和房东关于软件影响的陈述，指控软件帮助房东协调提价或避免降价。
• RealPage软件用于设定全国超过300万套公寓的租金，涉及超过1600万套公寓的竞争敏感信息。
• 司法部称软件对住房市场产生“重大”影响，并指出其“自动接受”设置可让RealPage实际决定租客支付的租金。

未涉及房东与政治背景

• 与租户诉讼不同，司法部诉讼未将房东列为被告，官员拒绝解释原因。
• 住房成本已成为总统选举的政治议题，副总统卡玛拉·哈拉斯批评房东使用定价软件人为推高租金，并指其为反竞争行为。

参与州与行业关注

• 加入联邦诉讼的州包括北卡罗来纳、加利福尼亚、科罗拉多、康涅狄格、明尼苏达、俄勒冈、田纳西和华盛顿。
• 司法部官员表示，他们也在审查其他行业的类似信息共享行为，如肉类加工业。

挑战与意义

• 专家指出，将已有100多年历史的《谢尔曼反托拉斯法》适用于竞争对手通过新技术协调定价的情况，检察官面临挑战。
• 本案是拜登政府推动反垄断执法的重点案例。

编程的艺术与我对LLM的抵触

作者指出，随着LLM（大语言模型）编程能力的提升，越来越多人将其融入工作流程，并称赞其能提升生产力。但作者认为，LLM在编程中的实际效果被严重高估，即使其如支持者所言般强大，他仍不会在实质上使用LLM。

编程的艺术性
作者将编程分为两部分：1）通过算法解决问题，将问题分解为计算机在约束下可执行的步骤；2）用计算机能理解的方式表达解决方案。这两部分都为程序员提供了无限的创意画布——解决问题的方式几乎无限，表达解决方案的方式也近乎无穷。因此，编程是一种自我表达，是一种艺术形式，其产出是少数人才能欣赏的“艺术品”。

自视为编程艺术家
作者视自己为通过编程表达创造力的艺术家。他享受创造“编程艺术”的过程，因为只有在此过程中才能找到充满热情与创造力的真实自我。

为何不使用LLM
作者将使用LLM写代码比作“让画家代笔绘画”。如果只追求结果，使用LLM无可厚非；但若像他一样享受绘画（编程）过程，为何要将乐趣自动化？即使LLM只负责写代码，而人类仍负责解决问题，作者也认为编程若不亲自用代码表达解决方案，便不完整——非亲手创造的作品，便不属于自己的艺术。

令人遗憾的现状
作者对业界试图将编程自动化、甚至将复杂任务委派给一个“连单词字母都数不清”的黑箱模型感到遗憾。他质疑：是否已无人享受编程乐趣？是否无人愿意超越“勉强能用”而追求更深层次？这或许是一种“可得性偏误”。文章末尾强调，此观点并非评判他人——不享受编程或只求结果均可接受，但他失望于“真正热爱编程的人似乎日渐稀少”。

Stripe 数据获取局限性与开源替代方案分析

Stripe 的数据访问限制与高昂成本

Stripe 的默认 API 难以直接计算月经常性收入（MRR），其内置仪表板无法满足成长型企业的数据分析需求。这源于其利润最大化策略，旨在促使客户购买附加服务：

• Stripe Data Pipeline：将数据同步至 Snowflake 或 Redshift 的 ETL 工具。按交易笔数收费（基础费率 $0.03/笔），对高频小额交易企业（如 DoorDash）而言成本极高。
• Stripe Sigma：协作式 SQL 查询工具，同样按交易笔数阶梯收费，对数据量大的企业费用昂贵。 此外，Stripe 完全基于订阅模型设计，对基于使用量的计费（如按席位或 API 调用）支持极差，导致此类数据分析极为困难。

第三方工具的局限性

为弥补 Stripe 的不足，企业可选择第三方工具，但均伴随额外成本或技术复杂性：

• 财务指标与 FP&A 工具：如 ChartMogul、ProfitWell 和 Pigment，能生成报表或构建仪表板，但价格昂贵且多面向大型企业。
• 第三方 ETL/ELT 工具：如 Airbyte 或 Fivetran，可将数据导入数据仓库，但企业仍需自行编写复杂的逻辑来计算 MRR。

开源计费解决方案的优势（以 Lago 为例）

采用开源计费框架（如 Lago）可让企业完全掌握计费基础设施与数据所有权，其核心优势包括：

• 无需依赖第三方 ETL 工具或复杂的查询插件。
• 数据直接存储在 PostgreSQL 中，表结构清晰简单（如 invoices、events、fees）。
• 可轻松集成 Metabase 等 BI 工具，直接基于底层数据构建自定义财务仪表板。

Lago 的关键财务指标计算逻辑

Lago 提供了简化的 SQL 查询结构来计算核心财务指标：

• 计算总收入（Total Revenue）：查询 invoices 表，通过 payment_status 过滤已支付发票，并使用 issuing_date 按月份进行分组聚合，涵盖订阅、使用量计费和附加费。
• 计算基本 MRR 与 ARR：查询 fees 表，排除一次性附加费和使用量费用（charge），仅统计经常性订阅费用。后续可通过排除折扣（coupons）或退款（credit_notes）进一步优化。
• 计算使用量 MRR（Usage MRR）：针对基于使用量的计费，查询 fees 表并仅筛选与使用量相关的费用（charge），以处理月度波动的非固定收入。

结论

闭源公司往往通过限制基础数据功能来推动高利润的付费升级。Stripe 的数据结构不仅使基于使用量的计费分析变得困难，其附加数据工具的成本也十分高昂。采用开源计费框架或自建系统，能有效避免财务数据被商业策略绑架，确保数据所有权与分析灵活性。

前英特尔资深CPU架构师组建RISC-V初创公司
在英特尔进行大规模裁员之际，其四名资深CPU架构师（Debbie Marr、Mark Dechene、Jonathan Pearce和Srikanth Srinivasan）已离职，共同创立了名为AheadComputing的RISC-V初创公司。该公司于7月18日宣布成立，早于英特尔裁员计划的公布。

创始人背景
四人在英特尔的工龄合计超过80年，均拥有深厚的技术积累：

• Debbie Marr：曾任英特尔首席架构师，任职33年，主导超线程技术落地，拥有40余项专利。
• Mark Dechene：英特尔首席工程师，16年间参与Haswell、Skymont等多代CPU架构开发，持有15项专利。
• Jonathan Pearce：英特尔首席工程师，22年经历覆盖硅前与硅后多个CPU产品阶段，持有19项专利。
• Srikanth Srinivasan：曾主导Nehalem、Broadwell等芯片设计，拥有50余项专利及多项高影响力论文。

公司目标与业务
AheadComputing以“设计、验证并授权高性能RISC-V核心IP”为核心任务，专注于开放指令集架构的处理器开发。目前公司官网信息较为简洁，主要包含团队介绍、招募信息（面向CPU设计与验证人才）及定期线下交流活动（每周二在俄勒冈州举行）。

行业影响
此次人才流动被视为英特尔“严重脑力流失”的体现之一，可能对英特尔未来的技术复兴构成挑战。与此同时，AheadComputing凭借创始团队的资深背景，有望在RISC-V生态中形成显著影响力。

Rerun：时间序列多模态数据可视化与处理平台

核心定位

Rerun 是一款开源工具链（SDK），旨在为机器人学习等领域提供多速率、多模态数据的统一处理方案。它不只是一个固定平台，更是一个灵活的开发框架，支持用户构建自定义的数据处理流程。

核心功能

• 日志、存储与转换：以列式分块存储格式（.rrd文件）高效记录多速率、多模态数据，支持直接记录或从其他格式轻松转换。
• 查询与转换：支持对机器人数据执行完整的数据框（dataframe）或SQL查询，允许在不破坏历史数据的前提下，通过添加列的方式轻松进行后处理或标注。
• 可视化与调试：提供统一视图工具，用于审查数据集、调试细节问题，并可扩展自定义视图和工具，覆盖数据处理管线的各个阶段。
• 直接训练集成：无需导出步骤，可将数据集表达为查询，流式传输至GPU进行训练。其数据加载器具备列感知和视频编码器感知能力。

数据架构与 Rerun Hub

• 统一数据层：Rerun（0.32版本起）成为物理数据（如机器人数据）的统一数据层，整合了可视化、查询、转换和训练能力。
• 商业平台 Rerun Hub：作为Rerun数据层的后端基础设施，提供目录管理、字节范围索引与检索能力，可将对象存储转化为可查询、可流式传输的基础。支持在边缘或靠近数据源处运行转换。

关键特性与优势

• 数据一致性：团队共享同一个查看器和同一份记录数据，便于协同探索、标注和故障溯源。
• 高效数据处理：通过SQL查询深入记录数据的列、时间范围和数值内部（不仅是元数据）。
• 数据演化：支持添加派生列和演化数据模式（schema），同时保持原始记录的有序组织。

项目背景与信息

• 开源承诺：团队是众多所依赖的开源项目的积极贡献者。
• 版本更新：在0.32 SDK版本中引入了上述作为统一数据层的新能力。
• 企业信息：由 Rerun Technologies AB 公司维护，版权信息标注至2026年。提供每月约一次的深度技术通讯。

avante.nvim 插件摘要

avante.nvim 是一个 Neovim 插件，旨在模拟 Cursor AI IDE 的行为。它通过 AI 驱动的代码建议和一键应用功能，为用户在 Neovim 编辑器内提供类似 AI 编程助手的体验。

核心功能

• AI 代码辅助：用户可以就当前代码文件向 AI 提问，获取智能的修改或优化建议。
• 一键应用：通过简单命令或快捷键，快速将 AI 生成的代码变更应用到源文件。
• 项目指令文件：支持通过项目根目录下的 avante.md 文件（可自定义名称）提供项目特定的上下文和指令，用于定制 AI 行为。

关键特性

• Avante Zen Mode：一种专为在 Neovim 内部体验“Vibe Coding”而设计的界面。它外观类似终端 CLI（如 Claude Code），但底层完全基于 Neovim，允许用户使用熟悉的 Vim 操作和丰富的 Neovim 插件生态。
• 多提供者支持：默认支持 Claude，但也支持 OpenAI、Azure、Gemini、Moonshot、Copilot、Ollama 等多种 AI 服务提供商。
• ACP 协议支持：支持 Agent Client Protocol，可集成 Gemini CLI、Claude Code、Codex 等遵循此协议的 AI 代理。
• Fast Apply：通过集成 Morph 等专用模型，实现高达 96-98% 准确率的快速代码应用，模拟 Cursor 的即时应用功能。
• 工具与代理模式：
  • Agentic 模式（默认）：AI 可自动使用工具（如文件操作、bash 命令、网络搜索）执行复杂任务。
  • Legacy 模式：AI 提供建议和计划，但所有操作需手动批准。
• RAG 服务：可选启用，用于为 AI 获取生成代码所需的上下文信息。
• 可定制性：支持通过自定义提示模板、快捷键、命令和工具进行深度配置。

安装与配置

• 要求：Neovim 0.11.0 或更高版本。
• 安装：支持通过 lazy.nvim（推荐）、rocks.nvim、vim-plug、Packer 等多种插件管理器安装。从源代码构建需要 cargo。
• 配置：通过 require('avante').setup({}) 进行详细配置，包括选择提供者、设置 API 密钥、定义行为、窗口布局、快捷键映射等。

使用方式

• 基本流程：打开代码文件 → 使用 :AvanteAsk 命令询问 AI → 审阅建议 → 应用更改。
• 集成：支持与 Neo-tree、NvimTree、blink.cmp 等插件集成。
• 自定义工具：允许用户定义自定义工具供 AI 在代码生成和分析期间使用。

未来计划

• 更深入的 AI 交互、LSP + Tree-sitter + LLM 集成等。

该项目处于快速迭代中，以 Apache 2.0 许可证发布。

Olivetti Programma 101: 个人电脑的起源

Olivetti Programma 101（1965年）被公认为世界上第一台个人电脑。它诞生于意大利的奥利维蒂公司，在计算机发展史上具有里程碑意义。

历史背景与开发过程

20世纪60年代初，奥利维蒂决定开发一种“桌面”计算机，目标是让它成为可以与人共处的“个人物品”，而非当时那种需要专门机房和专业人员操作的大型机。该项目由电气工程师皮尔·乔治·佩洛托领导，团队仅有五名年轻工程师。

有趣的是，当奥利维蒂将其电子部门出售给通用电气时，该项目曾面临被放弃的风险。但团队巧妙地将机器从“计算机”重新归类为“计算器”，从而利用通用电气不感兴趣的计算器部门继续秘密开发，争取到了关键的发展时间。

技术特点

Programma 101的技术参数以今天的标准来看相当基础：

• 内存：仅有1920比特。
• 功能：主要进行算术运算，但已具备逻辑运算、条件跳转等计算机核心能力。
• 存储：创新性地使用可编程磁卡读写器替代了庞大的磁带机，程序记录在约3英寸宽的塑料磁卡上，每张卡可存储240条指令。
• 显示：没有显示器，使用小型纸带打印机输出结果。
• 内部构造：未使用微处理器或集成电路，完全由晶体管、二极管等分立元件构成，并采用了奥利维蒂专利的“微单元”技术集成。

这些特性使其被视为台式计算器与个人电脑之间的“过渡物种”。

设计创新

其外观由当时年轻的建筑师马里奥·贝里尼设计，这标志着计算机首次被当作工业设计产品来对待：

• 材料：采用压铸铝合金外壳（厚3毫米），主要为了屏蔽电磁干扰，当时大多数计算机使用钣金。
• 造型：圆角流线型设计，与同时代棱角分明的大型机（如奥利维蒂自家的ELEA 9003）形成鲜明对比，显得更加友好、未来感十足。
• 色彩与细节：浅色机身与鲜艳标识的对比、简洁的槽口和把手设计，被认为预见了二十年后苹果公司的“白雪公主”设计语言。
• 人机关系：设计核心是“以人为中心”，旨在创造一个普通人在家庭或办公室环境中都能轻松使用、不会感到畏惧的物体。

商业成功与遗产

尽管初期预期不高，Programma 101却取得了巨大成功：

• 定价：约3200美元（相当于今天的2万美元），相比昂贵的大型机极具性价比。
• 销量：全球售出约44000台，其中大部分销往美国。
• 重要用户：包括NASA，阿波罗11号任务就使用了10台该计算机进行计算。
• 革命性意义：它首次证明了计算机可以成为个人工具，而不仅仅是机构的设备。它不仅是技术上的先驱，更是第一台经过精心工业设计、注重用户体验的计算机，为后续的个人电脑革命奠定了概念基础。

因此，Programma 101不仅是一台早期的计算设备，更是一个开创了“人与机器”新关系的文化与技术标志，无愧为个人电脑的真正起源。

Coolify 的崛起及其潜在影响力

Coolify 是一个开源、可自托管的平台，旨在替代 Heroku、Netlify 和 Vercel 等商业部署服务。其创始人 Andras Bacsai 拒绝了超过30位投资者，选择以社区资助的方式开发该项目。

核心体验与功能

作者通过在 Hetzner 上租赁并配置 VPS，使用 Coolify 部署了 Api-Fiddle REST API，体验类似早期使用 Vercel 的“魔法时刻”。Coolify 虽然处于早期阶段且界面略显粗糙，但能快速实现：

• 轻松部署：例如，部署 PostgreSQL 实例仅需三次点击和30秒。
• 应用部署：指向 GitHub 仓库并指定域名后，应用可迅速上线，附带数据库、定时备份和 Caddy 代理等配置。
• 广泛兼容：支持任何已容器化或兼容 Nixpacks 的应用程序。

崛起背景与潜力

Coolify 在2024年经历了爆发式增长。尽管它并非全新的概念（类似于 Dokku 等早期开源 PaaS），且是建立在 Docker、Kubernetes 等现有技术之上的封装工具，但其快速的社区采纳表明它产生了更广泛的影响。

这一崛起与自托管软件趋势的兴起密切相关。商业开源软件模式允许企业自托管产品以保留数据所有权，并通过服务合同盈利。Coolify 有潜力让任何规模的组织比以往更容易地免费托管各类自托管软件（如 Cal.com、Mailcoach 等），从而改变中小型项目部署内部和外部工具的方式。

与传统模式的对比

作者认为，这并非简单的从 SaaS 回归到传统的本地部署。相反，它代表了工具和部署选择的丰富，使开发者能够针对成本效率和数据所有权进行优化。

现状与展望

文章强调这是一篇基于用户经验的正面评价，并非赞助内容。尽管 Coolify 已获得广泛关注，但它仍处于早期发展阶段。作者建议有兴趣的用户可以参考官方视频和网站开始使用。

数据库“分片”（sharding）技术中“分片”一词的起源可能与大型多人在线游戏《网络创世纪》（Ultima Online）有关。该术语用于描述将数据分布到多个并行数据库中的技术，以提高可扩展性，而非将所有数据集中存储。

文章指出，“分片”一词在技术领域逐渐流行，但其来源可能追溯到1996年《网络创世纪》开发期间。当时，为支持大量玩家同时在线，游戏需要运行多个并行服务器（即多个副本世界）。为赋予这一技术虚构背景，开发团队从《创世纪》系列游戏的历史中汲取灵感：邪恶巫师蒙丹试图通过水晶控制索萨利亚世界，但水晶被击碎后，每个碎片都映射出一个完整的索萨利亚副本。因此，“分片”（shard）一词被用于指代这些平行的游戏世界服务器。

这种用法后来可能被引入数据库领域，用以描述类似的数据分区策略——即将数据库拆分为多个独立但结构相同的并行实例。尽管该术语在技术圈内的使用并不完全统一，但许多90年代参与在线游戏开发的人士会交替使用“服务器”和“分片”来指代平行服务器集群。

文章还提到，尽管“分片”一词的直接技术来源可能存在争议，但其游戏起源故事为该术语增添了独特的文化背景。作者推测，这一术语的传播可能源于游戏行业向技术领域的跨领域影响，尽管并未确凿证据证明数据库术语直接借鉴自游戏。

创意工作是否需要原创性：取决于目标语境

本文通过烤桃子派的比喻，探讨了创造性工作中对“原创性”要求的两种不同语境。核心观点是：是否要求作品具有原创性，取决于创作的目标与所处环境。

两种创作语境对比

1. 个人创作（周末烘焙）：

   • 目标：享受创造过程、个人技艺提升、关怀他人。
   • 评判标准：作品本身的愉悦感和完成度。追问“这和别的派有什么不同？”是不恰当的，因为它误解了创作的本意——重点在于制作的过程与分享的喜悦，而非革新。

2. 学术研究（创新糕点大会CRISP）：

   • 目标：推动领域知识边界的前进，构建可积累、可扩展的实践社群。
   • 评判标准：必须明确说明作品相对于已有工作的新颖之处和理论贡献。能够定位自身工作，是研究者应具备的素养。

问题的根源与常见误区

作者指出，许多创作社群中的困惑源于混淆这两种语境：

• 将对学术研究的“创新性”要求，错误地强加于旨在探索和分享的个人项目上，会挫伤创作者的积极性。
• 反之，将个人探索的心态带入学术场合，忽视对现有工作的梳理和定位，其贡献将难以被领域理解和接受。

实践建议与策略

对于创作者：

• 明确初始目标：从纯粹为了乐趣的“玩耍式探索”开始，允许自己进行非功利、不受“是否足够新”束缚的创造。这能提供自由的探索空间。
• 随项目演进调整：当一个个人项目逐渐成熟，具备潜在研究价值时，再适时引入学术批判视角，为其进行理论定位。
• 避免高起点的压力：如果一开始就背负“做出重大原创贡献”的压力，往往会引发过早的严苛批评，不利于创意萌芽。

对于反馈者：

• 首要任务是理解创作者的目标：在给出反馈前，先弄清楚对方是在进行个人探索还是寻求学术突破。对于周末烘焙式的项目，可能更需要鼓励，而非创新性质疑。

结论

文章最终强调，原创性并非所有创作的必需品，但它在特定学术语境中是必要的专业门槛。健康的创作生态需要区分这两种语境，让个人探索的乐趣与学术研究的严谨性各得其所。理查德·费曼“玩转盘子”和帕特里克·杜布罗伊“像孩子一样玩耍”的引言，进一步佐证了以游戏心态开始创作的价值。

使用 S3 条件写入实现 Leader 选举

在分布式系统中，为了扩展工作负载，通常需要在多个计算节点中选举一个“领导者”（Leader）来执行特定任务（如处理 Kafka 分区、写入文件系统、调用远程 API），以避免重复操作和数据冲突。传统上，这依赖于 Apache ZooKeeper 或 PostgreSQL 等提供分布式锁的服务。然而，如果应用主要使用 Amazon S3 等对象存储，仅为选举目的运行这些有状态服务会带来额外的运维和成本开销。

AWS 近期为 S3 的 PutObject 操作引入了对 If-None-Match 请求头的条件写入支持。当指定该头时，只有当目标存储桶中不存在相同键（key）的文件时，写入才会成功；否则将返回 412 Precondition Failed 响应。这一功能使得仅基于 S3 实现轻量级的分布式锁和 Leader 选举成为可能。

选举算法

基本思想是让节点竞争创建锁文件，成功创建者成为领导者。由于 S3 的条件写入无法防止对已有文件的丢失更新，因此每次领导权变更（例如节点故障或主动释放）都会创建一个新的锁文件，对应一个新的“领导纪元”（leader epoch）。锁文件是一个简单的 JSON 结构，包含一个 expired 布尔字段和可选的 validity_ms 有效期字段。文件名中包含严格递增的纪元编号（例如 lock_0000000001.json），通过列出所有锁文件可以确定当前纪元。

算法步骤：

1. 列出所有锁文件。
2. 如果不存在锁文件，或最新的锁文件已过期（expired 为 true 或已超过 validity_ms 设定的有效期）：
   3. 将纪元值加一，尝试创建新的锁文件。
   4. 如果创建成功：当前节点成为领导者，开始执行实际工作。
   5. 如果创建失败（收到 412 响应），则返回步骤 1。
3. 如果存在有效的锁文件：当前节点不是领导者，定期返回步骤 1 检查。

获取与释放锁

获取锁：通过向 S3 发送带有 If-None-Match: * 头的 PutObject 请求来创建下一个纪元的锁文件。若收到 412 响应，表示其他进程已抢先创建了该纪元的锁文件，选举失败。

释放锁：领导者正常退出时，只需更新当前锁文件，将 expired 字段设置为 true。后续节点在列出锁文件时会发现锁已过期，从而触发新一轮选举。关键规则是只有创建锁文件的进程才能使其过期。

锁的有效性与“僵尸”处理

为防止领导者崩溃后锁永不释放，可以在锁文件中添加 validity_ms 字段（例如 60000 毫秒）来定义锁的有效期。领导者需要定期检查锁是否仍在有效期内，并通过更新文件来“续约”（尽管 S3 的 PutObject 是幂等的，更新会修改时间戳）。非领导者节点也可以检查最新锁的有效性。

这引出了时钟漂移问题。不同节点的时钟不一致可能导致领导权混乱：时钟快的领导者可能提前放弃锁，时钟慢的领导者可能超期持有锁，而时钟快的非领导者可能提前竞选。这正是分布式系统中基于锁的选举最终只能达到“最终正确性”的体现，因为检查锁的有效性与执行实际工作不是原子操作。

为了最小化时钟漂移的影响，可以采取最佳努力的时间同步措施，例如让节点通过 S3 上的临时文件创建时间来校准本地时钟，或使用亚马逊时间同步服务。

文章最后引用 Martin Kleppmann 的观点指出，必须准备应对“僵尸”领导者。解决方案是将递增的 领导纪元（epoch）作为“隔离令牌”（fencing token）。下游服务（如远程 API）可以追踪它所见过的最高纪元值，并拒绝纪元更旧的请求。例如，SlateDB 利用 S3 的新条件写入功能，通过遵循类似锁文件命名的序列顺序上传文件，并检测冲突，从而在不需要额外有状态服务的情况下实现了对竞态写入者的隔离。

错误消息内容

该内容是一个错误通知，显示在x.com（可能指Twitter/X平台）上发生了问题。消息以安抚语气开头，表示无需担心，并建议重试。它指出某些隐私相关扩展可能导致x.com上的问题，因此建议用户禁用这些扩展后再次尝试。整个消息旨在帮助用户解决访问或操作中的障碍，没有涉及其他技术细节或背景信息。