在 GF(2) 域上解线性方程组。

是索尼的问题，我是 Xperia 1 V ，偶发会掉，有的时候能一直是 L1 ，有的时候自己莫名其妙就掉 L3 了。最麻烦的地方在于每次都只有在比如开 Netflix 看剧的时候，看分辨率迟迟上不去才会发现，然后打开 DRM check 实锤了再重启，不胜其烦。

先问是不是再问为什么。

FP 跟 “OOP” 本来就是正交的概念，与 FP 相对的是 Imperitive Programming ，而 FP 可以看作一种 Declartive Programming 。在 1994 年确定的 ANSI Common Lisp 标准中，Common Lisp Object System （ CLOS ）已经被完整定义，这是一个完整的对象系统，而被广泛实现的 Meta Object Protocol ，更是后面 Java AOP 的真正前驱。同样，1996 年 OCaml 继承 Caml 衣钵，在 StandardML 基础上发展出了完整的 Object 系统，这也是一个完整的 OOP 系统。而 Scala 跟 Clonjure 这种本身就诞生于 JVM 的语言，更是天生就具有 OOP 能力。

@SimonOne uv 是替代 pip 的，rye 是 flask 作者 mitsuhiko 创始的，他觉得 Python 的研发生态链比起 rust 实在是太烂了，自己搞了一个工具关注整个研发生命周期，使用 独立 python 解释器 + venv + pip + pyproject.toml 等既有生态来管理。后面 astral 团队开发完 uv 之后跟 mitsuhiko 沟通，接管了 rye 项目（ https://astral.sh/blog/uv ）。

从关系上来说，rye 是一个研发管理工具，基于 project 粒度隔离 python 解释器、venv ，自然也就隔离了包管理生态，uv 跟 pip 在 rye 里可以互换，ruff 也不是强制要求接入。

从我个人体感来说，rye + uv + ruff 就是目前最舒服的方案，我有用来实验的 jupyter 项目，也有打包成 oci 的纯 python 项目，rye 都能非常完美去接入和使用（除了某些模型代码里面写死了 pip 之外）。

P.S.，关于 Python 开发者体验和 rye 本身，mitsuhiko 在 rye 创始之初就有个 discussion ，值得一读： https://github.com/astral-sh/rye/discussions/6

@lxdlam 记忆有偏差，最近一年应该

最近两年都在用 rye ，切到 uv 之后体验丝滑

1p 最近一两年一直在做 [developer experience]( https://developer.1password.com/)，现在已经有了 `op` cli, python 和 typescript sdk ，以及两种 prod env 部署模式，对个人来说可以完全替代掉 vault 之类的专业密钥管理系统，就这一点不会让我切换到官方的 password 。

想买的东西大部分都跟这个场景隔开了，本来想买台 mac mini ，但是听说 m4 能做到 apple tv size ，决定等等看；电视 LG C4 跟三星 S90D 合适尺寸的都不参与活动。观望到年底再看看。

一个 off-topic：

Bill Gates 开始他的生涯基本就始于他高中时代跟 Paul 开始的开发合约，其中一个非常知名的就是给他的母校 Lakeside 开发了一个排课系统。根据 Paul 晚年书里所述，他甚至魔改了算法，帮他安排了一节除了他全是女生的英语课。

Ref:
- https://tatler.lakesideschool.org/3085/news/return-to-the-source-lakesides-scheduling-algorithm-explained/
- https://www.businessinsider.com/10-things-you-didnt-know-about-bill-gates-2011-4?op=1&IR=T#he-wrote-his-high-schools-scheduling-program-to-book-him-into-an-english-class-with-all-girls-3

首先是一个时间线：
- 一个 standard 的 iterator 是一个社区一直在讨论跟推进的，正式的 proposal 在 2022 年就已经成型并进行了广泛讨论： https://github.com/golang/go/discussions/54245 。
- rsc 选择了使用 push-func 来实现的讨论，针对于他对*既有* stdlib 的代码的观察 https://github.com/golang/go/discussions/56413 。
- 关于最终加入 spec 的讨论，从 go1.22 到 1.23 release ，数百条关于实现方式、问题、语法选择的讨论都可以在 https://github.com/golang/go/issues/61405 看到。

在这条帖子的讨论中，mix 了非常多的对于不同方向的讨论：
- 该不该加入 Iterator ？这个问题相信毋庸置疑，一个标准化的 iterator 定义能够极大方便用户和库开发者。举个非常简单的例子，我们可以将 `sql.Rows` 传入一个 `slices.Chunk` 函数中，使得只需要
```
for batch := range slices.Chunk(sql.Rows() ,6) {
// do something with current batch
}
````
就能非常简单将 sql 返回的结果分批处理。类似的场景在各种延迟计算、数据获取、基于数据流向的调度中非常常见。
- 该不该使用 push-func 实现？ push-func 跟 pull-func 虽然在表达能力上是一致的，但是 rsc 认为：
> Although push and pull functions are duals, they have important differences. Push functions are easier to write and somewhat more powerful to invoke, because they can store state on the stack and can automatically clean up when the traversal is over. That cleanup is made explicit by the stop callback when converting to the pull form.
push-func 更容易转成 pull-func ，且更容易实现。当然，直观程度上，push-func 是弱于 pull-func 的，这导致了这次语法看起来更加奇怪。（来自于 Java 的例子是，stdlib 对 iterator 的实现是 pull based 的： https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Iterator.html ）
- 该不该使用 rangefunc 实现 iterator ？这个是社区最核心的讨论点之一。援引一个老哥的文章： https://www.gingerbill.org/article/2024/06/17/go-iterator-design/，社区核心始终认为，这种函数破坏了既有用户群体对这个语言的 philosophy （宗旨？方法论？不知道怎么去定义这个词比较好）的认知，一部分群体认为 Go 就是个基于过程的语言，不应该如此“函数式”；同样也有人认为，这种基于完全隐式的控制流（依赖 function stack frame 控制生命周期，range Func 完全依靠 compiler 重写）是引入新的 Bug 的万恶之源。

就我个人来说，我并不赞成使用这种方式实现，如果有一个编译器可以认知的新的 iterator 对象，那无论从实现还是使用角度都会简单很多，而且就 go 整个语言的发展历史来看，为了一些之前没考虑到的事情，动态开洞擦屁股这种事，也不是发生一次两次了。但是这条回复的目的还是给大家一个清晰的认知，也建议讨论设计问题前，先搞清楚前因后果时间脉络，减少鸡同鸭讲。

这个位置一直漏电，都习惯了

支持了，如果能看到 TV 支持就更好了哈哈

Copilot 对临近 context 的学习能力很强，写日志和监控的输出、接口的相似实现实在是太好用了。虽然核心逻辑始终现在的 AI 还是不够好，但是大量的人力工作也就是在写这些纯模板代码上，确实帮我节省了大把时间。

@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

零知识证明。