@lxdlam 有一定差距 -> 有一定不同

Zookeeper 不是 Paxos ，而是自己发明的协议 ZAB ，跟 Paxos 有一定差距；实现了 Paxos 的系统有很多，比如 Google 的 Chubby 和 Scylla DB 。

同样，根据 DDIA 的说法，现代 CAP 其实逐渐式微，因为现代系统设计里面这三个每一个话题都会有很多需要考虑的问题，不再只是单纯的 3 选 2 了。

@ShinichiYao #28 如果 Key space 足够小且 IV 的 space 也足够小的情况下，知道一定的 plaintext 才是可以攻击出密钥的，这个叫做 Known-plaintext Attack 。

在已知范围内，如果不满足上面的结论，AES （所有模式）都免疫 KPA ，这是因为 KPA 的一种最直接的攻击就是遍历 key 跟 iv space ，尝试每一种可能的 combination ，如果都在 2^16 这个级别，现在的好一点的家用电脑可能不需要一晚上时间。而在现代实践中，AES 一般使用 128bit 及以上的 key ，这种情况下即使 IV space 较小，攻击难度也非常大。跟知道多少 (plaintext, encrypted) 无关。

Reference： https://crypto.stackexchange.com/questions/100521/for-aes-gcm-does-knowing-plaintext-and-ciphertext-allow-attacker-to-learn-the-k

零知识证明。

@kuanat OCaml 有两种数据对象，一种是传统的函数式对象 Record ，这个是 nomimal 的，类型 tag 区分不同类型，而 object 和 module system 是 structural 的，实际上我例子中提到的函数可以这么写：

```ocaml
let print (bar : < foo : string; .. >) = print_endline bar#foo;;
```

注意到这个独特的签名，其实要求 `bar` 需要具有一个特定的 foo 即可，对其他的都不要求。

@lxdlam oops ，应该是 #10 ，看错楼了

@lxdlam 补充一点，Go 的基于 Signature 的 interface matching ，实际上 OCaml 早实现出来了，即使是 First class module ，也是 2011 年引入的，早于 Go 。

```ocaml
module type Foo = sig val foo : string end;;

class a = object method foo = "A" end;;
class b = object method foo = "B" end;;

let print bar = print_endline bar#foo;;

print (new a);; (* "A" *)
print (new b);; (* "B" *)
```

不同意 #14 的说法，实际上 #14 所需要的只是 Composable 的 interface ，而并不是所谓的 duck typing 。

引用原文：

> - Don't implement Interfaces preemptively.

在这里提到的 case 实际上是因为，Java 由于无法对任意 External Type 实现 Internal interface ，所以如果原始的行为 Contract 没有被声明为 Interface ，我们既不能实现我们自己的替代品（有 interface 的情况下，实现一个 Adapter 不就可以了？），也无法使用我们的 interface 去将其替代；而这个限制在 Rust 中已经被放宽到不允许使用 External struct 去实现 External trait （ https://doc.rust-lang.org/book/ch10-02-traits.html#implementing-a-trait-on-a-type ）。

而 Go 这种 Duck typing ，实际上比起 Java 的显式声明，是另一种推卸责任。举个例子，假定我存在两个 interface：

```go
type Visitor interface {
Saw() bool // If we have seen this node
}

type Sawyer interface {
Saw() bool // Can sawyer saw?
}
```

当我实现 `func (???) Saw() bool` 的时候，我究竟在实现谁？这大大加剧了误用几率，反而在工程上是一个 bad practice 。（这种 case 一定存在，参考 Hyrum's Law - https://www.hyrumslaw.com/ ，一个行为只要被足够多的人观察，无论是否跟你的设计和想法保持一致，一定会有人在依赖这个行为）。

如何回避上述行为？一种方案是实现一个空的 method ，限定其在特定 namespace 下面，比如：

```go
type Visitor interface {
Saw() bool

IsVisitorImpl()
}
// ...
```

但这跟 Java 的 `implements XXX` 相比，无非是把这个 Tag 下推到 `interface` 内部了，本质是完全一样的。

而如果实现细粒度的 `interface`，#40 提出了一个很好的例子，我们甚至可以：

```java
public interface Putter {
String put(Item item);
}

public interface Getter {
Item get(String key);
}

public class Storage {
private Putter putter;
private Getter getter;
}
```

虽然有点累赘，一样实现了类似的细粒度接口组合，并未有任何功能上的差异。

看 op 应该是 Oracle

猜测 union 查询命中了联合索引，所以不需要对 `datetime` 排序，只需要决定起始位置就可以直接 fetch 数据；而 IN list 先对命中三个条件的数据进行 merge ，然后 sort 后再筛选，无论是合并、排序操作还是需要扫描的行数（ 8989K > 2123K+180K ）都远比前一个查询计划大。

一种可行的优化可以尝试 over partition 拆成三个子表排序再重新 where 一下，不确定优化效果，需要再 explain 一下看看，参考 https://use-the-index-luke.com/sql/partial-results/window-functions

家里 Apex Pro TKL Wireless
公司 宁芝 Micro84

@lxdlam 补一句，通过 template + if constexpr + static_assert 可能可以将这个 `to_runtime` 自动化生成出来，不过我也好久没写过 C++ 了，如果不行当我没说。

本质的核心问题是 C++ 没有真正的 exhaustive 的 enum ，导致编译器无法限定 `E` 的值在一个可优化的 immedate value 范围内，无法将其在 comptime 求出来，所以将其放到参数里无法做编译期生成。

为什么 `to_runtime` 又能 work 了？因为在当前场景下，编译器推导出来对于 `consteval` 函数 `flattern`，可行的值是有限的，所以能够正常编译。把最后一个分支改为 `f(_e)`，编译器会报错 `f` 为一个 `consteval function`，但是参数是 comptime unknown 的。

对于有 exhaustive enum 的语言（ rust 、zig 等），要实现这种需求应该是 trivial 的。

DuckDB ，非常好用的 in memory OLAP 数据库，跟 sqlite 一样，而且可以统一连接 csv 、parquet 、mysql 、postgres 数据源，python 包可以兼容 pandas/polars/arrow ，纯粹开箱即用，非常方便

@lxdlam 没写完发出去了。补充一下特性第一条：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑可以读写分离的架构，使用一些缓存、分片的技术难度会大幅下降，且能在合理资源量内得到一个不错的效果。

日志需要持久化，尤其是有跨天 case 的可能性。使用 MySQL 或者其他 OLTP DB 是一种方案，但是不是最好的方案。

将日志当作事件流，思考日志的使用场景：
- 问题定位：最常见的 case ，通过请求、用户、设备等等维度抽取一个特定的事件流分析，哪一步出现了问题，这种 case 通常需要对一些特定的 field 当作 key ，抽取查询相关联的事件。
- 数据分析：通过对特定事件进行聚合，计算出来一些业务或者技术指标，诸如平均响应时间、订单完成延迟等。这种场景一定程度上会被 metric 所替代，但是在错误日志聚合上仍然有价值。

同时，日志有一些自己的特性：
- Append only：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑
- 丢失冗余：根据日志量的关系，其实允许一定程度的日志丢失和冗余，也就是没有严格事务要求。
- 量级和查询需求：很多日志都是大海捞针，允许一定的查询延迟和一定延长的运行时间

从上面的角度，其实使用一个 OLAP 系统或者更加专门的系统更好。OLAP 常规的选型可以选择诸如 ELK 、ClickHouse 这样的系统，搭配 Kafka 之类将日志落进去；而比较完善的日志系统现在比较流行的就是 Loki + Promtail/Grafana Agent ；如果量小，使用 fluentd 采集并发送到 S3 使用一些脚本去分析也是 OK 的。

本科阶段用了很久的 Manjaro ，现在主力开发两台机器还是 macOS + Fedora ，不太追求 Cutting Edge 的滚动更新，Fedora 用着正好。

之前用过一段时间 NixOS ，但是 NixOS 会有一些 dirty hack 的工作要做，会有一定量级的时间定期调配置文件，后面就放弃日常使用了，下一步打算在 CI 场景用一下。

Redis 这次换其实是比较强盗逻辑的。

背景是 Redis 之前开发了很多附加组件，如时序数据扩展 Timeseries ，JSON 扩展 RedisJSON ，然后这一系列扩展统称为 Redis Stack ，所有 RedisStack 就是按 SSPL 分发的，同时保持原有的代码为 3-Clause BSD 。

> In fact, more than 50% of redis.io downloads – from Redis 6 and beyond – come from Redis Stack. We now believe that extending this licensing to Redis itself will enable us to continue to evolve the most holistic set of data models, processing engines, and developer capabilities for our users.

根据原文，他们觉得既然有超过 50% 的用户下载 Redis 都是从 Redis Stack 过来的，那为什么不把这俩合一呢？是否合理、怎么合并暂且不提，单纯因为这个原因把 core Redis 的 License 换成 RSAL+SSPL ，就纯粹是在绑架那一批完全用不到 Redis Stack 的用户了。而显然，这虽然看起来是 Redis 跟托管云的斗争，但是实际上这部分成本总会以各种形式转嫁到 end user 上。

我的桌面是 Windows ，用一对 PreSouns Eris 3.5 ，但是接了个外置声卡走的平衡输出。

XKCD 538.

https://imgs.xkcd.com/comics/security.png