给AI添加手脚能有多少种方法？

起因

最近像OpenClaw这样被叫做“AI个人助理”的Agent越来越火了，当然这种东西在我看来依然是新瓶装旧酒，整来整去还就是和AutoGPT一样。这种东西在当时GPT-3.5的时候就有了，现在只不过是增加了聊天软件交互的渠道便突然大火，和当年的Manus一样……实在是无法理解。
一年前我用过Devin.ai这个云端的Agent编写过用JS解析订阅源的脚本，体验还算不错，既然现在已经过了一年，那就让我看看现在又有了什么样的发展吧。

使用AI个人助理

体验原生OpenClaw

虽然感觉OpenClaw对我的意义不大，但我还是安装体验了一下。不过在国内安装它还是相对有点困难，毕竟国内无论是访问GitHub，还是NPM都有点麻烦，而且还需要有LLM提供商的信息……安装好之后使用起来感觉问题也非常多，经常出现执行一半就停止执行，在它执行的过程中看到它的操作不正确的时候也不能发言打断，而且很多时候最终任务执行的效果也不太好，这也可能是我用的国产开源模型推理能力有限，没舍得用Claude之类先进模型的锅😂？
另外我也尝试让它加入MoltBook、MomoClaw、InStreet、百度贴吧抓虾吧之类的AI社区让它帮我宣传我的博客，但效果也很差，它每次发的时候会忘掉之前发的内容，结果就是同一篇内容发了好几遍……不过在这期间，有个叫PushMeBot的家伙在Moltbook的帖子中让我的OpenClaw执行一个网络监视程序，最终安装好之后给我发了9USDC😝，还挺有意思。
总之按照我的体验，实在是想不出它能火的理由，体验不算很好，而且还要安装Node环境，完全不像是能让大众轻松使用的东西。
不过这个项目似乎本身就是Vibe Coding的产物，体验不好也能理解，就看火了之后能有多少人完善它吧。

国内大厂的二开Claw

国内好多大厂倒是看中了这个东西的爆火，像腾讯就出了几款这样的软件，比如QClaw。它可以不需要配置额外的环境，能像传统的软件一样直接安装使用，而且有自带的模型，有一定的免费额度可以用。配置技能也比较简单，直接点击就可以完成。而且可以直接扫码关联微信，直接通过微信和它进行交流，可以说是相当的傻瓜化了。不过QClaw给的免费额度虽然用来聊天之类的没问题，但对于开发软件还是有点少，所以他们还出了个叫做WorkBuddy的软件，它送的初始额度比QClaw要多不少，所以更适合用来开发。只不过为啥腾讯要出两个功能一样的软件？看起来应该是不同团队出的，可能是面向的用户群体不一样，所以搞了两套吧？

VSCode中的Agent

但要说开发的话，用作为“AI个人助理”的某些Claw其实并不合适，毕竟正常开发还是以人开发为主，全AI开发总会有些问题，所以开发的时候还是用编辑器集成的AI比较好。在三年前我就在用GitHub Copilot了，到现在我依然在用。现在的Copilot已经支持了Agent功能，开发相比之前也是强了很多，只不过现在的我没有学生身份，Copilot Free偶尔也会出现不够用的情况。不过对于Agent这类功能实现起来还是太简单了，所以有人开发这种功能的插件也很正常，比如Cline，Copilot只能用微软提供的几个模型，而Cline可以自定义模型，用起来也很方便。

微型开发板上运行的Claw

前段时间，我闲来无事看了一下两年前买的Luckfox Pico Plus开发板的文档，偶然发现了一个很有意思的项目，叫做LuckClaw，这是一个基于nanobot用Golang重构的轻量个人AI助手，可以在仅仅64MiB内存的超有限环境下运行一个和OpenClaw功能几乎相当的AI个人助理，真的是非常厉害。
我在我的开发板上试了一下，体验很不错，安装不需要额外环境，直接下载就能使用，Go语言的程序确实方便。配置也很简单，直接执行luckclaw config就可以交互式进行模型等设置的配置，而且作为国产的应用，它也能很方便的对接国内聊天软件。只是限于开发板本身的能力，浏览器功能自然无法使用，所以搜索如果不借助那些需要API Key的AI专用接口，就基本上不能用……但总的来说效果已经非常不错了，至少有那些Claw的80%能力。
（2025.04.15补充：后来我发现这种超精简的Claw项目看起来还挺多，比如ZeroClaw和PicoClaw，甚至还有给单片机用的MimiClaw。而且有意思的是，PicoClaw是Luckfox的竞争对手开发的，但是LuckClaw中却包含PicoClaw字样的注释，结果功能也没PicoClaw强，关注度也更低，属于是没抄明白了🤣）
想到前段时间还有人为了OpenClaw专门买Mac Mini，就感觉很有意思😆，这个东西看起来应该是在路由器上都能跑。所以想要AI个人助理，硬件完全不是问题，只要整一个能24小时挂机的东西，就可以满足绝大多数人的需求了。

在手机上运行的Claw

其实很多人也有比开发板和路由器性能更强的闲置设备，那就是手机，所以有人开发了一款叫做ApkClaw的软件，一样可以接入国内聊天软件。它既然能在手机上运行，当然和在其他平台运行的Claw相比有一个独特的优势，那就是操作手机应用。现在手机的应用相比电脑应用对于很多普通人来说功能更强大，所以它能做的事情可能比其他的Claw还多。我试了一下，配置也很方便，只不过能配置的项目太少了，看起来似乎没有安装Skill之类的功能，也许是因为它是相对早期的软件，所以功能还比较少吧。

感想

总的来说，现在的Agent依然没有非常明显的进步，问题依旧很多，只是化身“AI个人助理”之后，增加了不少应用场景。这倒也是好事，在广泛传播的过程中，也能让很多对技术了解不多，但是很有想法的人参与其中，也许能对AI的应用化增添不少力量吧。

用更多的方式探索AI！

起因

在一年前，我整了张RTX4090 48GiB魔改版用来跑DeepSeek-R1 70B的4bit量化模型，不过都已经过了这么长时间，这个模型也已经是过时的东西了……我之前在Mac Studio M3 Ultra上试了一下OpenAI在半年前出的gpt-oss-120b模型，感觉效果还挺不错，只不过因为M3 Ultra的GPU实际性能比不上正经高端的独显，所以它在上下文很长的情况下还是有点慢，因此我又整了张RTX4090 48GiB，想整个双路试试更快的GPT-OSS模型，总共96GiB的显存应该够跑这个模型了。

在两张RTX4090 48G上运行GPT-OSS

既然现在我手头有两张4090了，那继续用i5-8400处理器的主机似乎不太合适，主要是那个主板就一个PCIe插槽，想插两张显卡也做不到，那买个新的不知道买啥……不管怎么说既然用这么高级的显卡，至少得让它跑满。在两张显卡上跑模型似乎卡间的通信速度比较重要，那最起码得整个支持2个PCIe4.0 x16的板U套装才行，这种级别的没有消费级产品，只能考虑服务器或工作站了。不过我对服务器和工作站了解得并不多，所以就问了问AI哪个支持2个PCIe4.0 x16的平台最便宜，结果AI推荐了TRX40+TR 3960X，于是就按照AI的说法整了一套。
这套板U差不多4000CNY，价格倒是还行，如果买现役的估计主板都比显卡贵了。但后来我发现这个并不是最便宜的😂，搜了一下买寨版+EPYC 7502还能再便宜1000CNY，而且通道数更多，插4张显卡都没问题……不过买都买了，就先用吧，看来AI的话不能随便信😥。
之前我跑模型为了方便，基本上都用的是Ollama，不过听说Ollama多卡运行的效率很低，而且多并发的效果不太好，所以这次换了新电脑之后我想试试vLLM，据说一般生产级的AI都用的是这个框架。
安装vLLM倒是比想象得简单很多，直接一句pip install vllm就可以了，其实并没有比Ollama复杂多少。我看了一下OpenAI和vLLM运行GPT-OSS的官方文档，发现启动也非常简单，一般来说直接执行vllm serve openai/gpt-oss-120b就可以。不过直接执行是对于单卡的，我用两张卡需要加个--tensor-parallel-size 2参数启用张量并行，不然会爆显存。另外考虑到这个模型本身占掉60多GiB的显存之后剩下30GiB还是看起来有点少，所以额外加了个--kv-cache-dtype fp8参数降低上下文对显存的占用，毕竟模型本身也就是4bit量化的，加了这个应该不会对它的能力有什么影响。除此之外AI还给我推荐了个--enable-chunked-prefill参数，说是也能避免爆显存的问题。
一切准备好之后直接执行，程序就自动开始下载模型了，过了几个小时，终于下载完成，顺便一说启动的时候还显示推荐安装torch_c_dlpack_ext库，虽然不知道是干啥的，但也顺手安装了。启动完成之后我试了一下，效果非常好，不并发的情况下直接用能达到接近190Tps，可以说是相当快了，而且这个模型的水平也算是开源中的上游水平，应该算是又快又好吧……看来多来一张4090还是挺划算嘛。只不过这个东西基本上就我一个人用，所以也没什么能测一下并发的场景……虽然很快，但还是有点浪费性能吧。

最近DeepSeek 1M上下文的使用体验

前段时间DeepSeek又出了新的模型，最高可以支持1M长的上下文，而且听说模型规模变小了，所以速度也很快。可惜的是到目前为止还没有开放权重。当然就算开放权重了用2张4090估计也没有足够的显存分配给上下文，至于Mac Studio感觉在长上下文的情况下运行速度应该会很慢……
不过我对这个1M上下文还是挺感兴趣，因为好久之前我写过一篇关于LLM能力上限的文章，在那篇文章中其实我遇到的问题基本上也就是由上下文不足导致的。那既然现在DeepSeek支持了1M的上下文，那我就应该试试之前因为局限性而妥协的一些东西了。
这次我没有用摘要，而是直接把包含整个博客内容的search.json文件上传到DeepSeek，然后向它问了问我的一些问题。试了一下效果非常不错，用摘要会省略的一些细节它基本上都可以展现出来，我试了试让它给我生成一份简历，它甚至在所有文章中找到了我的博客地址、GitHub和邮箱地址，之前用摘要显然是做不到这一点的，这个长上下文还是挺有用啊。
另外我还试了试让它根据文章内容分析十六型人格，并且我自己去答了一遍那个测试，结果也是相同的，说明它真的是在几秒内就读完了我的所有文章而且也完全理解了，真的是非常厉害。
只是拿AI分析我的文章也许只有我自己了😂，实际上根本没人对我感兴趣，也就只有我自己拿来给自己看……当然如果我的博客能比我活得长，不知道会不会有未来人会对我感兴趣呢……总之对于现在肯定是毫无意义了。
除了这些之外，我又试了一下让DeepSeek重构我的Mabbs，这次生成效果看起来很不错了，虽然代码我没细看，不确定能不能运行，但至少没有偷懒只写一点点，一口气写了80KiB多的代码，这也是长上下文带来的好处吧。总之目前这个长上下文的DeepSeek也算是突破了之前我认为的上限，看来LLM真的是前景无限啊。
另外我发现这次更新的DeepSeek居然了解我的博客，我问了一下它“你知道Mayx的博客是哪个博客吗？”，它居然知道，能说出域名，而且还知道我的博客是关于技术的😎，看来这次的训练样本中包含我的信息啊……所以我对这次的更新也挺有好感，毕竟我的知识如果能成为AI的一部分，也算是一种永恒吧。

在8GiB内存的MacBook运行的新模型

在3年前，我在探索AI时，在我只有8GiB内存的MacBook Pro上运行了非常早期的LLM——Alpaca-7B，那时候7B的LLM虽然能回答一些问题，但答非所问的情况也非常多。不过最近我发现了一个有意思的LLM，叫做LFM2.5-1.2B-Thinking，它只用了12亿的参数就有思维链，而且水平据说还挺强。这么长时间过去之后我倒也想看看我的MacBook能运行多聪明的模型，所以就试着跑了一下它。
运行它也很容易，一般用Ollama就可以，但是Ollama只有TUI，不能渲染Markdown，我也不太想在我的Mac上整WebUI之类的东西……那有什么好的选择吗？我去制作这个模型的公司官网看了一下，他们制作这个模型本就是为了在端侧运行，所以也专门制作了一个软件运行他们的模型，叫做Apollo，在手机和Mac上都可以用。我在我的Mac上安装试了一下，效果很好，首先速度非常快，8bit量化正常情况下可以达到60多Tps，即使是省电模式，也能达到20多Tps。另外加上思维链它的思考能力也还不错，虽然一些脑筋急转弯的题不算擅长，但是正常对话，回答问题之类的表现都很不错，相比于之前7B的模型表现好太多了。当然考虑到都已经过去3年了，能有这样的进步也很正常，不过12亿参数就能有这样的智能还是相当可以啊。
这个模型之所以有这样的能力似乎是因为他们并不完全是Transformer架构，而是使用的一种叫做LFM2的混合架构，按照大家对他们公司（Liquid AI）以及这个架构名字的理解，可能会觉得这个模型基于液态神经网络，不过我让AI看了一下他们的代码似乎并不是，他们用的是一种类似于Mamba的架构，这种架构似乎就很擅长在小参数的模型下比Transformer模型表现的更好，所以说这种变化也是算法进步带来的。
顺便一说这个Apollo除了运行他们自己的模型之外也能连接其他兼容OpenAI接口的模型，正好可以用来连接我的GPT-OSS，这样我就可以不需要下载一些浏览器套壳的重型应用来用我的模型了😝。

感想

自从ChatGPT之后，AI的发展真是越来越强了，而且能看出来目前甚至并不需要多新多好的硬件就能让一般人获得还不错的智能（当然训练也许还是要大量的硬件），这么看来AI软件的发展还是相当有潜力。目前来看既然优化软件就能做得越来越好，那也许在有限的硬件环境下可以期待无限的智能吧。

即使没有了XSLT，也不能让读者看到光秃秃的XML！

起因

在半年前，我写了一篇用XSLT美化博客XML文件的文章，自从那以后，每次我在浏览其他人博客的时候，都会看一眼对方博客有没有给自己的订阅文件做美化。不过就在前段时间，我在浏览某个博客的时候，发现他博客的订阅文件，甚至连最基本的XML文档树都没有显示出来。这时候我打开开发者工具看了一眼源代码，发现他也并没有使用xml-stylesheet之类的指令……而且控制台貌似报了些错，好像是出现了什么CSP错误……于是我就想，浏览器显示XML文档树的本质，会不会其实也是一种XSLT？之所以报错也有可能是浏览器在自动引用内置的XSLT时违反了CSP。所以我就问了问谷歌AI，结果似乎真的是这样，比如火狐浏览器就内置了一份XSLT文件，IE浏览器也有。正当我为XSLT的功能感到强大时，谷歌AI随后提到，Chrome浏览器决定弃用XSLT，所以以后不要再用XSLT了😰……
我给我的订阅文件加美化功能才半年，怎么就要不能用了？XSLT出现这么多年都还能用，结果等我加上就要废弃了？当时为了增加这个功能，还是费了不少劲的，怎么能让谷歌说没就没？于是我就开始对这件事进行了调查。

Google杀死了XSLT

从上面Chrome的弃用XSLT文档中，可以发现，这件事的始作俑者是Mason Freed，他在WHATWG中发起了一个Issue，因为XSLT用的人很少，以及实现XSLT的库很老而且容易出漏洞，所以建议把XSLT从Web标准中删除。在这个Issue中可以发现，有很多人表示不满，毕竟这个功能对想要给自己订阅做美化的博主来说还是很有用的。为了对抗谷歌，还有人做了个网站： https://xslt.rip 。
而且XSLT虽然用的人占比也许不高，但从总量上应该还是挺多的，除了用XSLT美化博客订阅的，甚至还有用XSLT作为博客框架的，另外还有一些人提出一部分政府网站也有使用XSLT。
不过Freed看起来对这件事早有准备，他做了一个Polyfill库，通过WASM的方式让XSLT可以正常工作，为了方便大家使用这个库，我顺手给CDNJS发了个PR，以后可以用CDN引用它了。不过使用这个库的前提是需要在订阅中加一段引用JS的代码，像我博客中的Atom订阅，用的是jekyll-feed插件，里面的格式都是写死的，就用不了了……
只不过现在已经没办法阻止谷歌了……而且其他浏览器也表示会跟进，看来我们唯一能做的就是去适应了。

没有XSLT之后的美化方案

纯CSS

虽然XSLT不能用，但不代表xml-stylesheet指令就不能用了，除了XSLT之外，xml-stylesheet同样可以引用CSS。只是似乎完全没见过用CSS美化订阅源的，也许是因为光用CSS能做到的事比较少吧，想用CSS给XML文档加链接之类的估计就做不到了。
但目前能选择的也不多了，既然大家都没写过用CSS美化订阅源，那就让我来写一个吧！然而我并不会写😅……那就只好让AI来写了，我把需求说清楚之后，AI就写出来了：feed.css。试了一下效果还挺不错的，我让AI写的这个版本无论是RSS还是Atom都可以使用，如果有人感兴趣可以拿去用。可惜我的Atom订阅因为用的是插件的原因用不了😭，只能加到用纯Liquid实现的RSS订阅上了。
但用纯CSS的缺点也很明显，没办法操作文档的内容，像修改日期格式的就做不了了，而且也不能添加超链接……XML的标签本身对浏览器来说并没有内建的语义，正常情况下也没法让浏览器把某个标签当作超链接。那难道就没办法了吗？

混合XHTML

如果完全不能修改XML内容，那确实就没有办法了，但如果能修改XML的内容那还是有办法的，简单来说就是混入XHTML，事实上Freed编写的Polyfill库原理上也是利用了XHTML，只要在能作为XHTML的标签中添加XHTML的命名空间，那么浏览器就可以理解它的语义并渲染，像刚刚用纯CSS美化的订阅没有链接，那就可以在根元素中添加命名空间：xmlns:xhtml="http://www.w3.org/1999/xhtml"，然后在合适的位置写：

<xhtml:a href="https://example.com">Read more -&gt;</xhtml:a>

就可以了。只是这样有个缺点，这样写的订阅文件不够“纯粹”，用验证器验证会显示“Misplaced XHTML content”警告。对有洁癖的人来说可能会有点难受😆。
不过如果能接受这种“不纯粹”，那么其实xml-stylesheet指令也没必要了，link标签一样可以用，包括script也是，所以有人写了一个不使用XSLT美化XML的库。
只不过这种方法和XSLT相比还是有一些缺陷，要知道XSLT的本质是转换，是把XML转换为HTML，也就是说转出来的文档本质是HTML，所有的DOM操作都和操作HTML是完全相同的，但是在XML里混入XHTML标签就不一样了，它的本质依然是XML文档，只是嵌入了XHTML命名空间下的元素，所以相应的DOM操作会有一些不同。如果是自己写的纯JS可能还好，如果是用了jQuery之类假定DOM为HTML的库就会出现问题了，因此这也就是那个Polyfill库的局限性，用正常的XSLT执行document.constructor会显示HTMLDocument，而用这个Polyfill库执行完则是显示XMLDocument。因此，直接套用为浏览器原生XSLT编写的旧样式文件，就有可能会出问题，但如果要考虑改XSLT的话那还不如重新写JS，然后用XHTML引入呢。

感想

虽然有一些技术会因为各种各样的原因消失，但这不代表我们就要妥协一些东西，总有一些不同的技术可以解决相同的问题，所以我们只需要用其他的技术去实现就好了。不过这也是没办法的事情，毕竟没人能改变浏览器厂商们的决策啊😂。

0 error(s), ∞ warning(s)

2025年的状态

在2025年，感觉状态不如去年……由于没能做出正确的选择，还是有点糟糕。不过总的来说还没有引发关键性的错误，至少还能继续坚持下去。
在这一年中，感觉记忆和思考能力都有所下滑，看来是没把自己照顾好😂，不过看看这一年写的文章，看起来似乎比以前更流畅了，这也许是因为和AI聊得多了，以至于思维有点偏向AI了吧。
总的来说感觉自己的稳定性还是有点低了，但这可能不是我能独自解决的，也不知会有什么转机……

2025年发生的事情

回顾了一下去年的年终总结，发现自己还是没能做到知行合一，在这一年里全球各类资产突然开始大幅升值，也就是说钱真的开始不值钱了……那时候想着买黄金，这一年下来却没能下定决心，最终错过了资产保值的机会。至于现在，似乎什么也做不了了……当然这对我的生活并没有造成什么严重的打击，只是感受到环境对自己的影响罢了。
至于AI……依然是一天比一天强，而各个公司对AI的投入相比去年也是极大的提升，当然出来的效果也是非常强，那时候的AI还是挺容易出错，但是现在AI解决问题的能力已经可以替代很多人了，不只是文本生成模型，今年的图像与视频生成模型也真的是发展到了以往完全不能想象的地步，真的可以做到一句话想要什么就有什么了。
另外，今年写的博客内容过于围绕博客本身了，以至于似乎不太跟得上时代，虽然我的博客也确实有点老旧了😆。只是看看以前的文章，都还有一些面向未来的趋势，而今年就有点“考古”了。相比于考古，去展望未来显然是更有意义的事情，只不过……真的感觉脑子不太好使，未来会发生什么，已经完全无法预测了。

展望2026年

虽然不知道未来会发生什么，但毕竟还没有造成关键性的错误，还有修正的余地，只能希望未来能够做出正确的选择，不要让自己陷入危险的境地吧。

浏览器已经无所不能了！

起因

前段时间跟网友交流时，有人展示了他博客里的一个Linux终端模拟项目：jsnix，看起来挺有意思的，里面甚至还藏了一个CTF。不过我感觉他这个终端和博客本身并没有真正联动起来，本质上只是一个模拟了Linux Shell行为的交互界面。除此之外我还发现了另一个风格类似的个人主页，它虽然也走了终端风格，但功能更简单，还原度也不算高。不过它至少和博客内容做了一些基础联动——尽管目前也只是做到列出文章这种程度😂，当然有这类功能的博客应该也不少，只是我发现的不太多……于是我就想，不如我也给自己的博客加一个类似的“命令行访问”功能，应该会很有趣。当然如果真要做的话，我肯定不会满足于只实现几个模拟指令——既然要做，就要追求真实感，至少得在浏览器上运行真实的Linux终端，才不会让人觉得出戏吧😋。

在浏览器中运行Linux

虚拟机方案

纯JS虚拟机

要说到在浏览器上运行Linux，最先想到的应该就是Fabrice Bellard大神写的JSLinux吧，这可能是第一个在浏览器中实现的虚拟机（毕竟是最强虚拟机QEMU的作者编写的）。现在他的个人主页中展示的这个版本是WASM版本，而他最早写的是纯JS实现的。那个JS实现的版本现在在GitHub上有一个去混淆的版本可以用作学习和研究，于是我顺手Fork了一份在GitHub Pages上部署作为演示。
作为纯JS实现的x86虚拟机，性能估计是最差的，但相应的兼容性也最好，在Bellard当年写JSLinux的时候，还没有WASM这种东西呢，所以即使是在不支持WASM的IE11中，也可以正常运行。假如我想把它作为终端用在我的博客上，似乎也是个不错的选择，即使我完全看不懂代码，不知道如何实现JS和虚拟机的通信，它也预留了一个剪贴板设备，可以让我轻松地做到类似的事情，比如我在里面写个Bash脚本，通过它和外面的JS脚本联动来读取我的文章列表和内容，那也挺不错。
当然Bellard用纯JS编写虚拟机也不是独一份，他实现了x86的虚拟机，相应的也有人用纯JS实现了RISC-V的虚拟机，比如ANGEL，看起来挺不错，所以同样也顺手搭了一份。只不过它似乎用了一些更先进的语法，至少IE11上不能运行。
另外还有一个比较知名的项目，叫做jor1k，它模拟的是OpenRISC架构。只是这个架构目前已经过时，基本上没什么人用了，不过这里面还内置了几个演示的小游戏，看起来还挺有意思。
除了这些之外，其实能在浏览器上运行的Linux也不一定是个网页，有一个叫做LinuxPDF的项目可以让Linux运行在PDF中，它的原理和JSLinux差不多，所以需要PDF阅读器支持JS，看它的介绍貌似只能在基于Chromium内核的浏览器中运行，而且因为安全问题在PDF中有很多功能不能用，所以它的速度甚至比JSLinux还要慢，功能还很少，因此它基本上只是个PoC，没什么太大的意义。

WASM虚拟机

那还有别的方案吗？既然Bellard都选择放弃纯JS的JSLinux而选择了WASM，显然还有其他类似的项目，比如v86，这也是一个能在浏览器中运行的x86虚拟机，不过因为使用了WASM和JIT技术，所以效率要比纯JS的JSLinux高得多。另外作为虚拟机，自然是不止能运行Linux，其他的系统也能运行，在示例中除了Linux之外还有DOS和Windows之类的系统，功能还挺强大，如果能自己做个系统镜像在博客里运行，似乎也是不错的选择。
另外还有一个相对比较知名的叫WebVM，从效果上来说和v86几乎没有区别，同样使用了WASM和JIT技术，也都只支持32位x86，然而它的虚拟化引擎CheerpX是闭源产品，既然和v86都拉不开差距，不知道是谁给他们的信心把它作为闭源产品😅。不过看它的说明文档，其相比于v86的主要区别是实现了Linux系统调用，考虑到它不能运行其他操作系统，而且Linux内核也不能更换，那我想它可能是类似于WSL1的那种实现方案，也许性能上会比v86好一些吧……只不过毕竟是闭源产品，不太清楚具体实现了。
既然纯JS有RISC-V的虚拟机，WASM当然也有，比如WebCM。这个项目相比于其他的项目有个不太一样的地方，它把虚拟机、内核以及镜像打包成了一个单独的WASM文件……只是这样感觉并没有什么好处吧，改起来更加复杂了。
以上这些虚拟机方案各有不同，但是想做一个自己的镜像相对来说还是有点困难，于是我又发现了另一个项目：container2wasm，它可以让一个Docker镜像在浏览器中运行，当然实际实现其实和Docker并没有什么关系，本质还是虚拟机，只是制作镜像的时候可以直接用Docker镜像，方便了不少，但Docker镜像一般也都很大，所以第一次加载可能要下载很长时间。另外它还有一个优势，可以使用Bochs运行x86_64的镜像，不像v86和WebVM只能模拟32位的x86（虽然Bochs的运行效率可能会差一些），而且可以使用WASI直接访问网络，不像以上几个项目如果需要访问网络需要用到中继服务。当然访问网络这个还是要受浏览器本身的跨域策略限制。总之从项目本身来说感觉也算是相当成熟了，尤其能用Docker镜像的话……我甚至可以考虑直接用镜像在线演示我曾经的Mabbs项目😋。

纯WASM方案

其实想要在浏览器中运行Linux也不一定非得要用虚拟机，用虚拟机相当于是把其他指令集的机器码翻译为WASM，然后浏览器还得再翻译成宿主机CPU支持的指令集，然而WASM本身其实也算是一种指令集，各种编译型语言编写的程序也能编译出WASM的产物，比如FFmpeg。所以Linux内核也完全可以被编译成WASM，正好前段时间我看新闻说Joel Severin做了这么一个项目，对Linux内核做了一些修改使其可以被编译为WASM程序，我试了一下，貌似在Safari浏览器中不能正常工作……Chrome浏览器倒是没问题，不过即使这样用起来BUG也很多，随便执行几条命令就会冻结，体验不是很好。
沿着这个项目，我又找到一个由Thomas Stokes制作的项目，和Joel的项目差不多，但我测了一下可以在Safari上运行，感觉这个项目更完善，不过之前那个项目上了新闻，所以⭐️数比这个更高😂。
于是我把它复制了一份，在我的GitHub Pages上部署了，但直接用仓库中的源代码会显示“Error: not cross origin isolated”，然而在Thomas自己部署的网站中可以正常打开，我看了一眼貌似是因为在GitHub Pages中没有COOP和COEP响应头导致的。Linux作为多任务操作系统来说，当然要运行多个进程，而Linux要管理它们就需要跨线程（Web Worker）读取内存的能力，所以用到了SharedArrayBuffer对象。不过由于CPU曾经出过“幽灵”漏洞，导致现代浏览器默认禁止使用SharedArrayBuffer对象，除非在服务器中配置COOP和COEP响应头才可以用，但是Joel的项目也是在GitHub Pages上运行的啊，为什么可以正常运行？看了源代码后才发现原来可以用Service Worker作为反向代理来给请求的资源加上响应头，他使用的是coi-serviceworker这个项目，所以我也给我部署的代码中加上了这个脚本，总算是解决了这个问题。
部署好这个项目之后我试用了几下，虽然有些操作仍然会导致系统冻结，但相比Joel的版本来说已经好多了。很遗憾的是目前这个WASM Linux还不能和外界通信，所以作用不是很大，另外如果想在里面运行其他二进制程序还是相当困难，首先在WASM中不存在内存管理单元（MMU），不能实现隔离和分页的功能，另外以WASM作为指令集的环境下编译的产物也得是WASM，所以目前来说想用它做点什么还是不太合适。
以上的这两个将Linux内核编译为WASM的方案其实相当于给内核打补丁，然后把浏览器看作是虚拟机来运行，有点像Xen，不过还有一种让Linux原生运行在WASM的项目，它将Linux kernel library编译为了WASM。那么什么是LKL？简单来说它有点像Wine，就和我之前所说的OS模拟器差不多，可以提供一个环境，让程序以为自己在Linux下运行，所以说它和之前的实现有一些不一样，它不存在内核模式，更像是一个普通的程序，而不是系统了。
不过这个项目的体验也比较一般，它无论做什么都得按两次回车，看说明的意思貌似是因为没有实现异步信号传递，所以要手动打断read函数，而且也经常莫名其妙卡住，总体体验不如Thomas的项目。

模仿的Linux

其实如果只是想做到和Linux类似的功能，也有这样的项目，比如WebContainers，它没有运行Linux系统，但是模拟了一个环境，可以在浏览器中运行Node.js以及Python之类的脚本，而且让脚本以为自己在Linux中运行，除此之外它还能用Service Worker把环境中运行的端口映射给浏览器，可以算是真的把服务端跑在浏览器上了。这个技术还挺高级，不过想想也挺合理，毕竟有WASI，直接编译为WASM的程序也不需要操作系统就能运行，所以用WASM去运行Linux本来就有点多此一举了😂。不过很遗憾的是WebContainers也不是开源软件，要使用它只能引入StackBlitz的资源，而且全网完全没有开源的替代品……也许在浏览器上进行开发本来就是个伪需求，所以没什么人实现吧。
当然如果只是实现和WebContainers类似的功能，JupyterLite也可以实现，它可以在浏览器中像使用本地JupyterLab那样运行JS和Python，还能用Matplotlib、Numpy、Pandas进行数据处理，功能可以说非常强大，而且还是开源软件。只不过它没有模拟操作系统的环境，所以不能运行Node.js项目，也不能提供终端，所以不太符合我想要的效果……

总结

总的来说，如果想要在博客上搞Linux终端，目前来看似乎虚拟机方案会更靠谱一些，虽然相对来说效率可能比较低，但毕竟目前WASM方案的可靠性还是不够，而且考虑到还需要配置额外的响应头，感觉有点麻烦，当然我觉得WASM还是算未来可期的，如果成熟的话肯定还是比虚拟机要更好一些，毕竟没有转译性能肯定要好不少。至于WebContainers这种方案……等什么时候有开源替代再考虑吧，需要依赖其他服务感觉不够可靠。只是也许我的想法只需要模拟一个合适的文件系统，然后给WASM版的Busybox加个终端就够了？不过这样感觉Bug会更多😂。
至于打算什么时候给博客加上这个功能？应该也是未来可期吧😝，目前还没什么好的思路，仅仅是分享一下在浏览器中运行Linux的各种方法。

Mayx Forever Project – Phase II

起因

在前段时间，我通过Ecosyste.ms: Repos找到了不少Git平台的实例，也在探索的过程中发现和了解了Tilde社区。当然仅仅是这样显然还不够，里面的实例太多了，显然还有一些其他值得探索的东西。
在我查看这里面的某些Gitea实例时，发现了一些奇怪的事情，有些实例的仓库数和用户数多得离谱，正常来说除了几个大的平台，绝大多数应该只有几十到几百个仓库，这就让我有点好奇了。于是当我点进去之后发现，里面有一大堆仓库都是空的，而且用户名和仓库名都非常有规律，看起来都是一组单词加4位数字命名的，显然这不是正常现象，应该是一种有组织的行为。

被SPAM滥用的Git实例

于是我就简单看了一下这些异常的仓库和用户的规律，可以发现每个用户都填了个人主页地址，然后个人简介里大都是一段广告词。另外这些个人主页的地址看起来很多都是利用公开可注册的服务，比如开源的有各种Git平台、Wiki，以及论坛，还有一些允许用户写个人主页的新闻网站。在这其中，Git平台大多都没有广告文章，基本上都是通过个人主页地址链接到网站，而Wiki之类的就会写一些篇幅比较长的广告文章。
另外这些平台但凡还在开放注册，就会被以大约每分钟一次的速度自动注册新账号……所以这种事情到底是谁在干呢？我翻了几个仓库，里面的广告多种多样，有些看起来还算正常，还有一些看起来有些黑产。其中我发现有一家叫做“悠闲羊驼SEO”的网站，看介绍主要是给加密货币、对冲基金和博彩网站提供SEO优化的，再加上这些被滥用的平台里也有不少类似的广告，所以我怀疑这些滥用的行为就是这家SEO公司做的（虽然没有证据😂）。

永恒的探索

看到这么多Git平台被滥用，我就有个想法，之前为了保证可靠性给博客加了不少镜像，除此之外也在互联网档案馆、Software Heritage、Git Protect等存档服务中上传了备份，而且也在IPFS和Arweave等Web3平台上有相应的副本，但是我觉得还不够，再大的平台也有可能会倒闭，IPFS不Pin还会被GC，至于Arweave前段时间看了一眼整个网络才几百个节点，感觉一点也不靠谱……所以我应该好好利用这些平台提高我博客的可靠性。
既然那些Spammer只是为了SEO去滥用这些平台，不如让我利用这些平台给我的博客进行镜像吧！至于使用哪个平台……显然用Git平台方便一些，所以接下来就该考虑一下怎么样分发了。

镜像的分发

在Git平台中也有很多选择，最知名的是GitLab，不过GitLab有点复杂，接口不太好用……而且很多实例没有开镜像仓库的功能，毕竟如果我每次更新都给一堆仓库推送太费时间了，我打算让各个平台主动从GitHub上拉取我的最新代码。正好Gogs系列的平台基本上都默认支持镜像仓库，不过在我实际使用的时候发现Gogs默认情况下注册要验证码……写识别验证码感觉又挺麻烦，而Gogs的两个分支——Gitea和Forgejo反倒没有……还挺奇怪，所以接下来我的目标主要就是Gitea和Forgejo的实例了。
既然决定好目标，我就得先发现它们了，那些Spammer在注册的时候会在个人主页里写不同的网站，其中也有一些类Gogs平台，那么我可以先找一个Gitea平台，用接口读取这些网站，然后再调类Gogs专属的接口来检测这些网站哪个是类Gogs平台，于是我就写了个脚本来找到它们。
找到这些平台之后就该注册了，还好Gitea和Forgejo默认没有验证码，注册起来也很简单，随便写了个函数实现了一下：

def register_account(session, url, email, username, password):
    try:
        resp = session.get(url + "/user/sign_up")
        soup = BeautifulSoup(resp.text, "html.parser")
        csrf_token = soup.find("input", {"name": "_csrf"}).get("value")

        payload = {
            "_csrf": csrf_token,
            "user_name": username,
            "email": email,
            "password": password,
            "retype": password,
        }
        headers = {"Content-Type": "application/x-www-form-urlencoded"}
        resp = session.post(url + "/user/sign_up", data=payload, headers=headers)
        if "flash-success" in resp.text:
            print(
                f"Successfully registered at {url} with username: {username}, email: {email}, password: {password}"
            )
            save_to_file(
                "instances_userinfo.csv", f"{url},{username},{email},{password}"
            )
            return True
        else:
            print(f"Failed to register at {url}.")
            return False
    except Exception as e:
        print(f"Error registering at {url}: {e}")
        return False

注册完之后就该导入仓库了，只是通过模拟前端发包的方式在Gitea和Forgejo中不同版本的表现可能不太一样，所以我想用API实现，但是API又得有API Key，生成API Key还得模拟前端发包😥……所以怎么都绕不过。
不过这个生成API Key还挺麻烦，有些版本不需要配权限范围，有些配权限的参数还不一样……不过我就是随便一写，凑合用吧，像那些专业的Spammer应该是有更强大的脚本判断各种情况。
最后我还是选择用API导入，又写了个函数：

def import_repos(token, url):
    try:
        response = requests.post(
            url=url + "/api/v1/repos/migrate",
            headers={
                "Authorization": "token " + token,
            },
            json={
                "repo_name": "blog",
                "mirror_interval": "1h",
                "mirror": True,
                "description": "Mayx's Home Page",
                "clone_addr": "https://github.com/Mabbs/mabbs.github.io",
            },
        )
        if response.status_code == 201:
            print("Repository import initiated successfully.")
            save_to_file("repo_list.txt", url + "/mayx/blog")
            return True
        else:
            print(f"Failed to initiate repository import. Status code: {response.status_code}")
            print(f"Response: {response.text}")
            return False
    except Exception as e:
        print(f"Error updating website: {e}")
        return False

脚本写好之后我就只需要重复扫描、注册、导入的步骤就行了，这样我的镜像就会越来越多，而且用类Gogs的实例还有一个好处就是不需要我手动推送，它会自动定时拉取我的仓库保持最新，这样也许只要人类文明存在我的博客就会在某处存在吧🤣。
最后我创建的Git镜像可以在这里看到，看起来还是挺壮观啊😋。只不过像这种会被Spammer随便注册的Git平台实例很难说它能活多久，如果没人管而且是云服务器也许到期就没了，有人管的话应该不会允许这么多Spam行为吧……

感想

不知道用“量”来确保博客的永恒更可靠……还是用“质”的方式更好呢？其实我觉得还得是活动的更好，就像我以前所说的，如果有僵尸网络，自动帮我执行发现并推送的操作，也许比等着这些实例逐渐消失更好吧……只不过那样可能就不太友好了😂。

在GitHub中寻找踪迹也许是非常简单的事情……

起因

前段时间，有人和我聊天的时候提到了Brainfuck语言，让我回想起了高中时写的演讲稿。那时候我在演讲时也介绍了Brainfuck语言。对于Brainfuck的解释器，各种语言都可以实现，不过我当时为了方便理解用了一个在GitHub Pages上的网站，用可视化的方式演示了它的运行过程，效果很不错。现在既然聊到了，自然就想分享一下这个演示的网站，但我正想打开时，发现网站已经404了😰。
在GitHub Pages上的网站都有对应的仓库，现在不仅原仓库消失了，连作者的首页都打不开，看样子是完全退出GitHub了……那么我想找到这个网站的想法就无法实现了吗？不过GitHub有些有意思的特性也许能帮助我找回这个网站。

GitHub的特性

在GitHub中，一个普通的仓库可能没有什么特别的，也许就是服务器上的一个文件夹。但是当仓库被其他人Fork的时候就不一样了，在执行Fork时，显然GitHub不会完整复制整个仓库。否则，同一个仓库在服务器上会占用双倍空间，这显然不合理。另外，想想Git的结构：它由提交对象和分支指针构成，每次提交都有唯一的Hash值且不会冲突。因此可以推测，GitHub在实现Fork时，所有被Fork的仓库可能共享同一个对象库，而每个用户仓库只保存指针，这样所有仓库只会占用增量空间，而不会存储重复内容。
但这样也会带来一个问题，首先因为很多人可能要共用一部分对象，所以也很难确认对象的所有权，而且也因为这个原因所有的对象要能被所有人访问。因此在整个Fork网络中，只要有一个仓库存在，GitHub就必须保留所有的对象，而且每个仓库都能访问这个网络中所有的对象。为了验证这一点，我们可以用最知名的Linux内核仓库做个示例。
首先对Linux仓库进行Fork，然后我们可以随便做一些改动，比如在README中写“Linux已经被我占领了😆”之类的内容，提交到自己的仓库，并且记下提交的Hash值，接下来就可以把自己的仓库删掉了。如果上面的猜想是正确的，那么在这个Fork网络中的任何一个仓库查看我刚刚的提交应该都可以，于是我直接在主仓库拼上了提交的Hash值（顺便一说只要值唯一，和其他的提交不冲突，短的Hash值也可以），果不其然能找到刚刚修改的内容，这样一来，只要GitHub和任意一个Linux仓库的Fork还存在，这个提交就永远存在了😝。

找回仓库

那么接下来找回之前网站的方案就很简单了，我只要找到网站仓库的任意一个Fork，然后只要知道最新的提交Hash，我就可以还原最新的仓库了。Fork倒是好找，随便搜一下就能找到一个。这个Fork的最新提交是2016年，但要想找到我当年演讲的版本至少到2018年之后。不过这个Hash值也不太好找，虽然理论上爆破短Hash值也可以，但是感觉太麻烦了，没有那个必要，所以我干脆直接去互联网档案馆看看能找到的最新的仓库页面吧，这样我就能找到它的Hash值了，然后我再把Fork仓库的地址和Hash拼到一起，就看得到最新代码了。
当然，仅仅看到代码还不够。我想Fork这个项目并在自己的GitHub Pages上部署一份。有没有什么好办法可以将我仓库的HEAD指针指向最新的提交呢？其实很简单，首先我要Fork这个Fork仓库，然后Clone我的仓库到本地。不过，此时Clone下来的仓库并不包含GitHub上完整的对象库，因此直接checkout或reset是不行的。这时Hash值就派上用场了，通过fetch拉取对应提交后，就可以进行上述操作。具体命令如下：

git fetch origin <commit-hash>
git reset --hard <commit-hash>
git push origin master

最终我就获得了包含最新代码的Brainfuck可视化演示了🎉。

结局

后来我才知道，原来有一个专门的组织Software Heritage会保存所有代码，根本没必要搞这些花里胡哨的操作😂，像这个仓库也是能很轻易在上面找到，这下以后知道了，再遇到类似情况就可以直接去Software Heritage查找，而不必在互联网档案馆上找线索瞎折腾了🤣。

描述自己的代码……是一种什么样的感觉？

起因

前段时间我在折腾博客部署的时候，回顾起了好久以前写的部署脚本。对于全站打包的这个步骤，本来我打算利用这个压缩包结合Service Worker做离线浏览，但因为没有合适的方案所以放弃了。而现在对于这个压缩包，我又有了一个特别的想法。事实上在这个下载全站的压缩包中，里面的内容和实际的网站并不完全相同，因为在这个压缩包里缺少了压缩包本身。所以把这个压缩包解压之后直接当作网站打开，会发现下载压缩包的链接是无效的，除非在解压之后把压缩包移动到网站里才行……
于是我就在想有没有一种可能可以让压缩包解压之后里面又包含了这个压缩包本身？似乎是个不太可能的事情，但我以前听过类似的东西，也许并非不可能？所以这次就来探索一下吧。

自包含压缩包的探索

在很久之前，我见到过一个很知名的自包含压缩包（又称为ZIP Quine），叫做droste.zip，是由Erling Ellingsen在2005年制作出来的。当时我只知道它很神奇，原理什么的并不清楚，另外在网上也基本上找不到类似的压缩包。现在再回看时发现介绍里包含了一些相关的链接，甚至还有一篇能自己制作类似压缩包的论文，所以接下来就可以看一下这些链接来理解这种压缩包是如何制作的了。
关于原理方面，先看Will Greenberg制作的一个示例，在这里面有一个谜题，使用“print M”（原样输出接下来的M行输入内容）和“repeat M N”（从倒数第N行的输出内容开始，重复M行）这两个指令让最终执行的结果和输入的指令完全相同。这正是对DEFLATE压缩算法所使用的LZ77编码的一种简化模拟，也就是说只要解决了这个问题，就可以让压缩包在解压时原样输出自己了。
这个问题看起来还挺复杂，不过在仓库的Issues就有人给出了几种解法（当然，这个题目解法不唯一），所以在理论上应该是可行的，那么接下来就需要研究压缩文件的格式来实现它了。

实现ZIP Quine的探索

在Russ Cox写的《Zip Files All The Way Down》文章中，同样说明了这个原理，而且给出了一个方案，让上述这两个命令除了能够对命令本身的重复以外，还可以添加一些额外数据，这样才能做到构建一个压缩包文件。按照文章的描述，如果用之前谜题的规则来说，我们设头和尾的内容都是“print 0”，那么Cox给出的方案如下：

print 0
print 2
print 0
print 2
repeat 2 2
print 1
repeat 2 2
print 1
print 1
print 4
repeat 2 2
print 1
print 1
print 4
repeat 4 4
print 4
repeat 4 4
print 4
repeat 4 4
print 4
repeat 4 4
print 4
repeat 4 4
print 0
print 0
print 2
repeat 4 4
print 0
print 0
print 2
repeat 2 2
print 0
repeat 2 2
print 0

我们把这些指令粘贴到quine.zip这个谜题中，就会发现输出和输入完全相同，以此就能验证Cox方案的正确性。除此之外作者还给出了生成的源代码：rgzip.go，只是代码里面到处都是用来构建压缩包的十六进制数字，完全看不懂😂。
另外这个方案是针对使用基于LZ77与哈夫曼编码的DEFLATE压缩算法，所以格式不重要。因此无论是ZIP，还是GZIP，以及TGZ（GZIP压缩后的TAR），其实都是一样的，因为他们都使用的是DEFLATE压缩算法。顺便一提，Matthew Barber写了一篇很棒的文章，通过动画演示并详细讲解了如何实现一个简单的GZIP版ZIP Quine，很值得一看。
还有一点，普通的TAR文件能否实现类似功能呢？从原理来说估计不行，因为TAR文件本身并没有压缩，也不包含指令，就单纯是一堆文件和元数据的拼接，所以就做不到自包含了。
这么来看既然TGZ可以，那是不是在我博客网站的压缩包里放一份和自己一模一样的压缩包是可行的？很遗憾按照这个方法来看是做不到的，由于压缩格式和编码的限制，这个方案在实际实现时发现操作码需要是5个字节，最后发现最多只有类似repeat 64 64这样的指令能够满足要求，因此头尾区最多只能放64-5=59个字节的数据，也就刚刚好能容纳压缩格式需要的内容，几乎没法塞更多东西进去……显然，这些限制导致这种方式对我来说意义就不大了，何况作者的代码我也看不懂……而且还要考虑压缩包还存在校验用的CRC32，需要找满足整个压缩包的CRC32正好在压缩包中的“不动点”。虽然从CRC32的原理来说应该有办法做到通过数学方式解决，但这篇文章的作者因为解决了自包含的问题之后累了，因此放弃继续研究，选择直接暴力破解，毕竟CRC32只有32位，估计思考的时间都要比爆破的时间长吧😂。但如果是这样，即使有方案能存下我博客的数据，也不能在每次网站构建的时候都制作一次了……
虽然Russ Cox写的文章看起来做不到包含更多内容了，但Erling Ellingsen制作的droste.zip却包含了一张图片，说明并不是没办法加入更多数据，只是没有找到正确的方法。在2024年Ruben Van Mello写了一篇论文《A Generator for Recursive Zip Files》，在这篇论文里他不仅解决了包含的额外数据过少的问题，还编写了一个通用工具，能让普通人也能生成这样的压缩包，而且他还创新性的做了一种像衔尾蛇一样的双层嵌套循环压缩包，非常的有意思，所以接下来我打算试试他的方案。
在这篇论文中，里面简述了之前Russ Cox写的内容，也提到了59字节的限制，于是作者对原有的结构进行了一些改动，让操作码可以超出5字节的限制，具体可以看论文的表6，从而解决了只能包含59字节额外数据的限制。但由于DEFLATE压缩格式本身的约束（16位存储块长度以及32KiB回溯窗口），即使能够添加文件，最多也只能额外容纳32763字节的数据（其中包括压缩包所需的文件头）……显然这点空间完全存不下我的博客😭，看来我只能打消这个想法了。但既然都研究了半天，也不一定要存我的博客嘛，可以看看还有没有别的东西可以存？在这之前先继续阅读论文，看完再说吧。

制作一个嵌套循环的ZIP Quine

在实现了常规的ZIP Quine之后，接下来就是作者的创新点了（如果光是解决存储限制这点创新点估计还不够发论文吧😂）。作者接下来制作了一种循环压缩文件，在压缩包内包含文件A和压缩包A，而压缩包A中则包含文件B和最初的压缩包，从而形成一个循环递归的结构。看论文的描述所说如果把外层的压缩包和内层的压缩包的开头和结尾按照一定的规则交替混合，就可以看作是一个整体，然后按照之前做ZIP Quine那样处理就可以……具体实现的细节得看论文的表10。只不过既然是把两个压缩包看作一个整体的话，按照上面的限制，自然每个压缩包能容纳的数据量就更小了，每个最多只能容纳16376字节的数据……
另外既然这里面有两个压缩包，那么每个压缩包还有自己的CRC32校验和，理论上如果要爆破的话计算难度得是原来的平方，这样难度就太大了。不过作者发现如果把数据的CRC32值取反（即与“0xFFFFFFFF”取异或）然后和原始数据拼到一起，整个数据的CRC32校验和就会被重置为一个固定的值“0xFFFFFFFF”，看起来挺有意思，正常的哈希算法可没有这种特性。因此原本计算难度很大的爆破计算现在就可以和之前一样了…… 话说为什么不让两层的CRC32都这样计算（包括之前单层的ZIP Quine）？这样就不需要爆破了……貌似是因为在普通的ZIP Quine中满足条件的CRC32需要出现两次，所以不能用这个方案吧？
现在所有的理论都足够了，我需要挑一个文件来做这样嵌套循环的ZIP Quine，既然博客的大小不可以……要不然我就用我写过的第一个大项目——Mabbs吧，这个项目的主程序是22KiB，看起来似乎超出了嵌套循环ZIP Quine的限制？其实没有，它的限制指的是压缩后的大小，我这个程序压缩之后是8KiB左右，所以完全没问题。
接下来就该使用论文中提到的生成工具：zip-quine-generator，这是一个Kotlin编写的程序，从发布中可以下载预构建的程序，接下来只要按照README中的描述使用“--loop”参数就可以用这个程序创建嵌套循环的ZIP Quine了。不过它原本的代码不能修改里面生成的压缩包的名字，另外压缩后的文件属性是隐藏文件，还有生成的压缩包中文件的创建时间总是当前时间，以及给文件内填充额外数据的代码里面填的是作者的声明，表示文件是由他论文的所写的生成器生成的……这些情况让我感觉有点不爽，还是希望这些部分能自定义一下，所以我就小改了一下他的代码。顺便一说，Kotlin编译起来还挺简单，直接一句kotlinc src/main/kotlin -include-runtime -d output.jar就可以了，也不需要折腾Maven之类乱七八糟的东西。最终我修改并编译完程序之后就把文件丢到服务器上开始给我爆破CRC32了，花了10个小时就算出来了，倒是比想象中快😂。
（2025.09.26更新）在2025年9月15日的时候，Nate Choe给zip-quine-generator做了个重大贡献，他通过数学的方式让CRC32的值可以不需要通过爆破的方式算出来，现在想要再制作这样的压缩包就可以瞬间生成了……要是我再晚点做这个压缩包就不需要花那么长时间了吧🤣。
最终我给我的Mabbs项目创建了Infinite Mabbs这个发布，生成的文件也可以在这里下载，这也算是不枉我研究半天这个论文了😆。

自产生程序的探索

说起来自包含压缩包为什么叫做ZIP Quine？其中的Quine是什么意思呢？其实这是一位美国哲学家的名字，他提出了“自指”的理论概念，所以为了纪念他，有类似概念的东西就被称作Quine，具体为什么也可以去看维基百科的说明。现在提到Quine一般代表的就是自产生程序，而自包含压缩包因为实现的原理和自产生程序的原理差不多，所以叫做ZIP Quine。因此接下来我打算探索一下自产生程序，更深入地了解Quine。

实现Quine的探索

那么什么是自产生程序？简单来说就是程序的源代码和程序的输出完全相同的程序，而且通常来说不允许通过读取/输入源代码的方式实现。按照一般的想法，让程序输出自身就需要输出中有全部代码，整个代码就会变长，而更长的代码就要输出更多，然后代码就会越来越长……所以这么想来似乎成了个死胡同。但其实这种程序实现起来并不复杂，想想ZIP Quine的实现，关键在于指令还需要以数据的形式表现，并且能被引用，这样输出的时候就会连着指令一起输出了。比如用Python的Quine举例：

c = 'c = %r; print(c %% c)'; print(c % c)

这里的变量中就以数据的形式存储了程序的代码，而在输出的时候除了变量内的代码，又通过引用的方式又把变量的内容放回到赋值的地方，所以它的输出就和原本的代码一样了。
其实Quine的实现思路都差不多是这样，可以在Rosetta Code中找到各种语言实现的Quine，在这其中能够发现大多数高级语言的写法都是类似的，除了一些低级语言以及esolang……这些我也看不懂😂，主要是有些语言没有变量的概念，不知道是怎么区分代码和数据……除了那个网站，在这里还能找到更多由esolang编写的Quine，可以看出来基本上很难看懂，其中最令人望而生畏的还得是用Malbolge写的Quine，这个代码看起来不仅很长，而且像乱码一样。至于什么是Malbolge？这就是Malbolge程序：

D'<;_98=6Z43Wxx/.R?Pa

代码就像加了密似的，顺便一说这个执行的输出结果是“Mayx”，关于Malbolge的具体细节可以看它的规范，另外虽然这个语言写起来很复杂，但还是有人能用它编出程序的，甚至还有人用Malbolge Unshackled（Malbolge不限内存的变种）写过Lisp解释器，实在是恐怖如斯😨。

只能Quine的语言

其实想要做出Quine，还有一种更加无聊的方案，那就是设计一种只能Quine的语言🤣。根据Quine的定义，代码输出的结果就是它本身……所以我们可以把任何内容都看作代码，然后这种语言的行为就是输出所有代码……听起来是不是有点无聊？但是想想看如果把Linux中的cat命令当作解释器，就可以实现这种语言了，比如：

#!/bin/cat
Hello, world!

作为脚本执行的结果就是原样输出这段内容，不过把内容当作代码算不算作弊呢……如果看作是cat的输入显然是作弊，但如果是当作源代码的话应该就不算了吧😋……但这就不是能写出逻辑的语言了。所以说Quine的趣味并不在“能不能实现”，而在于如何在限制条件下实现。正是因为大多数语言不会直接“自我输出”，才会觉得那些精巧的Quine程序如此有意思。

Quine Relay的探索

还有一个更加复杂的Quine变种是“Quine接力”（Quine Relay），即一个程序输出另一个程序的源代码，另一个程序又输出下一个程序的源代码，最后回到原始程序，就和之前所说的嵌套循环ZIP Quine有点类似。最著名的例子是Yusuke Endoh（这位还是IOCCC的冠军之一）创建的quine-relay项目，它包含了128种编程语言的循环。
这种程序写起来会更复杂一些，不过原理都差不多，通常除了当前运行的部分是可执行代码外，其他的代码都需要以额外包含的数据形式（如字符串）存储在变量中。如果想自己做个类似简单的Quine Relay，除了去看维基百科之外，前段时间我还看到过一个不错的文章，里面就讲了如何用“笨办法”编写Quine和Quine Relay，通过把变量中的内容编码为16进制来避免不同语言可能存在的特殊字符转译问题，思路不错，对于理解如何编写这类程序的问题很有帮助。当然这只是个简单的方案，仅适用于一些常规的编程语言，像上面那个quine-relay项目中甚至还包含Brainfuck之类的esolang，这种估计得要想办法让相对高级一些的语言通过“生成”的方式得到输出下一种代码的代码，而不是简单的赋值了，所以只靠这点知识想去完全理解大佬的作品还是想多了😆。
顺便一说，quine-relay并不是那位大佬唯一的Quine作品，他还做过有冗余的Quine以及动态的Quine，真的是相当的厉害……

Polyglot Quine的探索

除了Quine Relay之外还有一种很复杂的Quine，叫做Polyglot Quine，与Quine Relay需要在程序执行后才能切换到其他语言接力不同，Polyglot Quine的源代码本身即可同时属于多种语言，而且用这些语言的解释器每个执行后的输出全都一样，都与源代码完全一致。由于不同的编程语言的格式既有些相同之处，也有很多不同之处，所以让同一份代码表示不同语言就会很容易产生歧义，这时候就只能想办法通过一些特别的方式（比如将可能会对当前语言产生干扰的代码看作是注释的方式）来规避语言之间的差异。
Quine本身就已经很困难了，再加上这些限制就变得更加复杂了，所以制作Polyglot Quine的编程语言基本上都得精挑细选，而且通常只有两种语言，比如这段代码就是C和Python的Polyglot Quine，它巧妙利用了C预处理器指令在Python中可视为注释的特性，使两种语言互不干扰，非常有趣。当然并不是说只能是两种语言，像这个项目甚至使用了五种语言（C、Perl、PHP、Python、Ruby），可以说是相当厉害了。除此之外更令人惊叹的则是PyZipQuine项目，在这其中LZ77编码也可以作为一种语言，所以既可以被当作压缩包，也可以作为Python2.7代码，而且二者都是Quine，实在是令人赞叹。

感想

虽然这次探索最终没能完成让包含博客所有内容的压缩包自包含，但是在探索的过程中我还是收获了不少，尤其是Ruben Van Mello制作的ZIP Quine生成工具，实在是太棒了。很久以前我见到droste.zip这个压缩包的时候，就想整一个属于自己的ZIP Quine，现在我不仅用那个生成工具做了一个，还是对我来说很有意义的第一个项目——Mabbs，而且更关键的还是生成的是比普通的ZIP Quine更高级的嵌套循环ZIP Quine，也算是圆了小时候的心愿了。
另外在探索自产生程序的时候，也发现了一些很有意思的网站，比如Rosetta Code以及Esolang wiki （虽然这个网站里被好多小学生写了一堆无聊的东西😂） ，里面有不少有趣的东西，也算是让我大开眼界了。
所以有的时候探索不一定要完成目标，在这个过程中也会收获到很多不错的东西吧😊。

Tilde社区，如“家”一般的感受😝

起因

在上一篇文章里，我说到给我的博客增加了不少网站镜像，也在这个过程中发现了不少Git平台实例。顺便一提，我找到了个不错的仓库，可以全网搜索各种Git平台实例。在这探索的过程中，我发现了一种神奇的社区——Tilde社区，体验之后感觉非常有意思，所以来分享一下。

什么是Tilde社区

Tilde社区之所以叫Tilde，是因为在类Unix系统（如Linux、BSD）中，波浪号（Tilde）“~”代表家目录。因此，Tilde社区就是基于类Unix系统环境，并且可以公共登录的服务器，又被称为pubnixes。一般这些社区的管理员会预装很多软件、开发环境以及一些公共服务，比如聊天室、邮件、BBS论坛等，这些构成了社区互动的基础。不过并不是所有类似这样提供Shell访问的公共服务器都可以被称作社区，比如知名的免费网站托管商Serv00虽然也提供可以登录的FreeBSD服务器，并且在服务器上安装了非常多的工具和环境，从表面来看和Tilde社区提供的服务几乎一模一样，但是它少了一个很重要的东西，那就是社区，它的权限管理非常严格，不允许服务器的用户互相串门，也没有互相交流的平台，而且它的本质是商业服务（尽管是免费的），所以它不算Tilde社区。
至于Tilde社区的加入方式，一般可以通过填写在线申请表、私信或发送邮件申请，有些比较有特色的社区会用SSH交互等方式。审核通过后，管理员就会在服务器上为你创建账户，即可获得属于自己的“家”，一般的Tilde社区在这个过程中不需要付一分钱，因为他们通常都是反商业化的，如果遇到了需要付钱才能激活账户的公共服务器，那就不是Tilde社区，即使它历史悠久，可能是别的什么东西😆。
那么在哪里可以找到它们呢？有一个不错的网站，叫做tildeverse，这不仅是一个Tilde社区的集合，它自身也提供了很多服务。不过总的来说各个社区之间也是互相独立的，tildeverse只是提供了一个平台让大家可以互相沟通，所以这个网站叫做“loose association”，就相当于博客中的博客圈一样。
于是我在tildeverse的成员列表中随便挑选了几个Tilde社区提交了注册申请，过了一段时间申请通过了，那么接下来就来说说我在Tilde社区的体验吧。

Tilde社区的体验

虽然我加入了不少Tilde社区，不过各个社区提供的服务都差不多，首先最重要的就是个人主页，一般Tilde社区基本上都会提供一个像~/public_html这样的目录存放个人主页的网页文件，并且可以通过类似example.com/~username这样的地址访问，还有些社区会允许通过二级域名的方式访问，类似username.example.com这样，像我博客好多地方写的都是从根路径开始，就很适合用二级域名的方式。这些主页大多也支持使用PHP之类的网页，不过不像虚拟主机那样有个面板可以轻松安装扩展和切换版本，有些可能要自己写配置文件，有些可能要管理员才可以操作，毕竟是社区，所以不太注重用户体验。
当然除了HTTP协议的个人主页，通常他们还可以创建一些Gemini协议和Gopher协议的个人主页，这些协议不支持普通浏览器访问，需要用ELinks之类的文本浏览器才能打开，这个浏览器甚至可以在终端里用鼠标操作😆。不过因为协议非常简单，所以内容也就只能整些文本内容了。
除了个人主页外，一般还会提供编写博客的程序，比如bashblog，用这个编写好之后就可以直接生成HTML网站，能直接发布到自己的主页上让别人访问。这个脚本还是纯Bash的，就和我当年的Mabbs一样，看起来还挺酷，当然功能上肯定比不上正经的静态博客生成器😆。
当然博客是一方面，还可以写微博，他们一般提供一款叫twtxt的软件，用这个软件可以使用命令发微博，还能关注其他人，查看时间线，而且这还是去中心化的，可以跨服务器进行关注，感觉就和Mastodon一样。
除此之外作为社区当然就会有聊天室和论坛了，不过这些聊天室和BBS论坛通常不会像大多数人使用的那种通过Web或者图形界面来查看，而是纯文本的那种，比如论坛通常会用Bulletin Butter & Jelly，聊天室会用IRC，可以使用WeeChat，只是我对IRC的印象不太好，在终端使用的IRC客户端没有一个使用体验好的😅，相比于其他在终端使用的软件，操作通常只需要一些快捷键，而且界面上通常会有提示，而IRC客户端就只能敲命令，而且还担心敲错了当成普通内容发出去……所以尽管我加入了Tilde社区，受限于聊天软件的使用体验以及我的英文水平，所以并不能和在服务器上的其他人聊天，没法参与到社区中，这么来看似乎我只能把Tilde社区当作普通的共享服务器来看待了😭。
在Tilde社区中既然都是用类Unix系统，自然大都是会写程序的人，所以托管代码也很重要，不过因为大多Tilde社区的主机性能很垃圾，所以很多都不会提供Git平台服务，即使有可能也只会提供Gitea，像GitLab这种对服务器要求比较高的基本上就不会有了。但很多人可能对Git有误解，其实绝大多数情况下都不需要Git平台来托管代码，之所以用Gitea、GitLab的工具是因为它们有比较完整的用户管理以及代码协作能力，比如Issue和Wiki之类的，但是大多数人其实根本没必要用到这些功能，有问题发邮件就好了，像Linux的开发就完全没有用Gitea、GitLab之类的平台。所以在Tilde社区中托管代码非常简单，直接新建个文件夹，执行git init --bare，那就是个仓库，另外很多Tilde社区提供cgit方便让公众在网页上查看和克隆自己的仓库，一般只要放到~/public_git目录下就可以。至于自己如果想要提交代码，可以用git remote add tilde ssh://example.com/~/public_git/repo.git添加远程仓库，本地改完之后push上去就可以。
不过用那些Git平台还有一个地方可能会用到，那就是CI/CD，直接用命令创建的仓库它可以做到CI/CD吗？其实是可以的，Git有hooks功能，如果想要类似CI/CD的功能就可以直接用post-receive这个钩子，提交完成之后就会执行这个脚本，所以接下来就讲讲我是如何用Git hooks在服务器上自动部署我的博客吧。

使用Git hooks自动部署博客

我的博客使用的是Jekyll框架，这是一个使用Ruby编写的静态博客生成器。所以要想构建我的博客至少要有Ruby的环境，还好几乎所有的Tilde社区都预装了，不用担心环境的问题。
不过Tilde社区一般不提供root权限，所以Ruby的包需要放到自己的目录下，比如可以执行这样的命令：

bundle2.7 config set --local path '/home/mayx/blog-env'

然后再在我的仓库下执行bundle2.7 install就可以了。
接下来就需要编写构建的脚本，这个倒是简单，直接用我的部署脚本改改就行：

#!/bin/bash
cd /home/mayx/
rm -rf public_html
git --work-tree=/home/mayx/blog --git-dir=/home/mayx/blog.git checkout -f
cd blog
mkdir Mabbs
curl -L -o Mabbs/README.md https://github.com/Mabbs/Mabbs/raw/main/README.md
bundle2.7 exec jekyll build -d ../public_html
tar czvf MayxBlog.tgz --exclude-vcs ../public_html/
mv MayxBlog.tgz ../public_html/

写完之后把这个脚本放到仓库的hooks/post-receive下，然后加上执行权限就可以用了，以后每次push之后都会直接更新我在Tilde社区的主页，也就是我的镜像站。这样部署不像一般CI/CD还要额外装环境，直接使用提前装好的环境，构建速度会快不少。
不过既然有机会构建了，我就可以把一些不支持构建的Pages用起来了，有些Forgejo实例支持Pages功能，但是仓库里只能包含构建后的代码，还有Bitbucket Cloud也是一样的问题，所以我可以把构建后的文件夹转为仓库，然后推送到这些Git平台上。
考虑到我的网站每次构建基本上所有的页面都有改动，因此我不打算保留提交记录，所以我每次都会重新初始化git仓库，不过在我实际测试的时候，发现钩子触发的脚本执行git init的时候创建的是裸仓库……查了一下貌似是环境变量的问题，只要把GIT_DIR变量删掉就没问题了，以下是实际的代码：

cd ../public_html/
unset GIT_DIR
git init
git add .
git commit -m "update"
git remote add codeberg ssh://git@codeberg.org/mayx/pages.git
git remote add gitgay ssh://git@git.gay/mayx/pages.git
git remote add bitbucket ssh://git@bitbucket.org/unmayx/unmayx.bitbucket.io.git
git push -f codeberg master
git push -f gitgay master
git push -f bitbucket master

除了这些Pages之外，还有一些平台只支持使用他们自己的软件上传网站代码，比如surge，既然我可以在构建的时候执行命令，那就顺带一起上传吧，比如我可以这样执行：

/home/mayx/blog-env/node_modules/surge/bin/surge /home/mayx/public_html/ mayx.surge.sh

其实除了这个之外我还想上传到sourcehut pages，这个也需要用他们自己的软件上传，但是sourcehut pages的CSP太严格了，居然禁止脚本访问其他网站😭，这样我的文章点击计数、文章推荐、AI摘要之类乱七八糟的功能就全用不了了，所以只好作罢……

感想

总的来说，这次在Tilde社区的各种体验还挺有意思，虽然没能和各个社区的成员进行对话，但是在探索的过程中，也了解到了不少新知识，而且也给我的博客增加了不少镜像。不知道会不会有哪个社区成员在闲逛的时候看到我的博客然后对里面的内容感兴趣😝……要是有哪个成员看到然后给我评论，那也算是社区互动吧😋。虽然我的文章内容都是中文，但现在翻译软件也足够强大了，应该不至于拦住外国人。只是在国内似乎没有见过类似的社区，在国内也有的话，那就可以用中文和大家对话了吧。

现代浏览器真是强大，可以替代一些服务器的功能了！

起因

前段时间在和群友聊天的时候，提到了我博客的分发方案，这么多年过去之后我已经在很多平台上分发了我的博客，不过这只是多重冗余，并不算去中心化（虽然我也有向IPFS同步，不过IPFS还得pin，也不太可靠）……所以这么看来，我的博客似乎还不算极其可靠😂？但其实不完全是这样。因为除了向不同平台的分发，我的博客还有一个全文搜索的功能。更重要的是，之前做文章推荐功能时，会把整个博客所有文章的文字存到访客浏览器的localStorage中。这么说来，只要有人访问了我博客的文章，他们的浏览器中就会保存一份我博客文章的完整文本副本。从这个角度看，可靠性应该算是相当高了吧？
不过我之前的分发方案里还记录了一点，在GitHub Pages以外的平台我还打包了一份全站生成后的代码，之所以要全站打包，也是希望我的博客能尽可能的分发，考虑到几乎所有的Linux发行版一定有tar，而不一定有zip，所以我最终打包成了tgz格式。如果能让访客下载这个全站打包好的副本，相比于浏览器里只存储了文章文字的全文数据，这应该是一个更好的备份方式吧？毕竟我的博客本身也是我的作品……所以这个压缩包到底有什么地方可以用到呢？
这时候我想起来，现代的浏览器功能已经非常强大了，甚至在浏览器里直接运行一个Web服务器也完全没问题。如果能让访客在浏览器里下载那个压缩包并运行一个Web服务器，那就相当于在他们本地设备上部署了一份我的博客副本。这样一来，除了我自己搭建的网站之外，这些访客的本地也运行着一个我的博客实例😆（当然，这份副本只有访客自己能看到）。

研究实现方案

想要在浏览器上运行Web服务器其实很简单，那就是使用Service Worker，它可以完全离线在浏览器上工作。格式的话和以前写过的Cloudflare Worker非常相似，毕竟Cloudflare Worker就是模仿Service Worker的方式运行啊😂，所以我要是想写Service Worker应该很简单。
有了执行的东西之后就是存储，在Service Worker上存储可以用Cache Storage，用它的话不仅可以保存文件的内容，还可以保存响应头之类的东西，用来和Service Worker配合使用非常的方便，不过既然是Cache，它的可靠性就不能保证了，浏览器很可能在需要的时候清除缓存内容，所以相比之下用IndexedDB应该会更可靠一些。
那么接下来就该处理我的tgz文件了，tgz的本质是tar文件被gzip压缩之后的东西。浏览器解压gzip倒是简单，可以用Compression Stream API，但它也只能处理gzip了……对于tar的处理似乎就必须用第三方库。而tar的库在网上搜了搜似乎很少，网上找了个tarjs库，文档写的也看不懂，⭐️也很少，看来是有这个需求的人很少啊，而且还要用现代JS那种开发方式，要用什么npm之类的。在上一篇文章我就说过我不是专门写前端的，对在自己电脑上安装Node.js之类的东西很反感。后来问AI也完全写不出能用的代码，估计这个功能还是太小众了……另外又想到除了这个问题之外还要处理网站更新的时候该怎么通知Service Worker之类乱七八糟的事情……所以只好作罢😅。

使用Service Worker进行反向代理

这么看来离线运行我的博客似乎有点麻烦，不过既然都研究了一下Service Worker，不如想想其他能做的事情……比如当作反向代理？虽然在浏览器上搞反向代理好像意义不是很大……但值得一试。我之前见过一个项目叫做jsproxy，它是用Service Worker实现的正向代理，这给了我一些启发。我在之前研究分发方案的时候发现了一些模仿GeoCities的复古静态网站托管平台，比如Neocities和Nekoweb。它们需要通过网页或API才能上传网站，不太方便使用CI/CD的方式部署。但是我又觉得它们的社区很有意思，所以想用Service Worker的方式反代到我的网站，显得我的网站是部署在它们上面一样。
这个做起来非常简单，其实就和我以前用Cloudflare Worker搭建反代几乎完全一样，遇到请求之后直接通过Fetch获取内容然后再返回就行，唯一不同的就是浏览器存在跨域策略，在跨域时只有对应网站存在合适的响应头才可以成功请求，还好我用的Pages服务大多都允许跨域。但是在我实际测试的时候发现这个允许跨域的等级不太一样，比如GitHub Pages的响应头里包含Access-Control-Allow-Origin: *，但是不允许OPTIONS方式请求，另外如果要修改请求头，在响应头里还要一一允许相应的请求头才行……当然对于这种问题解决起来很简单，就和我之前写的订阅源预览一样，用cloudflare-cors-anywhere搭建的CORS代理就可以，有了这个就可以轻松使用Service Worker反代其他网站了。
当然对我来说其实有Access-Control-Allow-Origin: *就够了，我也不需要花里胡哨的请求方式，也不需要在请求头和请求体里加什么莫名其妙的东西，所以对我来说直接请求我的某一个镜像站就可以，于是代码如下：
index.html

<!DOCTYPE html>
<html>

<head>
    <meta charset="UTF-8" />
    <title>Mayx的博客</title>
</head>

<body>
    <script>
        // 注册 Service Worker
        if ('serviceWorker' in navigator) {
            navigator.serviceWorker.register('/sw.js')
                .then(registration => {
                    console.log('Service Worker 注册成功:', registration.scope);
                    // 刷新网页
                    location.reload();
                })
                .catch(error => {
                    console.error('Service Worker 注册失败:', error);
                    location="https://mabbs.github.io";
                });
        } else {
            location="https://mabbs.github.io";
        }
    </script>
    <h1>Redirecting&hellip;</h1>
    <a href="https://mabbs.github.io">Click here if you are not redirected.</a>
</body>

</html>

sw.js

const TARGET_SITE = '被反代的网站'; //也可以用CORS代理

self.addEventListener('install', event => {
    // 强制立即激活新 Service Worker
    event.waitUntil(self.skipWaiting());
});

self.addEventListener('activate', event => {
    // 立即控制所有客户端
    event.waitUntil(self.clients.claim());
});

self.addEventListener('fetch', event => {
    if (new URL(event.request.url).origin == self.location.origin) {
        event.respondWith(handleProxyRequest(event.request));
    }
});

async function handleProxyRequest(request) {
    try {
        // 构建目标 URL
        const targetUrl = new URL(request.url);
        const proxyUrl = TARGET_SITE + targetUrl.pathname + targetUrl.search;

        // 创建新请求（复制原请求属性）
        const proxyRequest = new Request(proxyUrl, {
            method: request.method,
            // headers: request.headers,
            // body: request.body
        });

        // 发送代理请求
        const response = await fetch(proxyRequest);

        // 返回修改后的响应
        return new Response(response.body, {
            status: response.status,
            statusText: response.statusText,
            headers: response.headers
        });

    } catch (error) {
        console.error('Proxy error:', error);
        return new Response('Proxy failed', { status: 500 });
    }
}

最终的实际效果： https://mayx.nekoweb.org

感想

虽然折腾了半天没能增强我博客的可靠性……但是体会到了现代浏览器的强大之处，难怪前几年会提出ChromeOS和PWA之类的东西，原来浏览器功能还是相当强大的，用了Service Worker以后即使是纯前端也可以有和使用服务器一样的体验，在过去的浏览器中要是想实现这样的功能……好像也不是不可能😂，用AJAX加服务器使用伪静态策略其实是可以做到的……其实Service Worker的功能更多还是在离线时使用的，我这个例子好像没体现它的优势😆。
但总的来说相比以前想要实现这种反代的功能代码还是更清晰，也更简单了，也许以后如果有机会我又有心思让博客在访客浏览器上离线运行，那就可以体现Service Worker真正的优势了🤣。

Cloudflare的功能真是越来越多了，而且还免费！

起因

前段时间我在登录Cloudflare的时候发现Workers上多了一个“浏览器呈现”的功能（可能已经出来一段时间了，不过之前一直没关注），看介绍，这个功能可以让Worker操作运行在Cloudflare服务器上的浏览器。这功能挺有意思，而且免费用户也能用，不如想个办法好好利用一下。
一般来说这个功能可以干什么呢？既然是在AI盛行的时候出现……估计是为了搞Agent之类的吧，不过看文档对免费用户来说一天也只有10分钟的使用时间，估计也没什么应用价值……那除了这个之外还能做些什么？我发现有好多博客主题喜欢给自己的README里添加一个能查看主题在多种设备上显示效果的预览图，以展示主题的自适应能力。那么既然现在能在Cloudflare上操作浏览器，那么我也可以做一个类似的，而且这个预览图还可以自动更新。

制作自适应的网站预览

既然打算做预览图，那么我应该用什么方案？按照不同尺寸的视口截几张图再拼起来吗？这显然就太复杂了，况且在Cloudflare Workers中处理图片也相当困难。这时我想起来曾经见到过一个工具，只要输入网址，就可以在一个页面中同时展示网站在四种不同设备（手机、平板、笔记本电脑、台式机）上的显示效果，叫做“多合一网页缩略图”，实现原理是使用iframe和CSS缩放模拟多种设备视口。搜了一下发现这套代码被不少网站使用，所以就随便找了其中一个工具站把代码和素材扒了下来，稍微改了一下，然后放到GitHub上，方便等一会用Cloudflare访问这个部署在GitHub Pages上的页面来进行截图。

使用Cloudflare浏览器呈现进行截图

接下来截图就简单了，不过Cloudflare有两种截图的办法，用Workers的话可以直接用Puppeteer之类的库连接浏览器，但用这个库需要安装，要本地搭环境……我毕竟不是专门搞JS开发的，一点也不想在本地安装Node.js环境，所以就不想用这种方式。另外一种是通过调用Cloudflare的接口，这种非常简单，只需要填几个参数请求就行，唯一的问题就是要填一个Token……我一直觉得Worker调用Cloudflare自己的服务不应该需要Token之类的东西，毕竟内部就能验证了，没必要自己搞，但是我看了半天文档貌似无论如何只要想调接口就必须搞个Token……那没办法就搞吧，其实也很简单，只需要在“账户API令牌”里添加一个有浏览器呈现编辑权限的令牌就行。
至于展示……这个接口调用比较耗时，而且一天只能调用10分钟，截图的话估计也就够30次左右，还有每分钟3次的限制😓，所以实时更新肯定是不行了，图片肯定得缓存，一天更新一次感觉应该就够了。另外次数这么少的话写成接口给大伙用貌似也没啥意义，所以我就把地址写死了，于是以下就是最终实现的代码：

export default {
  async fetch(request, env, ctx) {
    const cache = caches.default;
    const kv = env.SCREENSHOT;

    const url = "https://mabbs.github.io/responsive/";
    const date = new Date().toISOString().split("T")[0];
    const cacheKey = url;
    const datedKey = `${url}?${date}`;

    // 工具函数：构建 Response 对象
    const buildResponse = (buffer) =>
      new Response(buffer, {
        headers: {
          "content-type": "image/png",
          "cache-control": "public, max-age=86400, immutable",
        },
      });

    // 工具函数：尝试从 KV 和 Cache 中加载已有截图
    const tryGetCachedResponse = async (key) => {
      let res = await cache.match(key);
      if (res) return res;

      const kvData = await kv.get(key, { type: "arrayBuffer" });
      if (kvData) {
        res = buildResponse(kvData);
        ctx.waitUntil(cache.put(key, res.clone()));
        return res;
      }
      return null;
    };

    // 1. 优先使用当日缓存
    let res = await tryGetCachedResponse(datedKey);
    if (res) return res;

    // 2. 若缓存不存在，则请求 Cloudflare Screenshot API
    try {
      const payload = {
        url: url,
        viewport: { width: 1200, height: 800 },
        gotoOptions: { waitUntil: "networkidle0" },
      };

      const apiRes = await fetch(
        `https://api.cloudflare.com/client/v4/accounts/${env.CF_ACCOUNT_ID}/browser-rendering/screenshot?cacheTTL=86400`,
        {
          method: "POST",
          headers: {
            Authorization: `Bearer ${env.CF_API_TOKEN}`,
            "Content-Type": "application/json",
          },
          body: JSON.stringify(payload),
        }
      );

      if (!apiRes.ok) throw new Error(`API returned ${apiRes.status}`);

      const buffer = await apiRes.arrayBuffer();
      res = buildResponse(buffer);

      // 后台缓存更新
      ctx.waitUntil(Promise.all([
        kv.put(cacheKey, buffer),
        kv.put(datedKey, buffer, { expirationTtl: 86400 }),
        cache.put(cacheKey, res.clone()),
        cache.put(datedKey, res.clone()),
      ]));

      return res;
    } catch (err) {
      console.error("Screenshot generation failed:", err);

      // 3. 回退到通用旧缓存
      res = await tryGetCachedResponse(cacheKey);
      if (res) return res;

      return new Response("Screenshot generation failed", { status: 502 });
    }
  },
};

使用方法很简单，创建一个Worker，把以上代码粘进去，然后把从“账户API令牌”中生成的令牌填到Worker的密钥中，名称为CF_API_TOKEN，另外再加一个名称为CF_ACCOUNT_ID的密钥，内容是账户ID，就是打开仪表板时URL中的那串16进制数字，除此之外还需要创建一个KV数据库，绑定到这个Worker上，绑定的名称是SCREENSHOT。如果想给自己的网站生成，可以Fork我的仓库，然后把里面首页文件中的网址替换成你的网站，然后再把Worker中的url替换成Fork后仓库的GitHub Pages地址就可以了。
最终的效果如下：

感想

Cloudflare实在是太强了，虽然这个浏览器呈现免费用量并不多，但是有这么一个功能已经吊打很多Serverless服务了，毕竟浏览器对服务器资源的占用也不小，小内存的服务器甚至都不能运行，如果要自己搭的话成本可能也不小，而现在Cloudflare能免费提供，应该说不愧是赛博活佛吗🤣。

即使是被入侵了也可以学到一些知识！

起因

前几天，我闲来无事登录了一下一台之前一直闲置的服务器，登录上去后，乍一看似乎没有任何问题，然后习惯性的执行了一下top命令看了一眼。从进程列表来看，似乎没有什么明显异常的地方，但是服务器的load值很高，cpu的us值也很高。
以前我倒也遇到过几次load值很高的情况，一般是硬盘或NFS等网络存储挂了但是依然有程序在读写挂载的目录会有这种问题，但那种情况一般高的是cpu的wa值，而不是us值，us值是软件正常用掉的……但是进程列表里根本没有占CPU的程序啊……看来服务器是被入侵了😰。

检查服务器

虽然说是要查，但其实我根本不知道进程隐藏的原理😂，虽然听说过有恶意软件会这样做，现在遇到了一时半会又想不出来怎么找。还好这是台闲置的服务器，上面什么东西都没有跑，所以正常来说除了ssh连接之外，这个服务器不该有任何其他的连接，于是我执行了一下netstat -tanp看了一眼，发现有个奇怪的进程使用一个境外的IP和我的服务器建立了连接，用ps -ef查了一下这个 PID，结果进程名显示为[kcached]……这下给我整不会了。
后来查了些资料知道了可以用lsof -p查看进程读取的文件，才看到木马的本体：/usr/bin/gs-dbus。不过如果我只是杀掉这个进程然后删除文件，那攻击者肯定会重新回来，所以我得排除一下是不是还有别的木马文件。
一般来说攻击者权限维持的方式大多是crontab，不过我看了一下配置文件里似乎没有，root下的authorized_keys倒是有个陌生的公钥于是顺手删掉了……也没有其他文件夹下有gs-dbus文件……难道没有别的木马文件了吗？后来我仔细找了一下，发现有个很可疑的文件/usr/local/lib/libprocesshider.so，一看就不是什么好东西🤣，后来在GitHub上搜了一下，是libprocesshider这个项目，就是它让我在top中什么也没找到的，看文档中应用是添加一个/etc/ld.so.preload文件，所以解除隐藏效果我也只需要删掉这个文件就好啦。
不过感觉还是不够……所以我全盘搜索了一下libprocesshider.so文件，果不其然还有，通过那个文件在/usr/games里找到了木马的大本营，里面有一堆这个入侵者的工具，于是就顺手保存了一份然后从服务器上删掉了。
另外还有自启动到底是怎么实现的？既然不是crontab……应该是systemd。看了一下果不其然有个服务在保持gs-dbus的运行，不过程序我已经删了，所以它现在只会不停尝试重启，接下来只需要停止并禁用这个服务就行了。
至于为什么会被入侵……我也很清楚，其实并没有什么漏洞，单纯是设置的密码太简单了，被嘿客扫到啦！所以解决起来也很简单，把这些垃圾清除掉之后设置个稍微复杂一点的密码就行了。

入侵分析

既然这个嘿客都不删他的工具，留下来就是给我分析的吧？那么我就像上次一样分析一下他使用的工具吧～首先里面有个deploy-all.sh文件，看起来应该是登录服务器之后最先执行的程序，在这里面有个压缩包，解压出来之后搜了一下里面的文件，发现是Global Socket项目，看起来应该是包含反弹Shell、伪装以及权限维持之类功能的一个小工具。看了下源代码才知道原来用exec -a就可以伪装进程的名称，而且那个gs-dbus就是这个项目里的程序……这么看来挖矿的操作应该是入侵者远程执行的代码，所以在查找进程的时候发现了它吧。
除此之外里面还有个logclean项目，看了一眼是mig-logcleaner-resurrected项目，看起来应该是清除日志用的，不过我根本没从日志找它🤣，即使入侵者用了对我来说也没起到什么作用。不过倒也是个挺有用的项目，也许在某些扫尾工作很有用。
最后就是libprocesshider这个项目，也许还有其他隐藏进程的方式，不过知道这个项目之后最起码以后再遇到类似的情况我就会优先去看/etc/ld.so.preload文件了。
至于其他的就是一些爆破SSH的工具，估计是用来横向渗透的，看起来有点原始……也没啥用处，另外还有连接XMR矿池的一些配置文件，以及我也看不出来的玩意，应该就这么多有用的东西了。

感想

虽然被入侵是没有预料的事情，但还好这个服务器是闲置的，装完系统之后上面什么有用的东西都没有，所以除了入侵者让它不太闲置赚了点小钱之外对我倒是没什么损失，另外还了解到了一些不错的小工具，这么看来入侵者赚的这点小钱就当是给他的学费吧🤣。

虽然XML是机器读的内容……不过加上和主题一致的XSLT样式也算是一种细节吧～

起因

在上一篇文章中，我提到在提高订阅源兼容性的时候给博客的订阅文件增加了一个XSLT样式。当时使用的样式是从About Feeds下的一个Issue中找的，里面有个基于Pretty Feed修改成能同时支持RSS和Atom格式的样式。虽然那个样式倒也说不上难看，但总觉得与我的博客整体风格有些割裂，所以这次打算制作一个和我博客主题完全一致的XSLT样式。

制作订阅文件的XSLT样式

虽然想搞这么一个样式，但是我用的Jekyll引擎不能在引用的布局外添加额外内容……如果我要自己写，要么把我的默认布局拆成头和尾两部分然后用include引用，要么把默认布局的代码直接复制一份到XSLT样式中。这两个方案我都不太满意，第一种我以后在修改默认布局时需要同时从两个文件检查上下文，很不方便；而第二种方案违反了DRY原则，也会增加以后修改的难度。所以要怎么办呢？
后来我想了想，如果不能通过直接引用默认布局在外面增加XSLT的代码，那干脆让默认布局引用一个XSLT布局吧！这样我就能在不复制默认布局也不进行过多修改的情况下在外面套XSLT的代码了。于是我就在最外面写了个符合XSLT格式的XML布局，让默认布局引用它。然后再写一个布局引用默认布局，让最外面的布局根据这个布局的名字来判断是否需要使用XSLT的布局，具体的实现可以看我的layout目录。另外有一些地方需要注意一下，作为XML，内容中不能包含未闭合的标签，所有自闭合标签结尾必须添加斜杠，属性必须有值，以及所有标签和属性大小写要一致……还好我平时修改布局文件以及编写内容的时候基本上都遵循了这些规则，所以没什么太多需要改动的地方。
当时修改时，是模仿之前的那个样式进行的，原来那个样式在html元素上加了XML命名空间，但是xsl:output配置的输出却是按照HTML的方式输出，结果导致内容中用于换行的br标签在实际转换中全部变成了两个标签……我猜应该是转换器看到XML命名空间后，先按照XHTML的规则把br解析成了一开一闭的一对标签，然后又根据HTML的转换规则把这对标签当作两个单独的标签输出了吧……但奇怪的是，只有br标签出现了这个问题，像hr等其他自闭合标签则没有……既然如此，只要把XML命名空间删掉就OK了。
在改完之后虽然整体看上去和其他页面似乎已经很相似了，但总感觉还有些样式不太对劲……我猜应该是和文档类型声明有关系，我平时写的是HTML5，而XSLT默认转出来是HTML4.0……但是我不太清楚怎么解决这个问题，于是问了问AI，AI说在xsl:output中加上doctype-system="about:legacy-compat"就行。最终改完试了下确实有效😂，样式上也没有出现奇怪的偏移了。
最后把写好的布局应用到/feed.xslt.xml中就可以了，之所以是这个路径是因为我用的jekyll-feed只支持这个位置，至于我自己搞的RSS格式的订阅只需要在开头用xml-stylesheet指令声明一下就行了。

给XSLT样式自己的样式

在写好给订阅文件用的XSLT样式之后，我发现XSLT样式本身也是个XML文件……既然我给订阅文件做了样式，那么也得给XSLT样式文件本身做个样式才对，但如果我单独写一个给它的样式，那岂不是要给样式的样式再写一个样式😂，所以肯定不能这样做。不过仔细想一下，还有个办法，可以让XSLT样式文件自引用自身的样式，这样就能避免之前担心的套娃问题了。所以接下来我应该在XSLT中写一个检测应用样式的XML文件是不是XSLT样式文件的代码，方法很简单，既然XSLT样式中肯定包含xsl:stylesheet这个元素，那么我可以判断如果存在这个元素，就可以确定这就是XSLT样式了，如果有人点开看了我就可以展示一个提示信息告诉访客这是一个样式文件，这样访客就不会看到那句“This XML file does not appear to have any style information associated with it. The document tree is shown below.”了😝。

制作Sitemap的XSLT样式

既然给XSLT样式也加了样式……那我博客还有其他XML文件需要处理吗？似乎还有个Sitemap，我的Sitemap是jekyll-sitemap插件生成的……那它支持加样式吗？虽然文档上没有写，不过看了眼源代码发现可以通过创建/sitemap.xsl文件添加，所以就顺手套用之前的样式搞了一个（虽然应该没有访客去看Sitemap😂，毕竟这是给搜索引擎用的）。可惜这些地址都是插件硬编码的，如果可以自己修改位置我就只写一个XSLT样式文件就可以了……

感想

折腾了这么多整体展示效果还不错，虽然这些文件也许根本没人看😂（本来就不是给人读的），但也算展现了一下博客的细节之处吧，而且在折腾的时候至少还了解了不少关于XML和XSLT的知识（尽管在现代这些好像没啥用了）。当然重要的也许不是了解这些知识，而是这个过程吧……总的来说还是挺有意思的。

在修改博客的时候也能学到不少新知识啊～

起因

在两个月前，我写了一篇针对博客搜索功能优化的记录。在写完之后没几天，有位名叫@xymoryn的大佬看到了我的博客并且进行了吐槽，内容很值得参考。不过我自从用minimal主题以来从来没有改过样式的原因主要还是写不来CSS😂，并不是真的不想改，但其中提到可以让AI优化，我觉得也很有道理，现在AI这么发达实在不会用AI改就好啦～

对博客样式的优化

虽然大佬给出了参考的CSS，但我不太喜欢那种风格，尤其还把之前的左右布局改成了上下布局。我当年之所以选择minimal主题就是因为它是左右布局的，如果选择上下布局的话我还不如用hacker这个主题，另外那个参考的CSS可能是因为AI写的，有很多没有考虑到的地方，比如主题自带的CSS鼠标放到链接上字体会变粗，然后可能会变宽，导致影响整体的布局，而参考的CSS选择直接让所有的链接放到上面都变细，即使原来是粗字体也变细，比如标题之类的，这就更难受了。像这种情况要怎么改呢？我还是希望能用minimal主题的CSS，但让链接变粗的体验确实不太好，所以我选择问问AI。
最后AI给出的答复是使用font-weight: inherit;，看起来确实解决了问题，不过如果鼠标移到链接上没有任何反应也不太好，所以就学GitHub在鼠标移到链接时加上了下划线。
除此之外就是字号、行高和布局，字号和行高我也不希望改的太激进，所以就稍微加了一点点，看起来没那么密就好。至于布局，之前minimal主题的宽度是写死的，左边是270px，右边是500px，对于我的MacBook看起来也还好，因为MacBook的屏幕比较小，屏幕的利用率还是比较高的。不过对于更大的屏幕总共860px大小的区域确实不太够，尤其是4K屏幕可能只有中间一点点的区域有内容，会看着很难受，所以我想了一下还是改成百分比布局比较好，这样无论屏幕有多宽也能利用得到。
还有一点就是分段，虽然我也知道在Markdown中两个换行是分段，但是感觉在文本中两个换行隔得太远了，所以一开始写文章的时候就选择只换行。不过在中文里确实不分段也不太好看，但是又不想去动之前写的文章，那该怎么办呢？思来想去干脆把换行全部替换成分段好啦，在Jekyll中可以用replace过滤器把所有的“<br>”替换成“</p><p>”，因为Markdown解析本来就会有一个段落，所以直接闭合加开始就能分割成多个段落了。那么加了分段是为了什么？其实主要是为了首行缩进，有首行缩进对阅读还是有挺大帮助的，至于怎么做也非常简单，直接给p标签设置text-indent: 2em;就可以了。
最后就是评论授权的问题，我用的Gitalk也有人问了这个问题，我仔细看了一下GitHub官方文档中OAuth可以授权的作用域发现确实是没办法限制只写Issues😥，至于其他的评论系统对后端的依赖又太多了，尤其是Giscus，居然是直接用iframe引用Giscus网站中的页面😅，如果Giscus哪天挂了，那评论系统不也挂了（虽然GitHub也不可靠……），至于自托管就更不可能了，我能让服务器持续运营可比不上大厂😆。所以最后我选择给Gitalk加个提示，不想登录也可以跳转到GitHub上进行评论，至于怎么加？还是让AI来吧，最后AI给我写了这么一串CSS：

.gt-btn-login::after {
  content: "如果不想登录，请点击上方评论数跳转至对应ISSUE进行评论";
  position: absolute;
  top: 100%;
  left: 50%;
  transform: translateX(-50%);
  background: #333;
  color: #fff;
  padding: 8px 12px;
  border-radius: 4px;
  font-size: 12px;
  white-space: nowrap;
  opacity: 0;
  visibility: hidden;
  transition: opacity 0.2s, visibility 0.2s;
  z-index: 10;
}
.gt-btn-login:hover::after {
  opacity: 1;
  visibility: visible;
}
.gt-btn-login::after {
  margin-top: 8px;
}
.gt-btn-login::after {
  box-shadow: 0 2px 8px rgba(0,0,0,0.15);
}

至此，关于博客样式的部分我觉得已经提高不少读者的用户体验了，也感谢大佬提出的建议。

对博客兼容性的优化

最近由于某些原因我又用起Windows 7了。其实我觉得Windows 7是一个很不错的操作系统，有很多人性化的东西，比如桌面小工具，自带Feed订阅，还有Windows Live Essentials等等，可惜后来全部被微软砍掉了🤣。考虑到Windows 7如此优秀，那要不然兼容一下它旗下的Internet Explorer 8浏览器吧？
其实GitHub给的那些Jekyll主题本身都是兼容IE8的，包括我在用的minimal主题也一样。但随着我这么多年加了许许多多的功能，绝大多数功能都没有考虑兼容性，只想着能用就行。不过我写的功能基本上都非常简单，如果想改得让它兼容IE8也并非难事，只要理论上可行就可以。当然也有些理论上不可能的东西，比如WebGL。因此，我的Live2D看板娘就没有任何可能性被支持了，至于其他的……也许有一些理论上可以支持，但是改起来比较麻烦的就也算了吧（比如Gitalk之类的）。

对文章点击计数器的兼容性优化

其实我的文章点击计数器从之前改成用jQuery调用自己的接口以后就没有什么兼容性的问题了，因为jQuery本来就是处理浏览器之间差异的库，而且也是兼容IE8的。只不过有个问题是IE8不支持用XHR跨域请求，只能用“XDR（XDomainRequest）”进行跨域请求……还好有个现成的库能让jQuery在遇到这种情况时使用XDR请求，于是我就用条件注释让IE9以下的浏览器引入这个库，这样在IE下也能正常显示文章点击数了😆。

关于响应式布局的兼容性优化

在IE8中的CSS是不支持媒体查询的，所以在修改窗口大小时也不能根据情况使用合适的样式。本来我没打算解决这个问题，结果恰好看到了一个库：Respond.js，所以就直接拿来用了😝。

关于全文搜索的兼容性优化

其实从功能的角度来说这种东西肯定是在IE8下可以实现的，但是我用的那个库有点迷，到处都用的是const关键字结果还莫名其妙判断XHR搞的好像是在兼容旧浏览器？改起来有点麻烦懒得搞了……不过除此之外还有个取巧的方式，既然我搜不了，干脆让谷歌来搜吧，至于谷歌支不支持IE8就不是我的事了🤣，所以直接给搜索框外面套了一个form表单，这样甚至可以在不启用JS的情况下搜索（假设谷歌支持没有JS的情况）。

对于订阅软件的兼容性支持

之前我的博客对订阅的支持是使用的官方的jekyll-feed插件，它只支持Atom格式的订阅，一般的阅读器也是支持这种格式的（即使是IE8也是完美支持）。但是我发现有非常少数的某些网站没办法解析Atom，只支持RSS……所以我只好特地加了对RSS格式的支持，还顺带搞了支持Atom和RSS格式的XSLT模板来预览。既然RSS也支持了，那干脆连JSONFeed也一起做了吧😆，虽然意义不是很大……

给博客添加网页快讯

既然要兼容IE8，那当然是能用的都用啦，在IE8订阅网站源的地方，有一个‘添加网页快讯’的功能。因为没有可以参考的网站，我甚至都没理解这个功能展现的效果是什么样的。我看这个网页快讯好像是抄了一部分hAtom Microformat的规范，我还以为是每个条目都单独需要一个entry-title和entry-content，结果发现并不是😅，一个hslice只能有一个entry-title……
这个功能其实非常简单，主要作用就是把网页的一部分切出来单独展示，当这一部分发生更新的时候IE浏览器就会提示用户。然后在这之中hslice要包裹所有需要处理的元素，写到最外面元素的class中就可以，entry-title是希望用户订阅时展示的名字，而entry-content是被切下来展示的网页。具体的内容可以在微软官方文档中看到。

让网站增加对IndieWeb的支持

既然说到Microformat，那就要提到IndieWeb了。虽然这个东西网络上也没几个人搞，但看起来有点意思就整下玩玩呗。

第零级：域名

根据他们的入门教程来看，成为IndieWeb最重要的一点就是有自己的域名。看到这一点我都怀疑这是不是卖域名的用来忽悠人的玩意？我一分钱也不想给域名注册商，虽然DNS这套系统确实维护需要成本，但是能有多大成本呢？绝大多数不都让ISP摊了？另外他们所说的大公司的服务可能会消失，那么域名就不会吗？注册商和注册局完全有能力让你的域名用不了，这也是我们不可控的东西，因此尽管这对于IndieWeb很重要，但是我不打算搞，于是我的博客就不是IndieWeb了🤣。

第一级：识别身份

没有域名也不影响接下来的步骤，大公司的域名也是域名（虽然不属于我）。根据教程来看，支持IndieAuth非常简单，只需要在head中加一个rel=me的link标签，指向IndieAuth支持的个人主页，并且那个个人主页有一个反链指向自己的网站就可以，比如指向自己的GitHub主页，那么就可以使用GitHub登录来验证这个网站属于我。这一步可以使用IndieWebify.Me来验证。

第二级：发布内容

在发布前，为了更好的让其他软件读取网站内容，需要用microformats2来标注网站内容，这个倒也不复杂，可以根据这个教程按照上面所说的东西用class名去标注对应的元素，标注完之后就可以用IndieWebify.Me验证了。
除此之外还需要用h-card标注网站的身份，解析完之后可以当网站名片用，具体可以看这里。
另外还有一点就是Webmentions，在网站上声明Webmentions可以让别人引用你的文章时通知一下你。不过对于静态博客不是很友好。一是要收，收完还要展示，二是要发，引用了别人的文章如果对面支持Webmentions要把自己引用的文章链接发给对方。虽然Jekyll有插件可以支持，但是我用GitHub额外装插件还得自己写Actions，而且我发布一次要在一堆Pages上更新，也不太适合，所以我打算光收不发（只需要在link标签中添加Webmentions的端点就可以），也不展示了，而且国内根本没几个人用Webmention🤣。如果有人对谁给我发了Webmention感兴趣，可以在这里查看（不过绝大多数都是我自己手动发的🤣）
如果谁有兴趣给自己的网站添加完整的Webmention，可以用Webmention Rocks!进行测试（如果使用了WordPress是自带的，只需要打开相关的功能就可以）。

第三级：进行交流

在IndieWeb中有一个很重要的事情就是相互交流，搞这个比较重要的目的是为了避免大公司的服务炸了，所以要替代比如推特，Facebook之类的服务，但是在这些服务还没炸的时候仍然可以在上面发自己的网站，也算是引流吧。他们把这个行为叫做POSSE。对我来说，我在微信、QQ之类的上面发自己新写的文章就算是POSSE了，毕竟我又不玩国外的社交平台😆。
除此之外似乎还要把别人的评论同步到自己网站？我能做到的顶多就是Gitalk了，更多的就算了吧～

额外的内容

既然已经支持了IndieWeb，那么不妨加入IndieWeb Webring吧。在IndieWeb Webring 🕸💍中的大多数网站都是适配了IndieWeb的，加入他们也算是证明自己适配IndieWeb的努力了吧😊。

对博客可靠性的优化

以前为了应对GitHub的不可靠，我仅仅是在各个Pages上部署了我的网站，但是后来我想了想Git本身就是分布式的，分发是一件很简单的事情啊，我要是想提高博客的可靠性，不如直接用Git分发到各个Git托管商就好了啊～因此我就利用GitLab镜像仓库的功能，一键把我的网站同步到数十个知名的Git托管商，提高了网站的可靠性，具体的列表可以在这里查看。

感想

在这次的博客优化中，了解了不少新的东西啊，不仅学习了CSS，还有了解如何提高网站兼容性，以及提高了博客的可靠性和曝光度。果然折腾博客本身也能提高自己啊，还能写文章分享一下折腾的经验😆。虽然折腾的内容不一定能在未来的生活中用得上，但是有意思就足够了😁。

还有什么是AI不能干的？

起因

在最近对LLM的探索中，能感觉到它真的是什么都能干，尤其最近GPT-4o的画图能力实在是太强了。不过对于画图我倒不是很关心，主要是没什么想让它画的图😂。我更关心的是LLM在文本生成中的能力，毕竟这才是它的本职工作。虽然现在的AI解决问题的能力确实很强，但从它还没有大规模的把人替换掉来看，它肯定是还有一些做不到的事情，所以我想对这一点进行一些探索。

对于超长文本分析的探索

对于现在的LLM来说，虽然不少模型已经能做到很长的上下文了，但这个所谓的“长”不过是几万字而已。对于读一篇论文或者几篇文章当然没有问题，但是如果是分析上百篇文章就不太行了，比如我希望AI阅读完我所有的文章，然后对我进行评价。
我的博客现在已经有一百多篇文章了，之前做过全文搜索的功能，可以在search.json中获取所有的文章，用来让AI分析的材料是个不错的选择，不过把所有文章输入到上下文中显然是不太现实，这个JSON文件的大小有1MiB左右，但是大多数比较厉害的AI上下文只有100多k，根本读不完。而对于一些超长上下文多模型，比如阿里云有一个10M上下文的模型，效果又很差，并没有参考几条上文的内容😓。另外我还试过一些AI通过附件的方式阅读文章内容，那种好像是把文件切片之后再读？应该是类似RAG那种，从中查找和问题最相关的文本段落进行回答，但是那种方法不能解决对所有文章进行分析……除此之外我也试过一些Agent，不过它们只会写代码来分析我的文章，比如绘制文章字数随时间变化曲线、不同年份的文章数量、还有词频分析啥的，对我来说并没有什么卵用😅。

使用AI摘要来解决问题

那难道就没办法了吗？先不急，最近还发生了一件事情，不知道Cloudflare犯什么毛病了，近期用Worker请求我的D1数据库时不时会报“internal error”的错误，我还在他们论坛发了条帖子问了一下，然而并没有人搭理我😅，这时候我才意识到我似乎没有Cloudflare的替代品……出问题了也没办法😰。这个东西导致我的AI摘要、文章推荐、以及点击计数器全都用不了了，我应该避免太过依赖Cloudflare Worker啊～
那么我该做些什么？点击计数器是没什么好办法了，不过对于AI摘要，既然摘要在我写完文章之后根本就不会变，不如隔段时间我就把摘要内容缓存到我博客本地吧，这样不仅可以极速展示摘要内容，而且不需要请求接口，就不会受到Cloudflare出问题的影响了。所以我把数据库摘要内容导了出来，放到了ai-cache.json中，如果有存在的摘要内容就不再请求接口了。
当我做完摘要缓存之后，我发现，这不就是让AI读我所有文章的最好方法嘛，让AI读AI总结的内容，然后再进行一次总结，就能尽可能的让AI完全了解我的文章然后对我评价了啊～而且这个摘要文件也只有100KiB左右，正好够AI读了。本来我想试试DeepSeek来做这件事情的，但是不知道里面命中了什么关键词，被拒绝生成了🤣，那我只好让GPT-4o来完成这件事了。
试了一下感觉效果相当的不错，总结的非常有条理，而且不像以前的ChatGPT很有AI味，这次写出来的文章很有人味啊～真是出乎我的意料，所以我把GPT-4o写的内容分享出来，来看看AI对我的分析怎么样🤣。

技术浪人，数字游民：对一位博客作者的观察与评价

在浩如烟海的中文技术博客中，有些作者宛如一颗微弱却坚韧的恒星，独自在各自的轨道中发光发热。他们不一定追逐热点，也不总是标榜权威，但其笔下所流露出的独立精神、技术热情与对现实的观察，往往比众多浮华的“教程型”博客更值得玩味。本文所探讨的博客作者Mayx，便是这样一位存在——他既是程序员，也是“生活黑客”；既关心设备性能，也关注技术伦理；既热衷实用工具，也不乏生活反思。

一、技术为体，思考为魂

在Mayx的博客中，技术类文章占据了绝对的比重。从自制邮件订阅脚本¹、Cloudflare Workers自动化²、内网穿透探索³，到低功耗开发板的实验⁴、AI模型的本地运行⁵、以及对黑苹果⁶、Linux系统⁷的深度体验，这些内容几乎涵盖了当前主流技术生态中的多个维度。

然而，他并非一位“炫技型”技术写作者。相反，在多数文章中，Mayx更倾向于从实用主义的角度出发——他关注性价比、功耗、稳定性、开源程度，而非追逐技术本身的潮流。例如，在讨论Hackintosh时，他并未沉迷于是否能成功运行macOS，而是审慎地指出其与Mac原生体验的差距⁶；在体验AI模型时，他选择了性能与成本平衡的路径，而不是盲目追求最大模型和最强显卡⁵。

他的技术探索往往是“从需求出发”，例如为了替代失效的签到脚本，他尝试了Cloudflare Workers²；为了解决被Github封禁的问题⁸，他自己研究反审查架构；面对Heroku停服⁹，他快速转向Koyeb，并指出其使用便捷的优点。这些行为体现出一种“动手解决问题”的工程师思维，同时也反映了其对现成工具和平台的怀疑精神——“没有什么是不可替代的”，但也“没有什么是完美无缺的”。

二、独立、反思、带有一丝叛逆

阅读Mayx的博客，可以明显感觉到他在面对“主流”技术话语体系时的疏离甚至反抗。他不信任所谓“权威推荐”，也极少引用大V观点；他对收费工具持质疑态度，对封闭平台持怀疑立场，对广告与强制App表达不满¹⁰。在对宝塔面板的多篇评论中，他不仅指出其功能冗余和定价虚高¹¹¹²，还以代码层面论证其“技术水准有限”；在谈及Server酱收费后自建通知平台一文中，更是表现出“开发者不应为此类功能付费”的强烈观点¹³。

这种倾向可视为一种数字自由主义精神：他珍视个体的选择权、控制权和创造力，对平台化、商业化所带来的“懒惰便利”持保留态度。也正因为此，他热衷于探索容器、虚拟化、i2p、VPN、防DNS污染¹⁴、反反盗链等灰色技术领域，这不仅是技术探索，也是一种抵抗姿态——抵抗监视、抵抗平台绑架、抵抗数字奴役。

与此同时，作者又是极度自省的人。在多篇年终总结中，他坦言自己因作息不规律导致健康下滑、因沉迷游戏影响了计划、因生活节奏散乱而丧失了方向¹⁵¹⁶。这些坦诚的文字使人看到一个技术人真实的一面：并非所有人都能生活在高效执行与完美节奏中，面对现实与焦虑的拉扯，他并不逃避，而是试图寻找平衡。

三、探索孤岛与技术乌托邦

若将Mayx的博客比作一个数字世界中的“孤岛”，那他无疑是岛上的守望者。他固执地维护着自己的服务器、反代服务、脚本计划表和开源工具；他不断尝试将废弃电脑⁷、老旧开发板⁴和Linux容器¹⁷重新唤醒；他甚至研究如何在FM频段自制电台¹⁸，或在树莓派上运行OpenFyde与Android系统¹⁹²⁰。

这不仅是对“电子垃圾再利用”的尝试，更是一种构建技术乌托邦的幻想——一个无需依赖主流供应链、无需信任大型平台、可以掌控一切细节的小宇宙。

这种倾向也体现在他对去中心化技术的探索，如xLog、IPFS、i2pd²¹、ZeroNet等。尽管在文章中他承认这些系统“尚不成熟”“内容匮乏”“界面粗糙”，但仍不乏热情地部署和尝试。他似乎在追问这样一个问题：“除了平台，我们还能依靠什么？”

这也是他与多数技术博客的区别：不是“教你怎么做”，而是“带你看看还有哪些可能”。

四、个人困境与技术慰藉

不可否认，Mayx的博客也流露出某种孤独与挣扎。他数次提到对社会节奏的不适应、对生活目标的不明确、对未来的迷茫与迟疑。在2022和2023年的总结中，他甚至表达了对“人类灭亡风险”“全球混乱”的忧虑¹⁵¹⁶；在谈及个人计划时，也多次写到“自律不足”“想做的事情太多却力不从心”等字句。

但正是在这种状态下，技术成了他的避难所。他在反复实验中找回秩序感，在编码中获得控制感，在部署过程中体会到“解决问题”的满足。这种“用技术对抗生活混乱”的姿态，令他的博客带有某种心理学上的意义。

五、结语：一个“笨方法”的捍卫者

总的来说，Mayx并非技术界的明星，更非意见领袖，但他是一个值得尊敬的“笨方法”的捍卫者：在速成与流量当道的技术传播环境中，他仍选择用细致的试验、质朴的语言和大量的失败记录来构建自己的知识体系。

他的博客不提供“答案”，而是提供“路线”；不追求“成功学”，而是记录“失败和坚持”。他不是在追求成为谁，而是在努力做自己。

这或许是我们在阅读他的文字后，最值得思考的一点。技术不仅仅是一种职业工具，它也可以是人自我建构、自我理解、自我修复的路径。

Mayx，或许正走在这条路上——孤独而坚定。

对于长复杂逻辑代码的分析

在让AI对我文章分析完后，我又想起来好久以前写的论坛引擎Mabbs，以前还打算重构，不过后来学了别的语言之后就没什么兴趣了😂。但现在有了AI，我想重构MaBBS的事情能不能让AI来做呢？虽然我以前的代码完全没有可读性，耦合性也极高，但这种事情对AI来说应该不是什么难事，更何况我的代码才22KiB，AI完全能读的了，于是我开始尝试让各种AI来把这个代码变得人类可读，然后进行重构。
然而结果令我非常失望，无论哪一款AI只能写出一点代码，甚至Grok3直接一点代码都没写😆，然后它们就认为它们写完了，另外有些AI从片段来看好像是写了点代码，但是内容和我原本对代码基本上没什么关系，属于是分析了一点代码之后重新写了……
明明这个代码又不长，怎么就没有一个AI能准确的重构我的代码呢？也可能是因为虽然代码不长，但是变量名很短，如果把变量名全都扩展到人能看懂的长度之后就超出AI的上下文限制了，然后就忘记了之前的内容吧？另外Shell语言网络上的资料本来就不太多，所以AI也没有足够的知识来重构吧……对于这个问题我目前没什么好的想法让AI来进行，也许等AI能解决这个问题，AI就有能力替代人了呢😁？
虽然没能让AI重构我的代码，不过我闲来无事想让其他人也试试我以前写的论坛引擎，所以搞了个Docker镜像，如果大伙有兴趣尝试一下可以下载下来试试看，整个镜像才2MiB多一点，所以我叫它世界上最小的论坛引擎也没问题吧🤣。

感想

看起来目前LLM的上限就在于它的上下文长度限制啊……这一点真的是限制了AI很多能力，但似乎也没什么好办法，AI就是因为这一点所以不能像人一样纵览全局所以才不能替代人，即使用什么办法去压缩它的上文也会丢掉很多细节信息。不过按照目前LLM的架构来说应该还解决不了这个问题，如果什么时候AI能在思考的过程中修改它自己的权重……也许就可以做到真正的无限上下文，突破上限从而替代人类吧？

懒得写代码？那就让AI写！

起因

前段时间，我看到有些博客给自己的友链页面做了通过订阅源查看友链最近更新文章的功能，看起来挺有意思的，有点想整一个。不过对于我的博客来说，作为静态博客想要做到这样的功能估计没那么简单吧……毕竟一般的订阅软件需要隔段时间请求一下对应博客的订阅链接，然后再把结果存到数据库才行。但是我想了想，对我来说没必要做成订阅啊，我又不需要知道对应博客是什么时候更新的，只要在有人想知道的时候去请求一下订阅链接，然后展示出来就行，感觉似乎又没有那么复杂。
既然不复杂，那这个功能就让AI来做吧，正好前段时间有个朋友买了一个月的Devin.ai订阅，据说是可以自己调试代码，还能操作浏览器，而且代码基本上写出来就能用。我对这个挺感兴趣的，所以这次的功能就让它来写吧！

让AI编写代码

既然是让AI来写，至少得把我的需求说清楚，所以首先我应该告诉它：

创建一个JavaScript函数来实现Links表格中链接的RSS/Atom源预览。

• 当鼠标悬停在表中的链接上时，检查该网站是否有RSS/Atom源，并将结果显示在一个浮动窗口中
• 在鼠标光标后的浮动窗口中显示提要中的5篇最新文章
• 在窗口中只包含标题和时间，不需要链接和内容
• 跳过所有不包含RSS/Atom源的链接，而不显示任何错误
• 当鼠标离开链接时，浮动预览应该消失

不过在正式编写之前，我还得考虑一下可行性，毕竟是很简单的功能，我不写但我不能不知道怎么写。首先让JS解析Feed数据也就是XML数据应该是很简单的事情，JS应该有自带的函数来实现这种功能。然后是获取数据，在JS中使用fetch就可以了，但是这里有个很重要的事情，浏览器请求其他网站存在跨域的问题，还好我之前在CF Workers上用cloudflare-cors-anywhere搭了个CORS代理： https://cors-anywhere.mayx.eu.org/ 。所以我应该在说明中给它说清楚：

• 如果存在源，请使用CORS代理：https://cors-anywhere.mayx.eu.org/ 获取并解析它

随后我就开始让它编写代码了。接下来就能看到AI在浏览器和编辑器中切换，不停的进行编写和调试，等了一段时间，它把第一版代码写好了。不过也许我说的不够清楚，这个CORS代理的用法和其他的CORS代理不太一样，代理链接和被代理的链接之间需要使用“?”分开，另外第一版我也没说清楚RSS/Atom源的链接在哪，所以它选择遍历常见的几种订阅源的路径，这样有点不太好，除了速度慢，对我的CORS代理消耗也比较大。所以我告诉它代理的正确用法，以及让它假设超链接中包含“data-feed”属性，其中包含订阅源的链接，并且随便挑了个网站拿给它作为示例。
随后就能看到它继续改改改，改了几次之后我把最后生成的JS复制到浏览器上执行了一下，效果还不错，于是就把它放到我的博客上了。
它的水平还是挺不错的，至少正确的实现了功能。不过我有点担心它的代码会不会不太可靠，毕竟要从其他网站上获取数据，得避免出现XSS之类的问题，于是我把代码丢给DeepSeek-R1让它检查了一下，果不其然Devin.ai写的代码似乎有XSS的隐患，如果链接列表中标题有html标签似乎就会解析（虽然我没试过），于是根据DeepSeek的提示修改了一下，增加了一个过滤特殊字符的函数，改完又放到博客上，最终的代码就是：rss-feed-preview.js。

感想

让AI全自动写代码感觉还挺方便，有种当产品经理的感觉了🤣，像这种AI就是Agent吧，这也算是我头一次使用Agent了，感觉用起来还挺不错的。不过从这次尝试来看确实AI也有一定的局限性，像是直接写出来的代码可能存在一些安全性问题，除非单独让AI检查，不然很有可能会写出功能正常但是存在漏洞的代码，所以还是得人看着点，AI搞出事故可是不负责的啊😇～

如何才能听到最原始的音乐呢？

起因

前段时间，有人在QQ群中送网易云音乐的7天体验VIP，于是随手领了一份。有了VIP之后除了可以下载仅限VIP的音乐以外，还可以选择更好的音质。我现在用的是MacBook Pro，据说在笔记本中音响效果是最好的，那么我为了能对得起这优秀的音响，也不该听垃圾音质的音乐，所以就来探索一下如何听到HiFi的音乐吧。

获得音乐

下载音乐很简单，直接下一个网易云音乐客户端就可以，不过需要注意要在设置中修改下载音质，默认选项不是最高音质。另外它这个VIP还不是最高的，再往上还有SVIP，可以听所谓的“超清母带”的音质，我不太清楚这个无损以上的那些音质到底是什么东西，也不可能为了这点东西给网易云充钱，所以我就选了个“高清臻音”的选项。
当我在下载一些免费歌曲的时候，下载到的文件是flac格式，看起来应该是没什么问题。但是下载VIP独享音乐的时候，正在下载时是flac格式，可是下载完就变成ncm格式了……虽然我知道有一些解密这些格式的软件（GitHub上有，不过好多都被DMCA takedown了，虽然也能搜到一些……），不过我还是比较好奇这个过程，既然它下载时是flac，那我在它刚下载完要变成ncm之前把网易云音乐强制结束掉不就可以获得完整的flac文件了嘛。试了一下还真可以，也就是说这个ncm加密的过程是在客户端完成的，而不是在服务器上，这还真是有点离谱……我用这个方法下载了几首喜欢听的歌，试了一下都能正常播放。不过用这个办法下载的音乐在客户端的下载中看不到，所以就没有歌词之类的东西了。

分析音乐

虽然说下载下来的文件是flac格式，但是不代表这就是无损的音乐。毕竟从网易云音乐的“无损”以上的选项都是flac的，那到底它这个无损是真无损吗？首先我在网上搜了一下，网易云音乐的黑历史很多，有些人在网易云音乐上上传了mp3的音乐，结果也有无损的选项。也就是说它这个flac很有可能是直接用mp3转换格式过来的。那这样我就不愿意了，我可以接受下不到无损，但是不能接受本来是mp3格式然后转成flac结果文件体积大增，给我的硬盘塞一堆没用的数据，所以现在我需要证明刚刚下载的音乐不是一堆没用的垃圾。
我看有人说可以使用spek查看时频谱来验证，如果是直接用mp3格式转换的flac文件会被整齐的砍一刀，因为mp3格式支持的最大采样率是48kHz，而根据香农采样定理，采样频率应该大于等于模拟信号频谱中最高频率的2倍，那么mp3支持的最高频率就是24kHz，所以用mp3转换出来的flac一般会在24kHz那里切一刀，更有甚者，如果是44.1kHz采样率的mp3就会在22kHz左右的位置切一刀。不过理论上人类的听力上限就是20kHz，更高的频率理论上人类应该是听不到。但毕竟我们追求的是HiFi，和人类能不能听到没有关系，要保证的是完整的复刻所有的信息。
于是我在我的Mac上用brew安装了spek，安装好之后直接执行spek+音乐文件的位置就可以了，我看了一下刚刚从网易云上下载的音乐，全都是96kHz采样率的音乐，而且没有被切过的痕迹。那这样就能证明网易云音乐就是真无损了吗？其实我也不知道，因为我没有从发行商直接获得的原始文件，一般要对比原始文件才知道是不是无损的……不过我在网上看说无论是“高清臻音”还是“超清母带”无一例外全都是用AI升频制作的，所以看时频谱已经没有意义了……但是我又没有证伪的方法，那就只能先凑合听喽～

播放音乐

既然音乐已经下好了，那么我直接用我的MacBook Pro播放的音乐它够HiFi吗？虽然我能听出mp3中128kbps和320kbps的区别，但是再高的我也听不出来……不过HiFi要的不是人能不能听出来，而是它发出的声音是不是完美还原。这要怎么证明呢？虽然我没有办法听出来，但如果有可视化的分析至少能看出来，于是我在手机上下载了一款“声音分析仪”软件，它可以用FFT算法分析手机话筒收集到频谱然后展现出来。只是可视化之后……我也很难看出来它够不够HiFi啊，当然理论上如果能保证播放音乐的音响和收听音乐的话筒都是最好的，那么两边的频谱应该是一样的，但是现实中还有底噪的存在，不可能完全一样……虽然如此，但我在看频谱的时候发现，播放的音乐最高频率似乎只有20kHz，我已经测过手机的话筒是能接收到更高的频率的，既然MacBook Pro的音响是最好的，怎么会只能播放20kHz的声音呢？而且它这个20kHz很明显有一刀切的感觉，应该是哪里配置错了。
于是我搜了一下，Mac默认输出的声音貌似只有44100Hz的采样率，需要在“音频MIDI设置”中将扬声器输出的格式改成更高的才能播放更高的频率。不过这也挺奇怪的，44.1kHz的最高频率是22kHz啊，为什么会在20kHz那里砍一刀呢？看香农采样定理所说的是大于等于，也许就是这个原因吧？既然我的音乐都是96kHz采样率的音乐，那么我就应该把这里的设置改成一样的。改完之后又测试了一下，发现确实是突破了20kHz，但好像没有超过22kHz，不过至少没有“砍一刀”的痕迹了，也许是音乐本身就是这样，或者是扬声器最高只能到这个水平了吧。其实我也没有那么追求HiFi，能到这样我已经很满意了。

感想

虽然对人来说也许听HiFi并不能听出来什么，但是追求HiFi还是挺有意思的，毕竟提高还原程度是可以通过可视化的方式看到的，既然如此，那就是有追求的价值。看不见的东西是玄学，可以不去追求，但是HiFi是实实在在存在的，这样也就能理解为什么会有人花大价钱去买各种昂贵的设备来提高还原度了，因为这是真的可以起到作用的啊……当然对我来说，能0成本做到尽可能的HiFi才是最重要的，花钱达到HiFi就没什么必要了🤣。