九维我操你爹
https://github.com/containerd/containerd/releases/tag/v2.2.0
containerd 发版 2.2.0 了。新版本新气象，光是看着 changelog 我就已经在流口水了🤤
containerd 发版 2.2.0 了。新版本新气象，光是看着 changelog 我就已经在流口水了🤤
GitHub
Release containerd 2.2.0 · containerd/containerd
Welcome to the v2.2.0 release of containerd!
The second minor release of containerd 2.x focuses on continued stability alongside
new features and improvements. This is the second time-based release...
The second minor release of containerd 2.x focuses on continued stability alongside
new features and improvements. This is the second time-based release...
为啥会发生这么大的变化呢？因为我司产品真的要换 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 即便是作为桌面系统来使用，也有一流的体验
