Chet Haase宣布离开谷歌Android团队，结束其近14年的职业生涯。他的离职属于主动选择，而非受裁员影响，目的是彻底离开科技行业，转向全新的领域——喜剧编剧。

作者自2010年加入Android团队以来，参与了多项核心工作，包括开发关键技术与API（如Animator）、处理平台及AndroidX的图形、UI与性能项目，并长期参与开发者社区活动（如主持播客、撰写文章）。他还耗费多年时间采访并撰写了记录Android早期发展史的书籍。近年来，他的职业路径经历多次“倒带”，逐步从管理岗位回归工程角色。

去年秋季，他开始在芝加哥De保罗大学攻读喜剧编剧艺术硕士（MFA），该项目为期两年，并在第二城学习喜剧课程。他坦言辞去高薪稳定的科技工作是一个重大的财务牺牲，但认为追随内心热爱至关重要。他希望通过全职学习与写作，将长久以来的业余爱好转变为主业。

作者对Android社区及共事团队表达了诚挚感谢，并表示未来可能以新的身份（如外部分析师）继续参与相关讨论，甚至不排除未来将编程重新作为兴趣。最后，他幽默地回应了可能的离职猜测，并期待读者未来能在各类创作媒介上看到他的作品。

文章指出，大型制药公司常以药品高价用于研发新药和中间商（药品福利管理机构，PBMs）牟利作为辩护理由，但国会听证会揭示事实并非如此。

参议员伯尼·桑德斯主持的听证会上指出，制药公司在高管薪酬、股息和股票回购上的支出远超过其研发开支，意味着更多资金用于 enrich 股东和高管而非新药研发。此外，虽然 PBMs 的操作确实推高了药品价格，但其利润占比相对较小，并非药品价格高企的主因。

参议院报告强调，问题的核心在于制药公司的贪婪、通过专利策略延长垄断地位以及强大的游说活动。听证会召集了默克、强生和百时美施贵宝的 CEO 接受质询。桑德斯强调，救命药物若无法 affordability，则失去意义。

在Apple Vision Pro中编程的体验探索

空间计算设备：Apple Vision Pro

作者将Apple Vision Pro比作"眼睛的高级耳机"——佩戴后，数字世界与现实环境融合。用户可选择让现实世界透入或完全沉浸，类似于主动降噪耳机的工作原理。该设备利用先进芯片、传感器和摄像头，将虚拟物体投射到现实世界中，并固定在特定位置。

核心交互方式

Vision Pro通过内部摄像头追踪用户视线，配合外部摄像头识别手指轻触，实现"注视并轻点"的交互模式。这种交互方式在几分钟内就能变得自然，形成了类似iPhone"滑动解锁"的流畅体验。

作为生产力工具

作者将蓝牙键盘和触控板连接至Vision Pro，将其作为独立计算机使用。设备搭载Apple Silicon芯片和高达1TB的存储空间，无需连接其他计算设备。

多显示器工作空间

Vision Pro能创建具有真实深度感的虚拟多显示器设置：

• 可布置多个大型虚拟屏幕（最高可达3米高）
• 用户可在虚拟屏幕间走动、近距离查看
• 屏幕可自由拖动和重新排列
• 数字内容与现实环境自然融合，减少"被困在计算机中"的感觉

深度工作模式

针对需要高度专注的编程工作，作者会完全沉浸在虚拟环境中，过滤掉现实世界的视觉干扰。他将各种工作上下文（代码、日志、设计图等）以大型窗口形式环绕自己，形成类似"大型机器房间"的沉浸式体验。设备会在用户可能撞到现实物体时发出警告。

总体评价

作者对Vision Pro的空间计算能力印象深刻，认为其开启了数字第三维度的新前沿。虽然存在一些使用限制（如佩戴时喝咖啡困难），但设备在提供沉浸式编程工作空间方面表现出色，代表着计算体验的重要演进。

Zed联合创始人访谈：从Atom到Zed的技术选择与设计哲学

核心技术决策：Rust与性能优先

• 选择Rust的原因：团队认为JavaScript（通过Electron）限制了Atom的性能和内存控制。Rust提供了零成本抽象、内存安全和多线程支持，使构建高性能编辑器成为可能。
• GPU加速渲染：为追求极致性能和帧率（目标低于3毫秒），团队放弃DOM，转向自研GPU加速UI框架（GPUI），通过着色器直接控制像素渲染。
• 数据结构的革新：从Atom的JavaScript字符串数组转向Zed的多线程友好、可快照、写时复制B树（如SumTree），支持并发和高效文本操作。

设计理念：控制权与迭代

• 愿景延续与超越：Zed继承了Atom对轻量、可扩展编辑器的愿景，但通过掌控全栈（从解析器Tree-sitter到UI框架GPUI）解决了Atom的性能瓶颈。
• “构建一次，但要正确”的权衡：对核心模块（如GPUI、编辑器转换层）进行精心打磨和随机测试，对边缘功能则更注重快速迭代和实用优化。
• 持续重写与学习：团队强调通过实践学习，必要时不惜重写（如CRDT和编辑器渲染层），而非简单修补，以积累深刻理解并改进架构。

开发策略与挑战

• 权衡控制与效率：自研技术栈耗时且增加新成员学习成本，但长期带来积累优势（如便于自定义和优化）。
• 测试驱动的质量保证：对关键组件（如SumTree和文本渲染层）进行随机测试和属性测试，以捕获边缘情况，确保可靠性。
• 性能优化的务实态度：如优化“查找所有匹配”从1秒降至4毫秒，展示了Rust高级抽象下的高效实现。

团队观点与未来展望

• Rust对社区的贡献友好：严格的编译器和cargo工具链降低了贡献门槛，促进了开源社区参与。
• 技术栈的潜在演进：团队对Zig等新兴语言保持开放，但短期内仍专注于Rust以保持一致性。
• 用户对技术的感知：开发者工具用户可能更关注性能和可扩展性，而技术选择（如Rust）间接影响贡献生态和编辑器可塑性。

总结

Zed团队通过反思Atom的局限性，以Rust为核心、GPU加速为手段、全栈掌控为策略，构建了一个注重性能、控制和持续演进的编辑器。他们的方法强调从实践中学习，对核心模块精细打磨，同时保持对边缘功能的灵活迭代，以实现对轻量、快速、可扩展编辑器的长期愿景。

主要发现

• 报告来源：气候完整性研究中心（CCI）发布新报告，结合现有研究和内部文件，揭露石油和塑料行业数十年来知晓塑料回收在技术和经济上不可行。
• 行业欺骗：塑料行业通过欺诈性营销和公众教育活动，推广塑料可回收，导致一次性塑料行业扩张，并规避了有效的废物和污染监管。
• 内部证据：行业内部文件显示，早在1986年，贸易组织乙烯基研究所（VI）就指出回收不能作为塑料的永久固体废物解决方案；1994年埃克森化学副总裁称“致力于活动，但不致力于结果”；1995年美国塑料委员会内部承认回收塑料无法与原生材料竞争。

塑料回收困难

• 技术挑战：塑料类型多达数千种，收集和分拣成本高昂；且仅能使用一两次后降解，每次再利用会增加毒性。
• 经济不可行：回收塑料无法与价格更低的原生塑料竞争，内部文件预测原生材料供应将大幅增加，打击回收市场。

法律问责可能

• 法律依据：报告作者认为，行业对公众的欺骗可能违反消费者保护法和环境法，建议总检察长等官员采取法律行动，追究欺诈和污染责任。
• 现有案例：该报告补充了针对塑料生产商的诉讼，包括2022年加州对埃克森美孚的调查和2023年纽约对百事公司的起诉。

回收现状与建议

• 回收率低：全球每年仅约9%的塑料废物被成功回收；欧洲每年产生约2600万吨塑料废物，欧盟目标是到2025年将1000万吨回收塑料用于产品。
• 实践建议：最佳方案是避免使用一次性塑料；尽管回收有局限，但回收塑料仍比丢弃更好，能为产品提供材料。

作者核心观点是：为开源工作付费是绝对的好事，应停止批评开源维护者获得报酬，转而支持并庆祝。

背景与问题

作者在社交媒体上因一句话引发争议。其观点是：社区常声称“开源应可持续，维护者应获报酬”，但当维护者通过引入商业功能、为大公司工作或接受投资等方式实际获得报酬时，却常遭批评。作者认为这反映出一种虚伪或不切实际的态度。

核心立场

1. 付费从事开源是根本好事：所有让维护者获得收入的机制虽有缺陷，但世界本身不完美。将系统问题归咎于为生计挣扎的个人是错误的。
2. 开源的重要性：开源是人类集体协作的显著成就，有益于全社会。应让更多人能以此为生，并过上体面生活。
3. 当前现实：极少有人能靠维护开源软件维生（如Django、Python等重要项目仅有个位数全职维护者）。可持续性应指维护者能获得接近行业平均水平的收入，拥有同事支持以保障休息。

关键定义澄清

• 开源/自由软件：作者采用广义定义，涵盖从完全自由到有限制的许可证（包括OSI、FSF批准之外的PolyForm、BSL等），反对过于狭隘的许可证纯洁性争论。
• 可持续性：特指维护者能否靠写开源软件维持舒适生活。

为何应支持各种报酬方式

• 理想与现实的差距：理想中政府应视开源为公共产品并资助，但现实中这并不存在。因此，任何实际报酬方式都是进步。
• 具体应庆祝的情形：包括受雇于大公司（如微软）、获得资助、通过众筹（如Patreon）、接受风险投资、采用开放核心模式、使用非OSI许可证避免被滥用等。每种方式都有缺陷，但都是在当前体系下的现实胜利。

对批评的反驳

• 常见批评：如“非OSI许可证不算开源”、“受雇于公司则立场不纯”、“众筹是乞讨”、“风险投资会导致变质”等。
• 作者的回应：应区分批评系统与批评个人。可批评风险投资模式、平台抽成或许可证限制，但不应指责试图谋生的维护者。结构问题是社会性的，个人无需承担。
• 纯洁性的代价：坚持绝对纯洁的机制会限制开源对社会的价值。在更公平的社会制度出现前，应接受不完美的现实方案。

结论

应停止对获得报酬的开源维护者的批评，转而庆祝任何为开源工作带来可持续收入的尝试。这需要社区调整心态，优先支持人的生存，而非纠结于意识形态的纯洁性。

Ollama Windows 预览版发布

核心特性

原生 Windows 体验：Ollama 现已推出 Windows 预览版，用户可直接在 Windows 系统中拉取、运行和创建大型语言模型。

硬件加速：

• 自动利用 NVIDIA GPU 加速模型运行。
• 支持现代 CPU 指令集（如 AVX、AVX2）。
• 无需配置或虚拟化，开箱即用。

完整模型库访问：

• 可访问 Ollama 的完整模型库，包括视觉模型（如 LLaVA 1.6）。
• 运行视觉模型时，支持通过拖放图片至 ollama run 界面来添加图像内容。

始终在线的 API 服务：

• Ollama API 在后台自动运行，服务地址为 http://localhost:11434。
• 第三方工具和应用可直接连接，无需额外设置。

示例：可通过 PowerShell 调用 API：

(Invoke-WebRequest -method POST -Body '{"model":"llama2", "prompt":"Why is the sky blue?", "stream": false}' -uri http://localhost:11434/api/generate ).Content | ConvertFrom-json

OpenAI 兼容性：

• Windows 版支持与其他平台相同的 OpenAI 兼容模式。
• 允许使用为 OpenAI 开发的现有工具与本地 Ollama 模型交互。

开始使用

1. 下载 Ollama Windows 安装程序。
2. 双击运行 OllamaSetup.exe。
3. 安装完成后，在终端执行 ollama run llama2 以运行模型。

后续更新：Ollama 将在有新版本时提示更新。 反馈渠道：用户可通过提交 GitHub issue 或加入 Discord 服务器反馈问题与建议。

流行的Git配置选项

作者在Mastodon上询问人们最喜欢的Git配置选项，并收集了许多回复。文章列出了最受欢迎的Git配置选项，按流行度大致排序，并解释了每个选项的用途、设置方法和注意事项。以下是主要选项的摘要：

避免意外合并提交

• pull.ff only 或 pull.rebase true：这两个选项最流行，用于避免运行git pull时意外创建合并提交。pull.rebase true等同于每次拉取时使用--rebase，pull.ff only等同于使用--ff-only。Git默认行为在分支分叉时会报错，类似于--ff-only。

改进合并冲突显示

• merge.conflictstyle zdiff3：使合并冲突更易读。默认冲突显示只比较两个版本，而zdiff3（或diff3）会显示原始版本，帮助理解冲突来源。zdiff3是更新版本，更受欢迎。

优化变基操作

• rebase.autosquash true：自动处理fixup!提交，便于修改旧提交。设置后，git rebase会自动应用--autosquash，将修复提交与目标提交合并。
• rebase.autostash true：在rebase前自动运行git stash，rebase后自动运行git stash pop，简化工作流程。

推送行为配置

• push.default simple：Git默认值，只推送到已跟踪的远程分支。
• push.default current：总是推送到同名远程分支，无需预先跟踪。
• push.autoSetupRemote true：首次推送时自动设置跟踪，允许后续拉取。作者更喜欢这个选项，因为它兼顾推送和拉取功能。

初始化和提交相关

• init.defaultBranch main：创建新仓库时默认使用main分支而非master。
• commit.verbose true：在提交信息编辑器中显示完整的diff，帮助记忆更改。

冲突解决和帮助功能

• rerere.enabled true：启用rerere（重用已解决的冲突），记录合并冲突的解决方式，自动解决重复冲突。
• help.autocorrect 10：设置自动纠正命令的延迟时间，例如10表示1秒后执行纠正后的命令。

分页器和差异显示

• core.pager delta：设置分页器为delta等工具，提供语法高亮。其他选项包括less -x5,9或cat。
• diff.algorithm histogram：使用histogram算法显示diff，特别在函数重排序时更清晰，比默认算法更易读。

全局配置和排除文件

• core.excludesfile ~/.gitignore：设置全局.gitignore文件，用于排除如.DS_Store等不应提交的文件。默认路径为~/.config/git/ignore。
• includeIf：为不同目录设置不同的git配置，例如区分个人和工作邮箱。通过目录条件加载配置文件。

URL替换和安全性

• url."git@github.com:".insteadOf：自动将HTTPS URL替换为SSH URL，简化克隆操作。示例：将https://github.com替换为git@github.com:。
• fsckobjects：设置transfer.fsckobjects、fetch.fsckobjects、receive.fsckObjects为true，用于检测数据损坏，防止仓库问题。

子模块管理

• 子模块相关选项如status.submoduleSummary true、diff.submodule log、submodule.recurse true，用于改善子模块的使用体验。

其他流行选项

• blame.ignoreRevsFile .git-blame-ignore-revs：指定忽略特定提交的blame，避免大型重命名干扰。
• branch.sort -committerdate：按最近使用排序分支，便于查找。
• color.ui false：禁用颜色输出。
• commit.cleanup scissors：防止提交信息中的#被当作注释删除。
• core.autocrlf false：在Windows上与Unix用户协作时设置。
• diff.tool difftastic：使用外部工具（如difftastic）显示差异。
• fetch.prune true：自动删除已删除的远程跟踪分支。
• gpg.format ssh：允许使用SSH密钥签名提交。
• rebase.updateRefs true：简化多个堆叠分支的变基操作。

设置方法

这些选项通常使用git config --global NAME VALUE命令设置，作者偏好全局设置。删除选项时，手动编辑~/.gitconfig文件。

作者自己的更改

作者在写文章后添加了三个配置：diff.algorithm histogram、branch.sort -committerdate和merge.conflictstyle zdiff3，并提到谨慎添加新选项以避免混淆。

文章总结指出，通过社区询问常用选项，整理列表比浏览所有600多个Git配置选项更高效。Git默认选项随时间变化，一些实验性选项可能已被移除或替换。

API“惰性”设计原则：正确执行“无操作”的艺术

本文探讨了当API需要执行“无操作”（do nothing）时的设计哲学——关键在于以正确的方式实现“无操作”，确保行为与文档一致且不破坏现有应用。核心概念被称为“惰性”（inert）：API表面完整且符合规范，但实际不执行任何操作。

核心设计原则

1. 避免破坏性异常：应避免抛出NotSupportedException等未处理的异常，否则会导致应用崩溃。
2. 保持行为一致性：API的返回结果应与其文档描述一致，即使功能无效也不应产生矛盾信息。
3. 优雅降级：应模拟正常场景下的“空状态”（如无打印机），而非直接报错。
4. 利用已有容错机制：优先使用文档中已定义的返回码（如ERROR_CANCELLED），使现有错误处理逻辑能自然适配。

典型应用场景

1. 跨平台功能适配（如Xbox打印）

• 错误做法：直接抛出NotSupportedException，导致PC应用在Xbox崩溃。
• 正确惰性设计：
  • 打印函数成功返回，但打印机列表为空。
  • 安装打印机函数返回“用户取消”操作。
  • 提供独立检查函数，供主动探测支持状态。
• 设计效果：应用按正常流程操作（弹出空打印机列表），用户自行意识到无可用设备并取消，不会崩溃。

2. API退役时的惰性化

原文以widget管理API为例，说明退役时应如何保持API表面功能但内核为空：

• 初期问题方案：
  • CreateWidget成功返回但句柄为nullptr（与成功返回矛盾）。
  • EnableWidget对传入的“有效”句柄返回“无效句柄”错误（逻辑矛盾）。
• 修正后的惰性设计：
  • CreateWidget统一返回ERROR_CANCELLED（文档已有此返回码）。
  • 后续所有操作（如GetWidgetAliases、EnableWidget、Close）均返回E_HANDLE，因为永远无法创建有效句柄。
• 设计优势：
  • 行为逻辑自洽：既然无法创建widget，自然不存在有效句柄。
  • 复用现有错误码，应用已有的错误处理逻辑可正常运作。
  • 避免生成无意义的虚拟数据（如空别名）。

惰性设计的核心价值

• 对现有应用友好：依赖现有API行为模式的代码（即使不完美）仍能合理运行。
• 维护契约精神：API的行为严格符合其文档规范，不欺骗调用者。
• 降低移植成本：使不支持功能的平台能通过惰性API无缝运行未适配的应用。

作者Raymond Chen（Windows资深开发者）通过此设计模式，强调API设计应优先考虑向后兼容性和行为可预测性，而非简单粗暴地拒绝请求。

根据网络安全公司CHEQ提供给Mashable的数据，在2024年超级碗周末期间，从X平台导向其客户网站的流量中，高达75.85%被判定为虚假流量（如机器人或虚假用户）。CHEQ创始人Guy Tytunovich表示，从未见过如此高比例的虚假流量。

数据对比显示，X的问题远高于其他平台：

• TikTok：虚假流量比例为2.56%
• Facebook：虚假流量比例为2.01%
• Instagram：虚假流量比例为0.73%

此问题并非仅限于超级碗期间。2024年1月的整月数据中，X的虚假流量比例仍高达31.82%，而同期TikTok、Facebook和Instagram的比例分别约为2.8%、2%和0.96%。

背景与原因：

• 2023年超级碗期间（即马斯克收购Twitter后数月），来自该平台的虚假流量比例仅为2.81%，表明问题在近期急剧恶化。
• 可能的原因包括：马斯克收购后大量裁员（包括信任与安全团队的工程师和内容审核员）、验证机制的变化（如取消传统认证并推广付费订阅）、以及新的内容创作者盈利计划等，这些变化可能为机器人活动创造了条件。

影响：

• 广告商通常根据展示次数或点击量付费，大量虚假流量可能导致他们为无效流量买单。
• X平台已因内容管理问题（如仇恨言论）导致广告商流失，而虚假流量数据可能进一步加剧广告商的担忧。

CHEQ通过监测访客与客户网站的互动方式（如检测伪造操作系统信息等）来识别虚假流量。尽管数据基于部分客户样本，但趋势具有显著性。X公司未对Mashable的置评请求作出具体回应。

WJLX无线电塔失踪事件调查新发现

• 实地调查情况：有人前往WJLX无线电塔原址实地查看并拍摄了视频。视频显示，塔楼机房门严重损坏且敞开，周围杂草丛生；内部显然已长期暴露在自然环境中；外部的电表已被拆除。这些迹象表明，该站点可能已被废弃数月甚至数年。
• WJBE电台发射地点违规：调查发现，持有建设许可（CP）的WJBE电台实际上并未在规定的许可地点（位于柯里镇北部的一个手机信号塔）进行发射。相反，它可能在使用几英里外的一个市政水塔进行广播。尽管该电台在2009年、2021年和2024年多次申请建设许可，但从未就水塔发射站点提交正式的许可覆盖申请，此举涉嫌违反广播电台发射地点的相关规定。
• 关联机构与模式：负责WJBE项目的机构“Big South Community Broadcasting”的主要联系人是Brett Elmore。文章指出，此人此前已涉嫌违反AM广播规则。此外，该机构最近获得了位于汉密尔顿的90.1频率的新非商业广播许可证，并恢复使用了历史呼号WERH。鉴于其过往记录，文章对其在新项目中是否会遵守规则表示怀疑。

TestGen-LLM: Meta使用LLM自动改进单元测试

核心工具与功能： Meta开发了TestGen-LLM工具，其核心功能是自动改进现有的人工编写测试。为了解决大型语言模型（LLM）可能产生的“幻觉”问题，该工具在生成测试类后，会强制其通过一组过滤器验证，以确保生成的测试能可衡量地改进原始测试套件。

部署与评估效果： 该工具已在Instagram和Facebook平台的内部测试活动（test-a-thons）中得到部署和评估。具体效果如下：

• 构建与运行成功率：在对Instagram的Reels和Stories产品评估中，生成的测试用例有75%能成功构建，57%能可靠通过。
• 覆盖率提升：其中25%的测试用例成功提升了代码覆盖率。
• 整体改进率：在测试活动中，该工具改进了它所应用的**11.5%**的测试类。
• 工程师采纳率：其生成的改进建议中，有**73%**被Meta的软件工程师接受并部署到生产环境。

意义与结论： 该论文报告了TestGen-LLM在工业规模上的成功部署，并强调这是首份关于在如此规模下部署LLM生成代码并附有明确改进保证的报告。

MathOverflow上第七个最受欢迎的容易理解的未解决问题涉及一个特定的数学恒等式，即Gourevitch猜想：∑_{n=0}^{∞} (1+14n+76n^2+168n^3)/(2^{20n} (2n choose n)^7 = 32π^3。该恒等式可以通过计算机验证，但无法被证明，突显了数学中仍有简单的身份难以通过理论证明。

作者认为这类恒等式虽然本身可能不重要，但暗示着存在数学分支等待被更好地理解。类似问题由数学家Ramanujan发现，许多后来通过模形式（modular forms，连接复分析和数论）和仿模形式（mock modular forms，Ramanujan在给Hardy的最后一封信和他丢失的笔记本中发明的推广）的进步得到证明。Ramanujan的笔记本于1976年在Trinity College被发现。

当前问题询问这个恒等式是否能用模形式或仿模形式证明，或者它是否指向一个全新的数学领域。作者强调只有时间能揭示答案，并提供了完整的未解决问题列表链接供参考。

项目：macOS-cross-compiler

核心功能
这是一个允许在 Linux 系统上编译生成 macOS 可执行文件（二进制文件） 的交叉编译工具链。它使得开发者无需 macOS 硬件或系统环境，即可为 macOS 平台构建软件。

技术背景

• 用途：主要面向需要为 macOS 开发软件但主力环境是 Linux 的开发者，或用于持续集成（CI）流水线中自动化构建 macOS 二进制包。
• 原理：在 Linux 上配置并使用针对 macOS（x86_64 或 ARM64 架构）的编译器、链接器和系统库，实现交叉编译。
• 优势：避免了维护 macOS 机器的成本，统一了跨平台项目的构建环境。

重要说明

• 项目为 开源，托管于 GitHub。
• 使用前需查阅官方文档，了解具体支持范围、配置步骤及潜在限制（如部分 macOS 特定 API 的支持情况）。
• 适用于 C、C++ 等可编译为原生二进制的语言项目。

总结：该工具扩展了 Linux 开发者的跨平台编译能力，简化了 macOS 应用的构建流程。

树莓派长期运行注意事项

树莓派实现数周、数月乃至数年无人值守稳定运行需要系统化应对。文章将常见问题分为四类，并给出了相应的预防与恢复方案。

主要问题类别：

1. WiFi连接失效
2. 软件服务停止工作
3. 硬件/固件/驱动不稳定导致系统崩溃
4. SD卡磨损或存储空间耗尽

关键解决方案与建议：

• 存储优化：
  • 选择高质量的microSD卡。
  • 禁用SD卡上的交换分区。
  • 减少对SD卡的写入，特别是日志写入（可考虑日志轮转或远程日志）。
  • 将根文件系统设置为只读模式。
• 系统维护：
  • 如果未使用只读根文件系统，应定期检查文件系统。
  • 禁用不必要的服务，这有助于提高软件稳定性和减少存储卡磨损。
• 运维策略：
  • 在采取任何侵入性干预措施前，需权衡风险与收益。
  • 配置远程日志记录，以便在出现故障时帮助诊断问题。

重要警告：

• 切勿采用禁用文件系统日志的方案。虽然这能减少存储卡磨损，但会大幅增加系统在崩溃或断电时发生文件系统损坏的风险，这与提高可靠性的目标背道而驰。

Driftmania: 一款PICO-8开源赛车游戏

Driftmania 是一款街机风格的时间挑战赛赛车游戏。玩家的目标是在15条具有挑战性的赛道上获得最快的单圈时间。

核心玩法与操作

游戏提供直观的操控：

• 赛车中：方向键/Z/X 控制加速、刹车、转向和特殊制动(D-Brake)，R键重置关卡，P键暂停。
• 菜单中：方向键导航，Z/X键选择。

关键技巧与机制

• 使用 D-Brake 可加速转向。
• 赛前研究小地图以预判弯道。
• 草地不减速，但会降低抓地力，可利用此特性漂移。
• 触碰黄色瓷砖会激活加速，方向以车辆朝向为准。
• 车库定制仅改变外观，不影响操控。
• 暂停菜单可启用幽灵车，但退出赛道后重放将丢失。

版本更新历史

• 1.0.1：降低了大部分赛道的奖牌难度和解锁新赛道的奖牌要求；幽灵车默认开启。
• 1.1.0：调整了D4赛道（可选的第一个跳跃板，更大的第二个跳跃板）；方向键可用于赛道选择和车库定制；进一步调整奖牌平衡。

制作团队与社区

• 由 Max Bize 制作，Vav 创作音乐，PixelArtM 提供车辆美术（基于其作品），TerracotaScarf 负责封面艺术。
• 游戏为开源项目。
• 拥有竞速社区，玩家可在 Discord 和 speedrun.com 上提交最佳成绩。

可通过 Twitter 关注开发者，或观看 金牌攻略 视频获取更多提示。

简·奥斯汀的小说深刻揭示了爱情与婚姻中的策略性互动，其核心逻辑可借助博弈论进行解读。这一视角表明，人物在看似不理性的行为背后，实则面临着复杂的决策环境。

1. 高风险决策与经济现实 在奥斯汀的时代，婚姻对女性而言是至关重要的经济决策。以《傲慢与偏见》为例，伊丽莎白若不结婚，年收入仅约40英镑；而她后来的丈夫达西先生年收入高达1万英镑，两者差距悬殊。因此，女性择偶时必须极度谨慎，权衡追求者的财富与品格，这关乎其一生的社会地位与经济保障。

2. 择偶谨慎的理论基础：亲本投资理论 女性在生育中投入更大（如怀胎九月），因此面临被只为短期关系、不愿长期投入的男性欺骗的风险。这解释了为何女性在择偶时通常比男性更挑剔、更慢热。奥斯汀笔下的女主人公，如伊丽莎白、玛丽安和爱玛，都曾被看似迷人实则品格不佳的男性所迷惑，这正体现了她们需要规避的风险。

3. 高阶信念与“洞察力” 理解他人的意图需要构建“高阶信念”——即对他人信念的信念。奥斯汀擅长描写人物如何层层推理对方的想法。例如，在《诺桑觉寺》中，凯瑟琳与亨利的互动就涉及多达八层的信念推理。这种在他人视角间反复切换、以理解复杂心理状态的能力，被奥斯汀称为“洞察力”。

4. 现代约会中的类似逻辑 尽管求爱规则已变，但背后的博弈逻辑依然存在。研究表明，男性在约会中通常表现出更大的急切感（如Tinder数据显示男性“点赞”远多于女性），这源于亲本投资不对称。因此，在现代约会中，男性常通过承担约会费用、赠送礼物等成本来表明其认真态度和长期承诺的诚意，从而发出可靠信号。

5. 模糊试探与合理否认 在关系未明时，双方会通过“模糊的试探”谨慎交流。这种含蓄的表达既能探查对方意向，又为若无回应留下了“合理否认”的空间，避免了直接拒绝的尴尬。奥斯汀笔下的人物常在表面礼仪的掩护下，通过机智对话暗通款曲或互相驳斥。然而，过于直白的表态会消除所有高阶信念中的不确定性，将意图变为“共同知识”，可能使关系陷入无法挽回的僵局。

结论 尽管时代背景迥异，但奥斯汀洞察了浪漫互动中永恒的战略层复杂性：如何在高风险下评估他人的品格与意图，如何管理不确定性与模糊性，以及如何通过策略性互动最终达成匹配。正因如此，她的作品跨越两百年，依然能与现代读者产生共鸣。博弈论为我们理解她笔下人物精妙的心理博弈与行为逻辑提供了清晰框架。

论文标题：通过细粒度奖励训练LLM生成带引用的文本

核心问题：大型语言模型在回答用户查询时虽有用，但存在幻觉问题，且回答因缺乏对可靠来源的引用而可信度不足。一种直观的解决方案是在文本中加入指向外部文档的文内引用作为证据。先前工作直接提示LLM生成引用的效果不佳，尤其对较小模型而言。

提出方法：本文提出一种有效的训练框架，利用细粒度奖励来教导LLM生成高度支持且相关性高的引用，同时确保其回答的正确性。研究系统分析了将此类细粒度奖励应用于常见LLM训练策略的效果，证明了其优于传统方法的优势。

实验验证：

1. 数据集：在来自ALCE基准的问答数据集上进行了广泛实验。
2. 泛化能力：使用EXPERTQA验证了模型的泛化性。
3. 关键结果：在LLaMA-2-7B模型上，引入细粒度奖励后，在所有基线中取得了最佳性能，甚至超越了GPT-3.5-turbo的表现。

提交历史：该论文自2024年2月6日首次提交，于5月27日和8月30日进行了两次修订。

古罗马失败的建筑项目

古罗马不仅以其卓越的建筑成就闻名，也存在代价高昂的失败工程。这些未能完成或设计不当的项目引发了关于责任归属的讨论。

在现代新闻中，充满问题的大型建筑项目屡见不鲜。当人们寻找历史上铺张浪费的大型基础设施计划的类比时，记者和政治评论员常会提及20世纪某些政权偶尔出现的荒唐与失败案例。然而，追溯更久远的历史会发现，即使是那些通常以强大建造能力著称的古文明，也曾资助过考虑不周且未能实现的建筑项目。古罗马便是其中一个例证。

文章旨在探讨这些失败项目背后的原因，并可能涉及对古罗马社会、工程管理及资源分配等方面的审视。

Hyrum's Law 核心观点

Hyrum's Law（海勒姆定律） 是关于软件工程的一项观察，其核心表述为：
当一个API拥有足够多的用户时，无论你在接口契约中承诺了什么，系统的所有可观测行为都会被某些用户所依赖。

接口与实现的理论分离

在软件设计中，我们通常将接口视为与系统交互的抽象（如汽车的方向盘和踏板），而将实现视为系统内部的工作方式（如车轮和引擎）。这种分离有助于管理复杂性，使得系统更易于理解和维护。理想情况下，接口应为使用者和实现者提供清晰的界限。

理论与实际的差距

然而在实践中，随着系统使用规模扩大，用户可能会依赖于那些通过接口故意暴露的实现细节，或者通过长期使用而推测出的行为。这种现象类似于Joel Spolsky提出的“抽象泄漏定律”。极端情况下，这会导致“隐式接口”的形成——即如果接口的使用者足够多，他们将共同依赖实现的每一个方面，无论是有意还是无意。

隐式接口的影响

• 逐渐形成：隐式接口通常在使用过程中逐渐形成，且使用者往往并未察觉。例如，即使接口未对性能做出保证，用户也可能依赖其现有的性能特征。
• 约束系统变更：系统实现必须同时遵守明确的文档化接口和由使用模式决定的隐式接口。这常被称为“bug-for-bug兼容性”。
• 接口蒸发：当隐式接口最终与实现完全匹配时，接口实际上已“蒸发”——实现本身成为了接口。此时，任何实现改动都可能破坏用户预期。

设计启示

隐式接口是大型系统有机增长的结果。设计者和工程师在构建和维护复杂系统时，应充分意识到隐式接口对系统设计和演进的约束作用。对于任何广泛使用的系统，接口的影响范围往往远超人们的预期。

作者与命名

• Hyrum Wright：Adobe首席科学家，此前曾在Google担任软件工程师，专注于大规模代码变更工具和基础设施，并参与改进Google的核心C++库。
• 此定律源于其在处理底层基础设施迁移时的经验，即使是最简单的库更改也可能导致远处系统的失败。
• Titus Winters 将此观察命名为“Hyrum's Law”并推动了其广泛传播。

文章标题：Ledger：Stripe用于跟踪和验证资金流动的系统

这篇文章介绍了Stripe开发的Ledger系统，该系统专门用于跟踪和验证资金流动，属于支付基础设施的一部分。文章发布于2024年2月16日，由Stripe工程师Ilya Ganelin撰写，阅读时间约为10分钟，类别涵盖工程、支付和基础设施。作者Ilya Ganelin是Ledger平台的工程师，专注于该系统的设计和实现。

Stripe提供了多种开发者资源以支持相关开发，包括YouTube频道订阅、文档指南、Discord服务器和本地开发者聚会，旨在帮助开发者集成和使用Stripe的功能。此外，文章引用了相关主题的内容，如构建Stripe Credits和实时分析，但本文焦点集中于Ledger系统的核心目的和背景。

总之，本文概述了Ledger在Stripe生态系统中的角色，强调其在资金管理中的关键作用，并提供了相关资源供进一步探索。

Progman: 一个模仿 Windows 3 时代的 X11 窗口管理器

Progman 是一个简单的 X11 窗口管理器，其设计理念模仿了 Windows 3 时代的程序管理器。

许可与编译

• 许可证：MIT 许可证。
• 编译安装：在源代码目录运行 make 进行编译，运行 make install 则默认安装到 /usr/local 目录。

主要功能特性

窗口管理与操作

• 最小化：窗口可以最小化，其图标和标签会显示在桌面（根窗口）上。
• 最大化/全屏：双击窗口标题栏可最大化窗口，并支持通过 _NET_WM_STATE_FULLSCREEN 实现全屏功能。
• 窗口着色：右键单击窗口标题栏可实现“窗口着色”（折叠窗口只显示标题栏）。
• 窗口移动：通过按住 Alt 键（可配置）并单击窗口任意位置即可移动窗口。

输入绑定

• 键盘绑定：支持通过配置文件 ~/.config/progman/progman.ini 的 [keyboard] 节添加快捷键，例如 Win+L = exec xlock。
• 鼠标按钮绑定：支持在桌面上绑定鼠标操作。通过配置文件的 [desktop] 节设置，例如 Mouse3 = exec xterm。默认配置为右键单击桌面时显示一个可配置的启动器菜单，菜单项目列于 progman.ini 的 [launcher] 节中。

工作区与导航

• 虚拟桌面：支持多个虚拟桌面。默认通过 Alt+1 到 Alt+0 的快捷键切换，也支持在桌面上用鼠标滚轮滚动切换。
• 窗口循环：支持使用 Alt+Tab 和 Shift+Alt+Tab 在已打开的窗口间循环切换。

视觉与显示

• 主题支持：支持更换主题。
• HiDPI 支持：提供可选的 HiDPI 缩放支持，用于放大图标和按钮。

文章摘要：从工程师到管理者的爱与恨

本文作者分享了从拥有7年经验的前端开发者转型为工程经理（EM）约两年后的心路历程，对比了该职位带来的积极面与消极面。

喜爱的部分

• 更大的影响力：作为管理者，拥有正式和非正式的权威来改进产品、优化流程和提升团队福祉。个人的建议和决策更有分量，能更有效地推动变革。
• 更优的职业前景：
  • 管理岗位的薪资通常高于基础级别的工程师（初级/中级/高级）。
  • 更高级别的IC岗位（如Staff+）通常集中在大型科技公司，且数量有限。而管理领导职位在几乎所有软件团队中都存在。
  • 管理职级阶梯“更高”，提供了成为CTO等高层职位的可能性。
  • 总体而言，对EM的需求比对Staff+工程师的需求更稳定，职业后期机会更多。
• 可迁移的技能：管理技能适用范围更广。可以领导技术方向迥异的团队（移动端、基础设施、ML等），也有条件转向项目或产品管理。这些技能甚至在其他行业和创业中也很有价值，提供了职业灵活性。
• 知识不易过时：管理核心（团队协作、人际互动）几十年来变化不大，不像前端技术那样快速迭代。可以缓解“技术疲劳”，只需大致关注技术趋势，无需深入钻研每个新工具。
• 新的挑战：对于资深工程师，转向管理是在不降薪的情况下，获得持续多年、全新学习挑战的绝佳方式。

讨厌的部分

• 执行公司政策：曾作为工程师所讨厌的公司流程（如绩效评估、无用的截止日期），现在需要由自己来推行和维护，有时需要做出艰难决定（如评定“低于预期”的员工），容易成为团队眼中的“公司代表”，令人沮丧。
• 处理棘手的人际问题：工作很大一部分是调解人际冲突和安抚心理不安，而非纯粹的技术决策。这对于不擅长处理人际关系的工程师背景者来说极具挑战。
• 不自由的工作时间：工作不再有工程师时期的灵活性。无法长时间离线而不做准备，会积累大量问题。工作与生活的平衡直接取决于你的管理水平。
• 漫长的反馈周期：工程任务（修Bug、新功能）能较快看到结果。而管理举措（如团队重组、招聘新人）往往需要数月才能见效，甚至短期内情况会变糟，难以获得即时满足感，容易让人感到挫折。

总结

作者总结道，转向管理岗位是一次充满起伏的旅程。它拓宽了影响力，提供了持久且灵活的职业路径，并带来新的挑战。但同时也伴随着执行公司政策、处理人际难题、工作时间不自由以及反馈周期漫长等压力。最终，作者认为这是一次值得尝试的经历，能扩展技能并从新视角看待工程工作，但也承认它并非适合所有人。

UI = f(statesⁿ) 文章总结

本文深入探讨了影响用户界面（UI）渲染与体验的各类状态，旨在扩展“UI是状态的函数”这一流行观点，指出UI层受到远超于传统应用或组件状态的多种因素影响。

主要内容概述

文章将影响UI的状态系统性地分为以下几类：

1. 第一方应用状态

指应用程序内部自身的状态。

• 全局状态：应用级的数据存储与功能开关。包括应用存储（如Redux、Vuex、浏览器存储如localStorage）、各类数据（如访问控制数据、用户数据、集合数据、会话数据等）。
• 页面/组件状态：界面元素在不同情境下所处的状态。文章引用了Vince Speelman经典的“设计的九种状态”：空白、加载、无数据、单一数据、部分数据、数据过多、错误、成功、完成。作者在此基础上增加了自定义状态、实时多用户事件消息以及滚动位置状态。
• 元素状态：单个HTML元素自身的状态，通过不同技术体现：
  • 光标状态
  • Intersection Observer状态（是否在视窗内）
  • 堆叠上下文（z-index， 图层）
  • HTML属性状态（如可见性、语言方向、功能属性等）
  • CSS伪类状态（如:hover、:focus、:checked、:disabled等）
  • ARIA状态（面向用户的状态，如aria-expanded）

2. 第二方用户（或设备）状态

指终端用户及其设备、浏览器所引入的状态，这部分状态由Web的设计基础决定，差异性巨大。

• 语言与本地化：文本方向、书写模式、网络延迟、自动翻译、词汇长短等。
• 设备限制：网络连接、视口尺寸与分段、环境常量（如安全区域）、像素密度、低功耗模式、屏幕亮度、CPU/GPU性能、颜色域支持、键盘类型、XR支持等。
• 交互方式：用户输入方式多样，包括鼠标、键盘、触摸/点击、手写笔、手势、设备运动、语音识别、开关设备、眼动追踪、游戏手柄、XR控制器等。
• 输出方式：包括屏幕、文本转语音、屏幕阅读器、盲文显示器、屏幕放大镜、振动等。

3. 浏览器状态

指用户选择的浏览器及其配置、偏好和功能所带来的状态。

• 用户偏好：如配色方案（浅色/深色）、减少动画、减少透明度、页面缩放、文本大小等。
• 功能与特性：浏览器版本、特性检测、颜色域支持、缓存命中情况、显示模式（全屏、独立窗口等）、安装提示、打印模式、阅读模式、JavaScript禁用、休眠标签页等。
• 权限状态：如摄像头、麦克风、地理位置、通知、文件访问等权限的允许与否。
• 插件状态：广告拦截器、自定义插件/增强功能。

4. 用户状态

指实际使用应用程序的人的生理或心理状态，这些状态会直接影响其认知能力或“带宽”。例如：处于紧急情况、认知障碍、永久或暂时性残疾、“精力耗尽”、在室内或室外、在飞机或火车上、在城市或森林中等。

5. 第三方服务状态

第三方服务对UI用户体验有巨大影响。

• 可用性/状态：其他服务器的状态是UI故障的最大风险面。包括服务器硬件、数据库、API、网络字体服务、DNS解析状态、包依赖项（可能损坏或被注入恶意代码）、资产交付与缓存状态（如Cloudflare、S3）等。
• 脚本注入：第三方脚本注入是UI性能下降的最大贡献者，有时甚至会接管应用体验，且常不受控。例如：分析/跟踪服务、用户会话记录、A/B测试注入、教学覆盖层、无障碍覆盖层、第三方认证服务、验证码服务等。

结论与补充

作者总结认为，UI涉及的状态远不止上述所列，还未深入探讨CSS属性及其值冲突、表单控件样式、下拉菜单的ARIA组合、页面图片决策、head标签的设置顺序、用于SEO的微格式以及为发送分析数据所需的代码等复杂细节。文章最后强调，应雇佣精通UI的专业人才。

编辑说明（2024年2月16日）：根据建议，文章补充了“滚动位置”和Intersection Observer状态。

Godot 4.3 引入了基于有向无环图（DAG）的GPU同步系统，这是对底层渲染架构的一次重大升级。该系统完全在 RenderingDevice API 内部自动构建，对用户透明，且API本身保持向后兼容，仅简化了部分方法参数。

背景与问题 此前，Godot 4 的渲染依赖 RenderingDevice，该抽象层虽试图简化Vulkan/D3D12等现代API的复杂性（如命令缓冲、渲染通道、显式屏障），但在实践中暴露了诸多问题：

1. 维护困难：需要手动管理纹理布局转换、屏障掩码等，导致代码分支复杂且易错。
2. 性能隐患：默认采用“过度同步”策略（即为确保正确性而插入过多屏障），限制了GPU并行能力。
3. 难以调试：同步错误依赖特定硬件和场景才能复现，排查极其困难。

解决方案：自动有向无环图 新系统的核心是：在渲染时，将 RenderingDevice 的所有命令（绘制/计算列表等）记录到一个自动构建的依赖图中。

1. 图构建：每个命令成为一个节点。通过资源跟踪器自动检测命令间的依赖关系（如对同一资源的读写冲突、纹理布局变更需求），并在图中添加有向边。
2. 拓扑排序与分层：一帧命令记录完毕后，对图进行拓扑排序，将命令分为不同层级。同一层级内的命令无依赖，可安全并行执行。
3. 命令提交：排序后的命令序列转换为原生API命令并提交。通过按命令类型（绘制、计算、传输）分组执行，进一步优化性能。

关键优化与挑战

• 节点粒度：以整个绘制/计算列表（渲染通道）为一个图节点，而非单个命令，使每帧图节点数保持在数百个，开销极低。
• 资源跟踪：
  • 资源（缓冲/纹理）创建时默认标记为只读且不可变，不创建跟踪器以减少开销。
  • 若运行时修改只读资源，系统会触发一次全同步并创建跟踪器，代价是一帧的性能轻微下降。
• 纹理切片难题：纹理的mipmap层级和数组层可被作为“切片”独立使用，导致内存布局管理极其复杂。系统通过严格的规则（如禁止切片重叠使用、通过“脏列表”统一化布局）来保证正确性。
• 未来优化方向：
  • 多队列提交：利用GPU的专用计算队列等并行执行更多工作。
  • MSAA自动解析：图可自动在最后一次使用MSAA纹理的渲染通道中插入解析操作，节省带宽。
  • 二级命令缓冲：可并行录制大型绘制列表，减少CPU开销。目前因部分硬件兼容性问题暂未默认启用。

成果与影响

• 性能提升：GPU粒子系统获得巨大提升（可并行执行）；常规场景帧时间减少约5%-15%。无性能回退。
• 维护简化：移除了大量手动同步相关代码（约2500行），降低了开发复杂度。
• Bug修复：从根本上解决了因同步错误引发的难以排查的图形瑕疵（如MSAA+SSAO在特定AMD GPU上的问题）。
• 未来基石：为多线程渲染、更高效的资源管理奠定了基础。图结构本身独立且通用，甚至可被非Godot项目借鉴。

该升级是Godot渲染管线的一个长期技术投资，旨在提升性能、简化开发并为未来优化铺平道路。

这篇文章介绍了一个低成本全球规模地理编码器的构建方案：

核心问题

• 现有解决方案（如Pelias）依赖ElasticSearch，需要8GB以上内存，托管成本高
• 作者旨在创建一个运行成本低于10美元/月的可扩展地理编码器

技术实现

1. 地址解析：基于nom库构建了一个简易地址解析器，参考了Pelias的设计
2. 搜索索引：
   • 采用tantivy搜索引擎
   • 创新性地使用匿名内存映射和userfaultfd技术
   • 实现了按需从对象存储加载索引数据的机制
3. 数据存储：约320GB数据存储在对象存储中

性能表现

• 常规查询延迟：1-3秒
• 缓存命中时最快：2毫秒
• 通过范围查询按需获取索引数据，优化内存使用

成本分析

• 计算资源（Fly.io）：约3美元/月
• 存储费用：约7美元/月
• 总成本：约10美元/月

当前局限

• 演示站点仅索引OpenStreetMap数据，不包含OpenAddresses
• 数据覆盖范围有限

开源与扩展

• 项目完全开源
• 计划在未来扩展更多语言环境和用例
• 提供在线演示供测试

该方案通过技术创新成功将全球规模地理编码器的运行成本降至极低水平，为预算有限的项目提供了可行选择。