https://doi.org/10.1145/3297858.3304053
以用户进程的方式运行 unikernel。unikernel 本身的好处是减小攻击面，减少频繁系统调用的开销，从这个角度来看把 unikernel 当作一个程序来执行像是一种退步或者折中。但是另一方面来看，由于 unikernel 本身的实现，系统调用已经被静态链接到了业务程序中，仅剩一些和外界交互的 hypercall（如 IO 等），使用 seccomp 过滤，劫持了这些 hypercall 以后，确实依然能享受到减少攻击面与减少系统调用的开销。这个实现方式有点类似 gVisor，只不过 gVisor 的内核是在业务程序外，而把 syscall 转变成 hypercall，但限制 gVisor 访问的系统调用也能达到类似的减少攻击面的效果。
以用户进程的方式运行 unikernel。unikernel 本身的好处是减小攻击面，减少频繁系统调用的开销，从这个角度来看把 unikernel 当作一个程序来执行像是一种退步或者折中。但是另一方面来看，由于 unikernel 本身的实现，系统调用已经被静态链接到了业务程序中，仅剩一些和外界交互的 hypercall（如 IO 等），使用 seccomp 过滤，劫持了这些 hypercall 以后，确实依然能享受到减少攻击面与减少系统调用的开销。这个实现方式有点类似 gVisor，只不过 gVisor 的内核是在业务程序外，而把 syscall 转变成 hypercall，但限制 gVisor 访问的系统调用也能达到类似的减少攻击面的效果。
December 4, 2019
https://doi.org/10.1145/3341301.3359656
Ceph 10 年心路历程。大多数的分布式文件系统都是在一个已有的文件系统上实现的用户空间文件系统，Ceph 解释了为什么这么做很难，以及为什么他们认为从 raw device 去实现是更好的方式。尤其是对于 SMR 磁盘这种设备，一个专门设计的文件系统会大幅提升 SMR 磁盘的性能。可以作为实现一个分布式文件系统大概需要考虑哪些方面的问题的参考。
Ceph 10 年心路历程。大多数的分布式文件系统都是在一个已有的文件系统上实现的用户空间文件系统，Ceph 解释了为什么这么做很难，以及为什么他们认为从 raw device 去实现是更好的方式。尤其是对于 SMR 磁盘这种设备，一个专门设计的文件系统会大幅提升 SMR 磁盘的性能。可以作为实现一个分布式文件系统大概需要考虑哪些方面的问题的参考。
February 10, 2020
http://pdxplumbers.osuosl.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf
User-level threads. Google 内部实现协程的一种方式，提供了 SwitchTo 系列的 API。老文，最近刚注意到这个 presentation 里有个细节
- The switch into kernel mode (ring0) is surprisingly inexpensive (<50ns round trip).
- Majority of the context-switching cost attributable to the complexity of the scheduling decision by a modern SMP cpu scheduler.
和传统（过时）的认知有很大区别。
User-level threads. Google 内部实现协程的一种方式，提供了 SwitchTo 系列的 API。老文，最近刚注意到这个 presentation 里有个细节
- The switch into kernel mode (ring0) is surprisingly inexpensive (<50ns round trip).
- Majority of the context-switching cost attributable to the complexity of the scheduling decision by a modern SMP cpu scheduler.
和传统（过时）的认知有很大区别。
February 17, 2020
https://queue.acm.org/detail.cfm?id=3212479
C is not a Low-Level language. It’s a fast PDP-11 emulator.
C is not a Low-Level language. It’s a fast PDP-11 emulator.
April 6, 2020
https://kernel.dk/io_uring.pdf
Linux 内核新加的异步 IO 接口，系统调用只用于信令控制，数据依靠 mmap 共享内存，和 RDMA （或者 Google Snap）是同一类做法。
Linux 内核新加的异步 IO 接口，系统调用只用于信令控制，数据依靠 mmap 共享内存，和 RDMA （或者 Google Snap）是同一类做法。
April 9, 2020
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
fork 曾经被视为 *nix 哲学的代表（fork + exec），但是在这么多年后为了保持简单的接口，实现已经复杂到难以想象，是时候重新思考是不是真的需要 fork 这个接口了。可能是由于实现过于复杂，大多数 unikernel/unix 兼容层都没有实现 fork。
fork 曾经被视为 *nix 哲学的代表（fork + exec），但是在这么多年后为了保持简单的接口，实现已经复杂到难以想象，是时候重新思考是不是真的需要 fork 这个接口了。可能是由于实现过于复杂，大多数 unikernel/unix 兼容层都没有实现 fork。
April 29, 2020
https://queue.acm.org/detail.cfm?id=1814327
The past 30 or 40 years of hardware and operating-systems development seems to have only marginally impinged on the agenda in CS departments' algorithmic analysis sections, and as far as my anecdotal evidence, it has totally failed to register in the education they provide.
问题本身不复杂，简单的改进 binary heap 尽可能减少一次查询访问到的页的数量，在高内存负载下能提升最多 10 倍的性能。
The past 30 or 40 years of hardware and operating-systems development seems to have only marginally impinged on the agenda in CS departments' algorithmic analysis sections, and as far as my anecdotal evidence, it has totally failed to register in the education they provide.
问题本身不复杂，简单的改进 binary heap 尽可能减少一次查询访问到的页的数量，在高内存负载下能提升最多 10 倍的性能。
June 27, 2020
https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls
可以看一下对于系统调用开销的 evaluation，直接开销在大多数情况下占比都在 50% 甚至更少。系统调用导致的如 cache 清空等副作用，会大幅降低返回 userspace 执行的 IPC。
可以看一下对于系统调用开销的 evaluation，直接开销在大多数情况下占比都在 50% 甚至更少。系统调用导致的如 cache 清空等副作用，会大幅降低返回 userspace 执行的 IPC。
July 19, 2020
https://queue.acm.org/detail.cfm?id=3404974
提供一套处理线上 outage 的标准流程，基本上都是比较通用的步骤。可以防止手忙脚乱导致次生灾害，根据自己公司的情况酌情调整，原则上都比较类似。
提供一套处理线上 outage 的标准流程，基本上都是比较通用的步骤。可以防止手忙脚乱导致次生灾害，根据自己公司的情况酌情调整，原则上都比较类似。
July 19, 2020
https://ieeexplore.ieee.org/document/8543387
Checked C 的设计是在 C 原有的设计上打补丁，以最小的改动来避免某类（越界）错误的发生。在缓冲区溢出可能占了绝大多数 C 库安全问题来源的情况下，用这种方式来解决而不是从头设计一个语言是个挺有趣的思路。
Checked C 的设计是在 C 原有的设计上打补丁，以最小的改动来避免某类（越界）错误的发生。在缓冲区溢出可能占了绝大多数 C 库安全问题来源的情况下，用这种方式来解决而不是从头设计一个语言是个挺有趣的思路。
August 3, 2020
https://queue.acm.org/detail.cfm?id=3415014
Using services rather than a single centralized database is like going from Newton's physics to Einstein's physics.
All data seen from a distant service is from the "past." By the time you see data from a distant service, it has been unlocked and may change. Each service has its own perspective. Its inside data provides its framework of "now." Its outside data provides its framework of the "past." My inside is not your inside, just as my outside is not your outside.
Using services rather than a single centralized database is like going from Newton's physics to Einstein's physics.
All data seen from a distant service is from the "past." By the time you see data from a distant service, it has been unlocked and may change. Each service has its own perspective. Its inside data provides its framework of "now." Its outside data provides its framework of the "past." My inside is not your inside, just as my outside is not your outside.
August 22, 2020
September 14, 2020
https://github.com/seL4/whitepaper
seL4 白皮书（2020-06-10）。对 seL4 的架构，应用场景和各方面设计选型做了简要概述，可以对 seL4 有个整体的概念，也是比较好的了解微内核设计方向的综述。
...and Zircon is almost nine times slower than seL4
seL4 白皮书（2020-06-10）。对 seL4 的架构，应用场景和各方面设计选型做了简要概述，可以对 seL4 有个整体的概念，也是比较好的了解微内核设计方向的综述。
...and Zircon is almost nine times slower than seL4
December 28, 2020
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
What Every Programmer Should Know About Memory (2007)。一百页以上的内存相关的 All-in-one 手册，涵盖了从内存的硬件原理到和各种其他硬件的交互。建议挑自己感兴趣的章节阅读。
What Every Programmer Should Know About Memory (2007)。一百页以上的内存相关的 All-in-one 手册，涵盖了从内存的硬件原理到和各种其他硬件的交互。建议挑自己感兴趣的章节阅读。
January 28, 2021
https://hack.org/mc/texts/gosling-wsd.pdf
Window System Design: If I had it to do over again in 2002。 X11 的哪些设计假设已经不再成立，使得 X11 成为了 Linux desktop 的瓶颈。对成为瓶颈的硬件（对 X11 来说是渲染性能）提升的错估几乎是那个年代设计的的通病。不过即使到了快 20 年后， 2021 年解决这些问题的 Wayland 还是没有彻底的取代 X11。
Window System Design: If I had it to do over again in 2002。 X11 的哪些设计假设已经不再成立，使得 X11 成为了 Linux desktop 的瓶颈。对成为瓶颈的硬件（对 X11 来说是渲染性能）提升的错估几乎是那个年代设计的的通病。不过即使到了快 20 年后， 2021 年解决这些问题的 Wayland 还是没有彻底的取代 X11。
January 31, 2021
http://erlang.org/download/armstrong_thesis_2003.pdf
At the highest level of abstraction an architecture is “a way of thinking about the world.”
对 erlang 语言本身不是特别有兴趣的可以跳着看下 2，5，10 章和 APPENDIX B。
一些内容的 TL;DR 版本：
1. A component is considered faulty once its behaviour is no longer consistent with its specification.
2. We say a system is fault-tolerant if its programs can be properly executed despite the occurrence of logic faults.
- 系统中存在无法提前预估到的错误是不可避免的
- 既然错误无法避免，需要一种方法把无法预估到的错误转化为可以被预测到的逻辑，这是一种错误隔离的机制
- 要在这种情况下继续响应请求，可以降级到更简化更不容易出错的逻辑
erlang 的这种架构在其他系统中以更大规模的进程 / 服务 / 集群的形式广泛存在，其中最核心的理念就是错误隔离
At the highest level of abstraction an architecture is “a way of thinking about the world.”
对 erlang 语言本身不是特别有兴趣的可以跳着看下 2，5，10 章和 APPENDIX B。
一些内容的 TL;DR 版本：
1. A component is considered faulty once its behaviour is no longer consistent with its specification.
2. We say a system is fault-tolerant if its programs can be properly executed despite the occurrence of logic faults.
- 系统中存在无法提前预估到的错误是不可避免的
- 既然错误无法避免，需要一种方法把无法预估到的错误转化为可以被预测到的逻辑，这是一种错误隔离的机制
- 要在这种情况下继续响应请求，可以降级到更简化更不容易出错的逻辑
erlang 的这种架构在其他系统中以更大规模的进程 / 服务 / 集群的形式广泛存在，其中最核心的理念就是错误隔离
April 19, 2021
https://how.complexsystems.fail
> A corollary to the preceding point is that complex systems run as broken systems. The system continues to function because it contains so many redundancies and because people can make it function, despite the presence of many flaws.
写于 1998 年，即使描述的对象（e.g. transportation, healthcare, power generation）是和互联网公司完全不同类型的系统，复杂系统的本质并没有太多变化
> A corollary to the preceding point is that complex systems run as broken systems. The system continues to function because it contains so many redundancies and because people can make it function, despite the presence of many flaws.
写于 1998 年，即使描述的对象（e.g. transportation, healthcare, power generation）是和互联网公司完全不同类型的系统，复杂系统的本质并没有太多变化
May 3, 2021
https://arxiv.org/pdf/1305.4924.pdf
The experiments reported in this paper indicate that even a very basic nonlinear model is generally more accurate than the state-of-the-art linear model in the computer performance literature.
常见的非线性原因：L1 L2 cache，分支预测
The experiments reported in this paper indicate that even a very basic nonlinear model is generally more accurate than the state-of-the-art linear model in the computer performance literature.
常见的非线性原因：L1 L2 cache，分支预测
May 6, 2021
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/llama-vldb2013.pdf
LLAMA：一个通用的 page cache + storage management 的设计。作为一个存储系统中抽出的通用组件，LLAMA 设计了一套泛用高效的接口，并且讨论了许多解决竞态 / crash recovery 的方案。
LLAMA：一个通用的 page cache + storage management 的设计。作为一个存储系统中抽出的通用组件，LLAMA 设计了一套泛用高效的接口，并且讨论了许多解决竞态 / crash recovery 的方案。
May 18, 2021
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/acrobat-17.pdf
系统设计的常见 slogan 合集（1983）。其中很多系统的设计原则很难靠几句话几个例子理解，不过还是能提供一些思路。
The main reason interfaces are difficult to design is that each interface is a small programming language: it defines a set of objects and the operations that can be used to manipulate the objects.
系统设计的常见 slogan 合集（1983）。其中很多系统的设计原则很难靠几句话几个例子理解，不过还是能提供一些思路。
The main reason interfaces are difficult to design is that each interface is a small programming language: it defines a set of objects and the operations that can be used to manipulate the objects.
May 21, 2021
https://docs.wixstatic.com/ugd/0c1418_d9878707bbb7427786b70c3c91d5fbd1.pdf
Introduction to Compute Express Link。想象一下一台电脑中有多少设备有自己的内存：SSD/HDD/Raid cache、显存、SmartNIC。因为使用了 DRAM cache，为了提供掉电保护，很多设备有需要提供一套自己的电池 / 电容。这些都大幅提高了单个设备的成本，并且让硬件变得复杂很多。CXL 提供了一套基于 PCIE 5.0 及以上的协议，让设备和主内存可以共享资源，协议有三个部分：
- CXL.io protocol is based on PCIe and is used for the functions such as device discovery, configuration, initialization, I/O virtualization, and direct memory access (DMA) using non- coherent load-store, producer-consumer semantics.
- CXL.cache enables a device to cache data from the host memory, employing a simple request and response protocol.
- CXL.memory allows a host processor to access memory attached to a CXL device.
CXL.io 提供了最基本的支持 CXL 设备的发现和设置功能；CXL.cache 让设备可以使用主内存（或者任意 byte addressable 的内存性质的）来作为缓存，比如 DRAM-less 的 SSD 可以用系统的主内存来作为读写缓存；CXL.memory 让 CPU 可以直接访问 CXL 设备的内存（类似于 AMD 的 Smart Access Memory 对所有 CXL 设备的通用版本）。
几个现实场景：使用 CXL.cache 作为读写缓存的 SSD 不用再实现自己的掉电保护，host 可以提供统一的掉电保护功能；host 可以提供 16G 的 optane（persistent memory）来作为任何 CXL 设备的缓存，就按现在 Intel 的 M10 大小来说，是大多数设备单独提供缓存时不能承受的成本。
支持 CXL 1.1 的设备预计在 2022 年就会开始推出，这些设备本身也和 PCIE 5.0 兼容。
Introduction to Compute Express Link。想象一下一台电脑中有多少设备有自己的内存：SSD/HDD/Raid cache、显存、SmartNIC。因为使用了 DRAM cache，为了提供掉电保护，很多设备有需要提供一套自己的电池 / 电容。这些都大幅提高了单个设备的成本，并且让硬件变得复杂很多。CXL 提供了一套基于 PCIE 5.0 及以上的协议，让设备和主内存可以共享资源，协议有三个部分：
- CXL.io protocol is based on PCIe and is used for the functions such as device discovery, configuration, initialization, I/O virtualization, and direct memory access (DMA) using non- coherent load-store, producer-consumer semantics.
- CXL.cache enables a device to cache data from the host memory, employing a simple request and response protocol.
- CXL.memory allows a host processor to access memory attached to a CXL device.
CXL.io 提供了最基本的支持 CXL 设备的发现和设置功能；CXL.cache 让设备可以使用主内存（或者任意 byte addressable 的内存性质的）来作为缓存，比如 DRAM-less 的 SSD 可以用系统的主内存来作为读写缓存；CXL.memory 让 CPU 可以直接访问 CXL 设备的内存（类似于 AMD 的 Smart Access Memory 对所有 CXL 设备的通用版本）。
几个现实场景：使用 CXL.cache 作为读写缓存的 SSD 不用再实现自己的掉电保护，host 可以提供统一的掉电保护功能；host 可以提供 16G 的 optane（persistent memory）来作为任何 CXL 设备的缓存，就按现在 Intel 的 M10 大小来说，是大多数设备单独提供缓存时不能承受的成本。
支持 CXL 1.1 的设备预计在 2022 年就会开始推出，这些设备本身也和 PCIE 5.0 兼容。
May 22, 2021
https://ckrybus.com/static/papers/Bainbridge_1983_Automatica.pdf
Ironies of automation (1983)
- 系统自动化的部分出发点是降低维护成本
- 维护高度自动化的系统需要对该自动化系统相关领域知识有深入了解的操作员，高技能的操作员需要极高的培养成本
- 在系统自动化程度大于某个阈值时，培养操作员的成本会大于开发自动化系统的人员的成本，这个界限就是 ops 失去意义，devops 和 SRE 成为系统维护员的时刻
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
Ironies of automation (1983)
- 系统自动化的部分出发点是降低维护成本
- 维护高度自动化的系统需要对该自动化系统相关领域知识有深入了解的操作员，高技能的操作员需要极高的培养成本
- 在系统自动化程度大于某个阈值时，培养操作员的成本会大于开发自动化系统的人员的成本，这个界限就是 ops 失去意义，devops 和 SRE 成为系统维护员的时刻
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
May 24, 2021
https://people.eecs.berkeley.edu/~krste/papers/maas-isca18-hwgc.pdf
A Hardware Accelerator for Tracing Garbage Collection
可以把这个硬件想象为一个专门用来 offload GC 开销的特化 CPU 核心
> Most work on hardware-assisted GC was done in the 1990s and 2000s when Moore’s Law meant that next-generation general-purpose processors would typically outperform specialized chips for languages such as Java, even on the workloads they were designed for. This gave a substantial edge to non-specialized processors. However, with the end of Moore’s Law, there is now a renewed interest in accelerators for common workloads.
在通用硬件无法享受制程迭代提升的情况下，可能会有更多特化的专有硬件的出现
A Hardware Accelerator for Tracing Garbage Collection
可以把这个硬件想象为一个专门用来 offload GC 开销的特化 CPU 核心
> Most work on hardware-assisted GC was done in the 1990s and 2000s when Moore’s Law meant that next-generation general-purpose processors would typically outperform specialized chips for languages such as Java, even on the workloads they were designed for. This gave a substantial edge to non-specialized processors. However, with the end of Moore’s Law, there is now a renewed interest in accelerators for common workloads.
在通用硬件无法享受制程迭代提升的情况下，可能会有更多特化的专有硬件的出现
May 25, 2021
http://nischalshrestha.me/docs/cross_language_interference.pdf
Why Is It Difficult for Developers to Learn Another Programming Language?
主要的学习场景：
1. Learning on their own: Programmers lacked formal training for the new language and its associated technology stack, leaving learning to themselves.
2. Just-in-time learning: Programmers focused on only learning features as needed.
3. Relating new language to previous languages: Programmers tried to map features of the new language to their previous languages.
主要的困难：
1. Old habits die hard: Programmers had to constantly suppress old habits from previous languages.
2. Mindshifts when switching paradigms: Sometimes programmers wrestled with larger differences that required fundamental shifts in mindsets, or “mindshifts.”
3. Little to no mapping with previous languages: Programmers had a harder time learning the new language when there was little to no mapping of features to previous languages.
4. Searching for terms and documentation is hard: Programmers found it difficult to search for information about the language and its associated technologies.
5. Retooling is a challenging first step: Programmers faced difficulty retooling themselves in the environment of the new language.
学习新语言时由于自己的经验被 challenge，很容易陷入 defensive 的焦虑心态，特别是当新语言的特性 / 功能和预期（常常来自过去的经验）不符合时。虽然人不是理智的生物，无法避免这种情绪的产生，了解一些普遍的原因还是可以有助于调整自己的心态和帮助别人。
Why Is It Difficult for Developers to Learn Another Programming Language?
主要的学习场景：
1. Learning on their own: Programmers lacked formal training for the new language and its associated technology stack, leaving learning to themselves.
2. Just-in-time learning: Programmers focused on only learning features as needed.
3. Relating new language to previous languages: Programmers tried to map features of the new language to their previous languages.
主要的困难：
1. Old habits die hard: Programmers had to constantly suppress old habits from previous languages.
2. Mindshifts when switching paradigms: Sometimes programmers wrestled with larger differences that required fundamental shifts in mindsets, or “mindshifts.”
3. Little to no mapping with previous languages: Programmers had a harder time learning the new language when there was little to no mapping of features to previous languages.
4. Searching for terms and documentation is hard: Programmers found it difficult to search for information about the language and its associated technologies.
5. Retooling is a challenging first step: Programmers faced difficulty retooling themselves in the environment of the new language.
学习新语言时由于自己的经验被 challenge，很容易陷入 defensive 的焦虑心态，特别是当新语言的特性 / 功能和预期（常常来自过去的经验）不符合时。虽然人不是理智的生物，无法避免这种情绪的产生，了解一些普遍的原因还是可以有助于调整自己的心态和帮助别人。
May 27, 2021
https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf
Metastable Failures in Distributed Systems。这篇是最接近我对这类分布式系统事故的模式的理解的。这个理论把系统分为两种状态：
- 稳态：系统正常运作，并且在外部信号改变时能回到稳态
- 亚稳态：系统正常运作，但是当特定外部信号改变时无法回到稳态
亚稳态系统的典型特征：系统中存在某种正反馈循环，在特定情况下会导致系统的特定部分被不断放大直到耗尽资源。任何试图将系统恢复到稳态的尝试都会被无法终止的正反馈循环再次耗尽资源，所以亚稳态系统是无法从故障中自动恢复的，除非将放大器的部分从系统中摘除。亚稳态系统故障的 Root cause 是正反馈循环而不是触发正反馈循环的事件。
Metastable Failures in Distributed Systems。这篇是最接近我对这类分布式系统事故的模式的理解的。这个理论把系统分为两种状态：
- 稳态：系统正常运作，并且在外部信号改变时能回到稳态
- 亚稳态：系统正常运作，但是当特定外部信号改变时无法回到稳态
亚稳态系统的典型特征：系统中存在某种正反馈循环，在特定情况下会导致系统的特定部分被不断放大直到耗尽资源。任何试图将系统恢复到稳态的尝试都会被无法终止的正反馈循环再次耗尽资源，所以亚稳态系统是无法从故障中自动恢复的，除非将放大器的部分从系统中摘除。亚稳态系统故障的 Root cause 是正反馈循环而不是触发正反馈循环的事件。
June 15, 2021
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8704965
Evolution of the Unix System Architecture: An Exploratory Case Study。其中有对于 FreeBSD 从 1970 年（Research PDP7）到现在的架构的演进过程的简单介绍，可以帮助理解一些现在看来不合理的设计是在什么样的背景下做出的决定。现代的操作系统已经过于复杂而让人经常不知道从哪里入手开始了解，这类从最早的原型开始逐渐介绍演变过程的可能是更好的了解操作系统构成的资料。
Evolution of the Unix System Architecture: An Exploratory Case Study。其中有对于 FreeBSD 从 1970 年（Research PDP7）到现在的架构的演进过程的简单介绍，可以帮助理解一些现在看来不合理的设计是在什么样的背景下做出的决定。现代的操作系统已经过于复杂而让人经常不知道从哪里入手开始了解，这类从最早的原型开始逐渐介绍演变过程的可能是更好的了解操作系统构成的资料。
July 4, 2021
https://dl.acm.org/doi/10.1145/3465480.3467835
Thinking in events: from databases to distributed collaboration software。Event sourcing 架构的综述，着重介绍了需要对事件持久化的场景。在理想情况下任何后端的状态能依靠对外部事件的重放来重现，把 source of truth 从数据库转变为事件记录，数据库只是系统状态的一个 snapshot。
Thinking in events: from databases to distributed collaboration software。Event sourcing 架构的综述，着重介绍了需要对事件持久化的场景。在理想情况下任何后端的状态能依靠对外部事件的重放来重现，把 source of truth 从数据库转变为事件记录，数据库只是系统状态的一个 snapshot。
July 13, 2021
https://www.usenix.org/conference/nsdi21/presentation/ghigoff
BMC: Accelerating Memcached using Safe In-kernel Caching and Pre-stack Processing。架构上的改进虽然成立，做法本身有点 ad-hoc，非常强的依赖于 UDP 本身足够简单且无状态，memcached 业务场景大量零散查询，才能在网络栈处理请求之前增加一层 kv cache 提前返回一部分查询结果，eBPF 是否能拓展到更复杂的情况也存疑。比较有意思的是和 kernel-bypass (Userspace Network Stack) 的对比，即使 eBPF 有不小的性能惩罚，现阶段缺少 Userspace Interrupt 的 kernel-bypass 的 polling 开销也远大于 eBPF。
BMC: Accelerating Memcached using Safe In-kernel Caching and Pre-stack Processing。架构上的改进虽然成立，做法本身有点 ad-hoc，非常强的依赖于 UDP 本身足够简单且无状态，memcached 业务场景大量零散查询，才能在网络栈处理请求之前增加一层 kv cache 提前返回一部分查询结果，eBPF 是否能拓展到更复杂的情况也存疑。比较有意思的是和 kernel-bypass (Userspace Network Stack) 的对比，即使 eBPF 有不小的性能惩罚，现阶段缺少 Userspace Interrupt 的 kernel-bypass 的 polling 开销也远大于 eBPF。
September 18, 2021
https://doi.org/10.1145/3243176.3243195
Biased Reference Counting: Minimizing Atomic Operations in Garbage Collection。RC 操作在测试的swift 客户端场景中平均占 42% 的运行时间，RC 的 atomic 操作平均占 25% 的时间。观察到大多数对象很少跨线程，所以将 RC 的计数器区分出 owner 线程（不需要 atomic）和公共线程，最终减少了客户端 22.5% 的平均执行时间。感觉如果 CPU 能提供专门的 RC 指令然后分发给加速器而不在当前的指令流水线处理，能解决 atomic 对性能影响的大多数情况，这类 RC 场景并不需求非常严格的内存释放的实时性。
Biased Reference Counting: Minimizing Atomic Operations in Garbage Collection。RC 操作在测试的swift 客户端场景中平均占 42% 的运行时间，RC 的 atomic 操作平均占 25% 的时间。观察到大多数对象很少跨线程，所以将 RC 的计数器区分出 owner 线程（不需要 atomic）和公共线程，最终减少了客户端 22.5% 的平均执行时间。感觉如果 CPU 能提供专门的 RC 指令然后分发给加速器而不在当前的指令流水线处理，能解决 atomic 对性能影响的大多数情况，这类 RC 场景并不需求非常严格的内存释放的实时性。
September 25, 2021
https://lwn.net/ml/linux-kernel/20210913200132.3396598-1-sohil.mehta@intel.com/
Intel 在 CPU 中加入了 User Interrupts 的扩展，让进程具有不经过内核的 IPC 能力。当前版本的实现还比较受限，除了只能用于用户进程到用户进程的中断，Linux 也没有提供完全的控制调度的能力，可能只有 Snap 这种场景可以享受到延迟大幅下降的收益。不过这至少是实现能和内核空间同等性能的用户空间驱动的第一步，也有避免 hypercall 来解决硬件 / 部分虚拟化 I/O 性能的潜力。
Intel 在 CPU 中加入了 User Interrupts 的扩展，让进程具有不经过内核的 IPC 能力。当前版本的实现还比较受限，除了只能用于用户进程到用户进程的中断，Linux 也没有提供完全的控制调度的能力，可能只有 Snap 这种场景可以享受到延迟大幅下降的收益。不过这至少是实现能和内核空间同等性能的用户空间驱动的第一步，也有避免 hypercall 来解决硬件 / 部分虚拟化 I/O 性能的潜力。
October 3, 2021
https://www.usenix.org/conference/nsdi21/presentation/yang-juncheng
面向 TTL 设计的 in-memory key-value cache。常见的纯内存 kv 是依赖较为通用的基于 object 大小的内存分配策略的（类似 tcmalloc / jemalloc 的优化方式）；Segcache 将 TTL 作为 cache 的核心设计，围绕 TTL 来设计内存分配策略，把 segment 变成了类似于 Region-based memory management 的方式。
面向 TTL 设计的 in-memory key-value cache。常见的纯内存 kv 是依赖较为通用的基于 object 大小的内存分配策略的（类似 tcmalloc / jemalloc 的优化方式）；Segcache 将 TTL 作为 cache 的核心设计，围绕 TTL 来设计内存分配策略，把 segment 变成了类似于 Region-based memory management 的方式。
October 24, 2021
https://arxiv.org/abs/2107.01250
Linear Probing Revisited: Tombstones Mark the Death of Primary Clustering。Knuth 1963 年对于 linear-probing hash table 插入操作的复杂度分析指出在 load factor 是 1 - 1/x 的情况下，插入操作的复杂度期望是 Θ(x^2)。本文的不同在于指出如果只有插入操作，是不可能维持 load factor 在 1 - 1/x 或以下的，进一步的考虑常见作为工程实现 trick 的墓碑机制（删除时简单替换被删除的值为墓碑），由于插入在遇到墓碑时就可以停止，一个将 load factor 维持在 1 - 1/x 以下的操作序列中的插入的均摊复杂度会低于 Θ(x^2)。进一步的优化可以在定期重建时均匀的随机插入一些墓碑，让查找和删除均摊插入的开销，最终达到所有操作的期望复杂度都是 Θ(x)。
It turns out that both of these weaknesses can be removed if we simply use a larger rebuild window size R. Intuitively, the larger the R, the more time there is for tombstones to accumulate and the better the insertions perform. On the other hand, tombstone accumulation is precisely the reason that R is classically set to be small, since it breaks the classical analysis and potentially tanks the performance of queries.
这个结果不会显著影响 hash table 的工程实践，更多的是指出已经广泛使用的 linear-probing hash table 并没有过去理论分析中预想的慢。
Linear Probing Revisited: Tombstones Mark the Death of Primary Clustering。Knuth 1963 年对于 linear-probing hash table 插入操作的复杂度分析指出在 load factor 是 1 - 1/x 的情况下，插入操作的复杂度期望是 Θ(x^2)。本文的不同在于指出如果只有插入操作，是不可能维持 load factor 在 1 - 1/x 或以下的，进一步的考虑常见作为工程实现 trick 的墓碑机制（删除时简单替换被删除的值为墓碑），由于插入在遇到墓碑时就可以停止，一个将 load factor 维持在 1 - 1/x 以下的操作序列中的插入的均摊复杂度会低于 Θ(x^2)。进一步的优化可以在定期重建时均匀的随机插入一些墓碑，让查找和删除均摊插入的开销，最终达到所有操作的期望复杂度都是 Θ(x)。
It turns out that both of these weaknesses can be removed if we simply use a larger rebuild window size R. Intuitively, the larger the R, the more time there is for tombstones to accumulate and the better the insertions perform. On the other hand, tombstone accumulation is precisely the reason that R is classically set to be small, since it breaks the classical analysis and potentially tanks the performance of queries.
这个结果不会显著影响 hash table 的工程实践，更多的是指出已经广泛使用的 linear-probing hash table 并没有过去理论分析中预想的慢。
December 28, 2021
https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance
The Harmful Consequences of the Robustness Principle。Robustness Principle 是 HTML 和很多早期互联网协议的设计原则：
Be strict when sending and tolerant when receiving. Implementations must follow specifications precisely when sending to the network, and tolerate faulty input from the network. When in doubt, discard faulty input silently, without returning an error message unless this is required by the specification.
Robustness Principle 基于了一个假设的场景：It is not possible to affect change in a system the size of the Internet，而这和当前互联网协议的维护状况已经不符合了。为了解决 Robustness Principle 导致的事实标准凌驾于协议文档的问题的一个例子：https://web.dev/interop-2022/
The Harmful Consequences of the Robustness Principle。Robustness Principle 是 HTML 和很多早期互联网协议的设计原则：
Be strict when sending and tolerant when receiving. Implementations must follow specifications precisely when sending to the network, and tolerate faulty input from the network. When in doubt, discard faulty input silently, without returning an error message unless this is required by the specification.
Robustness Principle 基于了一个假设的场景：It is not possible to affect change in a system the size of the Internet，而这和当前互联网协议的维护状况已经不符合了。为了解决 Robustness Principle 导致的事实标准凌驾于协议文档的问题的一个例子：https://web.dev/interop-2022/
March 13, 2022
https://doi.org/10.14778/3485450.3485454
DBOS: a DBMS-oriented operating system。基于 DBMS 实现的分布式操作系统，比较性能的角度比较有意思，分布式操作系统并不应该以 Linux 作为一个性能比较的对象，而是应该和 Linux + k8s 类似的组合来比较性能。微内核 + 分布式操作系统可能不可能在单机上达到和宏内核类似的性能，但是从整个集群来说实际上减少了抽象层次，就算是带了个 DBMS 这么重的抽象也能达到不错的性能。
DBOS: a DBMS-oriented operating system。基于 DBMS 实现的分布式操作系统，比较性能的角度比较有意思，分布式操作系统并不应该以 Linux 作为一个性能比较的对象，而是应该和 Linux + k8s 类似的组合来比较性能。微内核 + 分布式操作系统可能不可能在单机上达到和宏内核类似的性能，但是从整个集群来说实际上减少了抽象层次，就算是带了个 DBMS 这么重的抽象也能达到不错的性能。
March 25, 2022
https://www.usenix.org/conference/usenixsecurity21/presentation/kirzner
An Analysis of Speculative Type Confusion Vulnerabilities in the Wild。Spectre v1 类的攻击对现代 CPU（和 Meltdown 不同，不局限于特定的 CPU 架构）在想要保持性能的情况下几乎是无法彻底解决的，这篇对利用的机制提供了一个比较全面的综述。
An Analysis of Speculative Type Confusion Vulnerabilities in the Wild。Spectre v1 类的攻击对现代 CPU（和 Meltdown 不同，不局限于特定的 CPU 架构）在想要保持性能的情况下几乎是无法彻底解决的，这篇对利用的机制提供了一个比较全面的综述。
March 27, 2022
https://eprint.iacr.org/2021/1022
Zero-Knowledge Middleboxes。利用零知识证明让合作的客户端能向中间人证明端到端加密的流量符合特定的 policy（如只允许部分协议 / DNS deny list）而中间人无法得知任何具体内容。对于部分中间人如 ISP 可以解决法律义务，对于公司 IT 来说可以在允许端到端加密的情况下保证网络策略，相对于现在只能阻断如 DoH 来强制触发降级到完全不加密的协议或者立法禁止所有端到端加密是一种大家都能接受的折中手段。作者希望 TLS 的后续协议迭代把便于零知识证明作为协议设计的一部分。
Zero-Knowledge Middleboxes。利用零知识证明让合作的客户端能向中间人证明端到端加密的流量符合特定的 policy（如只允许部分协议 / DNS deny list）而中间人无法得知任何具体内容。对于部分中间人如 ISP 可以解决法律义务，对于公司 IT 来说可以在允许端到端加密的情况下保证网络策略，相对于现在只能阻断如 DoH 来强制触发降级到完全不加密的协议或者立法禁止所有端到端加密是一种大家都能接受的折中手段。作者希望 TLS 的后续协议迭代把便于零知识证明作为协议设计的一部分。
April 18, 2022
Read It Never
http://erlang.org/download/armstrong_thesis_2003.pdf At the highest level of abstraction an architecture is “a way of thinking about the world.” 对 erlang 语言本身不是特别有兴趣的可以跳着看下 2，5，10 章和 APPENDIX B。 一些内容的 TL;DR 版本： 1. A component is considered faulty once…
https://keunwoo.com/notes/rebooting/
On rebooting: the unreasonable effectiveness of turning computers off and on again。为什么电脑重启一下就能解决各种问题，是个很好的 fault-handling 的例子。fault-handling 不是某个语言的错误处理方式，是一类将非预期的系统状态转化为可预期的程序逻辑来限制 ill-formed 状态扩散的方式。
On rebooting: the unreasonable effectiveness of turning computers off and on again。为什么电脑重启一下就能解决各种问题，是个很好的 fault-handling 的例子。fault-handling 不是某个语言的错误处理方式，是一类将非预期的系统状态转化为可预期的程序逻辑来限制 ill-formed 状态扩散的方式。
August 13, 2022
https://www.ietf.org/id/draft-dekater-panrg-scion-overview-02.html
SCION (Scalability, Control, and Isolation On Next-generation networks)，次世代 BGP。略读了一下：
- AS 带证书，可以给子 AS 签子证书，每个 AS 都可以配置自己独立的 root of trust CA。
- 每个 AS 给的不再是下一跳，而是 path-segment construction beacons (PCBs)，可以认为是一段路径。路径（PCB）上的每个 AS 都会对这个 PCB 签名，每个 AS 可以独立的配置允许的转发路径规则。
- 发送端可以组合最多 3 个 PCB 来决定发送路径，类似于 source routing，但是同时又能验证 PCB 符合 root of trust 以及各个 AS 都接受这个 PCB。
实现：https://github.com/scionproto/scion
但是建议看 https://www.scionlab.org/
SCION (Scalability, Control, and Isolation On Next-generation networks)，次世代 BGP。略读了一下：
- AS 带证书，可以给子 AS 签子证书，每个 AS 都可以配置自己独立的 root of trust CA。
- 每个 AS 给的不再是下一跳，而是 path-segment construction beacons (PCBs)，可以认为是一段路径。路径（PCB）上的每个 AS 都会对这个 PCB 签名，每个 AS 可以独立的配置允许的转发路径规则。
- 发送端可以组合最多 3 个 PCB 来决定发送路径，类似于 source routing，但是同时又能验证 PCB 符合 root of trust 以及各个 AS 都接受这个 PCB。
实现：https://github.com/scionproto/scion
但是建议看 https://www.scionlab.org/
September 19, 2022
Read It Never
https://www.ietf.org/id/draft-dekater-panrg-scion-overview-02.html SCION (Scalability, Control, and Isolation On Next-generation networks)，次世代 BGP。略读了一下： - AS 带证书，可以给子 AS 签子证书，每个 AS 都可以配置自己独立的 root of trust CA。 - 每个 AS 给的不再是下一跳，而是 path-segment construction…
在生产环境使用 SCION 的是 Swiss National Bank, 今年新的 The Complete Guide to SCION (https://doi.org/10.1007/978-3-031-05288-0) 相对 2017 年的 SCION: A Secure Internet Architecture 有一些设计更新和更详细的细节。
September 20, 2022
Read It Never
https://doi.org/10.1145/2901318.2901326 Linux 内核调度的 casestudy，比较全面的介绍了现代 Linux 内核调度的方法，同时几个调度的 bug 也对于在现代硬件下调度系统的复杂度有比较好的展现。
https://lwn.net/SubscriberLink/909611/447c4722188eb46b/
一个简略的关于 Intel 大小核调度是怎么实现的介绍，其他关于现代操作系统调度的复杂程度可以参见上面这篇 "The Linux scheduler: a decade of wasted cores"。
“And you have to realize that there are not very many things that have aged as well as the scheduler. Which is just another proof that scheduling is easy.” - Linus Torvalds, 2001
一个简略的关于 Intel 大小核调度是怎么实现的介绍，其他关于现代操作系统调度的复杂程度可以参见上面这篇 "The Linux scheduler: a decade of wasted cores"。
“And you have to realize that there are not very many things that have aged as well as the scheduler. Which is just another proof that scheduling is easy.” - Linus Torvalds, 2001
October 2, 2022
https://gvisor.dev/blog/2022/10/24/buffer-pooling/
How we Eliminated 99% of gVisor Networking Memory Allocations with Enhanced Buffer Pooling。在 GC 语言里手动管理内存提高了 gVisor 网络协议栈 30+% 的吞吐（笑）。当然不止简单的手动管理内存（引用计数），还对 buffer 分页，实现了 copy on write，新 buffer 的实现可以看：https://github.com/google/gvisor/tree/master/pkg/bufferv2 。并且 GC 语言本身依然保证了内存安全性。
How we Eliminated 99% of gVisor Networking Memory Allocations with Enhanced Buffer Pooling。在 GC 语言里手动管理内存提高了 gVisor 网络协议栈 30+% 的吞吐（笑）。当然不止简单的手动管理内存（引用计数），还对 buffer 分页，实现了 copy on write，新 buffer 的实现可以看：https://github.com/google/gvisor/tree/master/pkg/bufferv2 。并且 GC 语言本身依然保证了内存安全性。
October 26, 2022
http://www.melconway.com/Home/Committees_Paper.html
How Do Committees Invent? 相对于论证更多的是对现实系统架构的观察得出的假说："Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."
或者使用原文的另一个说法，一个组织设计的系统与组织本身是同构的。
How Do Committees Invent? 相对于论证更多的是对现实系统架构的观察得出的假说："Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."
或者使用原文的另一个说法，一个组织设计的系统与组织本身是同构的。
November 4, 2022
https://netflixtechblog.com/2721924a2822
Seeing through hardware counters: a journey to threefold performance increase。这是我第一次看到在生产上（Netflix）因为字段没有 padding 导致的巨大性能差异的分析，是标准的不同核心互相不停的 invalidate L1 cache 的场景。
Seeing through hardware counters: a journey to threefold performance increase。这是我第一次看到在生产上（Netflix）因为字段没有 padding 导致的巨大性能差异的分析，是标准的不同核心互相不停的 invalidate L1 cache 的场景。
December 2, 2022
https://doi.org/10.1145/3292500.3330651
MOBIUS: Towards the Next Generation of Query-Ad Matching in Baidu’s Sponsored Search。百度新的广告推荐系统，主要由两部分变化：
- 在排序层加入了一个额外的相关性模型保证相关性超过阈值
- 可能由于排序层大幅增加了计算量，在匹配层额外考虑了点击率来达到候选集减小的情况下保证召回率
其实我本来看图把三层揉在一起了以为是他们做了一套 e2e 的方案，结果那个图的意思是打破了原来各层的单目标优化，而且相关性还是得靠卡阈值。论文的很大一部分重点在于如何训练出一个有效的相关性模型。
题外话，这个三层架构（或者两层，召回和排序，百度内部架构把排序额外拆成了粗排和精排两层）是很多推荐系统通病的来源。这个架构有一个隐含假设：用户只会点击相关的东西，所以点击率 / 播放时长预估本身保证了相关性，但是这个假设对于高于全局平均优化目标的条目会失效（比如 YouTube 有一段时间给所有人都推荐某钢琴视频）。这个推荐结果在排序系统逻辑上是成立的：如果给所有人都推荐这个视频，所有人对这个视频的平均播放时长是高于用户的平均播放时长的（因为 YouTube 的单目标优化是优化播放时长），那么给所有人都推荐这个视频符合全局的优化目标。这个现象的出现是因为 1、排序层缺少相关性的目标 2、这类单目标优化很难学到负权重。百度这个模型解决了怎么学到负相关性和怎么以相关性作为优化目标，就是最后卡个阈值就发论文了还是有点太 it works 了（
MOBIUS: Towards the Next Generation of Query-Ad Matching in Baidu’s Sponsored Search。百度新的广告推荐系统，主要由两部分变化：
- 在排序层加入了一个额外的相关性模型保证相关性超过阈值
- 可能由于排序层大幅增加了计算量，在匹配层额外考虑了点击率来达到候选集减小的情况下保证召回率
其实我本来看图把三层揉在一起了以为是他们做了一套 e2e 的方案，结果那个图的意思是打破了原来各层的单目标优化，而且相关性还是得靠卡阈值。论文的很大一部分重点在于如何训练出一个有效的相关性模型。
题外话，这个三层架构（或者两层，召回和排序，百度内部架构把排序额外拆成了粗排和精排两层）是很多推荐系统通病的来源。这个架构有一个隐含假设：用户只会点击相关的东西，所以点击率 / 播放时长预估本身保证了相关性，但是这个假设对于高于全局平均优化目标的条目会失效（比如 YouTube 有一段时间给所有人都推荐某钢琴视频）。这个推荐结果在排序系统逻辑上是成立的：如果给所有人都推荐这个视频，所有人对这个视频的平均播放时长是高于用户的平均播放时长的（因为 YouTube 的单目标优化是优化播放时长），那么给所有人都推荐这个视频符合全局的优化目标。这个现象的出现是因为 1、排序层缺少相关性的目标 2、这类单目标优化很难学到负权重。百度这个模型解决了怎么学到负相关性和怎么以相关性作为优化目标，就是最后卡个阈值就发论文了还是有点太 it works 了（
December 16, 2022
https://engineering.fb.com/2022/06/08/core-data/cache-invalidation/
Cache made consistent: Meta’s cache invalidation solution。有点标题党，meta 并不是解决了 cache invalidation 的问题，而是把解决这个这个问题的角度从正确性问题转换成了可用性问题。要解决可用性问题，首先要做的是定义出问题的可观察指标。meta 建立了一套对于缓存一致性的监控系统，把问题从 “保证系统逻辑是正确的” 转变成了 “尽可能提高 cache 一致性指标”，对这个问题来说是个挺新颖的角度。
For any anomaly in a stateful service, it is an anomaly only if clients can observe it one way or the other. Otherwise, we argue that it doesn’t matter at all.
Cache made consistent: Meta’s cache invalidation solution。有点标题党，meta 并不是解决了 cache invalidation 的问题，而是把解决这个这个问题的角度从正确性问题转换成了可用性问题。要解决可用性问题，首先要做的是定义出问题的可观察指标。meta 建立了一套对于缓存一致性的监控系统，把问题从 “保证系统逻辑是正确的” 转变成了 “尽可能提高 cache 一致性指标”，对这个问题来说是个挺新颖的角度。
For any anomaly in a stateful service, it is an anomaly only if clients can observe it one way or the other. Otherwise, we argue that it doesn’t matter at all.
December 18, 2022
https://www.sigarch.org/fast-memcpy-a-system-design/
Fast memcpy, A System Design。优化目标是 CPU 的每个 cycle 移动 16 bytes，从 CPU 的角度来考虑达到这个目标 CPU 需要提供什么样的能力。也可以看 ClickHouse 的 memcpy 实现（的注释）：https://github.com/ClickHouse/ClickHouse/blob/master/base/glibc-compatibility/memcpy/memcpy.h
大体上分成三个阶段：
- Small Size: 复制的长度小于一次 load 的宽度（16 bytes）
- Medium Size: 复制的长度小于完整的一轮循环展开（如果循环展开 8 次，就是 128 bytes）
- Large Size: 在对齐的内存上循环展开复制
Fast memcpy, A System Design。优化目标是 CPU 的每个 cycle 移动 16 bytes，从 CPU 的角度来考虑达到这个目标 CPU 需要提供什么样的能力。也可以看 ClickHouse 的 memcpy 实现（的注释）：https://github.com/ClickHouse/ClickHouse/blob/master/base/glibc-compatibility/memcpy/memcpy.h
大体上分成三个阶段：
- Small Size: 复制的长度小于一次 load 的宽度（16 bytes）
- Medium Size: 复制的长度小于完整的一轮循环展开（如果循环展开 8 次，就是 128 bytes）
- Large Size: 在对齐的内存上循环展开复制
December 22, 2022
https://dl.acm.org/doi/10.1145/3510003.3510111
"Did you miss my comment or what?": understanding toxicity in open source discussions。对 GitHub 上的 toxic 行为做了一些采样归类和总结，只能说就算同为开源项目维护者有时候也未必能对其他维护者共情。
"Did you miss my comment or what?": understanding toxicity in open source discussions。对 GitHub 上的 toxic 行为做了一些采样归类和总结，只能说就算同为开源项目维护者有时候也未必能对其他维护者共情。
January 19, 2023
https://www.unison-lang.org/learn/the-big-idea/
Unison。基于 content-addressed code 来设计的语言，这样让对任何函数的 reference 天然的具有了不可变的特性，无论其被分发到什么环境中。其文档列举了一些这么做的应用实例。
Unison。基于 content-addressed code 来设计的语言，这样让对任何函数的 reference 天然的具有了不可变的特性，无论其被分发到什么环境中。其文档列举了一些这么做的应用实例。
January 29, 2023
https://slsa.dev/spec/v0.1/threats
Supply chain Levels for Software Artifacts: Threats and mitigations。总结了从开发者到终端用户所有可能的攻击区间和一些对应的攻击实例，以及提供了对应的减缓其影响的方式。SLSA 在接下来几年有可能会成为缓解供应链攻击的行业方案。
Supply chain Levels for Software Artifacts: Threats and mitigations。总结了从开发者到终端用户所有可能的攻击区间和一些对应的攻击实例，以及提供了对应的减缓其影响的方式。SLSA 在接下来几年有可能会成为缓解供应链攻击的行业方案。
January 30, 2023
https://thenewstack.io/internode-cache-thrashing-hunting-a-numa-performance-bug/
Internode Cache Thrashing: Hunting a NUMA Performance Bug。无意中跨 NUMA 节点写入内存导致的性能问题。很少看到完整的定位这类 NUMA 性能问题的调试过程，关于 NUMA 为什么会产生这类性能问题可以参考：https://queue.acm.org/detail.cfm?id=2513149 经验数字来说 NUMA 相对 L1 cache 来说一次 load 的成本可能是 300 倍。
Internode Cache Thrashing: Hunting a NUMA Performance Bug。无意中跨 NUMA 节点写入内存导致的性能问题。很少看到完整的定位这类 NUMA 性能问题的调试过程，关于 NUMA 为什么会产生这类性能问题可以参考：https://queue.acm.org/detail.cfm?id=2513149 经验数字来说 NUMA 相对 L1 cache 来说一次 load 的成本可能是 300 倍。
January 31, 2023
https://www.usenix.org/publications/loginonline/prodspec-and-annealing-intent-based-actuation-google-production
Prodspec and Annealing: Intent-based actuation for Google Production。 对 Google 的生产管理系统的概述，可以认为是 Kubernetes 的内部版本。这篇文章对阐述 Kubernetes 的抽象模型的设计原则比大多数 Kubernetes 的介绍文章都更清晰。
一个典型的传统部署流程是 "canary in cluster X, then deploy N at a time in clusters Y and Z, run a test, and so on."，最早可能是手动，然后可能会有一些脚本来自动化。这么做最大的问题是每个服务往往都有特有的部署流程，一个尽可能去泛化不同的可能步骤的部署系统最后总会变成一个足够执行任何行为的脚本语言。另一个让这个方式难以扩展的原因是每一个步骤都是一个将系统从状态 A 转化到状态 B 的带有副作用的操作，但是要精确的确定系统处在状态 A 和系统达到了状态 B 都是非常困难的，往往最后都依赖于没有写明的隐含状态。
要解决这个问题最显然（2023 年，这个系统设计于 2015 年）的方式就是把最终想要达到的状态（intention）声明到 spec 里，然后再设计一个闭环控制系统来不断生成改变系统状态的操作，直到系统达到了声明的状态。Kubernetes 和 Prodspec/Annealing 都设计了一个非常类似于 Entity-Component-System（ECS）的系统：Prodspec/Annealing 中 Partitions = Entity，Assets = Component，System = Annealing。比如相对于 “把服务 X 部署到 A 和 B”，用户只需要定义一个 “Replicas: 2” 的 Assets 到自己的 Partition 上，而 Annealing 会找到达到这个最终状态的方法。
我个人感觉 Kubernetes 与 ECS 的映射对理解 Kubernetes 的设计逻辑会更有帮助，但是这条已经很长了。
Prodspec and Annealing: Intent-based actuation for Google Production。 对 Google 的生产管理系统的概述，可以认为是 Kubernetes 的内部版本。这篇文章对阐述 Kubernetes 的抽象模型的设计原则比大多数 Kubernetes 的介绍文章都更清晰。
一个典型的传统部署流程是 "canary in cluster X, then deploy N at a time in clusters Y and Z, run a test, and so on."，最早可能是手动，然后可能会有一些脚本来自动化。这么做最大的问题是每个服务往往都有特有的部署流程，一个尽可能去泛化不同的可能步骤的部署系统最后总会变成一个足够执行任何行为的脚本语言。另一个让这个方式难以扩展的原因是每一个步骤都是一个将系统从状态 A 转化到状态 B 的带有副作用的操作，但是要精确的确定系统处在状态 A 和系统达到了状态 B 都是非常困难的，往往最后都依赖于没有写明的隐含状态。
要解决这个问题最显然（2023 年，这个系统设计于 2015 年）的方式就是把最终想要达到的状态（intention）声明到 spec 里，然后再设计一个闭环控制系统来不断生成改变系统状态的操作，直到系统达到了声明的状态。Kubernetes 和 Prodspec/Annealing 都设计了一个非常类似于 Entity-Component-System（ECS）的系统：Prodspec/Annealing 中 Partitions = Entity，Assets = Component，System = Annealing。比如相对于 “把服务 X 部署到 A 和 B”，用户只需要定义一个 “Replicas: 2” 的 Assets 到自己的 Partition 上，而 Annealing 会找到达到这个最终状态的方法。
我个人感觉 Kubernetes 与 ECS 的映射对理解 Kubernetes 的设计逻辑会更有帮助，但是这条已经很长了。
April 1, 2023
把非计算机相关的内容移到别的频道了：https://t.me/+MU8ImsmmitNiNzVl
Telegram
Never Read It
分享非计算机相关读物
June 14, 2023
https://doi.org/10.1145/3593856.3595887
FIFO can be Better than LRU: the Power of Lazy Promotion and Quick Demotion。使用真实生产环境的数据来测试各个不同的缓存淘汰算法，LRU 相对于一些优化的 FIFO 算法并没有命中率并没有显著的优势甚至更低。本文主要考虑了两种优化策略：
- Lazy Promotion：当一个值被淘汰时才判断是否需要晋升（比如放到队首）。
- Quick Demotion：让低命中率的值尽可能快的被淘汰。
LRU 除了实现复杂且对并发不友好，另一个问题是任何一个值被淘汰都需要走遍整个队列（在此期间有且仅有一次访问）。对于一个长度为
FIFO can be Better than LRU: the Power of Lazy Promotion and Quick Demotion。使用真实生产环境的数据来测试各个不同的缓存淘汰算法，LRU 相对于一些优化的 FIFO 算法并没有命中率并没有显著的优势甚至更低。本文主要考虑了两种优化策略：
- Lazy Promotion：当一个值被淘汰时才判断是否需要晋升（比如放到队首）。
- Quick Demotion：让低命中率的值尽可能快的被淘汰。
LRU 除了实现复杂且对并发不友好，另一个问题是任何一个值被淘汰都需要走遍整个队列（在此期间有且仅有一次访问）。对于一个长度为
L，平均命中率为 H 的 LRU，每一个被 LRU 淘汰的值在被淘汰前的命中率都是 (1-H)/L。所以加快低命中率的值被淘汰的门槛（减小 L）预期上可以提高缓存利用率。September 6, 2023
https://doi.org/10.1145/3593856.3595909
Towards Modern Development of Cloud Applications。本文提出了一种新的部署微服务但是向开发者隐藏微服务复杂度的方式，描述的方式粗看很难和 Actor 模式区分开来（特别是代码组织的结构几乎一样）。本文没有很好的来抽象总结新的方式在架构上的变化，我试着重新描述一下
- Actor Model 的 Runtime 功能上可以认为等价于 Kubernetes，而每个进程相当于一个 Pod，但是和 Kubernetes 一样，只解决了 Actor 在这个 Runtime 内的部署问题，而不解决 Runtime 本身的部署问题，而 Runtime 的抽象（一个巨大的虚拟机器）与物理部署的不完全对应，最后导致物理部署的状态泄漏抽象到 Actor 实现。
- 本文描述的方式更接近于集成了 Kubernetes Operator，也就是说每个单体具有控制自身部署的能力，在架构上更接近应用对于部署的控制反转而没有引入额外的抽象层。也就是说 Runtime 并不包括 Kubernetes 而是控制 Kubernetes 来满足自身的需求，尽可能的贴近了物理部署的状态来避免抽象泄漏带来的复杂度。
别的一些设计目标比如因为部署和所有模块现在在同一个 self-contained 单体内，本身提供了一个类似全局锁的效果，保证了这个版本的部署逻辑满足这个版本的业务需求，同时模块只和单体内的模块通讯，避免了异步部署微服务带来的复杂度。
Towards Modern Development of Cloud Applications。本文提出了一种新的部署微服务但是向开发者隐藏微服务复杂度的方式，描述的方式粗看很难和 Actor 模式区分开来（特别是代码组织的结构几乎一样）。本文没有很好的来抽象总结新的方式在架构上的变化，我试着重新描述一下
- Actor Model 的 Runtime 功能上可以认为等价于 Kubernetes，而每个进程相当于一个 Pod，但是和 Kubernetes 一样，只解决了 Actor 在这个 Runtime 内的部署问题，而不解决 Runtime 本身的部署问题，而 Runtime 的抽象（一个巨大的虚拟机器）与物理部署的不完全对应，最后导致物理部署的状态泄漏抽象到 Actor 实现。
- 本文描述的方式更接近于集成了 Kubernetes Operator，也就是说每个单体具有控制自身部署的能力，在架构上更接近应用对于部署的控制反转而没有引入额外的抽象层。也就是说 Runtime 并不包括 Kubernetes 而是控制 Kubernetes 来满足自身的需求，尽可能的贴近了物理部署的状态来避免抽象泄漏带来的复杂度。
别的一些设计目标比如因为部署和所有模块现在在同一个 self-contained 单体内，本身提供了一个类似全局锁的效果，保证了这个版本的部署逻辑满足这个版本的业务需求，同时模块只和单体内的模块通讯，避免了异步部署微服务带来的复杂度。
February 24, 2024
https://dl.acm.org/doi/10.1145/121132.121151
Scheduler activations: effective kernel support for the user-level management of parallelism。提出一种用户态线程调度的设计，主要引入的几个新的抽象：
Processor：进程空间的虚拟处理器，类似于系统线程但是不会被阻塞，也可以直接对应物理的处理器。由内核来分配每个进程的处理器的数量。
Activation：相当于一个激活（运行）的状态，Activation 总是和 Processor 的数量相等，也就是说对于每个进程来说正在运行的用户态线程总是应该等于虚拟处理器的数量。
一些典型的场景：
- 当持有 Activation 的线程被阻塞在内核时（如 IO 系统调用），内核会 upcall 进程创建新的 Activation，而进程的调度器负责废弃被阻塞的 Activation 并用新创建的 Activation选择下一个执行用户态线程。
- 当内核要增加分配给进程的 Processor 数量时，内核会upcall 进程创建一个新的 Activation；当内核要减少分配给进程的 Processor 数量时，内核会暂停两个 Activation 并upcall 进程创建一个新的 Activation。
Activation 严格的对应于线程的实际运行状态，把系统调度的抽象映射到了用户态，这样进程的调度器可以根据 Activation 来决定调度策略，也可以和现有的同步 syscall 兼容。
Scheduler activations: effective kernel support for the user-level management of parallelism。提出一种用户态线程调度的设计，主要引入的几个新的抽象：
Processor：进程空间的虚拟处理器，类似于系统线程但是不会被阻塞，也可以直接对应物理的处理器。由内核来分配每个进程的处理器的数量。
Activation：相当于一个激活（运行）的状态，Activation 总是和 Processor 的数量相等，也就是说对于每个进程来说正在运行的用户态线程总是应该等于虚拟处理器的数量。
一些典型的场景：
- 当持有 Activation 的线程被阻塞在内核时（如 IO 系统调用），内核会 upcall 进程创建新的 Activation，而进程的调度器负责废弃被阻塞的 Activation 并用新创建的 Activation选择下一个执行用户态线程。
- 当内核要增加分配给进程的 Processor 数量时，内核会upcall 进程创建一个新的 Activation；当内核要减少分配给进程的 Processor 数量时，内核会暂停两个 Activation 并upcall 进程创建一个新的 Activation。
Activation 严格的对应于线程的实际运行状态，把系统调度的抽象映射到了用户态，这样进程的调度器可以根据 Activation 来决定调度策略，也可以和现有的同步 syscall 兼容。
April 1, 2024
https://doi.org/10.1145/564585.564601
CAP 定理的原始证明。找这篇看起因是因为 The CAP Theorem. The Bad, the Bad, & the Ugly 对 CAP 定理的抨击，看了下原始的证明这个定理确实没有太多现实意义。感觉最大的问题是对于 Availability 的定义过于狭隘，节点对所有请求都必须给出结果，但现实中在检测到网络隔离之后节点完全可以拒绝回复让客户端去重试。
权衡一致性和可用性确实是一个很好的考虑系统设计取舍的框架，但是 CAP 定理并没有否定一个同时满足高可用和强一致性的系统在实践上可以存在。毕竟对于理论来说 “可用” 是个正确性问题，而对实践来说是只是个请求成功率的指标。
CAP 定理的原始证明。找这篇看起因是因为 The CAP Theorem. The Bad, the Bad, & the Ugly 对 CAP 定理的抨击，看了下原始的证明这个定理确实没有太多现实意义。感觉最大的问题是对于 Availability 的定义过于狭隘，节点对所有请求都必须给出结果，但现实中在检测到网络隔离之后节点完全可以拒绝回复让客户端去重试。
权衡一致性和可用性确实是一个很好的考虑系统设计取舍的框架，但是 CAP 定理并没有否定一个同时满足高可用和强一致性的系统在实践上可以存在。毕竟对于理论来说 “可用” 是个正确性问题，而对实践来说是只是个请求成功率的指标。
May 4, 2024
https://doi.org/10.1145/2509578.2509584
What's wrong with git? a conceptual design analysis。从 git 设计中引入的概念来分析 git 为什么对新用户来说这么不友好，主要讨论的是从修改文件到 commit 以及 branch 的部分。本文基于 Brooks 提出的概念完整性的框架来分析，认为一个好的概念设计应该：
- 正交：功能之间的行为应该互相独立
- 适当：单个功能应该只包含其用途所必需的行为
- 泛化：单个功能应该适用于所有类似场景
- 一致：单个功能应该在不同的参数或者状态下表现出同类的行为
在这个框架下 git 的分析 git 的设计，如 working versions 和 staged versions 不正交，git commit 不同情况下有不同的行为，branch 不能泛化到 working/staged versions （只适用于 commited versions) 等等，并且提出了一个改进设计实现。
题外话，就我目前的观察来看就算招的人再聪明或者做了很多年开源项目，大家还是都不太会用 git。
What's wrong with git? a conceptual design analysis。从 git 设计中引入的概念来分析 git 为什么对新用户来说这么不友好，主要讨论的是从修改文件到 commit 以及 branch 的部分。本文基于 Brooks 提出的概念完整性的框架来分析，认为一个好的概念设计应该：
- 正交：功能之间的行为应该互相独立
- 适当：单个功能应该只包含其用途所必需的行为
- 泛化：单个功能应该适用于所有类似场景
- 一致：单个功能应该在不同的参数或者状态下表现出同类的行为
在这个框架下 git 的分析 git 的设计，如 working versions 和 staged versions 不正交，git commit 不同情况下有不同的行为，branch 不能泛化到 working/staged versions （只适用于 commited versions) 等等，并且提出了一个改进设计实现。
题外话，就我目前的观察来看就算招的人再聪明或者做了很多年开源项目，大家还是都不太会用 git。
June 6, 2024
https://www.usenix.org/publications/loginonline/evolution-sre-google
The Evolution of SRE at Google。用 System Theory 来分析灾难。传统的思路是事故是一连串的事件的结果，所以解决方法往往是如何打破这一串事件的因果链条（如加冗余，避免单点故障）。从系统的角度来看系统在正常工作时处在一个稳态，也就是说必然存在一套控制系统来维持系统，而一个事故是系统从稳态到亚稳态再最后到灾难的过程，其中亚稳态可能维持了很长的时间。识别出为什么控制系统无法从亚稳态回到稳态可以从一开始避免进入可能会发生事故的状态。System Theory 也能更好的把非技术的因素考虑进来（如组织架构，流程，外部环境）。
Instead of asking "What software service failed?" we ask “What interactions between parts of the system were inadequately controlled?” In complex systems, most accidents result from interactions between components that are all functioning as designed, but collectively produce an unsafe state.
The Evolution of SRE at Google。用 System Theory 来分析灾难。传统的思路是事故是一连串的事件的结果，所以解决方法往往是如何打破这一串事件的因果链条（如加冗余，避免单点故障）。从系统的角度来看系统在正常工作时处在一个稳态，也就是说必然存在一套控制系统来维持系统，而一个事故是系统从稳态到亚稳态再最后到灾难的过程，其中亚稳态可能维持了很长的时间。识别出为什么控制系统无法从亚稳态回到稳态可以从一开始避免进入可能会发生事故的状态。System Theory 也能更好的把非技术的因素考虑进来（如组织架构，流程，外部环境）。
Instead of asking "What software service failed?" we ask “What interactions between parts of the system were inadequately controlled?” In complex systems, most accidents result from interactions between components that are all functioning as designed, but collectively produce an unsafe state.
February 1, 2025
Read It Never
https://ckrybus.com/static/papers/Bainbridge_1983_Automatica.pdf Ironies of automation (1983) - 系统自动化的部分出发点是降低维护成本 - 维护高度自动化的系统需要对该自动化系统相关领域知识有深入了解的操作员，高技能的操作员需要极高的培养成本 - 在系统自动化程度大于某个阈值时，培养操作员的成本会大于开发自动化系统的人员的成本，这个界限就是 ops 失去意义，devops 和 SRE 成为系统维护员的时刻 “Debugging…
LLM 带来的问题和 1983 年自动化的问题本质是类似的，自动化程度越高需要的干预越少，操作员越缺少足够机会来习得维护系统的技能，然后复杂度和成本转嫁到了培养有能力维护自动化系统的操作员的教育系统上，因为不可能在工作过程中习得这些技能。
复杂度是不可能靠自动化来消解的，一个自动化系统必须内化其所自动化的系统的模型，所以必然继承了所有的复杂度并且增加了自动化系统本身的复杂度。
这不是说自动化是没有意义的，只是自动化不能降低系统的复杂度，认为用 LLM 来维护复杂系统会降低维护的复杂度可能是一个错误的优化目标。其结果和过去每一轮的自动化从结构上来说或许是类似的 - 减少低技能岗位的数量，增加高技能岗位的数量，成本转嫁给教育系统。
复杂度是不可能靠自动化来消解的，一个自动化系统必须内化其所自动化的系统的模型，所以必然继承了所有的复杂度并且增加了自动化系统本身的复杂度。
这不是说自动化是没有意义的，只是自动化不能降低系统的复杂度，认为用 LLM 来维护复杂系统会降低维护的复杂度可能是一个错误的优化目标。其结果和过去每一轮的自动化从结构上来说或许是类似的 - 减少低技能岗位的数量，增加高技能岗位的数量，成本转嫁给教育系统。
April 28