docs: update draft

Former-commit-id: cce6c9e768dbd055cd0f336053a00c5688d58eb4

1 files changed, 111 insertions, 9 deletions

diff --git a/content/_drafts/55.md b/content/_drafts/55.md
index 8203e9d7..9211b5fb 100644
--- a/content/_drafts/55.md
+++ b/content/_drafts/55.md
@@ -19,28 +19,94 @@ toc: true
 > [!note] 📜
 > [FFmpeg to Google: Fund Us or Stop Sending Bugs - The New Stack](https://thenewstack.io/ffmpeg-to-google-fund-us-or-stop-sending-bugs/)
 
-……
+FFmpeg 是一个非常重要的开源软件库，它用于转换音频和视频，包括 YouTube 在内的许多网站和软件都使用了 FFmpeg 提供的库。和许多其他的开源库一样，FFmpeg 面临资助不足的问题。这个开源库几乎完全是志愿者维护的，大家是把这件事情当作爱好进行免费劳动，开源软件几乎都是这样的。然而，近期 FFmpeg 却和 Google 闹了矛盾。
 
-## ⁂ · 星群
+简单来说，Google 使用他们的 AI 机器人不断地向 FFmpeg 发送 bug 反馈，要求维护者修复潜在的安全问题。安全风险当然重要，FFmpeg 也声称他们非常注重软件的安全性，但问题在于，Google 发送报告的速度太快，已经给这些维护软件的爱好者带来了压力，而且，大部分所谓的潜在安全问题，实际上并没有那么紧急需要修复。更何况，FFmpeg 是用 C 语言和汇编语言编写的，汇编程序维护起来有多困难不必多言，大部分的这些问题其实不值得汇编程序员花那么多的时间。在很多人看来 Google 用 AI 找 Bug 给这些爱好者增加工作量的做法无疑是在耍流氓，但有人声称：反馈问题也是对开源软件的一种贡献！真的是很流氓了。
+
+在之前，libxml2，同样是一个基础但重要的开源软件库，维护者因为每周需要在这个没有金钱回报的项目上花费太多时间精力而退出了工作。很难想象，如果我们继续这样对待开源库的维护者，包括大公司在内依赖的底层软件库可能都不会有人维护了。
 
 ### XLST RIP
 
-Google 即将在 Chromium 中移除 XSLT（将 XML 转换为其他格式显示的技术，被用在许多政府网站和一些 RSS 订阅源中），相关代码将在 2026 年 11 月完全废除，他们称此举是为了创造一个「更安全的浏览器」，并且 Mozilla 和 Apple 也将跟随 Google 的决定——Google 的一个决定就可以改变全世界的 Web 体验！Google 这边的说法是：
+> [!note] 📜
+> [Removing XSLT for a more secure browser  \|  Web Platform  \|  Chrome for Developers](https://developer.chrome.com/docs/web-platform/deprecating-xslt)
+
+> [!note] 📜
+> [XSLT.RIP - Google are killing XSLT!](https://xslt.rip/)
+
+Google 即将在 Chromium 中移除 XSLT（将 XML 转换为其他格式显示的技术，被用在许多政府网站和一些 RSS 订阅源中），相关代码将在 2026 年 11 月完全废除，他们称此举是为了创造一个「更安全的浏览器」，并且 Mozilla 和 Apple 也将跟随 Google 的决定——很恐怖，Google 的一个决定就可以改变全世界的 Web 体验！Google 这边的说法是：
 
 > The continued inclusion of XSLT 1.0 in web browsers presents a significant and unnecessary security risk. The underlying libraries that process these transformations, such as libxslt (used by Chromium browsers), are complex, aging C/C++ codebases. This type of code is notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. For example, security audits and bug trackers have repeatedly identified high-severity vulnerabilities in these parsers (e.g., CVE-2025-7425 and CVE-2022-22834, both in libxslt). Because client-side XSLT is now a niche, rarely-used feature, these libraries receive far less maintenance and security scrutiny than core JavaScript engines, yet they represent a direct, potent attack surface for processing untrusted web content. Indeed, XSLT is the source of several recent high-profile security exploits that continue to put browser users at risk. The security risks of maintaining this brittle, legacy functionality far outweighs its limited modern utility.
 
 大意是，XSLT 的底层库已经很老了，是很复杂、维护起来很困难且有很多安全风险的 C/C++ 代码库，这类代码往往有缓冲区溢出的问题，可能会被利用执行恶意代码。又考虑到，XSLT 在目前的 Web 环境中已经很少使用了，更现代的做法是使用 JSON 而不是 XML，也不会直接转换数据文件本身，通常会用获取并解析 JSON 数据的方式通过 JavaScript 展示。这么看，其实移除老旧，还有安全风险的技术而不是重写，是比较方便的做法。
 
-另一边，XLST RIP 这个网站的作者声称，自 Google 移除 RSS 阅读器 Google Reader 以来，他们又杀死了近 300 项技术，几乎可以肯定 Google 厌恶 XML 和 RSS。作者呼吁所有人在自己的网站上添加XSLT，不要让 Google 轻易地又杀死一项技术。这个网站的作者认为，目前还没有 XLST 用户被黑的案例，Google 说什么安全风险是在把用户当猴耍。在我看来，Google 不一定邪恶，但在某种程度上说得上是很烂，因为他们完全可以把实现 XLST 的底层库用更安全的方式重写一遍——不过指望他们这么做大概是不可能的，毕竟[他们一直给开源库反馈 Bug 却从没想过捐钱或者自己修](https://thenewstack.io/ffmpeg-to-google-fund-us-or-stop-sending-bugs/)。
+另一边，XLST RIP 这个网站的作者声称，自 Google 移除 RSS 阅读器 Google Reader 以来，他们又杀死了近 300 项技术，几乎可以肯定 Google 厌恶 XML 和 RSS。作者呼吁所有人在自己的网站上添加 XSLT，不要让 Google 轻易地又杀死一项技术。这个网站的作者认为，目前还没有 XLST 用户被黑的案例，Google 说什么安全风险是在把用户当猴耍。
+
+我的 [RSS 源](/index.xml)也使用了 XLST，我是不希望这个技术消失的。并且，浏览器明显应该尽量向下兼容。在我看来，Google 不一定邪恶，但在某种程度上可以说他们很懒，因为他们完全可以把实现 XLST 的底层库用更安全的方式重写一遍，比如用自家的 Go 语言——不过指望他们这么做大概是不可能的，毕竟[他们一直给开源库反馈 Bug 却从没想过捐钱或者自己修](https://thenewstack.io/ffmpeg-to-google-fund-us-or-stop-sending-bugs/)。
+
+### 适宜的大小
+
+> [!note] 📜
+> [On Being the Right Size by J. B. S. Haldane 1928](https://www.marxists.org/archive/haldane/works/1920s/right-size.htm)
+
+人们时常想象巨人的出现，[生物学家 J. B. S. Haldane](https://zh.wikipedia.org/wiki/%E7%BA%A6%E7%BF%B0%C2%B7%E4%BC%AF%E9%A1%BF%C2%B7%E6%A1%91%E5%BE%B7%E6%A3%AE%C2%B7%E9%9C%8D%E5%B0%94%E4%B8%B9)在文中表达了这样的观点：一个生物不可能只改变大小，而不改变形态和结构。他举例说，假使一个羚羊变得更大，它要么像河马一样长出更粗壮的四肢来支撑重量，要么像长颈鹿一样将四肢展开、倾斜。变大意味着重量会快速增长，如果结构和形态不变，骨头就没办法支撑，轻微的移动都会导致骨折。此外，如果变大，生物也需要更粗壮的血管，因为需要更大的血压来降血液输送到全身；呼吸也是一样；还有对食物和热量的需求，仅仅是长大十倍，就意味着机体需要摄入一千倍的热量。体型巨大的生物受重力的影响更大，相比之下，小老鼠和蚊子就受重力的影响就很小，不过，蚊虫受表面张力的影响很大，这也是为什么人类在沐浴之后即使身上附着了几斤水也没事，但虫子被浸湿了却是要命的。
+
+总的来说，每一种动物都有他们的最佳尺寸。同样的道理也可以推广到人类组织，对于一个团体、组织、政党或企业，扩大规模意味着机制、结构和运作模式也要发生改变，规模越大也意味着复杂度越高。就像动物只变大而不进化出更复杂的结构会是致命的，人类组织要是只增长而不调整，也会出问题。
+
+### 记忆系统的一种用法
+
+> [!note] 📜
+> [How I use memory systems](https://michaelnotebook.com/ongoing/hiums.html)
+
+作者是一个物理学和计算机领域的研究员（Research Fellow），这篇文章里他介绍了他使用 Anki 等记忆系统的方法。顺带一提，这篇文章是博客文章《[阅读的目的从来不是获取知识](/posts/阅读的目的从来不是获取知识/)》下 [@pepperex](https://github.com/pepperex) 推荐给我的。
+
+作者会把自己在视频、电影和影视剧里看到的，给他带来极大情感触动的画面做成记忆卡片，放在 Anki 里，目的是为了让自己时常回忆、重新思考这些由视觉信息触发的感受。这种做法对我而言很新奇。作者把 Anki 当作一个「创造意义的语境」，他会写在卡片里的东西并不是「我觉得自己应该感兴趣、应该记住的东西」，而是他真正感兴趣，但因为对相关知识的理解还不够深入，所以不能够阐明意义、理解透彻的东西。把这样的东西写成记忆卡片，每天回顾，能帮助自己思考和建立新的理解。
+
+> Anki is especially helpful in areas which you are very interested in, but don't yet have the expertise to enable rapid encoding of new memories.
+> 
+> Anki 在那些你感兴趣，但并不具有能够快速编码新记忆的专业能力的领域，尤其有用。
+
+作者还引用了美国作家 Edwim Schlossberg 的话：
+
+> The skill of writing is creating a context in which people can think.
+> 
+> 写作的技巧在于创造允许人们思考的语境。
+
+更重要的是，作者认为，要创造作者自己能够思考的语境。如果做得好，产生新想法就会变得简单。对他来说，写 Anki 卡片就是能够创造这种语境的写作方式。
+
+作者提出的这种方法似乎对初入一个新领域的学习者十分有用，正好我最近也在学些新东西，确实也可以写一些卡片来巩固记忆和加深理解。
+
+### 美国的书籍审核
+
+> [!note] 📻
+> [276-美国出版界如何审核书籍？ - 独树不成林](https://podcasts.apple.com/cn/podcast/%E7%8B%AC%E6%A0%91%E4%B8%8D%E6%88%90%E6%9E%97/id1711052890?i=1000736525089)
+
+仲树老师描述了美国出版界的现状。传统上讲，在美国出版书籍需要经过同行审核（peer review），这导致的问题是那些挑战领域内传统观点的书籍很可能得不到出版。如今，在美国出版不仅有同行审核这个障碍，还有政治正确这个障碍。出版社会雇佣「敏感审查员」，帮助作者和图书编辑把书本内容变得不那么「敏感」，防止书籍在出版的最后阶段被取消，或者在发布之后被群情激愤的读者「取消」。这些敏感审查员不需要任何资历，只需要属于某一群体，比如，一本描写了黑人生活的书，就要交给一个黑人敏感审查员审查，他们会关注「这个黑暗晚餐吃了什么」这种无关紧要但不知为何十分敏感的细节。
 
-我的 [RSS 源](/index.xml)也使用了 XLST，我是不希望这个技术消失的。
+诚然，敏感审查员对一本书的文学和思想价值毫无帮助，在美国出版界却是必不可少的。树老师认为敏感审查的做法无疑是加重了群体之间的矛盾，规定「黑人只能吃某种晚餐」「黑人只能说饶舌俚语」本就是在加深刻板印象、加剧种族歧视。
 
-访问：[XSLT.RIP - Google are killing XSLT!](https://xslt.rip/)
+社交媒体上如 Cancel Culture 这样的风气如今也开始影响传统纸质媒体和书籍出版了，这很可怕，而且在中国（中文是除了英文之外受众最多的出版语言），这种趋势也有苗头。
+
+## ⁂ · 星群
+
+### AI 世界时钟
+
+作者让不同的模型每分钟用 HTML 和 CSS 生成一个带动画的时钟，做成了一个网站。我不清楚作者开发这个项目的目的是什么，但我极度怀疑他是为了展示 LLM 的平面想象能力有多么弱智。
+
+{{< gallery >}}
+![](https://image.guhub.cn/picgo2025/1Capture_2025-11-15_18.34.42.png)
+![](https://image.guhub.cn/picgo2025/1Capture_2025-11-15_18.35.19.png)
+![](https://image.guhub.cn/picgo2025/1Capture_2025-11-15_18.35.40.png)
+![](https://image.guhub.cn/picgo2025/1Capture_2025-11-15_18.36.17.png)
+![](https://image.guhub.cn/picgo2025/1Capture_2025-11-15_18.37.15.png)
+{{</ gallery >}}
+
+目前看来，只有 Kimi K2 生成的时钟质量比较稳定，至少是为数不多能用的。
+
+访问：[AI World Clocks](https://clocks.brianmoore.com/)
 
-访问：[Removing XSLT for a more secure browser  \|  Web Platform  \|  Chrome for Developers](https://developer.chrome.com/docs/web-platform/deprecating-xslt)
 ## ↯ · 当下
 
-### 开发 wthis、学习 Go 语言
+### 开发 wthis
 
 我对自己的设备有种奇怪的洁癖，会不定期浏览电脑上安装的 App 并卸载长时间未使用的，即使这个程序不会占用太多的存储空间。某天，我把目光转向了 macOS 上的命令行工具，运行 `brew list` 发现 Homebrew 列出来的大部分软件包我都不认识，用 `brew info` 查询的结果可读性极差，遂用 Go 写了一个[命令行工具](https://github.com/BigCoke233/wthis)。
 
@@ -52,8 +118,44 @@ wthis <formula_cask_name>
 
 ![](https://image.guhub.cn/uPic/2025/11/3GrHqV.png)
 
-个人认为最有用的是可以直观地看到这个包是自己运行 `brew install`  安装的还是作为依赖自动安装的，如果是作为依赖安装的，则会列出依赖于这个包的其他包。同时还会查询对应二进制文件上次被访问的时间，也就是可以看到自己最近有没有用过这个软件，
+个人认为最有用的是可以直观地看到这个包是自己运行 `brew install`  安装的还是作为依赖自动安装的，如果是作为依赖安装的，则会列出依赖于这个包的其他包。同时还会查询对应二进制文件上次被访问的时间，也就是可以看到自己最近有没有用过这个软件。我把这两个部分的信息称作「用户交互记录」，这么看的话就会很清楚某个软件包为什么出现在列表里，以及应不应该留下。
+
+如果你感兴趣，可以运行一下命令安装 wthis。
+
+```shell
+brew install BigCoke233/tap/wthis
+```
 
 开发过程很有趣，第一次写 CLI，控制换行和排版什么的没有想象的那么简单；学到了一些 Homebrew 相关的基础概念。写 Hugo 主题的时候也会用到一些嵌入的 Go 语言代码，但整体写的不多，所以在做这个程序的时候也难免求助 ChatGPT。从敲代码的体感上，Go 很像是现代化、更花哨也更好用的 C 语言，虽然结构体和指针一个不少，但写起来还算方便（但是 Go 移除了三目表达式，这个还是非常不习惯的！）。做完 `v0.1.0` 版本之后就去看 Go 语言文档查漏补缺，今年年初为了做游戏学了 Lua，那今年就以入门 Go 作为结尾吧——总觉得这两门语言在气质上有些类似，尽管一个是脚本语言，一个是更底层的语言。
 
 访问：[GitHub - BigCoke233/wthis: 🍻 What the Homebrew is this?](https://github.com/BigCoke233/wthis)
+
+### 学习 Go 语言如何助长我的语言偏见？
+
+这 Go 语言越学，我就越讨厌 Java 这门语言。无意冒犯 Java 开发者，但我愈发觉得，人们使用 Java 的最大原因并非是这门语言和它的技术栈有多好用，而是因为技术债务[^1]、传统、人力资源[^2]和让人产生依赖的软件生态。事实上，选用其他编程语言和技术栈照样可以写出健壮、功能完善的后端程序，性能、速度和安全性可能还更好。
+
+我承认我对 Java 有偏见，我的确不喜欢这门语言，从刚接触到这一门语言和热门的 Spring 框架起，我就疑惑为什么实现简单的需求需要编写这么多文件和类、为什么有这么多的抽象、为什么有这么多我不清楚原理的「魔法」。即使弃用了 IDEA，转用一个简单的编辑器和命令行进行开发，做到了尽量透明可控，我依然对这门臃肿、啰嗦、复杂的语言提不起好感。
+
+诚然，我接触 Go 的时候也感到不适应，也会产生疑惑：为什么要移除这么好用的三目表达式？为什么编译器这么严格，未被使用的引用居然会导致编译时报错？为什么没有传统面向对象编程的类和继承？不过很快这些疑问就得到了解答，我很快就爱上了这门语言以及它背后的各种编程哲学。我正在逐条学习 [Go Proverbs](https://go-proverbs.github.io/)，目前为止我最喜欢的一条是：
+
+> Clear is better than clever.
+> 
+> 聪明比不过清晰。
+
+### 本周看了什么？
+
+《地狱客栈》（Hazbin Hotel）第二季更新到第六集了，这个剧情走向越来越让我感到迷惑。本来以为在铺垫，但是这季总共也就八集啊…… 我认为问题可能在于剧情线太多了，每个（组）人物都需要占用时间铺垫和表现，以至于第二季的叙事在我看来有些慌张，人物的动机和行为都挺令人费解的。如果每集时间更长或者剧集数更多的话，或许观感会有提升。
+
+目前最喜欢的音乐片段来自我最喜欢的角色 Husk（谁会不喜欢酒保猫恶魔！）。
+
+<iframe src="//player.bilibili.com/player.html?isOutside=true&aid=115541331148948&bvid=BV1vGC4B3ETf&cid=33969997588&p=1" scrolling="no" border="0" frameborder="no" framespacing="0" allowfullscreen="true" loading="lazy"></iframe>
+
+周五看了有名的音乐剧《吉屋出租》（Rent），看到四分之一的样子就没看了。我得说我不太能欣赏得来，叙事和音乐在我看来都有些乱乱的，兴许过几年再看会能够理解吧。
+
+周六看了 Apple TV 的新剧《同乐者》（Pluribus），很喜欢。这应该是今年看的第二部来自 Apple 的美剧了，第一部是《人生切割术》的前两季。目前的印象是，Apple TV 的剧集质量都还不错。《同乐者》是科幻题材的乌托邦（或反乌托邦）美剧，除了主角和少数幸存者，地球上所有人类都成为了一个集体意识，这让我想到了《瑞克与莫蒂》里的 Unity。不幸的是，尽管集体意识能够满足主角的所有需求，甚至带她找到其他的还保有自我意识的个体，她依然感到孤独和不快乐。目前《同乐者》只推出了三集，这三集我都很喜欢，期待后续。
+
+2025 年年底真的有很多好东西，本人的文娱生活算是有救了。尽管还没定档，但今年年底应该会上线音乐剧《魔法坏女巫》的第二部分，美剧《怪奇物语》也会在今年年底和明年年初播出。
+
+[^1]: 技术债务（technical debt）指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。—— 来源：[技术负债 - 维基百科](https://zh.wikipedia.org/wiki/%E6%8A%80%E6%9C%AF%E8%B4%9F%E5%80%BA)
+
+[^2]: 学过 Java 的人一定比学 Go 或其他语言的多，除了 C 语言、C++、Python 和 JavaScript 这些一般不会用在 Web 后端开发的语言。不过现在用 Node.js 写后端也很常见了。