#人物
前段时间telegram创始人Pavel Durov的采访播客火了。
实际上，telegram是由两兄弟创办的，还有另一个人Nikolai Durov（哥哥）。弟弟Pavel Durov更加有名气，可能是因为经常露脸。哥哥才是顶级程序员，根据维基对他的介绍：
获得两个和数学相关的博士学位，目前在网上还能找到长达500多页的博士论文《New Approach to Arakelov Geometry》。
按照以上描述，我想象这是一个一边做产品取得世俗意义上的成功，一边还能沉浸在自己纯学术研究精神世界里的人。
前段时间telegram创始人Pavel Durov的采访播客火了。
实际上，telegram是由两兄弟创办的，还有另一个人Nikolai Durov（哥哥）。弟弟Pavel Durov更加有名气，可能是因为经常露脸。哥哥才是顶级程序员，根据维基对他的介绍：
他以“Nikolai Dourov”的名义参加 1996 年、1997 年和 1998 年三年的国际数学奥林匹克竞赛，均获得金牌。此外，从 1995 年到 1998 年，他每年都参加比赛，并在国际信息学奥林匹克竞赛中获得了三枚银牌和一枚金牌。 Durov 与他的朋友 Andrey Lopatin是圣彼得堡国立大学 ACM 团队的成员，该团队在 2000 年和 2001 年的 ACM 国际大学生程序设计竞赛世界总决赛中获得了金牌。
获得两个和数学相关的博士学位，目前在网上还能找到长达500多页的博士论文《New Approach to Arakelov Geometry》。
按照以上描述，我想象这是一个一边做产品取得世俗意义上的成功，一边还能沉浸在自己纯学术研究精神世界里的人。
👍15❤4🤔2
#人工智能
谢青池，美团光年之外的产品负责人，用了一年多的时间一篇一篇地啃完了200多篇AI论文，从开始全然不得要领，到后来逐渐地入门，而他希望将他的论文探索之旅开源给大家。
正因为他是产品经理，也许他的讲解能更通俗地带领我们一窥“技术之美”。
《AI演义 36篇论文开启你的探索之旅》
谢青池，美团光年之外的产品负责人，用了一年多的时间一篇一篇地啃完了200多篇AI论文，从开始全然不得要领，到后来逐渐地入门，而他希望将他的论文探索之旅开源给大家。
正因为他是产品经理，也许他的讲解能更通俗地带领我们一窥“技术之美”。
《AI演义 36篇论文开启你的探索之旅》
w7py8ou4dk.feishu.cn
Docs
❤6
Forwarded from yihong0618 和朋友们的频道 (伊)
如果对 debug 感兴趣，大家可以依次看我心目中最厉害的 debugger 的三个视频和一个播客，能学到非常多的东西：
1. Real World Debugging with eBPF
https://www.youtube.com/watch?v=nggZEwGLC-Q
2. eBPF for Python Troubleshooting
https://m.bilibili.com/video/BV1bJz9YTEGJ
3. gdb -p $(pidof python)
https://bilibili.com/video/BV121Wnz1ELm
4. 播客《和 Gray 聊聊那些年遇到的神奇 Bug》
https://pythonhunter.org/episodes/ep35
1. Real World Debugging with eBPF
https://www.youtube.com/watch?v=nggZEwGLC-Q
2. eBPF for Python Troubleshooting
https://m.bilibili.com/video/BV1bJz9YTEGJ
3. gdb -p $(pidof python)
https://bilibili.com/video/BV121Wnz1ELm
4. 播客《和 Gray 聊聊那些年遇到的神奇 Bug》
https://pythonhunter.org/episodes/ep35
YouTube
SREcon23 Asia/Pacific - Real World Debugging with eBPF
Real World Debugging with eBPF
Zhichuan Liang, Isovalent
In this talk, we'll explore the use of eBPF for debugging real-world production issues in a Golang environment. We'll cover the limitations of traditional debugging tools like gdb and delve, and dive…
Zhichuan Liang, Isovalent
In this talk, we'll explore the use of eBPF for debugging real-world production issues in a Golang environment. We'll cover the limitations of traditional debugging tools like gdb and delve, and dive…
🤩3
#系统编程
《Performance Engineering of Software Systems》，MIT公开课，课程涵盖性能分析、高性能算法技术、指令级优化、缓存优化、并行编程以及构建可扩展系统等主题。
《Performance Engineering of Software Systems》，MIT公开课，课程涵盖性能分析、高性能算法技术、指令级优化、缓存优化、并行编程以及构建可扩展系统等主题。
MIT OpenCourseWare
Lecture Slides | Performance Engineering of Software Systems | Electrical Engineering and Computer Science | MIT OpenCourseWare
Complete lecture slides for 6.172 Performance Engineering of Software Systems.
❤15
#系统编程
《The Life of a Packet in the Linux kernel》，Linux中数据包的一生。
这篇文章以curl 访问一个网站为例，介绍了数据包在Linux系统中从应用程序发送到接收的完整路径。包括Linux网络数据包从send()到recv()的九大核心步骤，涵盖套接字、TCP/IP协议栈、路由、ARP、队列管理、DMA、NAPI、防火墙、NAT等关键机制，结合命令实践，帮助开发者理解底层网络通信原理，可以看作是Linux网络栈入门指南。
《The Life of a Packet in the Linux kernel》，Linux中数据包的一生。
这篇文章以curl 访问一个网站为例，介绍了数据包在Linux系统中从应用程序发送到接收的完整路径。包括Linux网络数据包从send()到recv()的九大核心步骤，涵盖套接字、TCP/IP协议栈、路由、ARP、队列管理、DMA、NAPI、防火墙、NAT等关键机制，结合命令实践，帮助开发者理解底层网络通信原理，可以看作是Linux网络栈入门指南。
0xkato
The Life of a Packet in the Linux kernel
A practical, plain-English tour of how Linux moves packets from write() to the wire and back
👍17
#系统设计
Cloudflare昨晚故障的分析：《Cloudflare outage on November 18, 2025》。
很多人喷生产代码不应该写unwrap，但是有一种场景是：这时候传过来的例如配置文件就是不对，你出错也好、panic也罢，都不能正确处理。与其这样，不如panic报错，我并不认为所有的错误都能被处理，处理的方式之一就是把错误暴露出来，这样才便于问题的修复。
与之相对应的，一个配置文件发布新版本的时候没有进行灰度测试，导致如此大的影响，这才是更大的问题。
Cloudflare昨晚故障的分析：《Cloudflare outage on November 18, 2025》。
很多人喷生产代码不应该写unwrap，但是有一种场景是：这时候传过来的例如配置文件就是不对，你出错也好、panic也罢，都不能正确处理。与其这样，不如panic报错，我并不认为所有的错误都能被处理，处理的方式之一就是把错误暴露出来，这样才便于问题的修复。
与之相对应的，一个配置文件发布新版本的时候没有进行灰度测试，导致如此大的影响，这才是更大的问题。
👍23❤3
#杂
软件发布中的"金丝雀测试"（Canary Testing），这个术语的命名可以追溯到19世纪末到20世纪初的英国煤矿工业。在煤矿中，矿工会随身携带金丝雀下井，这是一种对有毒气体特别敏感的小鸟。当矿井中出现有毒气体时，金丝雀会先于人类出现中毒症状（昏倒或死亡），于是金丝雀的状况成为矿工安全的"早期预警系统"。
在软件开发领域，"金丝雀测试"借用了这个概念：将新版本先部署到一小部分用户（金丝雀），监测这小部分用户的系统表现和错误率，如果出现问题，只影响少量用户，可以快速回滚，确认新版本稳定后再全面推广。
软件发布中的"金丝雀测试"（Canary Testing），这个术语的命名可以追溯到19世纪末到20世纪初的英国煤矿工业。在煤矿中，矿工会随身携带金丝雀下井，这是一种对有毒气体特别敏感的小鸟。当矿井中出现有毒气体时，金丝雀会先于人类出现中毒症状（昏倒或死亡），于是金丝雀的状况成为矿工安全的"早期预警系统"。
在软件开发领域，"金丝雀测试"借用了这个概念：将新版本先部署到一小部分用户（金丝雀），监测这小部分用户的系统表现和错误率，如果出现问题，只影响少量用户，可以快速回滚，确认新版本稳定后再全面推广。
👍11