Merge branch 'master' into draft

1 files changed, 83 insertions, 11 deletions

diff --git a/content/weekly/72.md b/content/weekly/72.md
index b884762b..b8ba40ae 100644
--- a/content/weekly/72.md
+++ b/content/weekly/72.md
@@ -1,14 +1,13 @@
----
-title: 稻草人周刊 Vol.
-subtitle:
-tags:
-date:
-categories: 稻草人周刊
-draft: true
-toc: true
----
-
-{{< music cover="" title="" artist="" apple="" spotify="" netease="" >}}
++++
+title = "稻草人周刊 Vol.72"
+subtitle = ""
+tags = []
+date = 2026-03-11 19:02:39
+draft = true
+toc = true
++++
+
+{{< music cover="https://r2.eltr.ac/geedeapro/weekly/72/f1bfa131-bb00-4a47-b3a2-c70fbf082b9c.jpg" title="Nothing's About To Happen To Me" artist="Mitski" apple="https://music.apple.com/cn/album/nothings-about-to-happen-to-me/1860622550" spotify="https://open.spotify.com/album/2M9F3AsbWy7n4LwmJ8pqEu" >}}
 
 <!--more-->
 
@@ -37,7 +36,80 @@ toc: true
 
 以前我认为这些人是没有教养，现在看来，他们有可能并不是想要这样做，而是因为觉得不这样做很困难。我想我可以多一些包容和理解吧。
 
+### Org Mode 是最好的标记语言吗？
+
+> [!note] 📜
+> [Org Mode Syntax Is One of the Most Reasonable Markup Languages to Use for Text](https://karl-voit.at/2017/09/23/orgmode-as-markup-only/)
+
+> I did not find any tool support for Markdown, AsciiDoc, Wikitext or reStructuredText anywhere that could compete with the cozy Org mode syntax support within Emacs.
+
+*Well, look harder.*
+
+作者在这篇文章中对比了 Org Mode 和其他标记语言（Markdown、AsciiDoc、Wikitext 和 reStructuredText）的区别，以及为什么他认为 Org Mode 比这些标记语言更具优势、更合理。
+
+文章前半部分的观点我很认同。首先，Org Mode 是规范化的，而 Markdown 却有很多不同的 Flavor，在不同的平台上输入 Markdown 得到的结果不总是一样的，比如 Markdown 很常见的表格就是拓展语法而非最初的标准。我自己也依赖一些并不常见的 Markdown 拓展语法，比如 Obsidan 里常用的 `==高亮标记==` 和 GitHub 上常用的 [Alert](https://github.blog/changelog/2023-12-14-new-markdown-extension-alerts-provide-distinctive-styling-for-significant-content/)，这两个语法都被 Hugo 支持，所以我在博客里也经常用，但是在其他地方就不一定了。这的确是 Markdown 的缺陷之一，不够标准化。
+
+其次，Org Mode 的行内标记是符合直觉的，`*加粗*` `/斜体/` `_下划线_` `~代码~` 和 `=等宽字=` 都很容易记住，是唯一的语法，而且都是一前一后的单个字符，不像 Markdown 有 `_斜体_` 和 `*斜体*` 两种写法，而 `**加粗**` 和 `~~删除线~~` 居然需要一前一后的双字符进行标记，和其他行内标记不统一。说实话，我之前尝试 Org Mode 时，就挺搀它的行内标记语法的。
+
+接下来是我不太赞同的部分。
+
+作者说他认为 Markdown 的链接语法令人疑惑，它会忘记 `[文字]` 和 `(链接)` 哪个在前、哪个在后，并且它不理解为什么要用到两种括号。Org Mode 里的链接写作 `[[链接][文字]]`。我可以用相同的逻辑论述为什么 Org Mode 的链接语法令人疑惑。在 Markdown 里，`[]` 是用来包裹文字的，`()` 是用来包裹链接的，至少我永远不会搞错文字和链接各自的括号是什么；我相信大部分 Markdown 用户记住哪边是链接、哪边是文字的方式都是这样的，`[]()` 这样的形式看得多了，就会知道谁在前在后；如此一来，我就不会搞错链接和文字的位置了。反观 Org Mode，链接和文字都用 `[]` 包裹，谁在前在后就更难记住。
+
+我认为「我容易忘记语法的顺序」并不是很有说服力的论据，因为我认为 Org Mode 用户能记住 `[[链接][文字]]`，和 Markdown 用户能记住 `[文字](链接)` 的方式一样：见多了就记住了，不是因为哪个语法更符合直觉。两边都有各自的优势和缺陷，仅仅是个人偏好和习惯问题。
+
+我尝试过 Org Mode，其中一部分我很喜欢，另一部分则很不习惯。我最不能接受的是 Org Mode 对中日韩文字的支持，它不能解析 `这样的*加粗*文字`，因为 Org Mode 的行内标记前后必须有空格，这显然是欧洲语言的使用逻辑，中文里就是很少用空格。其次，它不支持我很爱用的 `~~删除线~~`。再次，标准化是好事，但拓展性差也是问题，我没办法用 `==高亮标记==` 这种拓展语法。
+
+不过，读完这篇文章过后，我的确产生了很多思考，其中之一是：标记语言本身真的有好坏之分吗？我认为，就和代码风格一样，有的风格固然是不好的，比如可读性很差的风格，但有的风格很难分个高下，比如 `{}` 应不应该换行写、缩进应该用空格还是制表符、文件末尾应该不应有空行，标记语言也有很难说是好是坏的语法。用于写配置的标记语言 YAML 和 TOML 也是一样，有人认为 [YAML 有诸多缺陷](https://www.arp242.net/yaml-config.html)，而 [TOML 的缺陷](https://hitchdev.com/strictyaml/why-not/toml/)也有人能列出来不少。
+
+你猜怎么着？没有一门标记语言是完美的，包括 Org Mode 和 Markdown。
+
+如何选择标记语言，应该由使用者自己尝试、权衡和决定，不存在「最合理且对所有人都同样合理」的语言。或许，可以开发一种与 Vim 和 Emacs 类似的标记语言，人们可以自己写配置，调整各种语法，自己创造最适合自己的语言。
+
+### 「结果啊……」
+
+> [!note] 📜
+> [“It turns out”](https://jsomers.net/blog/it-turns-out)
+
+作者表示他很喜欢「It turns out」这个表达，他常在 [Paul Graham](https://paulgraham.com/articles.html) 的文章里读到，这个表达应该可以对应中文里的「结果……」「最后发现……」。
+
+如果把一句话直接说出来，尤其是那些稍微有些让人难以接受的观点，可能不会起到很好的效果，但如果作者自己在一开始就表达些许的质疑和不确定，然后再以「结果……」「最后发现……」来转折，语气中透露的些许惊讶就会让读者更容易接受这个没有论据支撑的观点。作者说这是一种很巧妙的偷懒技巧，或者说「黑客技巧」（Hack）。
+
+在[第 43 期周刊](/weekly/43/#读着顺口与写得正确)中我分享了 Paul Graham 的另一篇文章，题为《Good Writing》。PG 表示他发现「读着顺口」和「写得正确」这两者之间存在联系，简单来说，如果把句子写得更通顺，这个句子表达的意思就更有可能是正确的，内部逻辑可能更连贯——不过前提是修改，PG 表示他经常修改一些句子，使之更顺口，这样就无意识地修正了一些错误表达。
+
+我想「It turns out」可能也是 PG 的「顺口表达」之一吧。
+
+### 死互联网已经不再是理论了
+
+> [!note] 📜
+> [The dead Internet is not a theory anymore.](https://www.adriankrebs.ch/blog/dead-internet/)
+
+作者最近邀请了一个职位的申请者来参加第一轮面试，结果收到了这样的回复：
+
+> hey sorry - my agent got a mind of its own and started applying for jobs for me. i'm not currently looking for a job 😅 <br/>
+> 嘿不好意思 - 我的 Agent 有了自己的想法，开始帮我申请工作了，我现在没有在找工作。
+>
+> please ignore and sorry for that <br/>
+> 请忽略，抱歉。
+
+作者意识到「互联网已死」已经成现实了：Hacker News 开始限制新用户发表 ShowHN，因为最近出现了太多 Vibe Coded 且低质量的投稿； Reddit 上有很多机器人在评论区发帖宣传 SaaS 产品；LinkdIn 上的更新也是 AI 废料占大多数（作者贴的一条 LinkdIn 帖子的截图，帖子上全是些让人抓不住重点的车轱辘话，居然有两百多条评论和五千多个点赞；GitHub 也逃不过，AI 生成的 Pull Request 下的代码审查和回复竟然也是 AI 生成的。
+
+对此我的态度是，我就待在小互联网上好了，与大平台保持距离，和自己选择的真实的人社交。说实话，我一旦在 RSS 更新中看到了 AI 生成的内容，我就会直接把这个订阅源删掉。
+
+不过，倒霉的是，我办法屏蔽现实中人类的声音。
+
+{{< fedicard "https://akk.eltr.ac/@eltrac/posts/B48U34PYn9IvBEXdqK" >}}
+
 ## 星群
 
+### Hugo 社交媒体卡片
+
+Twitter 和 Mastodon 自带的嵌入卡片可能和网页的风格不统一，而且需要从外部加载资源，在这个过程中可能会暴露访客的 IP 地址和 Cookies 等信息给第三方。作者做了一个在 Hugo 构建过程从 API 拉取数据，静态展示社交媒体内容的卡片，和自己网站的风格更匹配，而且不会追踪任何用户数据。
+
+我其实也想添加，但我一直不太能接受在静态网站的构建过程中，从网络加载资源，我认为这会拖慢*世界上最快的静态网站生成器*的构建速度。尽管 Hugo 有构建缓存，但我还是不太想要在构建时引入网络资源。
+
+![](https://r2.eltr.ac/geedeapro/weekly/72/hugo-social-cards.png)
+
+访问：[thumbsupdotme/social-cards](https://github.com/thumbsupdotme/social-cards)
+
 ## 切片