1
0
Fork 0
blog/content/posts/百草园/DGP:重新出发.md

38 KiB
Raw Blame History

title date slug featuredImage categories tags series summary description wikilinks lastmod
DGP重新出发 2025-04-24 restart https://img.viento.cc/cover/restart-cover.webp
百草园
博客
开源
Codeberg
Netlify
GitHub
我们总要有重新出发的勇气 本文是作者对博客近期技术和理念上的大修进行的详细记录与反思核心围绕提升隐私保护、去中心化以及对自由开放的追求。首先由于对隐私和身份解耦的需求作者注销了网站备案减少与国内服务的绑定并对内容进行了身份模糊处理。虽然这带来了表达和身份认同的双重限制但作者更希望以内容和观点被记住。技术层面图床迁移至Cloudflare R2博客源码不再托管于GitHub而是转向更注重自由和非营利精神的Codeberg并尝试自建Forgejo实例同时为Codeberg社区捐款支持。作者对GitHub及其母公司微软的批评集中在平台闭源、AI训练争议、社区治理及对中国大陆用户的可用性问题认为其垄断和盈利动机已背离开源精神。部署方面作者探索了Vercel CLI、Netlify CLI等多种与Codeberg结合的持续部署方案最终实现博客与GitHub“断绝关系”实现更纯粹的自由部署。评论系统也从Twikoo迁移到Artalk提升了自定义和管理自由度。在整个迁移和重构过程中作者强调了对FOSS自由开源软件和开放共享理念的信仰以及在现实与理想之间的权衡承认完全割舍主流平台在实际操作中有其局限但仍愿意为自由和自我表达的空间持续努力。文章最后作者以温暖的语气邀请读者来到博客表达了对精神自由和自我重建的向往呼吁保持勇气不断从头开始。 true 2025-04-24

各位老友们,晚上好。这里是 Chlorine。

许久不见不知各位老友过得如何呢OωO

本期是一篇有点长的碎碎念,大概就是记录一下,小氯最近对园子进行的一些大修。

前言

这一切的一切,要从一个无风的下午说起。一次偶然的阅读,带来了一次思想的雪崩……

好了好了,说人话。其实就是小氯读了一些关于密码学和隐私保护的材料之后,觉得很有必要加固一下自己的隐私保护,同时逐渐将真实身份和互联网的人设解耦合,以减少被人开盒的风险,这样也能使得小氯在写文章的时候能够更加自如地表达自己的观点。那么作为小氯的精神家园,园子显然是要大大优化一番的。

当时深陷期中寄的小氯显然没有精力去做这些事,但小氯的期中季已经结束力(喜)。

不过吸取理想乡构筑手记的教训,小氯决定把所有事情都包在这一篇文章中讲完。于是有了这篇有点长的碎碎念。不过,可能是因为太久没来写文章了,小氯感觉写得有点费力。就像如果你太久不说话,说起话来就会很费力一样。

至于为什么叫 DGPData generating process数据生成过程。也就是统计学的创世纪。

名字与身份

小氯最终还是换掉了这个占位符(乐)。

Garden of Outlier没有中文名字。您也可以和小氯一样叫它「园子」。为了保留这个用惯了的昵称小氯也是稍稍费了点脑力的。

关于新名字的含义小氯应该不必多解释了。Outlier一个统计学名词字面意为「离群值」通常指高于第三四分位数一倍半四分位数极差的数据。

此外,为了避免被(过于容易地)爆破掉,小氯对园子的内容做了大量的修正,隐去和模糊了自己的真实身份相关的内容。当然,已经知道一些信息的老友,那也就是知道了。小氯也只能拜托您……请只让自己知道好吗?或者干脆忘掉,就把小氯当成不知道从哪个广口瓶里飘出来的元素娘,可以吗(可怜)。

这件事本身倒没有费掉多大的精力,只是小氯一直在想一件事:我通过这种方式规避了一些被开盒的风险,但这也意味着,我剥夺了自己谈论背景的能力。我再也不能提起我深爱的母校的名字,再也不能自然地提起我熟悉的地点名称,再也不能光明正大地为我的学士服与博士帽而骄傲。

这到底是更自由了,还是更不自由了?

我不知道。不过小氯可以肯定一点:我希望别人提起我的时候,第一个说的不是「那个 XX 大学的 XXX」而是「那个文章写得蛮有意思的小氯」。如果只能靠自己的学历宣称来留住老友们的脚步那小氯这个园子建得就太失败了。

再见备案

在拥有备案的时间内,小氯没有做任何违法乱纪的事情(那是自然),小氯本身呢,也对备案制度没有任何看法。注销单纯是因为:如无必要,勿增实体。既然这个「合规性证明」对我已经用处不大,小氯也不想着继续为面向大陆的访问而苦恼了,那么为什么我还要留着它呢。

大概也就是这样了。从此以后如果没有意外小氯再也不会想着去备案了对于国内访问的优化也会从「极力优化」调整到「维持基本功能」。Vercel 和 Netlify 这些大善人一时半会应该也还不至于彻底失联,如果出现问题,咱也还有一大堆冷备份呢。

如果真的有一天政策继续收紧……好吧,那就麻烦各位老友来园子的时候,将自己的小猫咪带来吧。

图床更换

由于打算换到国外的服务了,理想乡构筑手记3HelloNieve 自然也得换一下服务栈。正好小氯很久以前就看牢拍这个半死不活的 S3 API 不爽了,干脆全切到 Cloudflare R2 了。拜拜了您嘞。

rclone sync upyun:bucket ~/blogimg
# DGP重新出发
rclone sync ~/blogimg r2:bucket

然后做一次链接全量替换,完美。

开源与 Codeberg

小氯在大概今年 2 月把博客开源了。这种做法当然可以说是增加了一种技术化的交流渠道,但更多还是一种姿态或者说是象征意义,一种对开源、共享的支持,以及对透明度的宣誓——你正在访问的小岛,将自己的地图拓印在了世界上的所有地方。这里没有什么暗桩和陷阱,哪怕一个。

对于小氯来说,这或许还有一个作用:分发和存档。如果您喜欢小氯写的东西,而又碰巧是一个文本化、本地化的爱好者,那么只需要打一个压缩包,就可以获得小氯全部的文章随意把玩(当然,图片还在图床里面,所以暂时没办法实现 100% 的 Archive as a Website

不过,由于最近园子的大修,小氯把园子暂时闭源了。说得好听一点的原因是:频繁的推送会影响平台的显示,污染提交记录,实际上大概是因为 Git commit 的历史性,容易被人顺着历史记录反查过去,这就白清洗了。

正好,小氯也想趁此机会换一下自己博客的源码托管平台,不再使用 GitHub 了。

吐槽几句 GitHub

老实说呢GitHub 并没有给小氯带来什么直接的实质性损害。就小氯写的那些代码,双手送给 Copilot 人家都不一定吃。所以,下面的论述更多地是从一个「局外人」的视角来说的。

按照「批判性思维」的要求,我们似乎应该先夸几句 GitHub。这么说吧在大部分时候的大部分人眼中「GitHub」几乎就是「Git Forge 平台」的代名词,历史上为开源世界的发展立下了赫赫战功,其现今的开发者数目、关键项目数目、社区规模、生态整合可以吊打剩下所有平台的总和。「天下 Git Forge 共一石GitHub 独得八斗」,很可能是写实的,虽然小氯也没调查过。

好的,夸完了。开喷。

首先估计就是从 Gogs 诞生之前一直被提到现在的GitHub 自己是不开源的。一个托管了宇宙中大半开源项目的平台自己是闭源的这听起来颇有点黑色幽默。然后大概就不得不提到GitHub 的谜之操作——GitHub Copilot 了。当初为了这件事,社区里可是闹得沸沸扬扬的。

各位老友大概也对牢软拿用户代码训练 AI 这件事不陌生,不用知道很全面的细节,这对我们的讨论帮助不大。最大的面对疾风的问题显然是:使用开源代码训练盈利性 AI 是否违反开源协议。社区的说法大概是你使用我们的代码去训练模型结果不给我们分红、没有我们的署名也不公开训练细节这显然是违反开源协议的而微软则辩解称AI 训练属于统计学习,不属于复制、修改、分发等开源协议涉及行为的范畴,而且 AI 并没有直接把原作者的代码拿过来粘贴,这只能算是 Fair Use。1

不难看出,此处最重要的问题在于:用代码训练 AI 属不属于开源协议的管辖范畴。如果是,那么拿着协议的条款去卡;如果否,那么找其他标准。不过,这其实是个强人所难的问题,因为在开源协议大业草创的时候,生成式人工智能还只是科幻小说中的概念,就像你希望拿着《十二铜表法》去裁决罗诉韦德案一样。而开源协议之外的各国法律,也没有对于「模型训练」这种行为做出什么广泛认可的规定,这使得从法律上判断这件事困难重重,当然也给了律师们很大的发挥空间。

既然法律难以给出答复,我们就只好去找点别的东西了。众所周知,(理论中的)法律,实际对应于「正义」的概念。正义,是附有义务和要求的道德,那么我们就去看看一般的道德吧。2或者我们可以换个工具(希望这不是偷换概念或者偷换语境),我们从我们最纯粹的「自然道德观」去想一想这件事。

抛开繁文缛节的文字游戏不谈,从直觉上来说,拿代码训练 AI 属于「使用」(此处说的是自然语言的使用,不是法律概念的使用)吗?这是自然,而且是有明显下游产品的使用。

那么既然如此,被使用物品的主人,就应当持有一定的权利。比如说,既然是使用,或者至少是借鉴学习,那么你有没有尊重原作者署名权的义务?打个比方,你模仿一位画师的作品画了一些画(甚至拿它们去交稿),你有没有至少是提一句「模仿了 XX 老师的风格」的义务?再比如,如果主人没有明确说明「你可以直接拿去做 XXX」你在用之前是不是应该告知物品的主人我希望使用你的什么物品来做什么怎么做如果主人不希望你使用 TA 的物品你能强行拿来用吗……这么看GitHub 的做法或许是不违法的,但显然是不道德——不符合自然直觉的。

当然「道德」「直觉」这种概念本身是模糊的直接拿它们去断案估计行不通。但如果某个判决本身是违反不论哪种至少是社会广泛认可的道德的那只能说明法律本身有漏洞被某些擅长摇唇鼓舌的人钻了空子。此外AI 开发助手这种东西本身还是挺有用的,虽然说不能指望它产出多么高质量的代码,但是产出「能用」的代码,加快项目的开发,以及辅助学习,这还是游刃有余的。所以,一刀切地要求牢软别训练了也不符合最大效用原则。

那怎么办?小氯大概想了三种解决方案,依次退步:

  • 开放 AI 模型的权重(相当于模型的开源),但是提供付费的 Copilot 服务——这很合理,运行 AI 模型是要钱的。
  • 将 AI 模型的收益拿出足够的部分(到底多少算足够,这是另一个问题了),作为开发者的分红,或者用于促进开源社区建设。
  • 明确说明训练的数据集,尊重开发者的署名权和退出权。

当然指望牢软这么做属实有点鸭子睁眼——Duck 不必(闭)了。估计凭借牢软高超的法务能力,在这场诉讼中不会吃什么亏,但 GitHub 开发者们的信任估计又要消耗一层咯。

此处插一句话:小氯想过使用一种特殊的许可证,我们姑且叫它 AGPLv3 with AI restrictions 吧:

基本与 AGPLv3 一致,但是要求:所有希望使用本仓库代码训练的人工智能模型,必须开放权重,但教育和非商业研究目的除外。

不过这并不是标准的开源许可证。想让小氯和 OSI 搭上线去问问能不能收编这个许可证,还是有亿点啸难度的。


AI 的问题讲完了,再说说一些和 GitHub 的牢东家微软相关的其他问题。

微软的性质大概可以用一句话来概括:美国的科技巨头。你指望它去全心全意地支持开源事业,大概的确有一点痴心妄想了。毕竟微软要是搞开源去了,你让先锋领航、贝莱德和道富的老总们吃什么?此外,既然是牢美的公司,那自然也得接受牢美的管辖。牢美对于开放技术、数据人权之类话题的做法,不用我说大家也清楚(Snowden孩子们这是真的)。加上最近恩情无限的川大统领的一系列抽象操作,牢美这块洞天福地,不能说 Debuff 叠满了吧,至少也不是什么优质的选择。

就算不考虑意识形态的问题可达性和可用性也是一件令人扶额叹息的头疼事。举一个最典型的例子吧GitHub 在境内的可访问状态本就处于一种奇妙的叠加态,学会访问 GitHub 可谓是每一个初入开源世界的小可爱的必修课。现在的情况似乎还更糟了——根据 HPCesia 老友提供的信息(见此处),前几天 GitHub 似乎还开始主动屏蔽国内 IP 的访问了。小氯没遇到这件事因此没获得第一手资料。不过根据社区提供的图片中「Restricted」的描述和 403 的状态码,这应该是 GitHub 官方的锅,不然一般只会显示 Timeout 或者 Reset或者直接悄悄地弄坏你的 DNS那自然也不会有 403 了)。

嗯……GitHub 的具体动机我们不得而知,但不论从哪个方面说,这可都不是什么积极的信号。这次是暂时屏蔽了未登录用户,下次是不是就是持续屏蔽了?那接下来会不会就是登录用户了呢?再下次会不会就开始大规模关停账户了(比如,使用邮箱作为某种判定条件)呢——当然,这目前还只是带点滑坡谬误味道的假设。不过如果有一天这真的发生了,也别吃惊:牢软又不是没耍过类似的把戏。跨国公司可不是什么超国家的中立实体,俄乌冲突期间不就类似这样嘛(这甚至成了小氯的一篇论文的主题)。

此外还有一些其他的为人所诟病之处,比如社区治理问题、项目质量等。这里我们不多说了,小氯只想提一点自己的想法。

GitHub 的全部缺点,大概就可以概括为两点:它太大了,背后的人又太贪婪了。它足够大,大到几乎垄断了整个市场——初等的经济学知识告诉我们,在许多场景下,垄断都不是什么好事情。因为它太大了,所以它可以毫无顾忌地不听社区的意见,甚至是毫无顾忌地突破道德底线——反正大不了就是气哭几个理想主义者罢了,你不用有的是人用。而它甚至不可能倒下,因为这意味着大半个现有开源生态的崩塌,「大而不倒」莫过于此。而它背后的无限逐利性,给了这种作恶的能力以应用的动机。说得耸人听闻一点,这是一柄悬在世界头顶的达摩克利斯电锯——它不是剑,不会一次劈下来就完事。不启动则已,只要启动,它就会一点点锯断开源精神的头颅。

最后,一点个人原因:小氯很不喜欢章鱼猫这个 logo。

Codeberg

OK吐槽完毕。上面的话可以概括成一句

这 GitHub 小氯是一点也呆不下去了。

那么既然 GitHub 没资格作为主仓库了,去哪里好呢?

答案呼之欲出Codeberg 老爹FOSSer 们的准理想国。如果您不清楚 Codeberg 是什么,可以去看小氯之前介绍 Forgejo 的HelloForgejo

小氯闲着没事曾经做过一个两个平台的对比,结果差点给我看乐了。很难不怀疑我们的日耳曼朋友就是逮着牢软的缺点一顿针对。

对比方面 GitHub Codeberg
运营者 微软(商业巨头) Codeberg e.V. (非营利组织)
法律归属 美国 欧洲(德国)
数据存储 全球各地 只在德国本地
数据人权 你懂的 GDPR
项目类型 各种各样 严格 FOSS
商业化情况 本身由商业实体运营 完全由社区支持
付费功能 多样
AI 训练 使用代码训练 AI 明确承诺不使用代码训练 AI当然它也没这个实力
社区治理 核心团队主导 高度民主化
复杂程度 较为复杂(个人感觉) 极简化,功能全面

浓缩成一句话:信仰纯粹 + 功能全面。我们拎一个对照过来吧:SourceHut。确实很纯净,原汁原味的原教旨 Git 体验。但缺点也很明显:太难用了。想在网页新建一个 Issue回去学 git send-mail 去。代码概览Linguist热力图这些功能想都别想。对于原教旨的 Unixer 来说估计是单厨狂喜剩下的用户可能只能不明就里。毕竟世界不是只有原教旨主义者的。SourceHut 会成为一个很好很好的开放 Git Forge 平台,但如果是带领开源世界冲击 GitHub 的王座,那小氯还是会把仓加在 Codeberg 上。

此外,关于 Codeberg 是否可能被拒之门外的问题答案自然是有可能的但目前来说可能性不太大——听我说。GitHub 上面托管的项目,除了「用 Git」之外几乎没有任何的共同点从字面意义上的开源项目到分发二进制包的非开源仓库最重要的……还有一些不可描述的小项目某个喜欢吃数据包的萌娘可不会喜欢这些东西而 Codeberg上面全都是严格意义上的 FOSS除了开发之外基本就没有什么其他的内容了——至少在小氯的认知里是这样的。只谈代码和「技术自由」的理想主义者可能是最不值得大动干戈的一批人之一了。

当然了Codeberg 缺点也是很多的。最显著的一点:要拿现在的 Codeberg 和 GitHub 比规模和生态,不能说是蚍蜉撼树吧,至少也可以说是草履虫打霸王龙(通言通语 1/1。现在 Codeberg 上有影响力的开源项目和领袖开发者还是太少了,同时几乎没有任何可对接的生态(从下面小氯倒腾的部署可以大概看出来)。不过小氯对 Codeberg 很有信心:只要社区的维护者们不失本心(小氯相信这一点),那么 Codeberg 的蓬勃发展就是不可阻挡的。

至于为什么叫「老爹」?大概是来自于 Бáтько Махно́(马赫诺老爹)吧。

小氯的考虑

说实话,从技术实践的角度来说,小氯的这波操作基本上属于反向优化。背后的驱动原因,有且只有对 FOSS 和开放共享内容的支持,或者我们也可以叫「信仰」和「意识形态」一类的东西。

作为行动上的实用主义者,小氯一向讨厌拿这些标准毫无底线地去卡任何事。但只要想到一句话,小氯就开始对 GitHub 心神不宁:

你愿意让你的文字活在一座逐渐下沉的天空之城吗?

不行,绝对不行。我可以说服自己这样做,但我的文章不行。

从开始写博客时,小氯就一直采用着 CC 系协议。园子里的植物,老友们随意采撷便好,无论是收集些玫瑰花瓣回去泡茶,还是摘一捧桂花用来做甜甜的酒酿,还是带一盆多肉植物回去摆在案头。小氯乐意见到自己的花草被心意相通的老友们喜欢,也乐意看到它们随着洋流或者数据流旅行向其他的小岛,为那处的人们带来一点视觉、味觉或者心理上的满足。

它们是我用日光、热茶和位流种下的生命,如今以最简单和纯粹的形式返还给世界。它们是我在此地的生活、记忆、悲欢的全部。你可以把刺刀扎进我的心脏,但你不能踩踏我的花草。

……抱歉,小氯太激动了。相比 GitHubCodeberg 在自由、开放方面显然更能取得我的信任,这也和园子的基本价值观和长久发展战略吻合。这也就是我在「 如今 」页面说的:

自由的文字,理应生长于自由的土壤。

除了博客之外,小氯也逐渐在把其他的一些开发活动转移到 Codeberg。至于生态小氯不管我在哪看代码和在哪写代码是两回事。传播度您看这只元素娘搓的小小项目像是能有传播度的样子吗园子本身也就是这样一个小小的、无人问津的角落难道指望 GitHub 给我带来什么流量?反过来还差不多。

那过往的积累呢?小氯自然也不在乎。反正咱还只是个寂寂无名的开发小白,去哪里不一样呢?一无所有,才不会积重难返。那十几个星星或者四十几个 follower比得过「追随我心」的含金量吗别误会小氯真的很感谢那些为我点 Star 或者 Follow 的老友,你们为我单调的生活带来了难以言说的惊喜)?如果小氯真的被这一点成绩拴住了,那也太对不起小氯曾经说过的那句话了:

如果荣誉和地位会让我不快乐,让我失去我最爱的人和事物,甚至让我讨厌自己,那么万钟于我何加焉?

小氯甚至想过更极端的方案:把博客的源码放到自托管的 Forgejo 上。反正将来肯定是要有这么一个自己的实例的,权当是提前积攒威望了。这个主意其实非常可行,因为相比于对联邦功能要求很高的其他项目来说,博客更接近一个「只读开源」的属性。很适合住在现在联邦功能尚未完善的 Forgejo。

……嗯,写一篇时间跨度比较长的文章,坏处就在这里了——你需要频繁地更新你的草稿。在一个有点冲动的下午,小氯直接搭好了自己的 Forgejo 实例,名字叫 MoeForge其实界面还并不萌主要因为用了 foss.moe 这个域名嘛。于是园子的源码也出现在了 MoeForge 上面一份,也就是这里

MoeForge 小氯肯定是会长期运营的,不过这个开始显然是草率了一点。先看看情况如何,大不了删库重来(不是)。


不过,话说回来:虽然我们夸了这么多 Codeberg但如果只是嘴上说着「支持非营利组织」「开源万岁」之类的话虽然没错但也仅限于此。毕竟Kind words don't pay the bills柏林的电力系统可不会因为他们在进行一项高尚的事业就免去他们服务器的电费。所以小氯也在 Liberapay 上给 Codeberg 做了一点点周期捐款,虽然量很少,但也是小氯的一点心意吧。

至于资金来源?嗯,奖学金,或许还有当牢助教的工资(如果有的话。之前似乎给我发邮件来着,我原本以为本科生当 TA 是没工资的)。这点钱不多,但是表达一下善意和支持显然够了。

放一下小氯的 Liberapay 账户捐赠记录证明小氯没说谎。此外Stripe 是真坑啊,收了我好大一笔手续费(指相对大小)。

部署

如各位所见,小氯的园子一直跑在 Vercel 上。Vercel 也是一家公司,不过也算是位互联网善人。加之 Vercel 的优选线路的国内速度还可以,小氯也没想着切换。

不过既然把主要平台换到 Codeberg 了,那么对于部署的 Workflow 也得重新考虑一下。

Vercel CLI

这大概是最简单、最优雅的方法了。毕竟无论什么静态网站,本质上都是构建之后的一包文件而已,直接用 CLI 丢上去就好。而且,咱们的电脑再不济,性能应该也不至于不如 Vercel 免费计划构建分配的 0.6 个 vCPU构建速度的提升可以说是肉眼可见的。

这个方案的优点很多,只有一个小缺憾,就是完全没法用。

嗯。小氯永远登录不上 Vercel CLI每次会卡在同一步并且找不到任何解决方案。大概是网络环境的问题具体一点大概是在发送部署命令的时候这一步没有尊重系统代理设置。目前已经把 issue 提给 Vercel 官方了,等待回应。

继续使用 GitHub

别笑这是个方法而且可能是最省心的方法之一。Git 可以用很多个 Remote只需要在推送的时候同时推到一个 GitHub 镜像仓库。然后使用正常的方法部署就可以。

鉴于小氯前面说了这这么多 GitHub 的坏话,此处明显有既要又要,「背叛革命」的嫌疑。所以容小氯狡辩一下。

一个事实是:现在完全抛弃 GitHub 是不现实的。毕竟,那是世界上最大的开源平台,上亿个项目和十多年塑造的庞大社区和完善生态。即使是最激进的 Codeberg 和 Forgejo 支持者,估计也只能想想在几年之内取代或者撼动 GitLab 在自托管界的地位。要是说想在可预见未来内干翻 GitHub虽然也不是绝对不可能但难度大概相当于托洛茨基希望几年之内建成全球社会主义。我们将来面临的形势很可能会像未来的国际局势一样是多极化的。GitHub 再衰弱,也必然会保留下庞大的用户群体和生态,难道我们要把这些项目和开发者逐出开源世界吗?至于小氯自己,也只是把「主要的开发活动」迁移到 Codeberg 了(这还是在上面所说。小氯几乎没什么项目,可以随意走动的情况下),并没有把 GitHub 完全注销掉。

而且虽然说咱们对牢软都有意见但是资源就摆在那里。老实说GitHub 提供的资源还是相当慷慨的,也算是半个互联网善人了(从功利主义的角度,君子论迹不论心)。对于咱们这样的普通用户和开发者,「批判性使用」应该是最好的方法了,或者我们换一个更容易懂的说法:羊毛不薅白不薅,薅了不白薅。用大公司的资源不丢人,咱们不用 GitHub Actions 的服务器去构建项目,难道让那些服务器去给老总们挖矿吗?陕甘宁边区的游击队不是也用着缴获敌人的武器嘛,更何况 GitHub 目前还没有到要被定性为「敌人」的程度,只能说是「革命立场不坚定的资产阶级合作者」。

此外还有一点质变是不可能在毫无准备的情况下瞬时发生的。如果您看了或者听了什么之后GitHub 在您心目中就立即从开源社区的高标变成了人人得而诛之的贼人,那要么是您之前对 GitHub 有什么误解,要么就是您得到的说法或者您的解读存在严重的非理性。

Netlify CLI

话虽如此,但小氯总得做出点什么东西来,不然有水文章的嫌疑——你讲了这么一大堆,结果说到底还是在用 GitHub

好的。众所周知,在小规模的 Serverless 项目中Vercel 和 Netlify 几乎可以互换。相对来说Netlify CLI 对于国内的支持甚至更好。不过论速度Vercel 的优选线路似乎比 Netlify 优选快。但一如小氯上面说的,我不会再费心去优化国内速度了。

那如果 Vercel 不行Netlify 行不行呢?

小氯捣鼓了一个多小时后得出的结论是:真的可以。下面请欣赏小氯酱的表演。

前置

Netlify 支持的 Git 集成只有 GitHub、GitLab、Bitbucket 和 Azure DevOps。倒是有一个 Self-hosted Git 的选项,但咱自然是不会为了这东西付钱的(甚至需要企业计划)。不过在 Netlify 的 CLI 里面其实有个隐藏彩蛋——从 CLI 部署的时候,连接 Git repo 时并不会检查到底是哪一家的。我们可以从这里入手。

我们来仔细思考一下Vercel 和 Netlify 的持续部署到底是怎么实现的。直观来说,大概就是三个步骤:收到更新信号,拉取 Git 仓库,然后执行部署。那我们只需要把原本自动化的前两步变成可配置的就好了。

创建 Netlify 项目

首先在 Netlify 的界面,创建一个空项目。方式选手动上传就行,传一个只有一个 index.html 的文件夹,index.html 随便写点东西就可以,后面我们就用不到了。

然后,在环境变量一栏,创建一个环境变量 HUGO_VERSION,内容是你希望使用的 Hugo 版本号。这一步一定要做,不然 Netlify 识别不出来这是个 Hugo 项目,后续构建会报错。

本地连接项目

首先全局安装一下 Netlify 的 CLI小氯用的是 Bun你用 npm/pnpm/yarn 之类的都可以。

bun install -g netlify-cli

然后检测一下是否安装成功了,如果没有的话可能是环境变量没配好。

netlify version

然后打开全局代理模式(这样是为了防止奇奇怪怪的问题),进入你的项目,执行:

netlify login

登录会比较耗时,也有失败的可能,还请各位老友有些耐心。

登录之后,执行:

netlify init

等大概十五秒到半分钟(取决于网络情况),在选择中选择「连接到已有站点」,方式选择「查看最近更新的站点」,然后选择你刚刚创建的空白站点。

然后在构建命令那里输入你的命令,例如小氯的命令比较复杂,是:

hugo --gc --minify && bun install && (bun run shiki || true)

一般的 Hugo 博客使用 hugo --gc --minify 就差不多了。

目录直接默认的 public 即可。下面是重头戏,就是如何连接到 Codeberg。

当 Netlify 提示你 Remote 地址的时候,看看是否是你仓库的地址,然后它会给你一串 SSH 密钥。把密钥复制好,进入 Codeberg 的仓库界面,点击设置——部署密钥——添加部署密钥,把复制的密钥粘进去,名字随便起。

Warning

不要勾选「授予写权限」,这样会使得 Netlify 可以任意更改你的仓库,这可不是什么安全的事情。

然后回到终端,点击继续。

接下来会给你一个 Webhook 的 URL格式大概是 https://api.netlify.com/hooks/xxx。复制下来,回到 Codeberg 网页界面点击设置——Web 钩子(也就是 Webhook这翻译有点难绷——添加 Web 钩子,类型选择 Forgejo 即可(是的,你没听错,类型选择 Forgejo。具体配置没什么可以说的把你的 URL 粘到「目标 URL」处然后余下的什么都不用动无须鉴权请求体空的就可以如果你想调分支请自便。

回到终端,继续。这个时候 Netlify 会提示你配置完成。再回去看看你的 Netlify不出意外的话第一次部署已经开始了。以后就可以像使用 GitHub 时那样了。我们只需要 git push 就好了,而 Codeberg 和 Netlify 要考虑的就多了(鸣式 1/1

完工。从此以后,园子和 GitHub 断绝关系 (∠・ω< )⌒☆​

Codeberg Pages

GitHub 有 GitHub PagesCodeberg 也有自己的 Codeberg Pages。小氯没用过但推测速度八成是中等毕竟你也不能指望全栈位于德国境内的服务器的全球速度有多快。希望 All in Codeberg 的老友可以试一下。

其他平台

小氯没有试过其他平台能否和 Codeberg 联动,欢迎补充 (/ω\)

HelloArtalk

很好Residencia 0x001B 又多了一位使用 Artalk 的居民(喜)。

Why

我能说是我闲得慌吗

世界上开源的第三方评论系统很多,但小氯坚定地认为:如果你希望 Serverless那么选择 Twikoo如果可以接受 Serverful那么选择 Artalk。它们可以说是各自领域最优秀的代表。

从园子建立开始,使用的就是 Twikoo。迄今为止除了由于小氯的铸币操作被迫重建了几次之外没有出过大问题MongoDB 也一直运行正常,没有丢过数据。小氯自己也对 Twikoo 做了不少自定义,不论是暴力去掉 href="#" 来避免在 Efímero 主题中的滚动问题,还是胡乱自定义 Twikoo 的样式文件来适配主题风格。

不过 Twikoo 虽然好但也有一些让我感到很无语的缺点。比如修改数据极其麻烦MongoDB Atlas 的后台是一点也不拟人;评论的速度很慢,往往需要等好几秒才能显示。此外,有时候看着杜老师清扬老友的评论区丰富的自定义徽章属实是很想要。

恰好最近,HPCesia 老友把自己的评论系统换成了 Artalk终于把摇摆不定的小氯往 Artalk 的方向推了一下。反正现在服务器已经不再是问题了,那么也不妨来试一下新玩具嘛。

部署和迁移

部署其实没什么可说的。遵照官方的指示Compose 一把梭就完事。由于 Artalk 使用的是高贵的 Golang因此资源占用很小大概只有 30 M。

迁移的话,在 Twikoo 的前端面板把 JSON 文件导出来,稍微按照你的意愿修一修,转成 Artalk 兼容格式,导进去就可以了。

CSS 定制

说实话Artalk 的默认样式比 Twikoo 好看很多,基本上也和园子的世界风格比较搭,所以写个一百多行的代码小小地定制一下就完事了。源码请在小氯的主题仓库自取

邮件模板配置

这里小氯遇到了一个令人百思不得其解的报错:

2025/04/22 20:48:15.928 ERROR [email/sender_smtp.go:30] [Email] Email sending failed via SMTP gomail: could not send email 1: 450 Missing `html` or `text` field.

「Missing html or text field」难道是 DOCTYPE 声明的问题吗?事实证明显然不是。

切到 default 看一下……正常的。那看来问题出在小氯的模板上。

对比一下官方模板和小氯的模板,可以看出结构区别相当明显。具体来说,官方模板是一个……嗯,组织没那么美观的 HTML 片段,而小氯的模板是一个完整的 HTML 文件。

难道是 Artalk 不能识别完整的 HTML 吗?虽然直觉告诉小氯 Artalk 不可能那么杂鱼,但小氯还是反复试了去掉声明、去掉 Header、样式内联、只留下 Body、只留下一层 Div 等方法,结果不能说是硕果累累吧,至少也可以说是一无所获。

折腾了许久之后小氯有点累了,就试着把官方的模板粘了过去。结果……还是报错?

我发现了华点。

那看来,问题根本不出在模板上,而是 Artalk 读取的问题。那么最可能的就是路径有问题了。难道是 Artalk 没读到小氯的模板吗?

小氯的第一想法是 Artalk 没有权限访问小氯的 ~/projects/artalk/templates ——你这个笨蛋啊,你怎么不想想 Docker 是以什么用户的身份运行的?然后创建了一个 /opt/artalk,结果自然是没有结果。

一筹莫展之际小氯看到了这个 comment,哦,原来需要把模板放在容器的数据卷里面,使用相对于容器根目录的路径,例如 /data/xxx

问题解决。

想想似乎也挺合理,毕竟要是容器能访问数据卷之外的文件,那岂不是翻天了……

这里是小氯的邮件模板,请自取~

表情包配置

Artalk 也可以使用 owo 格式的表情包,但和 Twikoo 有一点差别。具体来说Twikoo 的表情文件长这样:

{
    "series_1": {
        "type": "image",
        "container": [
            {
                "icon": "<img src='https://owo.domain.tld/image.webp'>",
                "text": "alt"
            },
            // ...
        ]
    },
    // ...
}

而 Artalk 的长这样:

[
    {
        "name": "series_1",
        "type": "image",
        "items": [
            {
                "key": "alt",
                "val": "https://owo.domain.tld/image.webp"
            },
        ]
    },
    // ...
]

还是需要一点点的转换工作的。此外Artalk 支持直接引用外部的 JSON 文件作为其一部分。模块化编程嘛,小氯喜欢这样。

表情包图片呢,也趁机换到了国际平台托管,依然是带善人 Cloudflare 的 R2。速度其实也并不比原本的 EdgeOne Pages 慢太多。

Bonus

目前的 Artalk 还只有小氯自己的 Badge。如果有希望 Badge 的老友,请尽管留言或者发邮件,注意注明喜欢的文字和颜色,过时不候哦 OωO

后记

主要的更改,大概也就是这些了。如果说很多呢,这么讲一讲也就是讲完了;说不多,又确实是把园子的技术栈几乎掀了个底朝天。

说到底的目的,大概也就是如开头所述,隐私保护方面的考虑,以及希望自己能够有一片更加自如的精神家园吧。

这样的举措大概还是有效果的,只不过可能不是很大罢了。不过无论如何,我们都要有一些「从头开始」的勇气,不是吗?

最后……这里是一封邀请函,某只元素娘希望请您去它的园子里坐一坐,喝杯茶,顺便重新走一遍这片原教旨主义的知识旷野。

我们在洒满阳光的桌前读书,在小径分叉的花园漫步,在草木葳蕤的原野驻足。

在暴风眼中享受世界的宁静,每一缕被雨水打湿的发丝,都浸满最耀眼的光辉。


  1. Fair Use合理使用。美国版权法规定批评、评论、新闻报道、教学、学术研究等可不经授权使用版权材料。 ↩︎

  2. 关于这个观点的细节,请阅读穆勒《功利主义》的第五章。 ↩︎