科技爱好者周刊（第 305 期）里提到的怎么生成真随机数的问题很有意思。

我们都知道编程语言内置的软件随机数都是伪随机数，只要初始种子相同就会生成一样的结果。真随机数需要满足三个条件：1. 无法预测；2. 不能重复；3. 均匀分布

科学家们绞尽脑汁想出了各种方法通过硬件生成真随机数，如:

- random.org 在全世界不数了多个无线接收器，通过大气无线电波（大气噪音，可以理解为大气的布朗运动）来生成随机数

- Cloudflare 在三个办公室部署了不同的随机数生成装置：旧金山办公室放了几十盏不断变化的熔岩灯（图一），需要生成随机数就对着墙拍张照片作为种子；伦敦办公室放着很多单摆（图二），通过它们的摆动和影子生成；奥斯丁办公室则挂了很多彩色反光片（图三）

#fun #coding #visual #newsletter

The Pragmatic Engineer recap 从史上最大 outage 里码农可以学到什么

Root cause：并不是之前网上盛传的 null bytes，是 configuration update 引发了逻辑错误造成 unhandled error

修复过程很慢因为 IT 得手动进入 windows 安全模式并删除肇事文件。随后个人开发者和微软都释出了自动修复工具可以加快修复过程，两天之后 CrowdStrike 表示也在测试新的快速修复手段。

谁该负责？

CrowdStrike，显而易见。但随之而来的问题是：
1. 更新被测试了吗，怎么测试的？
2. 有被员工 dogfood 吗？
3. 有 canary rollout 吗？因为更新本身被认为是“content”而不是“business logic”，它们可能真的 YOLO 了。（这事儿我工作这些年也碰到过不少了，包括 Amazon 的 Sev 0 和特别有名的 Facebook 全系 down 了一整天的 incident）
4. CrowdStrike 是否认为 binary（”content”）files 无法影响 kernel level？
5. 是否忽略过之前类似的 outage？

Microsoft/Windows？在 Mac 上，类似的安全软件只在用户层运行，为什么 windows 允许在 kernel 层？这就引发了第三个罪魁祸首：

政策法规：WSJ 从 Microsoft 得到答复，因为 2009 年微软同意欧盟给安全软件与 Windows 操作系统一样的 access。但这源于 2006 年微软试图使 Windows Vista 更安全。

最后，码农可以从此次事件学到的事：
- 量化所有地方软件 crash 可能造成的影响
- 重新审视代码是如何被部署到 production 的
- Canary/staged rollout
- 把 Configuration 也像代码一样对待（像前面说的一样，光亲眼目睹就看到过两次业界龙头全球范围内的 outage 是这个原因了）
- Dependency/vendors 能未经审核推出什么样的更新？
- Outage 不是一个人的错

#coding #newsletter #tech #Microsoft #导读 #career