codedump的电报频道

#播客 #Infra 《关于 AI Infra 的一切 | 对谈阶跃星辰联创朱亦博》，推荐对Infra领域感兴趣的可以听听这一期。

#开源项目 Google出了一款新字体：Google Sans Code，我用下来体验还不错。

#分布式 年初开始写的分布式教程，目前完成了第一版的初稿，目前还是很粗糙，我还得在此基础上多改几版才能开始在博客公布。 写作这个教程的几个月里，实际上一直有一个自我怀疑：2025年了，还有多少人关注这个领域的原理？在很多系统已经上云、很多开发重心都转到AI上的今天，我始终找不到这个问题的肯定回答。甚至有时候会担心，这不会是类似于高级语言满天飞的年代，还有傻子在写汇编语言教程，受众多少还是会有，但是非常小众。 还有另一个原因让我深刻怀疑：如果这些技术真的很管用，那么我这大半年的时间找工作就不会遇到这么多困难。就我自己的体感而言：几乎是没有专门招聘有分布式经验的工作岗位的。 让我坚持往下写，而且一定要写完到公开状态的原因，到后来变成了要给自己一个交代：通过这段写作历程，系统回顾分布式系统中的常见问题，算是一个给自己的总结，对别人能有点用，这就够了。

#分布式 《Debugging incidents in Google's distributed systems》

#音乐 前两年乐夏里非常喜欢的一首歌《单身旅记》，后来才知道词曲原作者是张雨生，生前只是拍了这首歌简单的demo，陶晶莹也有过翻唱的版本，但是个人感觉还是不如乐夏的版本，电子配乐加上主唱空灵的声音更适合这首歌想表达的意境。 乐夏还有另一首原创的《大梦》，电影版讲完一个普通人的一生，陈楚生在这一季歌手里也有演绎，原创更佳。

#人工智能 我也在尝试AI辅助写代码了。 但是和很多人直接用AI IDE不同的是，我是选择到AI Chat里面问很具体的问题。得益于上古时代编程时积累的提问具体问题的好习惯（见《提问的智慧》），都还是能够得到不错的答案，效率也就提升了不少，估计至少提效了4成吧。对几个免费AI（DS、Kimi K2、Grok 2）的使用下来，感觉Grok 2的编码能力综合起来看是最好的。 另外，使用的过程中我的体验是：就现阶段而言，AI编码还不能让人绝对放心。我向它提问，需要首先我自己清楚这个问题的边界和答案，最后才能在它的基础上加上我的改动得到一个满意的结果。如果这个领域我不熟悉，我是不放心直接使用它提供的答案的。 也就是说，如果我原来的能力是80分，AI编程能够更快给我一个接近80分的答案；而如果我的边界就没有超过80分，我是不确定它提供的90分答案是否就真的是90分。它更多是我提效的工具，这件事情给我来做也可以，但是需要3小时，现在用了它可以提效到1小时。但是我原来就不会这个领域，既问不出好的具体的问题，更不敢放心它的回答。 就这个意义而言，编程这个技能实际上应该是更重要而不是不重要，因为如果不会编程，就像我上面说的那样，不清楚它提供的答案的边界和正确性，是不敢放心使用的。

#Rust Rust编译器贡献者 Nicholas Nethercote 在线找工作《I am a Rust compiler engineer looking for a new job》，连他也在抱怨“AI is sucking up a lot of money and attention in the tech world, leaving less for everything else.”。

#人工智能 XP总结了一套让人工智能总结工作输出周报的提示词，喂给cursor或claude code即可，输出例子如附图。

#杂 才想起来，2021年杭州野生动物园外逃的三只金钱豹，至今仍有一只没有被找到。

5月8日第二只金钱豹被捕获后，对第三只金钱豹的抓捕工作持续了一个月的时间，并采取了监控、诱捕、巡山等措施，但仍没有找到金钱豹的消息。搜捕工作一个月后，停止了对第三只金钱豹的搜捕工作。

#开源项目 给Rust编译器提交的第一个pr被合并了。跟进bug原因花了大几个（> 5）小时，最后只改动了一行代码。这是一次很简单的提交，但是对我个人却是跨出了一大步。 我这些年阅读过不少开源项目代码，但是没有主动给几个开源项目贡献过代码。由于对Rust和编程语言这一领域的喜爱，我打算后续在我业余时间能多参与Rust编译器项目。

#投资 #播客 最近听到的几期和投资相关的播客： 《E111.成为塔勒布门徒》：个人非常喜欢塔勒布，从他的几本书也学到很多在其它书籍上很少以及的知识点（幸存者偏差、黑天鹅、幂律分布、反脆弱...） 强烈推荐把塔勒布的几本书都好好看看。 《SP01 瑞·达利欧的 A 面与 B 面》：最开始因为《原则》一书知道的达里奥，也曾经在频道中推荐过他的视频《经济机器是怎样运行的》，这期播客真是让我对达里奥的公司管理“大开眼界”（贬义）。 《E112.这期节目献给每一位喜欢投资和求真的听友》：长达614分钟的播客，可能在中文播客圈前无古人后无来者了。但是感觉嘉宾滔滔不绝，但是做为基金主理人却没有拿住腾讯和英伟达这样的牛股，让我不得不怀疑实际能力到底如何。

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

#共识算法 #Raft 有一点后知后觉，Raft论文的两位作者分别是Diego Ongaro和John Ousterhout，前者是后者的研究生。 John Ousterhout在前几年出了一本流传甚广的软件设计书籍《A Philosophy of Software Design》（中文名《软件设计的哲学》）。

#书 我至今仍然认为，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地址）

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