[draft] update

1 files changed, 38 insertions, 11 deletions

diff --git a/content/weekly/79.md b/content/weekly/79.md
index bba52d3e..3b543e41 100644
--- a/content/weekly/79.md
+++ b/content/weekly/79.md
@@ -7,9 +7,9 @@ draft = true
 toc = true
 +++
 
-周刊临近 80 期了，如今周刊的样子和最初的几期已经有很大不同了，技术类的内容也多了不少，对读者来说兴许是门槛，所以我特意把不懂技术的读者也能读懂、大多数人都关心的话题放在了最前面，较小众的内容放在靠后的位置，希望能让你更容易找到感兴趣的链接。<!--more-->
+周刊临近 80 期了，如今周刊的样子和最初的几期已经有很大不同了，技术类的内容也多了不少，对读者来说兴许是门槛，所以我特意把不懂技术的读者也能读懂、大多数人都关心的话题放在了最前面，较小众的内容放在靠后的位置，希望能让你更容易找到感兴趣的链接。
 
-<!--more-->
+此外，自本期起周刊撤销[第 73 期](/weekly/73/#开始之前)下达的 LLM 禁令，我会讨论并且会毫不保留地表达我对这项技术的看法。<!--more-->
 
 ---
 
@@ -88,17 +88,38 @@ toc = true
 ### 如何做一杯好喝的美式？
 
 > [!note] 📺
-> [The Truly Absurd Secrets of An Incredible Americano](http://farside.link/invidious/watch?v=0HdzJz_evNw) ([YouTube](http://youtube.com/watch?v=0HdzJz_evNw))
+> [The Truly Absurd Secrets of An Incredible Americano](http://farside.link/invidious/watch?v=0HdzJz_evNw) ([YTB](http://youtube.com/watch?v=0HdzJz_evNw))
+
+当我看到 James Hoffman 在视频进行到一半的时候突然搬出来一台真空机，~~我就知道喝咖啡的人迟早都会疯的~~。我其实也不知道为什么我要看这期视频，毕竟我只喝手冲咖啡（filter coffee），美式仅仅是不得已时才会选择的饮品，但…… 这是 James Hoffman 欸，就像 Paul Graham 写了一篇有关我并不在乎的技术的文章，我也会去读的。
+
+视频里 Hoffman 尝试了许多种把美式咖啡变得更好喝的方法。美式其实就是加水稀释的意式浓缩咖啡，稀释后的口感是不如直接通过水滴滤出来的手冲咖啡的，冰美式更是难喝，苦味很重，浅度烘焙咖啡豆的风味也几乎无法被表达出来。
+
+美式不好喝的原因之一是意式咖啡机锅炉里的水硬度太高（毕竟美式不像牛奶咖啡一样有奶味遮瑕，非常考验水质和豆子本身的品质），因为锅炉反复沸腾、换水后留在其中的水会变得越来越浓。Hoffman 的建议是每次做咖啡时换新的水，并且…… 像做蒸气牛奶一样把水放在咖啡机的蒸气孔下面，把冷水蒸热，用这个水稀释意式浓缩来做美式。
+
+听起来不可思议，但这的确让美式变得非常好喝，常见于美式的粗糙感（harshness）显著地消失了。
+
+另一个可能会引发众怒的观点是，做美式应该把意式浓缩的 Crema（国内更流行但错误的叫法是「油脂」，因为 Crema 是二氧化碳被释放出来时产生的气泡，不是油）去掉，因为 Crema 里不仅有二氧化碳，还有咖啡渣，咖啡渣很苦。把 Crema 去掉并用蒸过的水稀释，美式的口感会好很多。
+
+Hoffman 猜测这和溶解在饮品里的二氧化碳有关，于是他把一杯美式放进真空机，利用真空环境让二氧化碳从水里跑出去，结果发现美式变难喝了。没有真空过的咖啡会更醇厚。
+
+总之是很有趣的实验，不过我还是会继续喝手冲咖啡的，因为美式真的很难喝！
 
 ### Clojure 纪录片
 
 > [!note] 📺
 > [How one programmer's pet project changed how we think about software](http://farside.link/invidious/watch?v=Y24vK_QDLFg)
 
-### mise 的作者成为全职开源开发者
+这周末看完了 Clojure 的纪录片，从 Rich Hickey 开发 Clojure 开始，到 Clojure 社区、Datomic 数据库、被 NuBank 收购等等，非常精彩。
 
-> [!note] 📜
-> [Going Full Time on Open Source](https://jdx.dev/posts/2026-04-17-going-full-time-on-open-source/)
+纪录片中我印象最深刻的有几个观点。首先，尽管 Clojure 是一门跑在 JVM 上的函数式、动态类型 Lisp 方言，但它从一开始就是为了解决真实世界的实际问题而创造的，纪录片中有一句话是「拥抱真实世界的混乱」。其次，Clojure 的哲学是简洁（simple），消除传统软件开发工具的复杂性（或许下周我应该去看看 Rich 的《[Simple Made Easy](https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md)》）。
+
+十多年前，Rich 用 Common Lisp 实现了某个软件需求，而客户要求它用 C++ 写，他发现用 C++ 重写比用 Common Lisp 编写耗时长太多了。我想这也是他创造 Clojure 的动力之一，用最少的代码实现最多的功能。由于 Clojure 跑在 JVM（Java 虚拟机）上，编译成 `.jar` 文件，所以客户能直接使用。如今拉丁美洲最大的金融科技银行 NuBank 就依赖 Clojure 和 Datomic 数据库运行。
+
+尽管用于解决实际问题，但 Clojure 本身并没有向现实妥协太多。我想这归功于 Rich 的组织能力。对于开源项目维护者来说，「说不」是很重要的，不仅仅是对坏点子说不，也要对某些好点子说不，否则软件就会变成一坨不可名状的怪物。如今 Clojure 1.0 的代码，放在十多年后的今天，几乎仍能够运行。Clojure 本身仍然是一门编写起来令人愉悦、优雅、简洁的语言。
+
+从我使用 Clojure 编程这两个月的经历来看，我对这门语言还没有什么想抱怨的（除了和 Java 互通的面向对象编程的部分语法），Clojure 本身设计得非常精巧。就连我仍然喜爱的 Go 语言，都让我对 `if err==nil` 感到些许不满。
+
+~~不过看到 CultRepo 还拍了 Java、Spring 和 IntelliJ IDEA 的纪录片我属实有些没绷住。~~
 
 ### 从 GitHub 到 Codeberg/Forgejo
 
@@ -107,9 +128,11 @@ toc = true
 
 又是一篇关于从 GitHub 搬离的博客，有越来越多的人在抛弃 GitHub，真好。
 
-不过需要提醒的是，作者似乎按照消费者的思路在做决策，抛弃 GitHub 是因为服务不稳定性和出现在 Action Runner 里的 Vibe Code 都体验上的原因，喜欢 Codeberg 和 Forgejo 似乎是因为它们很快、性能很好，而且够用了。我想说，Codeberg 并不是绝对的 GitHub 替代品，因为它实际上只托管自由软件，而且不是商业平台；而 GitHub 也提供商用，托管非自由的代码，对个人的小打小闹也有更多容忍度。我想，如果是没有协作需求、纯自用的项目，还是自己托管一个 [Forgejo](https://forgejo.org/) 实例为好，内存占用并不高，尽量不要去消耗 Codeberg 作为非营利组织的计算资源，有能力的话尽量[捐款](https://docs.codeberg.org/improving-codeberg/donate/)。
+不过需要提醒的是，作者似乎按照消费者的思路在做决策，抛弃 GitHub 是因为服务不稳定性和出现在 Action Runner 源代码里的 Vibe Code 等用户体验上的原因，喜欢 Codeberg 和 Forgejo 似乎是因为它们很快、性能很好，而且够用了。
 
-不过从另一个方面看，如果有越来越多的人依赖 Codeberg，这个平台也会受到越来越多的关注，自然也会有更多的人愿意贡献。写一篇博客提高曝光度，也是件好事。
+我想说，Codeberg 并不是绝对的 GitHub 替代品，因为它实际上只托管自由软件，不是商业平台；而 GitHub 也提供商用，托管非自由的代码，对个人的小打小闹也有更多容忍度。我想，如果是没有协作需求、纯自用的项目，还是自己托管一个 [Forgejo](https://forgejo.org/) 实例为好，内存占用并不高，尽量不要去消耗 Codeberg 作为非营利组织的计算资源，有能力的话尽量[捐款](https://docs.codeberg.org/improving-codeberg/donate/)。
+
+不过从另一个方面看，如果有越来越多的人依赖 Codeberg，这个平台也会受到越来越多的关注，自然也会有更多的人愿意贡献。写博客提高曝光度，也是好事。
 
 顺带一提，我还在这个作者的博客上看到一篇[用 Fennel 重写 Neovim 配置的文章](https://www.jonashietala.se/blog/2025/10/29/packing_neovim_with_fennel/)，我最近正好也在做一样的事情，还真是凑巧。
 
@@ -119,15 +142,19 @@ toc = true
 
 ### Tangled
 
-基于 [AT Protocol](https://atproto.com/) 的[开源](https://tangled.org/tangled.org/core)社交代码平台（social coding platform），大概就是更具社交属性的 Git 托管服务吧。不清楚 Forgejo 基于 ActivityPub 的联邦开发得怎么样，但 Tangled 貌似是可以完全自托管，然后通过 AT Protocol 联邦协作开发的，基础设施可以完全跑在自己的机器上。
+基于 [AT Protocol](https://atproto.com/) 的[开源](https://tangled.org/tangled.org/core)社交代码平台（social coding platform），大概就是更具社交属性的 Git 托管服务吧。不清楚 Forgejo 基于 ActivityPub 的联邦开发得怎么样，Tangled 可以自托管，然后通过 AT Protocol 联邦协作开发，基础设施可以跑在自己的机器上，不过目前仍在 Alpha 测试。
 
 Tangled 以 MIT 协议授权，是自由软件，用 Go 语言开发。UI 方面，我很喜欢他们把代码和 commits 并排放的方法。
 
+<div class="outbox">
+
 ![](https://img.eltr.ac/geedeapro/weekly/79/tangled-ui.png)
 
-除此之外，Tangled 还原生支持 [Jujutsu](https://www.jj-vcs.dev/)，用 Stack Pull Requests 重新想象了代码协作方式（大概就是把大的 PR 分成更容易审查的小块），CI 工作流还支持直接从 [nixpkgs](https://docs.tangled.org/spindles.html#dependencies) 获取依赖（虽然我还没有开始用 Nix，但不少人应该会喜欢），未来会支持基于 Docker 和 MicroVM 的 Runner。光是听到这些就觉得很令人激动了。
+</div>
+
+除此之外，Tangled 还原生支持 [Jujutsu](https://www.jj-vcs.dev/)，用 Stack Pull Requests 重新想象了代码协作方式（大概就是把大的 PR 分成更容易审查的小块），CI 工作流还支持直接从 [nixpkgs](https://docs.tangled.org/spindles.html#dependencies) 获取依赖（虽然我还没有开始用 Nix，但不少人应该会喜欢），未来会支持基于 Docker 和 MicroVM 的 Runner。光是听到这些就很期待了。
 
-最近它们还支持了[担保](https://blog.tangled.org/vouching/)功能，类似于我在[第 76 期周刊](/weekly/76/#humanjson)提过的 `human.json`。用户可以给其他用户担保（vouch），表示认可他们的代码没有滥用 LLM 编程工具，由此构建信任网络。你信任的人假如担保了别人，那么这个人也会显示被信任，在信任网络中离你越近的人就越值得信任。相对应的还有告发（denounce）功能。这其实很有用，比方说在 PR 里看到提交者的信任等级很低，就可以降级处理，优先审查那些受信任的人提交的代码。
+最近它们还支持了[担保](https://blog.tangled.org/vouching/)功能，类似于我在[第 76 期周刊](/weekly/76/#humanjson)提过的 `human.json`。用户可以给其他用户担保（vouch），表示认可他们没有滥用 LLM 工具，由此构建信任网络。你信任的人假如担保了别人，那么这个人也会显示被信任，在信任网络中离你越近的人就越值得信任。相对应的还有告发（denounce）功能。这其实很有用，比方说在 PR 里看到提交者的信任等级很低，就可以降级处理，优先审查那些受信任的人提交的代码。
 
 Tangled 提供了[自托管指南](https://docs.tangled.org/knot-self-hosting-guide#knot-self-hosting-guide)，我大概会尝试一下，