codedump的电报频道

#投资
#播客
最近听到的几期和投资相关的播客：

《E111.成为塔勒布门徒》：个人非常喜欢塔勒布，从他的几本书也学到很多在其它书籍上很少谈及的知识点（幸存者偏差、黑天鹅、幂律分布、反脆弱...） 强烈推荐把塔勒布的几本书都好好看看。

《SP01 瑞·达利欧的 A 面与 B 面》：最开始因为《原则》一书知道的达里奥，也曾经在频道中推荐过他的视频《经济机器是怎样运行的》，这期播客真是让我对达里奥的公司管理“大开眼界”（贬义）。

《E112.这期节目献给每一位喜欢投资和求真的听友》：长达614分钟的播客，可能在中文播客圈前无古人后无来者了。但是感觉嘉宾滔滔不绝，可做为基金主理人却没有拿住腾讯和英伟达这样的牛股，让我不得不怀疑实际投资能力到底如何。

#开源项目
《从Apache顶级项目到创业征程:一个开源人的坚守与突围》

#共识算法
#Raft
有一点后知后觉，Raft论文的两位作者分别是Diego Ongaro和John Ousterhout，前者是后者的研究生，Diego Ongaro正是在读博士期间和自己的导师John Ousterhout一起完成了Raft论文。

John Ousterhout在前几年出了一本流传甚广的软件设计书籍《A Philosophy of Software Design》（中文名《软件设计的哲学》），同时他还是Tcl的作者。

#书
我至今仍然认为，20多年前我刚刚接触编程的时候，就能看到《程序设计实践》（英文名《The Practice of Programming》，作者 Brian Wilson Kernighan、Rob Pike，C语言之父+Go语言之父的组合），实在运气太好了，它教会了很多如何写好代码的实践。

现在大部分代码都AI写了，不知道这样的书是不是还受人欢迎，不知道这样的技艺还有多少人在乎，想到这里多少有点悲凉。这里可以看到免费电子版。

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

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

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

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

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

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

#杂
非常形象。

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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