还有近几个月的美团也是脑子进水了，启动后就在通知列表冒出个播放器控件放你那什么神经病小说还是听书给用户喂💩，我看这么好的功能不如美团产品经理的妈放点悼词

Ubuntu Rust uutils 持续上分中
https://askubuntu.com/q/1559396/612877

mkdocs-material 也弃坑开新坑了？？？
https://github.com/squidfunk/mkdocs-material/releases/tag/9.7.0

本期报告您将看到：
1. 逆 城 市 化（指北京地区不推广）
2. 开 发 友 好（检测到有开发/调试/逆向软件就不推广）
3. 缸 中 之 脑（检测到虚拟机痕迹/任务栏图标个数过少/历史记录里缺乏指定游戏等虚假用户环境就不推广）
4. 善 待 同 行（检测同类杀毒软件的安装情况并差异化行为，并对控制面板等操作进行规避）（检测到有淘客类插件也不推广，防止推到同行脸上）
5. 给 钱 办 事（大量检测用户是否充值软件会员乃至充值金额的逻辑，甚至主动读注册表检测360弹窗过滤器的强力模式是否开启）
6. 不 求 功 名（检测到用户访问吾爱看雪等技术类、12315等投诉类网站会停止推广；检测到用户搜索流氓软件关键词会停止推广，检测到用户访问过周鸿祎的微博会停止推广）

——
刚读完，建议读者打开文章仔细过一过细节，这简直是教科书级别的流氓软件，该想到的想不到的都给你想了，以后写流氓软件不考虑这些的可以直接原地删库了。

看完了打个红衣疫苗再走：https://weibo.com/1708942053

抛开事实不谈，它是内存安全的（

https://github.com/torvalds/linux/commit/f076ef44a44d02ed91543f820c14c2c7dff53716

rtc: rk808: 补偿 Rockchip 历在十一月 31 日的误差

公元后 1582 年，教皇格里高利十三世意识到当时的儒略历无法反映现实状况，于是改变了闰年规则。无独有偶，公元后 2013 年，Rockcheap 的硬件工程师发现现有的格里高利历仍然存在问题：十一月应该有 31 天。很不幸，历法更改获得广泛采纳是需要时间的，就像三百余年后所有新教国家才接受格里高利历一样，我们还需要等待所有地区和操作系统内核接纳 Rockchip 历的优势。在那之前，从 Rockchip 硬件读写的日期都需要被转换回格里高利历格式。

笑死我了这个 commit message

虽然原文应该是：

我们还需要等待所有地区宗教和操作系统内核接纳 Rockchip 历的优势

#ops
DHCPv4 的包因为走的是 SOCK_RAW 而不过 iptables ，而 DHCPv6 的包需要过。有的时候会给 sysadmin 造成困惑。
https://unix.stackexchange.com/questions/593357

Cloudflare Boom!
原来这 ❌ 可以出现在中间的哇

#ops
CF验尸报告：

省流：
1. ClickHouse 的权限改动导致非预期的 Bot Management 配置文件增大。
2. Cloudflare 模块因为性能原因是预分配内存的，所以在读到过大的配置文件时……
3. 因为是自己生成的配置文件，所以自然而然的使用了 .unwrap() ，也就自然而然地 panic 了。（群友：无视风险，继续解包）
4. 因为这个 ClickHouse 的改动是逐步部署的，所以大家看到了喜闻乐见的仰卧起坐情况。
5. 部署修复之后，一大堆人同时试着登录以及默认的重试也降低了服务可用性。

CF 打算做的增强：
1. 对自己生成的配置文件也按照用户输入进行读取；
2. 提供全局开关来控制特性启用；
3. Coredumps和其他错误报告不再干死整个系统；
4. 重新检查所有代理模块的失效模型。

编者点评：
这个模块为啥不能是 fail-open 的？
这种更改导致出问题应该是一眼丁真啊，集成测试没看到？
https://blog.cloudflare.com/18-november-2025-outage/

#转发 #WTF

https://github.com/donlon/cloudflare-error-page

笑死，有人做了Cloudflare错误(?)页面生成器

最近写 Linux 201 的时候把 netfilter 这块搞清楚了，然后发现 Wikipedia 这张著名的流程图居然把这两个节点画反了

尽管 table 名字都叫 nat，实际上 OUTPUT / PREROUTING 的类型是 DNAT，而 INPUT / POSTROUTING 的类型是 SNAT，可以看到优先级是 DNAT → FILTER → SNAT，所以在 INPUT 链中，nat 位于 filter 后面

亲自指挥、亲自画图（

写到现在快把我自己搞晕了（
https://201.ustclug.org/ops/network/firewall/

现在怀疑这里也画反了，如果 reroute check 指的是 ip_route_me_harder / ip6_route_me_harder 的话，它应该发生在 mangle/OUTPUT 和 nat/OUTPUT 后面各一次

不严谨地实验了一下，好像它是对的，我可能看错代码片段了

结论：reroute check 在 mangle 和 nat 后面各发生一次是正确的，但 reroute 的结果并不会用于后续的 iptables 匹配（-o 参数仍然匹配最开始的 routing decision 确定的 oif）