瓠樽

靜態博客的『阿喀琉斯之踵』

Wed, 22 Jan 2025 00:00:00 +0800

最近終於下定決心遷移博客的評論系統，實際操作過後我的建議是早換，別偷懶

問題

六年前部署博客的時候，為了穩定和偷懶，就選擇了 Disqus 和 Disqus PHP API 的組合，當時使用起來體驗很不錯，國內國外的訪問和留言都無縫銜接。但是後來事情很快開始起變化，一開始是別人在 Disqus 里的評論我開始接收不到郵件提醒了，通過 Disqus PHP API 評論的郵件提醒是正常的，因為是我單獨配置的。然後很多 Spam 開始陸陸續續通過 Disqus PHP API 進入評論列表，可能是 Disqus 對這塊沒有審核。

再說說這個 Disqus 的 Spam 算法，我在這次遷移中發現，有很多正常評論被扔在 Spam 里，這就更離譜了。我仔細看了一下被判定為 Spam 的評論，發現 Disqus 算法其實很偷懶（甚至不知道有沒有上算法），只要評論裡面帶超鏈接🔗就會被扔進 Spam 里，關鍵的是進了 Spam 也沒有提示，到後來更過分，連有新評論都不發郵件了。這裡得對過去留言沒有得到回覆的讀者說聲抱歉。

Disqus 雖然說支持數據導出，但是數據導出的時候並不帶email字段，這就相當於在遷移評論系統之後就跟留下評論的人失聯了，當然這也是出於用戶的隱私考量，沒什麼好詬病的，如果對訪客互動這塊比在意，建議還是盡早遷出，及時止損。缺失email字段還會導致另一個後果：大部分評論系統都是通過郵箱地址從 gavatar 來獲取用戶頭像，沒有郵箱地址，不僅和以往的訪客失聯，而且評論頁都是清一色的默認頭像，觀感上很不好。

Disqus 還有一些其它問題我沒發現，可以參照這裡

對於email字段缺失導致的這兩個問題，我現在的解決方案就是，回覆評論的同時也在 Disqus 上回覆一遍，順便附上更新評論系統的通知（希望不要被判定成 Spam ），有條件通過別的聯繫方式聯繫上的就挨個通知。至於頭像獲取，這篇具體的部署記錄有一個折衷方案可以供參考。總體的思路就是通過獲取用戶名相關字段，並提交給Multiavatar的API接口，為每個用戶生成獨特的頭像。同時還可以判斷用戶名來指定頭像，我給互換了友鏈的筆友們都設置了固定的頭像。

替代

對於靜態博客的原教旨主義者來說，評論系統這種簡直就是對“靜態”的反動。當然也有 Staticman 這種將評論系統的評論拆分成純文本的數據，提交到靜態博客的項目中，當用戶發起評論後會自動提交一個 commit，或者發起一個 Pull Request 將內容保存下來。但是這個項目目前只支持 Github 和 Gitlab 的登錄驗證，一來不符合國情，二來我也不願意過於依賴商業公司的項目。另外還有一點，Staticman 的郵件通知只支持 Mailgun 服務，這也是我不太能接受的點。說不定等到以後他能支持自建的 Git 倉庫和郵件接口我會再考慮一下。也許有可能通過兼容 Github 和 Mailgun 的接口的開源實現，但是並不太想去搞了，等到以後放棄 Github Page 再研究吧。最關鍵的一點是， Staticman 雖然號稱純靜態，但是依然需要在服務器上跑一個進程，這就和一般的評論系統沒什麼區別了。

其他的幾個項目大同小異可以參照這裡。我最後選擇了 Artalk ，沒有什麼特別的原因，純粹是我對於單一 Go 語言程序 + SQLite 這種易於維護的架構有好感而已，當然文檔詳盡也是原因之一。部署記錄放在另一篇文章里了。

總結

總之，還是再一次地要對過去留言沒有得到及時回覆的讀者道個歉，用心的留言卻沒有得到回覆這種事想想都覺得難受。這篇文章也算是評論系統遷移的一個公告，也希望曾經訪問過、留言過的讀者可以在这里留言聯繫我，更改一下郵箱地址。

reference

部署 Artalk 評論系統

Wed, 22 Jan 2025 00:00:00 +0800

前言

要說的東西都在這裡了

部署

Artalk 的📦 部署文檔說得夠詳細了，不贅述。

遷移

Artalk 的🛬 遷移文檔同樣的，很詳盡，不贅述。

小撇步

這裡著重要說的是 avatarURLBuilder 是用於頭像鏈接的，可以玩很多個性化的設置。靈感來自於這篇博文

avatarURLBuilder: (c) => {  // 自定义头像URL生成器函数
    if (c.is_admin) {
      return "管理员头像 URL";  // 如果是管理员，使用指定的管理员头像URL
    }
    return `https://cravatar.cn/avatar/${c.email_encrypted}`;  // 否则，使用加密的邮箱生成Gravatar头像URL
  }
})

https://cravatar.cn/avatar/${c.email_encrypted}这里可以换成固定链接，就可以为自己设置头像而无需从 Gravatar 获取头像。也可以通过比对nick来为特定用户比如交换了友链的笔友们指定头像。

if (c.nick == "山月") {
  return `https://uploads.disquscdn.com/images/2412160f720b88e8e7fd35fb12e799de5ad521d86b164683d3ff79a20b233d78.png`;
}

由於 Disqus 導出數據時不包含email字段，在導入 Artlak 時就默認是anonymous@example.org也就是說可以根據這個郵箱地址篩選出所有的丟失郵箱信息的用戶。但是不知道為什麼明明有email這個變量，卻無法判定，懶得去深究，直接通過獲取email_encrypted來替代，因為二者一一對應。

if (c.email_encrypted == "fc8474cbaab2d6405ad637fd26c600da949f772781d75d53f310543acda36ba2") {
  return `https://api.multiavatar.com/${c.nick}.png`;
}

這裡的fc8474cbaab2d6405ad637fd26c600da949f772781d75d53f310543acda36ba2就是anonymous@example.org對應的email_encrypted。

Multiavatar 則是一個隨機頭像生成器，免費開源，總共可生成 120 億個密碼學上獨一無二的頭像。打開 Multiavatar 網站，就會隨機生成一個頭像，如果在網址後面加上內容，就會生成固定的頭像。也有 API 可以調用，類似於這樣https://api.multiavatar.com/${c.nick}.png。但是需要注意 Multiavatar API 限制為 20 次/分鐘，有概率評論列表用戶頭像獲取不全。~~但是總比一片默認頭像好吧~~

通過 avatarURLBuilder 結合不同的變量，可以有很多玩法，大家可以發揮想象力，這裡變量列表可以參考。

reference

林路行

Mon, 30 Dec 2024 00:00:00 +0800

新语言旧语言
该怎样回答不眠的时间

上周五去参加了一个欧洲版画的展览的开幕式，展厅里有一张木口木刻肖像版画，画的是罗伯特柯霍，但是绘画风格跟其它的木口木刻版画有着微妙的差别。收藏家跟我们介绍说，在这幅版画创作的年代，摄影术已经诞生了。绘制这幅版画的画家还有个身份是摄影家，他当时借助了摄影术完成了这幅版画。但是版画家并不知道，摄影术生来就不是用来辅助版画创作的，它是来革版画的命的，那个年代的人并不知道摄影术将会给版画带来怎样的冲击。古典版画的传承者们还在用它作为一个技术手段来创作版画。那幅作品就是在这样的一种懵懂和无知的情况下，借助了那个时代的最新技术制作的一张木口木刻版画。
收藏家不无悲戚地说：“他没想到矛和盾都在他手上，这个时代一去不复返了，这是一个悲剧，虽然这是整个人类文明进程的一个喜剧，但是对于木口木刻来说，这是一个不折不扣的悲剧，它的悲剧就在于被终结了。”
诚如斯言，此时此刻恰如彼时彼刻。我就像是那个一手持矛一手持盾的人，四周环顾心下茫然。
从年初单位新配了一台40系显卡的工作站开始，我就一直在如饥似渴地学习 AI 的应用，一整年下来，开源的、商用的模型倒也用过不少，各种领域的 AI 都试过一遍了。即便如此还是觉得不够，技术正在以周为单位在更新，新的模型、新的方法层出不穷，学术一点的论文暂且不论，哪怕是底层一些的应用，稍微被别的事情打个岔，回过头再看时，之前保存的文章就已经过时了。
AI 技术的迭代之快，第一次让我对技术感到了焦虑，有一种被淹没的感觉。

崭新万物正上升幻灭如明星
我却乌云遮目

好像是2022年11月的时候，NovelAI 突然杀出来，但是那时候还像个小傻子一样，致力于抽象画的创作，手部细节的处理就更不用说了。谁知刚转过年，Stable Diffusion 就已经相当成熟了。那时候生成一张图，需要吟唱很长很长的一段“咒语”才能生成出一张还算不错的图像，所以当时被调侃成“炼丹”。到了今年年初的时候，一部分商用模型已经能够理解部分绘画风格的定义了，提示词数量也大幅压缩。再到后来，当插画师被要求交出源文件和绘画过程用以证明非AI创作的新闻传出来后不久，AI 就已经能从画面倒推线稿了。
其实对于电脑绘画的冲击，中国画一直是以一种从容不迫的姿态来面对的。以前计算机图形学还在进行NPR研究的那段时间里，就已经有很多对于模拟水墨毛笔质感的研究，大体上都是通过把毛笔的形态、湿度和力度纳入数学模型，从而达到模拟水墨画的效果。但是，可能由于研究者本身对于中国美术史理解上的偏差和审美的局限性，效果并不是很理想。那段时间里，中国画尚且还能用水墨和毛笔当护城河。
但是当 AI 技术出现后，一切都变了，现在即便是最普通的商用模型、最初级的 AI 使用者都可以在不调试提示词的情况下任意模仿出何家英的工笔画、徐蒋风格的水墨画或者是王希孟的青绿山水。当笔墨语言这条防线被攻破的时候，体制内的中国画家们不疾不徐地掏出了“意境”这最后一张牌，相关的讨论已经从技术上的可能与否转而成为了玄学上的参悟——即从一张图像能不能看出来是AI创作的，转变成了能不能从这张图像中参悟出“意境”。
事实上，很多画家已经开始使用 AIGC 图像来参加国家级展览的评选。从一开始的直接照搬，再到现在，以百分之二十左右的透明度打印在绢布或者宣纸上再进行绘制，AI 对于传统绘画的渗透远比想象的要深。对此，体制内的画家们毫不担心，并且无不轻蔑地说，我们当评委的时候也会遇到很多 AI 制作的作品，一眼就能分辨出来哪些是 AI 出的图。
虽然这些画家里有很多都是我极为尊敬的师长，艺术造诣也有目共睹，但是对于 AIGC 实在是天真到无以复加的地步。且不说 LoRA 微调这种相对进阶的技术，只要是去几大 AIGC 社区里随便逛逛就知道，一张成熟的 AIGC 图像与普通的绘画的区别，几乎和电子书和纸质书的区别一样了。与体制内画家的从容不迫相对应，体制外的画家就如同几百年前的版画家一样使用 AI 来辅助创作。
诚然，就“意境”和“表达”来说，确实目前的 AIGC 跟传统艺术还有很大差距，但这并不是技术的局限而是从事 AIGC的人的局限，从事 AIGC 的人们往往对于宏大主题和内心关照的题材并不关心，更多的是一些插画风格的绘画。这里面也暗含着更深层次的问题，即宏大主题和内心关照的题材的受众越来越少。平时在以政府为主要艺术投资人的国内传统绘画领域里，这点经常被忽视，而放在 AIGC 这个被市场和商业主导的领域里看就很明显了。
当文人画的文人群体消亡、学院画院里聚满被豢养的画家、受众群体不断萎缩，这种环境下内心的观照和意境的参悟是否具有美术史上的意义还是个问题。文明的意义在于表达，没有接收的一方，表达的最后一个环节将无法完成，这种形式表达就不复成立。
之前看过一个视频，虽然说的流行音乐，但是我觉得最后的结论对于绘画也成立：数学复杂度上的简单，是绘画在 AI 时代被迅速攻破的理论上的原因。同样，视频里的另一个观点我也很认同，在面向公众时，当下的绘画更像是一种附属品，绘画对于大部分人不再是重要。天天被讨论中国画乃至绘画本身是否穷途末路并不可怕，可怕的是，不管好坏都无人问津、无人讨论，到处洋溢着小圈子的自我满足，这才是幕布真正落下的时刻。

发动新世界的前进的泡影

跟师友们提起 AI 绘画的时候，一般有这几种意见：一种是掏出一张经典之作，问我AI能画出这个来吗？另一种则是退到个人消遣的领域，并不在意其它；还有一种则是提醒我，AI 作为一个黑盒子，不能和以往知晓其运作机制的工具相提并论，它并不是一般意义上人类手臂的延伸。
我这边也说一说我这一年来对于 AI 绘画的理解吧。我认为，AI 确实能模仿各种绘画风格甚至各种画种，工笔也好、水墨也好、油画也好、赛璐珞也好，调校得当的话，甚至可以以假乱真，但是 AI 只能根据已有的绘画风格进行创作。尽管最近有风格融合的尝试，不过似乎并不成熟。一言以蔽之，目前看来 AI 并不能产生新的绘画样式，一切的图像产出都是基于模仿已有的绘画样式。AI 能替代的只是机械的图像生产者，并不能代替人们创造新的绘画样式。
对我们传统绘画的研习者来说，也许需要重新回到笔墨语言本身、从自我表达出发，去探索新的绘画样式。“外师造化，中得心源”恐怕是唯一的出路。至于绘画样式是否已经被穷尽，这点其实并不重要，现在的我们也只能相信，以压倒一切的偏见和执念去绘画。更何况，我们这行当的大多数人还是以专业、学者乃至艺术家自居的，假如连这点觉悟都没有的话，那除了自娱，也就再没有提起画笔的需要了。

Jekyll 更改 RSS 模版文件以验证 follow 阅读器

Mon, 09 Dec 2024 00:00:00 +0800

前言

最近在 Patrick 的邀请下尝试了一下 follow 阅读器，除了浓浓的 Web3 气息外，其它各方面都算得上相当优秀的产品。阅读器还支持验证订阅源的所有权，不过需要在 RSS 输出上进行操作，这里就写一篇粗浅的教程。

所有权验证

follow 阅读器验证博客的所有权是需要在 RSS 源里额外增加用于验证的<follow_challenge>标签，这个标签里包含<feedId><userId>两个元素。

Jekyll 可以通过更改 RSS 模版文件来实现。Jekyll 的 RSS 模版文件一般在根目录，文件名是feed.xml。我这边是在<description>和<link>之间添加了<follow_challenge>标签。修改完成之后的代码如下：

  <description>以瓠為樽而浮乎江湖 — Dylan Wu 的個人博客</description>
    <follow_challenge>
      <feedId>*****************</feedId>
      <userId>*****************</userId>
    </follow_challenge>
  <link>https://blog.dylanwu.space/</link>

修改完成后生成并更新网站，就可以在 follow 阅读器里右击自己的订阅选择验证。其它一些类似的静态博客生成器应该也可以这样操作。

写在最后

好久没有翻博客的评论了，今天一看，在之前一篇简述 RSS 协议的文章里有很多评论还是在列举 RSS 协议的“缺点”，我觉得应该是我那篇文章写得不够清楚，因为当时想得也不够清晰。

但是在使用 follow 阅读器后，我的看法越来越明晰了——RSS 协议作为一个文本输出的接口本身并没有什么问题，问题是围绕这个接口的实现极度匮乏。而 follow 阅读器可以说极大弥补了这种匮乏。

注意，这里说的“匮乏”并不是协议本身功能上的问题，而是围绕这个协议的开发实现的匮乏。打算后面有空再写一篇关于 RSS 协议的文章，这里先把观点摆出来。

利用脚本抓取 RSS 并用票据机打印

Thu, 31 Oct 2024 00:00:00 +0800

前言

记得之前咕咕机很火的时候，因为囊中羞涩，从咸鱼上淘了不少二手票据机当作平替。一开始还要折腾各种驱动什么的，不过后来才知道，只要买到的是支持 POS 协议的票据机，就可以在 Linux 系统下可以通过命令行直接向票据打印机发送文本并打印，也可以通过 POS 指令控制打印的格式，非常方便且不需要安装任何驱动。

需求

正好平时经常需要关注一些网站的更新，这些网站的更新频率不高，但是错过之后会很麻烦，按照四象限法则来归类的话，这些都属于重要但不紧急的信息，比如考试报名、展览征集资讯这种。就我个人的经验而言，这类信息和平时普通的订阅混在一起的话会常常会被忽略掉，我经常希望以一种对现实生活介入性更高的推送方式，来推送这些重要但是不紧急而且容易被遗忘的信息。于是就有了用票据机来打印这类信息的想法。

网上也有很多相同思路的项目比如这篇文章就实现了定时抓取 Github Issues 并打印为工单的功能。

为什么选择 Shell 而不是 python

我一开始也用 python 写过一版，需要配置运行环境不说，有的时候还要引入 python-escpos 库。~~当然也可以选择不引用~~因此后来就想着使用 Shell 去完成这种相对简单的任务，选择 Shell 还有个好处就是即便在 NAS 上也可以相对轻松地配置。

信息抓取

再来说说信息抓取这块，众所周知，国内大部分官方信息发布网站不提供 RSS 功能，这时候比较流行的办法就是使用 RSSHub 编写规则抓取并生成 RSS 地址。但是考虑到 RSSHub 需要部署，对于“抓取并推送”这种相对简单的需求来说，还是过于重了，而且还涉及到远端访问，会变得很麻烦。虽然也可以本地搭建 RSSHub 但是在我看来这么做违背了 RSSHub 项目的初衷。因此我另外写了一个不需要 RSS 源的脚本，只需要提供标题和正文的CSS Path就行。

XML/HTML 解析

其实在解析 HTML 的时候，需要额外引入 xmllint 来解析，xmllint 是包含在 libxml2 里的命令行工具，考虑到不是所有的 Linux 发行版都能很方便地安装各种包例如群晖，因此请教了 AI 并换成了一个叫做 htmlq 的项目，只需要在脚本里调用这个二进制程序就可以解析 HTML 代码。当然，如果你使用的是一个正常的 Linux 发行版，无论是出于安全性还是便利性的考虑，建议还是调用 xmllint 来解析。

说到字符串，自然绕不开编码的问题，编码对不上的话热敏票据机输出的就是一堆乱码。因此需要调用 iconv 转换编码。这个命令行工具更为常见，即便是群晖也可以通过 SynoCommunity 里的 SynoCli File Tools 包来安装，记得选择合适的架构。

配置及使用

先从代码库拉取代码。直接下载还是git clone都可以。~~几个小脚本就不用较真了吧~~

配置部分很简单，假设你需要监视 RSS 地址，则使用escpos-rss.sh，将escpos-rss.sh中的初始变量替换为你实际需要的值:

RSS_URL="https://www.appinn.com/feed/"  # 替换为你的RSS源地址
LAST_CHECK_FILE="/volume2/Material/last_check.txt"  # 用于存储上次检查的时间戳
PRINTER_DEVICE="/dev/usb/lp0"  # 热敏打印机设备路径

修改完赋予运行权限然后写个计划任务定时运行就好了。

如果需要监视的网站没有 RSS 的话，就需要下载escpos-web.sh和htmlq，escpos-web.sh里需要修改的变量则是：

URL="https://www.appinn.com/feed/"  # 替换为你的RSS源地址
LAST_CHECK_FILE="/volume2/Material/last_check.txt"  # 用于存储上次检查的时间戳
PRINTER_DEVICE="/dev/usb/lp0"  # 热敏打印机设备路径

另外还需要修改第26行、第27行还有第49行的CSS Path以及需要截取的信息的位置，我代码库里就直接以实际的例子为示范了。修改完记得两个文件都赋予运行权限然后写个计划任务定时运行就好了。

AI 书写代码

以上的 Shell 代码其实 80% 都是由 ChatGPT 完成的，包括整体的框架、Esc 指令的书写还有遇到死胡同时替代方案的选择。这块没啥好说的，网上的教程有不少，我也是在摸索之中，这里说一些自己的心得。

AI 书写代码其实具体来说是一个将自然语言翻译为具体编程语言的过程，并不是说随便说一个需求 AI 就可以给出一个方案。比较理想的方案是自己先对如何实现有个大致的概念，让 AI 给出一个大致的框架；再拆解流程，对各个流程进行验证、完善，通过对话不停修正；最后形成一个完整的程序。其中比较让人省心的一块是类似于正则式书写、Esc 指令书写这一类，都是 AI 擅长的环节。

这段时间很少更新博客，是因为大部分时间用来使用和学习 AI 上面了，有一些关于 AI 的思考，等想明白之后另写一篇。~~又给自己挖了一个坑~~

moe-counter-cf 安装手记

Mon, 04 Dec 2023 00:00:00 +0800

前言

目前我能找到的教程基本上都是照搬官方文档那几行少得可怜的部署方法，并不是非常明确，第一次接触 Cloudflare Worker 项目部署的人未必能成功。所幸在吕楪推荐了一篇比较全面的安装指南，配置文件这块可以参考一下。关于获取 KV 的 preview_ids 可以参考这里。

一些小问题

虽然上面提到的文章很全面，但是由于 Cloudflare Workers 的命令行部署工具 Wrangler-CLI 的迭代更新，在实际部署这一块还是有些小问题需要注意。

首先，并不建议将项目 fork 之后在自己的仓库里修改，我在 GitHub 上搜索的时候经常会看到有人把自己的参数公开，会有一些隐患。建议还是将项目拖到本地之后修改参数、编译发布。

另外在文章里提到的npm i @cloudflare/wrangler -g之前，还需要再跑一句pnpm install来安装依赖，这些依赖里还包括了 wrangler 的旧版本。

运行项目内指定版本的 wrangler

截至目前 wrangler 的版本是3.17.1，与项目内自带的1.19.12已经有了很大区别，如果强行用新版本编译发布的话就会出现各种报错。所以我们需要使用npx wrangler publish这行命令来进行部署。至于登录验证这块，笔者没有实际试验过，理论上讲，只要将命令替换为npx wrangler login就可以了。各位读者可以尝试一下，将结果留言在评论区。

其它

各种moe-counter-cf的实现，我附在最后面大家都可以试试。

Soapbox-fe 安装手记

Mon, 10 Oct 2022 00:00:00 +0800

前言

目前我能找到的安装指南都是基于 Rebased（Soapbox-be）+ Soapbox-fe 去部署的，而且都是通过源码 Source 部署，比较麻烦不说，Rebased 这个分支往后的开发能不能跟进也是一个问题。还有一些教程需要通过 nginx 新增一个虚拟主机去托管前端，依然比较麻烦，还不如托管到 Vercel 上。看起来 OTP 部署这块鲜有人提到，想通过 Admin-fe （Pleroma 的后台管理界面）里 Fontend 配置项进行安装就有些无从下手了。正好趁着这段时间更换域名、重建实例的时候，琢磨了一个可以通过 Admin-fe 来配置前端的方法。

目前因为 Admin-fe 还有一个无法下载前端的 Bug 所以还是要跑一下命令行，等到这个 Bug 修复之后，我再来补全文章，到时候可以直接在后台界面里安装前端。

步骤

首先是安装前端，进入命令行之后切到 Pleroma 的文件夹，如果按照官方 OTP 安装教程的话，路径应该是/opt/pleroma，然后运行

su pleroma -s $SHELL -lc "./bin/pleroma_ctl frontend install soapbox-fe --ref dev --build-url https://gitlab.com/soapbox-pub/soapbox/-/jobs/artifacts/develop/download?job=build-production"

具体参数解释，请参考官方文档。

这里需要注意的是--ref参数，这里是标记同一个前端的不同版本，让开发人员能够便利地更新前端代码，这个参数决定着前端文件的存储位置，按照${instance_static}/frontends/${name}/${ref}这个路径存储。比如上面这个命令里，Soapbox-fe 将会存储在${instance_static}/frontends/soapbpx-fe/dev这个文件夹里。运行命令时，就算不需要区分版本也一定要有这个参数，不然不会进行下载且不会报错，需要注意。~~不报错这个真的很值得吐槽~~

然后进入 Admin-fe 后台，Settings-Frontend-Primary，然后name填soapbox-fe、Reference填dev，提交完，重新打开实例网站就可以看到已经切换成功了。

其它

另外几个 Pleroma 官方提到的 Frontends 安装方式应该跟上面提到的差不多，有的看上去也很不错，不过开发进度堪忧就是了。另外，Primary 下面还有个 Available 块，有兴趣的朋友可以配置试试看。

参考

俳句练习其一

Sun, 29 May 2022 00:00:00 +0800

あの祭り打ち上げ花火

二人とも人混み避ける山雀やたり

关于 RSS 协议的一些迷思

Tue, 30 Nov 2021 00:00:00 +0800

近期在 Mastodon 上看到有人感叹用 notion 搭博客的人越来越多了，以其不支持 RSS 协议为一大憾事，原文链接下面引来了不少人的讨论，有人认为就是因为 RSS 协议没落，所以现在大家又都转向 Newsletter 订阅了，RSS 的反对者认为 RSS 协议有自身的局限性，需要更新换代，Mastodon 正应该是其演化的方向。而 RSS 的支持者觉得 RSS 的重要性不为人知，但是怎么个重要法，又讲不清楚，最后沦为了“RSS 协议就是好就是好”、“破坏开放”这种口号式的语言；又或者拿出“不便利正是我们所追求的”这种精神胜利法，很难说服别人。

其中比较能引起我注意的是@maylie@alive.bar的观点，嘟文中列举了一大堆 RSS 协议的缺点，有兴趣的可以点进去看一看。无意冒犯，这里面有很多观点其实都“古已有之”，跟我在十年前看到的一篇很有名的反 RSS 文章的观点类似，里面很多观点在相当长一段时间里成为了互联网迷思。当然我也参与了讨论，后来我把自己的嘟文整理了一下，发现这事情不是三言两语能够说清楚的，先就这样吧，也算是抛砖引玉了。限于篇幅，本文无意于彻底破除这些迷思，只是简单扼要地论述一下，随着时代的发展，在现在的网络环境下，这些观点的不合理之处。

先说说我是怎么用 RSS 协议的：我会把自己需求度比较高的信息公开网站、互相交换过友情链接的博客用 RSS Bot （Telegram 和 Matrix 上都有）做成推送，另一些不紧急的放到 Feedly 里订阅，保证跨平台同步阅读进度。有些别人也用得到的信息源我就做成 Pleroma 上的机器人账号分享给大家。值得一提的是，在实现这些功能的过程中，我发现绝大部分这些 Bot 功能的实现都依赖 RSS ，从联邦宇宙实例这个角度来说，RSS 可以理解为一个相当底层的 API 而不仅仅是一个输出纯文本的协议。从我个人的角度来说 RSS 存在的意义重大，不仅不是不便利的，而是信息整理分级的工具链中最重要也是最基础的一环。

反对 RSS 协议的观点角度有很多，一言以蔽之，就是认为 RSS 有利于读者但是并不利于作者，但这点实在是有待商榷。首先，在现阶段的应用场景来看，RSS 唯一不友好的只有商业，这里的商业，可以是指大公司们的 Walled Garden 也可以指试图通过博客盈利的作者。Walled Garden 自不必说，这是要强烈捍卫的利益所在，但是就算流行如 Twitter 也还是开放了 Developer API，可以理解为需要审核的、可控的 RSS 协议。由此可见，数据流动产生的活力有多么吸引人。对于想通过博客盈利的作者来说，的确有部分广告营收缺失，但是还是可以通过控制 RSS 输出部分文章来引导读者进入页面，甚至也有直接将部分广告放入 RSS 流中的做法，两两相抵，其实差别并不会特别显著。况且在现今这个环境下，个人博客想靠广告盈利，还是很困难的。从控制信息流动的角度来看，不提供 RSS 等于放弃了信息流动所带来的活力，从而换取对自身所产出的信息的绝对控制权。这对平台来说自然是一件美事：它本身坐拥大量用户，信息流动完全可以实现内循环，严格控制信息流动的出口利大于弊；但是对于博客这种单一用户产出的网站来说，并不是什么好事情。

从分析流量的角度来讲，使用过跟踪代码后台的人应该都能明白，跟踪代码主要还是为了营销服务的，对于一般的博客作者而言，除了查看浏览人数几乎没有什么用处。更何况，大部分博客作者既没有意愿也没有能力根据用户分布和喜好来调节自己的内容。另外，现在的一些 RSS 阅读器自带显示全文的功能，对于只显示摘要的 RSS 会自动在本地发起请求获取权全文，也不存在降低访问量的事情。再加上早在本世纪初的时候就有用图片来统计 RSS 访问量，WordPress 也有统计分析 RSS 订阅量的插件，再不济自己写一个重定向也是能够统计的。

从会让读者忽视网站设计这块来讲，我只能说，对设计不敏感的，就算发邀请函他也不会关注；对设计敏感的，就重重设限他也要看。

在十几年前爬虫框架还不是很多、编写爬虫成本还很高的时候，有人指责 RSS 协议会给盗文、盗站者以便利，但是现在，这个观点已经不再成立了。

在现在的博客作者中，还有一种观点很流行：博客与博客之间是一个一个孤岛，自己在别人博客的评论，不知道什么时候就会随着各种意外而丢失，评论回复的通知也不及时，由此得出结论，RSS 协议不完美，需要发展。其实，割裂的互动并不是 RSS 的缺点，硬要说的话也是评论系统的缺点，解决方案也是早已有之，Disqus 这类第三方评论就是试图统一每个博客割裂的评论和互动。况且现在也有把评论系统与 ActivityPub 协议结合的实现。至于 RSS ，它只是一个输出网文变动、控制信息流动的 API，这么理解可能会比较清晰。

RSS 发展到今天其实已经可以理解为一个极简功能、无需授权审核的 API 接口，以“人人为我、我为人人”为原则，可以在基于 Matrix、ActivityPub 这些协议的开放平台上实现各种扩展功能，比如推送通知。当然，也可以选择不开放这个接口，这是个人的自由，别人也无权说三道四，但是这些作者就要做好自己产出的信息被互联网海量信息以及推送埋没的心理准备，或者拥有自己的博文足够引人注目到别人为之生成 RSS 的自信。

花火下的恋情

Tue, 25 Aug 2020 00:00:00 +0800

花火、煙花，這兩個指向了同一事物的詞，一個將目光聚焦在那個閃耀的瞬間，另一個則是暗示了有花火就有煙雲，把繁花散盡後的煙霧繚繞都歸了進去。

之前在日本，在女友的精心安排和準備下，我和女友幸運的趕上了一場花火大會。當時我們在大阪，花火大會在隔壁堺市。晚飯過後，我們就從大阪出發，從天王寺站乘阪和線出發，在三國丘站換乘南海高野線坐到栂、美木多站，出了站我們就不知道怎麼走了，最後還是借助出租車才勉強趕上。

花火大會本身平平無奇——火球從遠處的地平線上竄到空中，散成精巧的各色形狀，最後留下了一團煙雲。由於間隔的時間沒有把握好，這團煙氣在下一朵花火綻放的同時被照得慘白。「無非是在日本隨處可見的群體活動罷了」，我在心裡這麼嘆道。

回去的路程也相當艱難，出口人太多，根本叫不上出租車，只能跟著人流往公交車站的方向走。

路上，一對高中生模樣的情侶引起了我的注意，他們四周散发著戀愛的氣息，無需什麼親密的舉動，也不用任何動聽的話語，就向周圍人宣示了他們的關係。男生什麼模樣我已經記不清了，女生穿著紅葉裝點的白底浴衣，腰帶扎得整整齊齊，在身後小心翼翼地打成一個蝴蝶結。女生頷首低眉，羞答答的。原來女生真的會害羞成這樣，我之前從沒見過。明明什麼都沒有說，但是比說什麼都要楚楚可人，就像是從輕小說和漫畫里走出來的一樣。

女友扯了扯我的袖子，向那邊努了努嘴，我也用眼神回應了她。班車到了之後他們就坐在了我們前面，剛剛燃盡的花火徬佛在他們四周再度綻放，化作了他們身邊滿天的繁星。

汽車開動，我開始想象他們的戀情，他們是如何相遇的呢？他們興許是同一個社團的，又或許從匆匆一瞥開始相識，當然也不排除是聯誼會上認識的。他們或許性格互補，又或者興趣相投？也許是男生追求的女生，也許是他們同時喜歡上了對方，又或許女生背地裡喜歡上了男生，然後女生的心意傳達到了男生，男生也盡了告白的義務。

總之，不管怎麼樣，他們以最真實的情感對待彼此，用最拙劣的技巧去經營感情，一切都恰到好處，宛如天成。就像是兩組精美複雜的齒輪，不停的旋轉、不停的靠近，伴隨著一絲顫動，最後無聲無息地緊緊咬合在一起，沒有磨損也沒有卡頓。在這夏日將盡之時，兩顆孤獨的心最終尋到了彼此，两人命運的紅線從此交織在了一起。

後來怎麼回到住處我已經全然忘記了，我只記得半路上我問女友，你現在還喜歡我嗎？「沒有之前那麼喜歡了」，她說，「大概就是像親人一樣吧」。我知道，這個夏夜短暫的魅力已經杳然无踪了。

當然，現在的我已經知道，這份怠慢既是我的過錯也是她的過錯，但是終歸還是我錯在先的吧。

瓠樽

靜態博客的『阿喀琉斯之踵』

問題

替代

總結

reference

部署 Artalk 評論系統

前言

部署

遷移

小撇步

reference

林路行

新语言 旧语言该怎样回答 不眠的时间

崭新万物 正上升幻灭如明星我却乌云遮目

发动新世界的前进的泡影

Jekyll 更改 RSS 模版文件以验证 follow 阅读器

前言

所有权验证

写在最后

利用脚本抓取 RSS 并用票据机打印

前言

需求

为什么选择 Shell 而不是 python

信息抓取

XML/HTML 解析

配置及使用

AI 书写代码

moe-counter-cf 安装手记

前言

一些小问题

运行项目内指定版本的 wrangler

其它

Soapbox-fe 安装手记

前言

步骤

其它

参考

俳句练习其一

关于 RSS 协议的一些迷思

花火下的恋情

新语言旧语言
该怎样回答不眠的时间

崭新万物正上升幻灭如明星
我却乌云遮目