九维我操你爹
为啥会发生这么大的变化呢？因为我司产品真的要换 nerdctl 了，我非常荣幸地接下了可行性调研的活
结果直接干到第二天凌晨🕛
nerdctl 以前在技术演讲上宣称从 docker 迁移过来只需要 alias docker=nerdctl 就行，导致我还是 nerdctl 吹的时候真的以为会有这么丝滑，实则不然
我们只是用 nerdctl 起 A、B 两个容器而已，不需要很复杂的功能。但是 nerdctl 和 docker 之间有很多行为上不一致的地方，踩坑踩麻了……（不是 bug，是一开始就这么设计的
https://github.com/microsoft/vscode-python-environments/pull/940
Visual Studio Code 上的 Python Environments 插件终于有了对 uv 的初步支持……
Visual Studio Code 上的 Python Environments 插件终于有了对 uv 的初步支持……
https://tee.fail/ wiretap 的团队继续发力，TEE 加密芯片对内存加密使用了确定性算法，同样的明文会生成同样的密文，导致可以通过内存分析破译私钥。继上次破解 SGX 老款芯片后，这次把最新款的 TDX 和 SEV-SNP 也攻破了，可以说 TEE 全军覆灭。
AMD 和 Intel 都表示不会修复，内存监听和改写不属于 TEE 的防御范畴。
看来，TEE 确实只能用来防内鬼，并不能构成一个可以放心地托管给别人的飞地。
* prev
AMD 和 Intel 都表示不会修复，内存监听和改写不属于 TEE 的防御范畴。
看来，TEE 确实只能用来防内鬼，并不能构成一个可以放心地托管给别人的飞地。
* prev
Kube-OVN 这么多年终于有了第一个海外的 maintainer，虽然从来没见过面，也不知道这是个啥公司，甚至我都不确认他的名字是什么，但是丝毫不阻碍我们相互之间的沟通和合作。
https://github.com/kubeovn/kube-ovn/pull/5855
https://github.com/kubeovn/kube-ovn/pull/5855
日本人ファーストというといかにも日本人のことを考えているようですが、実際は逆です。日本人のなかで働ける人、働けない人、健康な人、病気の人、障がいのある人、ない人というようにどんどん分断していって、最後にはいま、参政党を支持している人たちも切り捨てられます。
https://mainichi.jp/premier/politics/articles/20251103/pol/00m/010/004000c
毎日新聞「政治プレミア」
「外国人お断り」の避難所を作るのか 排外主義と社会保障 | | 奥貫妃文
社会保障は誰のためのものなのか。昭和女子大福祉社会学科教授の奥貫妃文さんに聞きました。【聞き手・須藤孝】 ◇ ◇ ◇ ――先の参院選の時期には外国人の生活保護の利用は不正だというようなデマが広がりました。
举个实际例子来说：
我在搬瓦工上的 VPS CPU 就是 x86_64_v2。我完全理解在 2025 年不再支持只能达到 v2 标准 的老 CPU 这一决定，但是其实这种 CPU 并不是那么罕见。哪怕是一般用户（比如你完全不搞技术只是照着网上的教程选择了 CentOS 系的发行版然后搭个梯子翻墙）也是可能会遇到这种尴尬的
再比如默认启用 CRB 软件源。可以帮助很多不知道 EPEL 依赖 CRB 的用户避免截图中这种问题，也节省了我装新系统时的一道步骤
上面提到的很多 RFC 在上游看来可能都是影响范围有限，从而吝啬于支持的。我想表达的是，AlmaLinux 真的让我有种它在为我着想的感觉，这种感觉在 2025 年太过于宝贵，以至于我愿意这么长篇大论地赞扬一番
我在搬瓦工上的 VPS CPU 就是 x86_64_v2。我完全理解在 2025 年不再支持只能达到 v2 标准 的老 CPU 这一决定，但是其实这种 CPU 并不是那么罕见。哪怕是一般用户（比如你完全不搞技术只是照着网上的教程选择了 CentOS 系的发行版然后搭个梯子翻墙）也是可能会遇到这种尴尬的
再比如默认启用 CRB 软件源。可以帮助很多不知道 EPEL 依赖 CRB 的用户避免截图中这种问题，也节省了我装新系统时的一道步骤
上面提到的很多 RFC 在上游看来可能都是影响范围有限，从而吝啬于支持的。我想表达的是，AlmaLinux 真的让我有种它在为我着想的感觉，这种感觉在 2025 年太过于宝贵，以至于我愿意这么长篇大论地赞扬一番
https://almalinux.org/blog/2025-10-21-announcing-btrfs-support-in-almalinux-10-1/
https://almalinux.org/blog/2025-09-08-enabling-crb-by-default-for-almalinux10/
https://almalinux.org/blog/2025-08-06-announcing-native-nvidia-suport/
长期以来我都不太清楚 AlmaLinux 和 Rocky Linux 两种发行版的区别，但是从 10 开始我觉得 AlmaLinux 已经有了遥遥领先的势头
在我片面的认知中，AlmaLinux 在下面几个方面一直都做得更好：
1. 更快推出新版本
2. 更积极地让用户参与到开发中（不仅每个大版本有 beta 版，还有 Kitten 这种当前开发中版本的直接上游）
3. 更积极地接纳社区意见（他们会在 https://github.com/AlmaLinux/ALESCo 讨论 RFC，并实现所有被采纳的优化建议）
4. 更开箱即用。拜上面的 RFC 所赐，AlmaLinux 10 也有对 x86_64_v2 的完整支持（包括 EPEL！）。此外还有 NVIDIA 显卡开源驱动程序的打包、默认开启 CRB 源以及对 btrfs 的实验性支持等等……这些还只是我挑一般用户可能会感兴趣的优化讲，其实还有很多面向企业用户的优化
我真的很佩服他们不仅接过了 CentOS 手里的那根接力棒，而且还做得更好。他们不仅有勇气在几乎整个 RPM 生态都放弃某项功能时，还愿意考虑分出部分精力去继续提供支持；也有时刻为用户着想的体贴。使得 AlmaLinux 即便是作为桌面系统来使用，也有一流的体验
https://almalinux.org/blog/2025-09-08-enabling-crb-by-default-for-almalinux10/
https://almalinux.org/blog/2025-08-06-announcing-native-nvidia-suport/
长期以来我都不太清楚 AlmaLinux 和 Rocky Linux 两种发行版的区别，但是从 10 开始我觉得 AlmaLinux 已经有了遥遥领先的势头
在我片面的认知中，AlmaLinux 在下面几个方面一直都做得更好：
1. 更快推出新版本
2. 更积极地让用户参与到开发中（不仅每个大版本有 beta 版，还有 Kitten 这种当前开发中版本的直接上游）
3. 更积极地接纳社区意见（他们会在 https://github.com/AlmaLinux/ALESCo 讨论 RFC，并实现所有被采纳的优化建议）
4. 更开箱即用。拜上面的 RFC 所赐，AlmaLinux 10 也有对 x86_64_v2 的完整支持（包括 EPEL！）。此外还有 NVIDIA 显卡开源驱动程序的打包、默认开启 CRB 源以及对 btrfs 的实验性支持等等……这些还只是我挑一般用户可能会感兴趣的优化讲，其实还有很多面向企业用户的优化
我真的很佩服他们不仅接过了 CentOS 手里的那根接力棒，而且还做得更好。他们不仅有勇气在几乎整个 RPM 生态都放弃某项功能时，还愿意考虑分出部分精力去继续提供支持；也有时刻为用户着想的体贴。使得 AlmaLinux 即便是作为桌面系统来使用，也有一流的体验
注意力不集中可能是大脑在清理垃圾
2025-11-03 18:02 by 伊卡狛格
晚上没睡好，第二天总是很难集中注意力，这可能是因为你的大脑正试图自我刷新，导致短暂的注意力缺失。
睡眠期间，大脑会进行一个冲洗循环——脑脊液被反复冲入大脑，再从大脑底部流出。这一过程能够清除白天积累的代谢废物，否则会损害脑细胞。MIT 的科学家想知道通常在睡眠不足时发生的注意力涣散，是否可能是大脑在清醒时试图弥补“自我冲洗”的结果。为了研究这个问题，科学家将试验分为两个阶段。第一阶段让26名19岁到40岁的参与者睡个好觉，得到充分的休息。第二阶段则是两周后，让他们在实验室里彻夜不眠。结果显示缺乏睡眠让参与者更难集中注意力。当研究人员分析大脑扫描结果时，发现参与者在脑脊液从大脑底部流出前约两秒就失去了注意力。更重要的是，在注意力恢复后约1秒，脑脊液被冲入大脑。研究结果表明，当大脑无法在睡眠中自我清洁时，它就会在你醒着时进行清洁，但这会影响注意力。
https://www.nature.com/articles/s41593-025-02098-8
中国科学报 注意力不集中，可能是大脑在“做扫除”
#科学
2025-11-03 18:02 by 伊卡狛格
晚上没睡好，第二天总是很难集中注意力，这可能是因为你的大脑正试图自我刷新，导致短暂的注意力缺失。
睡眠期间，大脑会进行一个冲洗循环——脑脊液被反复冲入大脑，再从大脑底部流出。这一过程能够清除白天积累的代谢废物，否则会损害脑细胞。MIT 的科学家想知道通常在睡眠不足时发生的注意力涣散，是否可能是大脑在清醒时试图弥补“自我冲洗”的结果。为了研究这个问题，科学家将试验分为两个阶段。第一阶段让26名19岁到40岁的参与者睡个好觉，得到充分的休息。第二阶段则是两周后，让他们在实验室里彻夜不眠。结果显示缺乏睡眠让参与者更难集中注意力。当研究人员分析大脑扫描结果时，发现参与者在脑脊液从大脑底部流出前约两秒就失去了注意力。更重要的是，在注意力恢复后约1秒，脑脊液被冲入大脑。研究结果表明，当大脑无法在睡眠中自我清洁时，它就会在你醒着时进行清洁，但这会影响注意力。
https://www.nature.com/articles/s41593-025-02098-8
中国科学报 注意力不集中，可能是大脑在“做扫除”
#科学
如果对 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
saka 老师前几周分享的这篇文章 https://skoredin.pro/blog/golang/cpu-cache-friendly-go 非常有意思，我虽然日常在 pahole 输出里看到 cacheline，但对其如何影响程序运行的理解也非常模糊。
不过更有意思的是，我已经见到三位工程师在 AI 的辅助下试图测试 “cacheline padding 带来六倍性能提升” 却没有成功，最后吐槽这是一篇错文、AI文。这里有一个有趣的知识屏障，如果不理解 cacheline 在何时会影响性能，那就可能无法写出正确的测试程序；但无法写出正确的测试程序又无法理解 cacheline 如何影响性能，知识死锁了。
你以为我想说原文的 “cacheline导致六倍性能差距” 的结论是正确的？不，那是错误的 有前提条件的，并非通用结论
这些对我也是新知识，水平有限，施工区域谨慎阅读
我的测试代码不用很多工程师和 AI 用的 go bench 方法，因为抽象程度太高了，在这种性能施工区最好就写一眼能看穿汇编的简单代码。
提供了两套变式， 通过命令行的 arg1 和 arg2 指定是否 padding 和是否用 atomic.AddUint64。
我本地的 cpu 0,1 是同一个核心，1,2 是不同核心，所以测试命令是
很多细节我依然在学习中，目前可以公开的情报是：（+表示前者性能更好，-反之）
1. "pad atom" vs "nopad atom": +7.3倍性能
2. "pad nonatom" vs "nopad noatom": +3.3倍
3. "pad atom" vs "pad noatom": -2.5倍
4. "nopad atom" vs "nopad noatom": -5倍
可以看到 atom (lock prefix insn)本身就造成大量的性能影响，而 pad 会进一步加重 cacheline false sharing 导致更极端的性能差距。原文里的六倍性能差距是在 atom + pad 的场景下的测试结果，但我觉得大部分场景根本不会这么极端。
核心绑定情况也会造成很大影响。如果绑核改为 0,1 cpu，它们是同一 core，测试结果是：
1. "pad atom" vs "nopad atom": +1.75
2. "pad noatom" vs "nopad noatom": +1.65
3. "pad atom" vs "pad noatom": -1.9
4. "nopad atom" vs "nopad noatom": -2.0
在这些测试里，经典的 perf topdown 方法在 L2->L3->L4 几乎完全失效，经常会看到 L2 的 tma_core_bound 40% 然后 tma_core_bound_group breakdown 是 0%、L3 的 tma_l3_bound 15% 然而 L4 的 tma_l3_bound_group 里面四个 0%。我的 cpu 型号是 x86 meteorlake，仔细看了 pmu metrics 定义之后我觉得这就是设计上的问题，L2 再往下没有保证，只能靠微指令法师的经验来跳跃性猜测和验证。
可以确定有用的 metrics 是
- tma_store_fwd_blk: atom vs noatom 性能差距的罪魁，lock prefix insn 阻止了 store forwarding (CSAPP $4.5.5.2) 导致性能大幅下降
- tma_false_sharing: cacheline 在多核心上共享时的 race。原文其实主要就是在讨论这个讨论的性能问题。
- tma_l3_bound: snoop hitm 的间接指标。
- L1-dcache-loads,L1-dcache-load-misses: cacheline racing 的间接指标。但由于 l1 miss 至少包含了 "cacheline 不在 L1" 和 "cacheline 在 L1 但是失效"，这个 miss 率其实很容易误导。
如何从 metrics 找到源码：
perf list 文档写得不全，直接看内核里的 pmu-events/.../mtl-metrics.json，比如说 perf record -M tma_false_sharing 很高，json 文件里这一项的 PublicDescription 就会写
然后采样
然后可以可以画火焰图和栈回溯，但我现在喜欢 perf annotate -l --stdio 直接看指令
看到 87% 的 false sharing 都是由于 inc %rcx 导致的。
讲完方法论终于可以回到主题了，cacheline 如何影响性能：如果是一个线程共享数据 A 在多核上并行 ++，核心1 修改了 A，那么核心2 的 L1 缓存的包含 A 的 cacheline 就会失效，这就是 false sharing。对于共享数据 A 来说这不可避免，但是如果有另一个 独立 数据 B 和 A 在同一个 cacheline，那么 A 在多核上刷存在感就会导致 B 的 L1 cache 失效，尽管 B 可能完全是一个单线程非共享数据。好的 cacheline 设计可以加上一段 padding 把 B 强制隔离出 A 所在的 cacheline，这样 A 刷新 cacheline 不会导致 B 的 cacheline 失效。
这些知识真的非常晦涩难懂，资料很少，AI 基本在帮倒忙，我感觉像是在星际航行，目睹所有令人惊叹的宇宙奇观，恍惚间就化入无穷。
不过更有意思的是，我已经见到三位工程师在 AI 的辅助下试图测试 “cacheline padding 带来六倍性能提升” 却没有成功，最后吐槽这是一篇错文、AI文。这里有一个有趣的知识屏障，如果不理解 cacheline 在何时会影响性能，那就可能无法写出正确的测试程序；但无法写出正确的测试程序又无法理解 cacheline 如何影响性能，知识死锁了。
你以为我想说原文的 “cacheline导致六倍性能差距” 的结论是正确的？不，那是
这些对我也是新知识，水平有限，施工区域谨慎阅读
我的测试代码不用很多工程师和 AI 用的 go bench 方法，因为抽象程度太高了，在这种性能施工区最好就写一眼能看穿汇编的简单代码。
package main
import (
"fmt"
"os"
"sync"
"sync/atomic"
"time"
)
const N = 100_000_000
type Counters interface {
Inc(idx int)
AtomicInc(idx int)
Result(idx int) uint64
}
type unpaddingCounters [8]uint64
func (u *unpaddingCounters) Inc(idx int) {
u[idx]++
}
func (u *unpaddingCounters) AtomicInc(idx int) {
atomic.AddUint64(&u[idx], 1)
}
func (u *unpaddingCounters) Result(idx int) uint64 {
return u[idx]
}
type paddingCounter struct {
val uint64
_ [56]byte
}
type PaddingCounters [8]paddingCounter
func (p *PaddingCounters) Inc(idx int) {
p[idx].val++
}
func (p *PaddingCounters) AtomicInc(idx int) {
atomic.AddUint64(&p[idx].val, 1)
}
func (p *PaddingCounters) Result(idx int) uint64 {
return p[idx].val
}
func main() {
var counters Counters
if os.Args[1] == "pad" {
counters = &PaddingCounters{}
} else {
counters = &unpaddingCounters{}
}
var inc func(idx int)
if os.Args[2] == "atom" {
inc = counters.AtomicInc
} else {
inc = counters.Inc
}
start := time.Now()
var wg sync.WaitGroup
for i := 0; i < 8; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for j := 0; j < N; j++ {
inc(i)
}
}()
}
wg.Wait()
fmt.Printf("Duration: %v ", time.Since(start))
for i := 0; i < 8; i++ {
fmt.Printf("Counter[%d]=%d ", i, counters.Result(i))
}
fmt.Println()
}
提供了两套变式， 通过命令行的 arg1 和 arg2 指定是否 padding 和是否用 atomic.AddUint64。
我本地的 cpu 0,1 是同一个核心，1,2 是不同核心，所以测试命令是
taskset -c 1,2 perf stat -d -- env GOMAXPROCS=2 ./go_cpu_perf pad atom很多细节我依然在学习中，目前可以公开的情报是：（+表示前者性能更好，-反之）
1. "pad atom" vs "nopad atom": +7.3倍性能
2. "pad nonatom" vs "nopad noatom": +3.3倍
3. "pad atom" vs "pad noatom": -2.5倍
4. "nopad atom" vs "nopad noatom": -5倍
可以看到 atom (lock prefix insn)本身就造成大量的性能影响，而 pad 会进一步加重 cacheline false sharing 导致更极端的性能差距。原文里的六倍性能差距是在 atom + pad 的场景下的测试结果，但我觉得大部分场景根本不会这么极端。
核心绑定情况也会造成很大影响。如果绑核改为 0,1 cpu，它们是同一 core，测试结果是：
1. "pad atom" vs "nopad atom": +1.75
2. "pad noatom" vs "nopad noatom": +1.65
3. "pad atom" vs "pad noatom": -1.9
4. "nopad atom" vs "nopad noatom": -2.0
在这些测试里，经典的 perf topdown 方法在 L2->L3->L4 几乎完全失效，经常会看到 L2 的 tma_core_bound 40% 然后 tma_core_bound_group breakdown 是 0%、L3 的 tma_l3_bound 15% 然而 L4 的 tma_l3_bound_group 里面四个 0%。我的 cpu 型号是 x86 meteorlake，仔细看了 pmu metrics 定义之后我觉得这就是设计上的问题，L2 再往下没有保证，只能靠微指令法师的经验来跳跃性猜测和验证。
可以确定有用的 metrics 是
- tma_store_fwd_blk: atom vs noatom 性能差距的罪魁，lock prefix insn 阻止了 store forwarding (CSAPP $4.5.5.2) 导致性能大幅下降
- tma_false_sharing: cacheline 在多核心上共享时的 race。原文其实主要就是在讨论这个讨论的性能问题。
- tma_l3_bound: snoop hitm 的间接指标。
- L1-dcache-loads,L1-dcache-load-misses: cacheline racing 的间接指标。但由于 l1 miss 至少包含了 "cacheline 不在 L1" 和 "cacheline 在 L1 但是失效"，这个 miss 率其实很容易误导。
如何从 metrics 找到源码：
perf list 文档写得不全，直接看内核里的 pmu-events/.../mtl-metrics.json，比如说 perf record -M tma_false_sharing 很高，json 文件里这一项的 PublicDescription 就会写
Sample with: OCR.DEMAND_RFO.L3_HIT.SNOOP_HITM然后采样
perf record -F9999 -g -e OCR.DEMAND_RFO.L3_HIT.SNOOP_HITM然后可以可以画火焰图和栈回溯，但我现在喜欢 perf annotate -l --stdio 直接看指令
0.42 : 4949aa: inc %rcx
: 42 inc(i)
87.08 : 4949ad: mov 0x18(%rsp),%rax看到 87% 的 false sharing 都是由于 inc %rcx 导致的。
讲完方法论终于可以回到主题了，cacheline 如何影响性能：如果是一个线程共享数据 A 在多核上并行 ++，核心1 修改了 A，那么核心2 的 L1 缓存的包含 A 的 cacheline 就会失效，这就是 false sharing。对于共享数据 A 来说这不可避免，但是如果有另一个 独立 数据 B 和 A 在同一个 cacheline，那么 A 在多核上刷存在感就会导致 B 的 L1 cache 失效，尽管 B 可能完全是一个单线程非共享数据。好的 cacheline 设计可以加上一段 padding 把 B 强制隔离出 A 所在的 cacheline，这样 A 刷新 cacheline 不会导致 B 的 cacheline 失效。
这些知识真的非常晦涩难懂，资料很少，AI 基本在帮倒忙，我感觉像是在星际航行，目睹所有令人惊叹的宇宙奇观，恍惚间就化入无穷。
fedora 大概不会有官方的 systemd-cron 了
就算用 copr 源，不说原作者会不会继续维护，至少目前作者最新的解决方案反而导致了 42 升级 43 失败
对后来人，我建议在 fedora 上自己编译安装 systemd-cron
