|
|
|
|
|
---
|
|
|
|
|
|
layout: post
|
|
|
|
|
|
title: Mayx的博客分发方案
|
|
|
|
|
|
tags: [Mayx, Github, Gitlab, 分发]
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
无论什么资料，都有保存的价值！<!--more-->
|
|
|
|
|
|
|
|
|
|
|
|
# 起因
|
|
|
|
|
|
在今年年初，[Github封禁了我的博客](/2022/01/04/banned.html)，因此我也对Github失去了信任。之前因为信任的关系，我几乎不会在其他地方备份我的博客，发生了这种事情之后我才明白这并不可靠，虽然我有时候会把我的博客整站隔段时间手动下载下来，但是这样实时性不高。其实我也不是不会做自动化方案，只是因为懒，就像这篇文章一样，分发我在上个月就已经完成了，现在才在这里写文章……
|
|
|
|
|
|
|
|
|
|
|
|
# 方案
|
|
|
|
|
|
去年我在[研究博客平台的时候](/2021/08/15/blog.html)已经调查过很多放静态站的平台了，所以这次进行分发的时候有了之前的经验，也简单了不少。
|
|
|
|
|
|
## 源代码托管平台的选择
|
|
|
|
|
|
因为Github不可信，于是我自然想到了用Gitlab来存放博客源代码。虽然吧Gitlab曾经也发生过用户数据丢失的问题，不过反正目标也是同时放在Github和Gitlab上，总不至于两个一起炸吧。其实最开始我的计划是用Github Actions进行同步，不过在我进行调查之后我发现Gitlab功能还是挺强大的，它支持对一个Git仓库进行自动的推送和拉取，也不需要做过多的配置，就只需要配置个地址和令牌就可以，还是挺方便的。
|
|
|
|
|
|
在我做完Github与Gitlab双向同步之后，我发现Gitlab还挺好用的，首先，Gitlab有个很棒的地方就是没被墙，我有时候写文章的时候不挂梯子用Github真的是非常难受，目前依我所感受，防火长城会对Github先进行一下TCP RST，然后刷新一下让你连上，连上之后如果长连接断开或者大概5分钟的样子就再阻断，然后再RST一波，非常的挑战心态。有时候我写了半天然后点预览结果就阻断，等半天还是连不上，还要挂梯子，能预览的时候就得赶紧提交，万一提交的时候再阻断要是没备份就炸了。像Gitlab我就从来没遇到过类似的情况，这一点还是很不错的，大概是因为Gitlab不是社区，而且滥用的人也少，所以政府也不太关系吧。
|
|
|
|
|
|
另外就是Web IDE，相比Github的VSCode Web IDE，Gitlab的要轻量很多了，也不容易发生卡的情况，而且其实Github的VSCode Web IDE也装不了几个插件，功能上也没强到哪去。
|
|
|
|
|
|
还有就是翻译，明明用Github的中国人/华人挺多的，官方就是不出中文界面，明明文档都有中文了……Gitlab可能是因为作为一个开源产品，i18n做的很好，虽然吧英文也不影响我使用，但是毕竟作为用户体验的一项，Gitlab做的确实更好。
|
|
|
|
|
|
不过其实我觉得Gitlab也许只是表面没那么出名，毕竟不是做社区的，大多数公司都用的是自建Gitlab托管代码，而且很多时候Github其实是在抄Gitlab的（虽然最早是Gitlab抄Github），比如Actions抄CI/CD，还有最近又出的一堆什么代码扫描和检查，Gitlab出现的都更早。不过这说着也跑题了这个文章又不是为了专门夸Gitlab的😂。
|
|
|
|
|
|
## 部署平台的选择
|
|
|
|
|
|
源代码平台整完之后就是部署平台了，除了Github和Gitlab上自己的Pages上各部署了一份，另外我也在Cloudflare Pages和Vercel上面也设置了部署，以后我也可能增加更多的部署和备份平台，具体目前可以参考[代理列表](/proxylist.html)。
|
|
|
|
|
|
在部署的时候目前我也增加了一些新的东西，比如下载全站的按钮，原来我是想把源代码和生成后的代码合到一起下载，不过没想到Cloudflare Pages竟然不能上传超过25MiB的文件，所以没办法，我只好光放下载全站的按钮。不过我也有做判断，如果是Github生成的代码，会放Github的下载链接，因为Github Pages生成没办法使用脚本，也没法打包全站代码，其他部署因为支持的多所以我就写了一个脚本来进行打包，一是方便在Wayback Machine保存我的全站代码，二是希望能通过这种方式让有兴趣的人帮助我来备份我的博客。
|
|
|
|
|
|
另外为什么是生成后的代码呢？因为如果用源代码要考虑很多依赖的项目会不会炸，比如Ruby、Jekyll、还有各种插件和模板，如果未来的某个时候它们其中有一个炸了，那么感兴趣的人就没办法再构建我的博客了。
|
|
|
|
|
|
在此之后也算是激发了我对博客代码修改的灵感，比如我改了下博客分页器，现在就没那么凌乱，使用select标签就更加简洁了。
|
|
|
|
|
|
|
|
|
|
|
|
# 未来的方案
|
|
|
|
|
|
之后我会想办法在Blogger之类的平台整个自动化发布脚本，还有就是上链啥的，不过上ETH这种公链的成本实在是太高了，我要是想把我的博客全部上传到公链上估计得要上百万CNY了吧……而且也没法编辑，回头看看能不能整个分布式社区，让大家的独立博客互相备份。另外这也是我之后想做的计划的一部分，我想整一个开放的匿名解决方案，比如整一个“OpenAnonymous”的项目，分布式在一定程度上能大幅提高追踪成本，其实在社会中就像谣言一样，为什么说“造谣一张嘴,辟谣跑断腿”？其实也是因为分布式的特性，对于已经散播的信息很难溯源，也很难制止。
|
|
|
|
|
|
总之希望作为Mayx Forever Project的载体——Mayx的博客能在我有生之年想出合理的方案，存在1000年吧！
|
|
|
|
|
|
|
|
|
|
|
|
# 补充
|
|
|
|
|
|
刚才在Gitlab上发布了文章之后我不知道Github Pages这里又犯什么神经病，没有给我构建，所以我又想到了些东西在这里补充一下：
|
|
|
|
|
|
Github Pages还有个地方让我比较难受，那就是Github Pages的默认域名在有些运营商会被屏蔽，我不知道是DNS的问题还是啥，总之这样我有时候发文章之后其他人就看不到了，所以现在我以后常用的域名也打算改了，我目前决定使用 <https://mayx.eu.org> ，好听也好记。
|
|
|
|
|
|
另外还有个比较难受的地方就是我的博客目前用的评论系统是Gitalk，这个是依赖Github的，之前评论全炸这个我也是非常难受，我之后再想想办法改一下评论系统吧。
|
