#杂
意大利作家卡尔维诺在1967年写到：“我们的房子越是灯火通明、繁荣昌盛，墙上就越是充满幽灵。 （The more our houses are illuminated and prosperous, the more their walls drip with ghosts）”

计算机课程教师Simone Conradi认为，这句话彷佛是卡尔维诺对现在的智能生活化的预言。

出自推特。

补充一下，在十几年前所谓的“智能家电”时代，我也没有跟风买了一堆可以用手机app控制的智能家电。家里的白色电器，除了小米电视盒子，都是传统的非智能家电。我觉得我不需要这样的功能。美剧《硅谷》里，也有一个智能电冰箱被控制之后做出不好事情的桥段。可能是因为我对“智能”的忌讳：机器要智能，前提是要足够了解人，要了解人就需要足够的数据。我不愿意暴露我的数据换取这些所谓的智能。

#数据库
我最近都在思考：我自己的本业数据库内核开发，如何和现在的Ai结合起来，或者说，AI会使用怎样的数据库？

刚好看到了这两篇文章。

《AI Agent需要什么样的数据库？》：
* 在各类AI应用中，AI Agent是最活跃的；
* Databricks 最终选择 Neon，无疑是看中了 Neon 数据库的高度亲和 AI Agent 业务特征的关键能力。
* Neon的优点：
* serverless
* 读写分离

由于以上两点，可以做到即使创建、大量小实例等特性，很适合AI Agent这样的业务。

《前阿里高管押注PostgreSQL，打造AI数据库底座》：同样也是提及AI Agent，除了同样分析了Neon这样的产品如何有利于Agent之外，还重点说了一个点：Postgresql上有目前的全模态产品形态（TP\AP\向量），能够一站式提供一个数据库所需的能力。

#杂
（仍然在）待业的这段时间，接触（观察）了很多人：菜市场里每天凌晨起来进货的60+大爷、在小区上门给人洗车的中年人、在直播间努力叫卖的年轻人。

在我眼里，他们都是“努力生活的人”。我感觉对比起来，在空调房里加班敲键盘的工作，还是太轻松了。我可能也是运气好，没怎么碰到过需要996的工作，也可能这是我一把年纪没做出什么成绩的原因吧。

（附件视频是一个在直播间卖衣服的小姐姐，能够做到不间断地每10几秒钟换一身衣服，并且还会有对应的介绍）

我这段时间刷抖音，有时候看到这些人，都会进去说一句：生活不易，加油陌生人。

#博客

博客换了一个主题，除了这个主题更加简洁干净接近我的审美以外，它对多语言的支持也更好，我后续打算把原先很多内容不错的博客转成英文输出，博客内容也“出海”，这样后续在海外做一些内容推广时也有一个能够引流的平台，比如我就把之前分享如何阅读源代码的文章翻译成了英文版本，等工作日的时候往HackerNews发一下。

#Linux内核
《The Kernel in the Mind》，Linux内核开发者写的一系列介绍Linux内核的设计理念、运行机制和核心特性的文章合集。

#人工智能
《Serving Large Language Models on Huawei CloudMatrix384》

硅基流动和华为一起发布了这篇论文，讲解了如何在CloudMatrix 384超节点上部署DeepSeek模型服务，应该算业界首次披露非英伟达体系下是怎么搞定那些难题的。

#博客
《线上故障应急处理：4 年多 on call 经验总结》

#数学
最近被王虹的新闻刷屏了，这名数学家很有可能拿到2026年的菲尔茨奖。

王虹的履历并不是一个中国传统意义上数学天才的故事：高考数学只有130多分、没有参加过什么高级别的奥数竞赛拿过大奖、大学最开始学的也不是数学专业而是从其它专业转过来的。

这样一个非中国典型意义上的数学家能够冲击菲尔茨奖，无疑是给国内的数学教育一记震撼的。对应的，2022年获奖的韩裔许埈珥也是在硕士期间才转到数学专业的。这两人都不能算是数学天才型选手。

我自己觉得，其实不止是数学领域，会解题和真正的研究问题，其实是两个不太一样的技能，中国人更擅长解题，尤其是已经有明确定义的问题。

#杂
https://roadmap.sh/ ： 提供各个方向开发者的学习路线参考。

#数据库
之前说过Postgresql在这一轮AI浪潮里大胜，这就看到一个收集各种PG开源项目的项目 postgres_for_everything。

#Rust
之前一直以为，在Rust代码中只有返回Result类型的函数可以用?提前返回，没想到可不止这个类型，参见：https://doc.rust-lang.org/std/ops/trait.Try.html

我离开 Databend，加入 LanceDB 啦，大家开源社区见！


https://mp.weixin.qq.com/s/5_ZaZAsCHdx9WWEWkWGMMQ

#杂
2024年诺贝尔物理学家得主、人工智能专家 Geoffrey E. Hinton，一家几代人都是科学家，这之前很多人说过就不复述了，参见附图。

值得一提的是他的姑姑Joan Hinton，中文名寒春，曾经参与曼哈顿计划，1948年后来到中国，为中国农业机械化贡献力量（但并未参与中国的核武器研制计划），可以说是中国人民的老朋友，也是首位拿到中国绿卡的外国人。

#文章
《关于编程字体的思考》

#杂
非常形象。

和过往的一切工具进步替代掉人类的某种能力一样：工具进步后，使用这些工具的碳基生物这方面的能力就会下降。例如有了车，人类的步行数量会减少。

#开源项目
asciimoon：一个用ascii拼出高清月相图的网站（Github地址）

#独立开发
《AI 时代如何做独立开发》

#人工智能
前阵子想开始学习一些深度学习的原理，从豆瓣上找来了传说中的鱼书第一册《深度学习入门》，马上就看进去了。浅显易懂，把深度学习和神经网络的相关知识都讲解的很好，没有采用类似PyTorch这样框架做为代码用例，而是用更基础的NumPy库来讲解代码原理。随后看了这套系列书的整体评价都很好，所以就全部收集下来打算都看看。总而言之，如果你和我一样之前都是相关领域的门外汉，强推这套书拿来入门，最近也出了第五册讲生成式模型的。

#开源项目
我把cat替换成了Rust写的bat（alias cat=bat），这个项目最大的亮点就是支持对各种文件的语法高亮。

#分布式
#系统设计
Sriram Subramanian ( niledatabase 的创始人) 关于构建高可用系统的一些思考。原文见推，引用部分是中文翻译。

这是一篇长文，是我在过去几十年构建大规模数据库和存储系统的经验总结和随想。

在超大規模（例如，超过10,000个节点）的系统中，故障随时都在发生。关联性故障（Correlated failures）甚至更为常见。在这样的规模下，要实现所有客户集群的零宕机时间是不切实际的。因此，所有的焦点都应该放在如何减小“爆炸半径”（blast radius）上。

所谓的“爆炸半径管理”（blast radius mgmt），指的就是减少受影响的客户数量，或降低某个特定客户受影响的操作百分比。

当您设计容错系统时，可以思考以下一些技术：

💥 实例崩溃（低爆炸半径）：您通常会故障转移（failover）到另一个实例。对于有状态系统，这通过复制（replication）来实现。对于无状态系统，则是将连接重新平衡（rebalancing）到其他可用实例。如果连接本身是有状态的，那么重新建立连接会变得很棘手。此外，如果一个实例正在为多个客户提供服务，您不会希望将所有负载都转移到另一个实例上，从而导致该节点饱和。您需要将负载重新分配到多个实例上。

⚙️ 实例的某个子系统故障（低爆炸半径）：例如，某个特定的卷（volume）可能会失败。在这种情况下，您通常也会选择直接关停整个实例并故障转移到另一个。因为处理局部故障（partial failures）比处理完全故障（full failure）更麻烦。这里适用第一点中的故障转移规则。

⚠️ 多个实例同时故障（中等爆炸半径）：对于有状态系统，这归结为您愿意设置多少个副本（replica）。这变成了一个成本与可用性之间的权衡问题。同时还存在延迟问题。通过复制，您的写入延迟将取决于写入法定数量（write quorum）中最慢的那个副本的延迟。副本越多，法定数量中至少包含一个慢副本的概率就越大。对于无状态系统，您需要有足够的容量来承接故障实例的负载。一个好的系统建模方式是，预先决定系统应该能够承受多少个关联性故障。例如，N<=2意味着系统在最多2个实例故障时仍能保持可用。
这里有一个有趣的观点是，您可以在云上应用一些巧妙的爆炸半径技术来确保最小化关联性故障。例如，AWS EC2提供放置组（placement groups）。您可以将副本放置在不同的放置组中，这能确保所有副本都位于不同的物理硬件上。

🏢 物理机（Bare metal machine）故障（中等爆炸半径）：为了成本效益，您可能会在一台物理机上托管多个虚拟机（VM）。当物理机发生故障时，爆炸半径会大得多。您需要具备将负载故障转移到不同物理机上的不同虚拟机上的能力。能够吸收负载的机器越多，故障转移就越容易。这需要在使用率和您希望为每台物理机维持的稳态（steady state）利用率之间进行权衡。

🌍 整个可用区（zone）和区域（region）故障（高爆炸半径）：这需要可用区级别和区域级别的故障转移。通过跨区域同步复制（sync replication）可以实现无数据丢失的区域故障转移，但在大多数情况下这并不现实。对于跨可用区复制，您通常希望客户端也一同转移到相同的可用区，以避免跨可用区网络成本。如果您处理的是像Kafka这样的高带宽服务，这个问题会更加突出。

🌐 网络的部分或完全故障（高爆炸半径）：网络的部分故障或网络分区（network partitions）是设计中最难应对的情况之一。您内部的健康检查可能认为一切正常，而客户却无法连接。因此，您总是需要一个从外部进行连接的健康检查。当网络发生故障时，困难的部分是快速检测到它。一旦检测到，标准的故障转移机制就是处理流程。

📡 DNS等全局系统故障（高爆炸半径）：这类故障非常可怕，常常导致一些最大规模的服务中断。您通常需要为这些全局系统设置冗余，以确保您的系统能够抵御这些故障。

🔧 配置、软件和维护变更（爆炸半径可低可高，取决于您的系统设计）：到目前为止，导致服务影响的最常见原因是发布新变更。您需要将您的集群划分为多个单元（cell），并严格控制部署的顺序以及在每个单元升级后如何进行测试。在我过去工作过的几乎所有公司中，我们都必须构建一个大规模的集群管理器（fleet mgr），以自动化地逐个单元地推送新配置、新软件或执行维护（如安全补丁、操作系统升级）。您还需要具备回滚（rollback）的能力。最关键的是，任何变更的回滚都不能有兼容性问题，以确保故障时间最小化。

☸️ Kubernetes故障（爆炸半径可低可高，取决于您打包了多少应用）：K8s管理着成千上万的虚拟机（或物理机），单个K8s集群的故障无疑会影响大量客户。您通常需要进行K8s的健康检查并执行故障转移。这有点棘手，因为您需要构建一种能力，能将一个K8s集群中的实例故障转移到多个其他的K8s集群中，以实现良好的负载管理。您可以保留一些空的K8s集群，以便在这类故障发生时接管工作。

🧩 外部系统（爆炸半径可低可高，取决于您的设计）：您的系统会依赖许多外部系统，如认证、存储、证书、指标等。您必须设计您的系统，使得非关键外部服务的故障绝不影响您的服务质量。例如，用量追踪服务的失败不应影响您的核心服务。您还应该将外部系统依赖的数量保持在最低限度。对于关键的第三方系统，您需要有冗余，并确保第三方提供高可用性保证。

🚦 数据平面（Data plane）与控制平面（Control plane）：控制平面操作是辅助系统管理的元数据操作。数据平面操作是实际的业务数据读写。例如，对于数据库来说，配置一个数据库是控制平面操作，而写入和读取数据是数据平面操作。控制平面操作本身也分层级（层层嵌套）。有全局控制平面操作、区域控制平面操作和单系统级别的控制平面操作。将它们隔离开来，并确保它们的故障不影响数据平面操作，是至关重要的。

这里可能还有很多我没有涵盖到的内容，但重要的是要理解，将一个系统简单地归类为“可用”或“不可用”是非常困难的。故障有许多级别，而爆炸半径决定了受影响的客户数量。构建出色的弹性系统，并理解您在成本、时间和可用性之间所做的权衡。