MoreRSS

site iconMayx修改

兴趣范围从技术到网络开发,还对编程、DIY和设计感兴趣。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Mayx的 RSS 预览

近期对博客的修改与优化记录

2025-06-02 00:00:00

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

起因

在两个月前,我写了一篇针对博客搜索功能优化的记录。在写完之后没几天,有位名叫@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,还有了解如何提高网站兼容性,以及提高了博客的可靠性和曝光度。果然折腾博客本身也能提高自己啊,还能写文章分享一下折腾的经验😆。虽然折腾的内容不一定能在未来的生活中用得上,但是有意思就足够了😁。

Mac Studio M3 Ultra使用体验

2025-05-07 00:00:00

使用最强的Macintosh是一种什么样的感受?

起因

在两个月前苹果公司出了一款可以选配超大统一内存(512GiB)的Mac Studio,那时候我还想着如果市场反应好就整台玩玩,现在从网上的各种反应来看这确实是一个很不错的产品,所以这次我就整来啦!所以这次就来谈谈初上手的体验吧~

远程体验

虽然Mac Studio理论上拿来剪电影之类的应该是更好的选择,但是显然我不会剪电影🤣,而且也没有合适的屏幕给它用,所以拿到手之后我需要让它可以远程使用。
macOS配置远程还是挺简单的,只需要在设置 -> 通用 -> 共享中打开远程管理就可以了(似乎现在Ubuntu也可以像这样轻松地配置远程桌面),配置好之后需要启用“任何人都可以请求取得控制屏幕的权限”选项,不然可能会连不上……
另外如果需要配置SSH也只需要打开远程登录即可,最好把“允许远程用户对磁盘进行完全访问”也打开,免得使用时还需要额外的操作。
其实开启远程没什么特别的,不过我发现在远程Mac Studio时和我远程Intel芯片的Mac mini 2018以及黑苹果有一个不一样的地方,那就是屏幕共享类型可以选择“高性能”,在这个模式下远程的屏幕就可以变成一块虚拟屏幕,不受Mac连接的屏幕分辨率所影响,可以配置动态分辨率。即使连接的屏幕不支持HiDPI,只要远程的客户端支持那就可以支持,这一点和Windows的远程桌面有点像,但是体验好太多了,使用起来和本地几乎没有差别,当然代价就是对网络要求特别高,基本上如果不是局域网内远程,就不能使用这个模式。
在我配置好远程后我就可以拔掉屏幕,然后把Mac Studio放在阴暗的角落里为我服务了😆。

关于LLM的体验

配置环境

买这个设备的当然也不为别的,主要就是为了能在本地跑完整参数的DeepSeek-R1,或者类似的MoE模型。至于KTransformers方案考虑到按照正价买要更贵(当然有便宜的购买方案,但是太不可靠了),而且这个框架也不够成熟,所以就算了。
在Mac上运行LLM有很多框架,最开始我选择的是Xinference,因为看它的文档中特地提到了苹果的MLX框架,而且可以使用命令启动,方便维护,另外看它支持的模型种类也比较多,所以就先考虑了它。
按照官方文档安装后就可以配置模型了,虽然它可以直接一键下载并运行模型,但是我已经提前下好了模型,另外……如果光运行DeepSeek-R1感觉也没啥意思,不如试试Perplexity AI的某个Finetune模型😆?所以我需要手动注册模型。配置好之后在MaxKB中配置好地址就可以使用了。
刚开始测试的时候倒是没啥问题,吐字的速度确实是挺快,但是用了几下就发现有不少问题,比如每次调用LLM的时候会发现内存压力会上升,APP内存会变成联动内存,在这个期间GPU并不会工作,需要等几秒钟,在生成结束的时候内存压力又会下降,联动内存会变回APP内存,每次生成都是这样。另外如果上文很长就要等几分钟,而且如果上文特别长的情况爆内存程序会直接卡死,还有并发也会导致程序卡死……总的来说这个框架根本不适合生产环境使用,而且文档也写的极其糟糕,看来是我看走眼了,不应该选择Xinference。
在抛弃Xinference之后我想了想还是随大流吧,选择了LM Studio,虽然它需要远程桌面操作,但是配置好之后应该也没有什么太多需要修改的地方,主要是社区相对要活跃得多,出了问题也好解决。
在我安装好LM Studio后发现这个支持的功能要多不少啊,还支持KV Cache量化,有了这个就可以支持更长的上下文了,另外它还支持超出上下文之后选择截断还是滚动,看起来使用非常的友好。
当我对LM Studio充满期待的时候问题就来了,我随便问了些问题,然后它回答的时候不知道什么情况会随机莫名其妙的冒出“<|begin▁of▁sentence|>”,出现这个之后后面的内容就会胡乱生成内容,怎么调都没法解决……后来看了一下DeepSeek的Issue里提到了似乎需要在模板中添加“<think>”标签才可以……但是这样的结果就是输出开头没有“<think>”了,MaxKB解析会出问题……这个问题的话回头看怎么解决吧,至少在模板中加上这个能正常使用了。LM Studio不会每次请求都重新加载一遍模型,输出第一个字的速度比Xinference快了很多,后面生成的速度也很快,输出的速度能接近20T/s,相比来说还是更有用一些。

模型对比

在我测试完DeepSeek-R1的某个微调模型后,最近阿里又出了一系列新模型:Qwen3,支持根据问题进行推理,据说它的235B参数的MoE模型比DeepSeek-R1还厉害,如果是真的,那就不需要用DeepSeek-R1了,虽然Mac Studio可以运行DeepSeek,但是512GiB内存也只能运行4位量化的DeepSeek-R1,而235B的Qwen3则可以用8位量化,还能空出不少内存用于上下文,想来应该效果会比DeepSeek好很多吧?于是我就下载试了试,然而刚下载好之后居然不能运行😅,首先是这个模型太新了,运行前需要把运行库的版本更新到最新,另外默认的模板有问题,解析会报错,需要根据这个Issue修改一下才能正常运行😅。在一切准备好之后,就可以进行测试了。
首先我试了试一些比较简单的问题,Qwen3回答的都还不错,例如24点、内容填空之类的,效果比QwQ-32B好了不少。测试的时候输出的速度和671B 4位量化的DeepSeek-R1基本一致。随后我让它用Mermaid绘制我以前写的AI摘要脚本的流程图,Qwen3绘制的结果是:

graph TD
    A[开始] --> B{解析URL路径}
    
    B -->|/summary| C1[查询内容]
    C1 --> D1{是否存在内容?}
    D1 -- 是 --> E1[构建AI摘要提示词]
    E1 --> F1[调用Qwen模型生成流式响应]
    F1 --> G1[返回SSE流]
    D1 -- 否 --> H1[返回'No Record']
    
    B -->|/get_summary| C2[查询内容]
    C2 --> D2{是否存在内容?}
    D2 -- 否 --> H2[返回'no']
    D2 -- 是 --> I2[计算内容SHA-256]
    I2 --> J2{哈希匹配?}
    J2 -- 否 --> H3[返回'no']
    J2 -- 是 --> K2[查询摘要]
    K2 --> L2{是否有摘要?}
    L2 -- 是 --> M2[返回现有摘要]
    L2 -- 否 --> N2[调用Qwen生成新摘要]
    N2 --> O2[存储摘要到数据库]
    O2 --> M2
    
    B -->|/is_uploaded| C3[查询内容]
    C3 --> D3{是否存在内容?}
    D3 -- 否 --> H4[返回'no']
    D3 -- 是 --> I3[计算内容SHA-256]
    I3 --> J3{哈希匹配?}
    J3 -- 否 --> H5[返回'no']
    J3 -- 是 --> K3[返回'yes']

    B -->|/upload_blog| C4{POST方法?}
    C4 -- 否 --> H6[返回'need post']
    C4 -- 是 --> I4[获取请求文本]
    I4 --> J4[查询现有内容]
    J4 --> K4{是否存在?}
    K4 -- 否 --> L4[插入新内容]
    K4 -- 是 --> M4{内容是否改变?}
    L4 --> N4[返回'OK']
    M4 -- 是 --> O4[更新内容并清空摘要]
    O4 --> N4

    B -->|/count_click*| C5[计算ID的MD5]
    C5 --> D5[查询计数器]
    D5 --> E5{是否含路径_add?}
    E5 -- 是 --> F5[更新计数器+1]
    E5 -- 否 --> G5[保持原值]
    F5 --> H5[返回最新计数]

    B -->|其他路径| I6[重定向到GitHub]

DeepSeek-R1的某个微调模型的结果是:

graph TD
    A[接收请求] --> B{解析URL路径}
    B --> |路径为/summary| C[获取查询参数id]
    C --> D{id是否为null?}
    D -->|是| E[返回错误响应]
    D -->|否| F[查询数据库内容]
    F --> G{内容存在?}
    G -->|否| H[返回'No Record']
    G -->|是| I[构建消息,调用AI生成摘要流]
    I --> J[返回流式响应]

    B --> |路径为/get_summary| K[获取id和签名参数]
    K --> L[查询数据库内容]
    L --> M{内容存在?}
    M -->|否| N[返回'no']
    M -->|是| O[计算SHA-256签名]
    O --> P{签名匹配?}
    P -->|否| Q[返回'no']
    P -->|是| R[检查是否已有摘要]
    R -->|有摘要| S[返回摘要内容]
    R -->|无摘要| T[调用AI生成摘要]
    T --> U[更新数据库]
    U --> S

    B --> |路径为/is_uploaded| V[获取id和签名]
    V --> W[查询数据库内容]
    W --> X{内容存在?}
    X -->|否| Y[返回'no']
    X -->|是| Z[计算SHA-256签名]
    Z --> AA{签名匹配?}
    AA -->|否| AB[返回'no']
    AA -->|是| AC[返回'yes']

    B --> |路径为/upload_blog| AD{方法是否为POST?}
    AD -->|否| AE[返回'need post']
    AD -->|是| AF[读取请求体数据]
    AF --> AG[查询现有内容]
    AG --> AH{记录存在?}
    AH -->|否| AI[插入新记录]
    AH -->|是| AJ{内容是否相同?}
    AJ -->|否| AK[更新内容并清空摘要]
    AJ -->|是| AL[直接返回OK]
    AK --> AL
    AL --> AM[返回'OK']

    B --> |路径为/count_click| AN[计算MD5哈希]
    AN --> AO[查询当前计数]
    AO --> AP{记录存在?}
    AP -->|否| AQ[插入新计数]
    AP -->|是| AR[增加计数]
    AR --> AS[更新计数器]
    AQ --> AS
    AS --> AT[返回当前计数值]

    B --> |其他路径| AU[重定向到GitHub页面]

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style E fill:#f96,stroke:#333
    style H fill:#f96,stroke:#333
    style Q fill:#f96,stroke:#333
    style N fill:#f96,stroke:#333
    style S fill:#9f9,stroke:#333
    style AC fill:#9f9,stroke:#333
    style AM fill:#9f9,stroke:#333
    style AT fill:#9f9,stroke:#333
    style AU fill:#99f,stroke:#333

    subgraph 函数调用
        O -.->|调用sha函数| SHA[计算SHA-256]
        AN -.->|调用md5函数| MD5[计算MD5]
    end

    subgraph 数据库操作
        F --> DB1[SELECT content]
        L --> DB2[SELECT content]
        R --> DB3[SELECT summary]
        T --> DB4[UPDATE summary]
        AG --> DB5[SELECT content]
        AI --> DB6[INSERT新记录]
        AK --> DB7[UPDATE content]
        AO --> DB8[SELECT counter]
        AQ --> DB9[INSERT计数器]
        AR --> DB10[UPDATE counter]
    end

    subgraph AI处理
        I --> AI1[构建系统提示]
        AI1 --> AI2[调用Qwen模型]
        T --> AI3[调用Qwen模型]
    end

这下就高下立判了🤣,同样的问题Qwen3只绘制了基础流程图,而DeepSeek-R1不仅包含子流程图,还通过颜色区分了响应类型,这么看来Qwen3还是不太行啊~当然我的测试非常的片面,仅仅根据这几次测试分析的结果。至于Qwen3到底有没有使用价值,回头再让其他人测测看效果如何吧。

UTM虚拟机的测试

在上次在UTM上用苹果虚拟化框架安装Windows的测试中我用的是Intel芯片的Mac,那时候已经说了打算等Mac Studio到了之后尝试一下用VZ框架安装Windows。那么经过我的测试结果如何呢?想不到居然失败了😭,相同的操作流程在重装脚本执行完后,再重启就没有任何反应了。在活动监视器中虽然可以看到虚拟机的CPU占用是100%,但是内存只占用了100多MiB,而且CPU占用没有任何跳变,显然系统没有正常启动。随后我又尝试在QEMU中安装好Windows然后把VZ虚拟机的硬盘替换掉,结果依旧一样,内存还是只占了100多MiB……看来ARM处理器和x86处理器还是有很大区别啊……
不过这个虚拟机到底有什么区别?为什么会无法启动呢?想到我在Intel芯片的Mac中测试用VZ框架是可以看到CPU型号的,再看看Mac Studio中的Linux虚拟机……似乎没有任何与CPU型号有关的信息,用QEMU至少也能看到类似“virt”之类的CPU型号,用VZ框架就什么信息都没有了……看来Apple芯片和正常的ARM处理器还是有不少区别啊……
不过除了这个以外还有什么有意思的东西可以测试吗?这时候我就想到了Asahi Linux,Apple芯片下的UTM有一个多出来的选项就是可以安装macOS虚拟机,那我能不能在macOS虚拟机中安装Asahi Linux呢?根据我的实际测试,结果也是不行的……因为Asahi Linux不支持M3 Ultra芯片😞,至于M2芯片能不能在虚拟机中运行Asahi Linux……虽然我的MacBook是M2芯片,但是不太想在我常用的机器上搞测试,所以也不知道实际上可不可以。另外Asahi Linux这个项目也基本上停了,估计以后新出的芯片也不会有机会安装Linux了,就像在macOS上运行Windows程序的Whisky项目也停了……真是太遗憾了😢。

感想

从这次体验来看,512GiB内存的Mac Studio M3 Ultra确实很厉害,本地跑LLM速度非常快,20T/s的速度已经很厉害了,而且风扇声音很小,在GPU满载的时候也完全听不到风扇的声音。当然这个前提是跑MoE模型,虽然我没测Dense模型,但想来根据M3 Ultra的算力,跑70B参数的模型肯定是达不到20T/s的,至于更大的模型估计速度就慢的不能看了……不过不影响,这已经够我用了。
至于除LLM以外的用途……我似乎没有什么能用到这么强性能以及这么大内存的地方了……其实还是挺浪费的,但是也没办法,毕竟我又不会剪电影啊🤣。

关于LLM上限的探索

2025-04-22 00:00:00

还有什么是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的博客中,技术类文章占据了绝对的比重。从自制邮件订阅脚本1、Cloudflare Workers自动化2、内网穿透探索3,到低功耗开发板的实验4、AI模型的本地运行5、以及对黑苹果6、Linux系统7的深度体验,这些内容几乎涵盖了当前主流技术生态中的多个维度。

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

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

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

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

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

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

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

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

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

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

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

四、个人困境与技术慰藉

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

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

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

总的来说,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能在思考的过程中修改它自己的权重……也许就可以做到真正的无限上下文,突破上限从而替代人类吧?

如何使用JS通过订阅源查看文章?

2025-04-08 00:00:00

懒得写代码?那就让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搞出事故可是不负责的啊😇~

最近对博客搜索功能的优化记录

2025-04-04 00:00:00

看看其他的博客也会有新的灵感啊~

起因

前段时间,我闲来无事在GitHub上搜和我使用相同模板minimal的博客。但搜索结果中有许多人用这个模板制作的是简历或作品集,这让我有些失望。不过这倒也能理解,因为这个模版并不算博客模板,没有文章列表之类的代码,这些都只能自己写。当然多找找还是能找到一些的,毕竟这个模板在GitHub Pages中算是最受欢迎,至少符合大众的审美。像我就搜到了一个叫Guanzhou Hu的博客,他对模板的样式做了不少的改动,而且改的还挺好看的,尤其是右上角的导航栏,看起来挺有意思,只是这个源代码……导航栏有点硬编码的感觉,我不是很喜欢这种实现方式……

使用标签作为关键词进行搜索

之后我又看了看其他博客,看到了Matt Walker Blog。他没有对模板做很多改动,只是把section元素变得更宽了,但是他没有改手机版自适应的样式,导致界面基本上没法在手机上查看。不过在他的首页中,我对他把文章标签放在文章列表这个操作非常感兴趣,因为每次我都有给文章打标签,但是几乎没什么用。他的标签点进去之后会跳转到该标签下的所有文章,我其实很早就想做这个功能了,但是在不用插件的情况下Jekyll基本上做不出来这种功能,因为没有插件的情况下是不能使用Liquid标签创建文件的,我看了下他的实现,原来是提前创建好的标签页面然后进行筛选的,这个实现我也不喜欢,这样的话我每次打标签都要新建一个标签对应的页面,这种事情不让程序做我会很不爽……(其实现在的GitHub Pages构建网站都是用的Actions了,完全可以自己写一个可以使用插件的Actions来进行构建,不过我也懒得折腾了🤣)
要么还有一个选择,可以单独搞一个页面,里面有所有标签对应的文章,点击文章的标签之后使用锚链接定位到对应标签所在的位置。但这样会导致一个页面有可能有一堆相同的文章链接,结果这个页面比归档页面的链接还多,那就感觉有点糟糕了……
不过我想起来以前做的博客全文搜索功能,如果把标签作为关键词进行查询,那也能起到筛选出标签对应文章的作用吧?而且这样即使我没给那个文章打标签也能搜出来,其实也算不错的选择,另外自从我做出来那个全文搜索的功能之后也没用过几次,没有关键词的话也一时半会想不出来搜什么比较好。于是说做就做,直接把Matt Walker Blog那段在文章列表生成标签的代码复制过来,感觉好像还不错😆?
顺便我也把文章里面的标签也加了链接到搜索的功能,不过原来的代码用的是.join实现的,现在加上这个功能的话就只能老老实实用循环写了😥……

搜索后使用高亮标记关键词

上面的标签搜索效果还不错,只是有些关键词搜完之后有点难发现。我搜索出来之后怎么证明搜到的内容里面一定有对应的关键词呢?虽然从程序的角度来说这是理所应当的事情,一定是有的数据才可能被搜到,但有时候不用Ctrl+F看一眼都不知道是哪里搜到了……所以我觉得应该像其他网站一样对搜到的内容用高亮进行标记。标记应该用什么呢?用样式也许不错,不过现在的H5标签里有一个叫mark的标签可以直接用,用这个标签包裹的内容背景颜色就会变成黄色,就像用荧光笔标记了一样,这样就不需要写样式了。
至于关键词用查询字符串传过去就好了,那我该怎么做呢?我用的搜索脚本叫Simple-Jekyll-Search,它的文档其实根本没有写怎么把搜索的请求传到模版里,还好它有个关于模版的测试脚本里面有写,有个query关键词可以把搜索内容给模版渲染出来,既然做了这个功能怎么不写在文档里😅,不过这个项目已经停止,也没法提出什么建议了……
这个功能听起来相当简单,我都懒得写了,这种简单的功能直接让AI写才对!于是我把需求告诉它,让它给我实现一份,于是这就是让AI给我写的高亮关键词的JS代码(经过了一点修改):

$(function () {
    const urlParams = new URLSearchParams(window.location.search);
    const keyword = urlParams.get('kw')?.trim();

    if (!keyword) return;

    // 转义正则表达式特殊字符,避免安全问题
    const escapedKeyword = keyword.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
    // 创建不区分大小写的正则表达式(全局匹配)
    const regex = new RegExp(`(${escapedKeyword})`, 'gi');

    // 递归遍历并高亮文本节点
    const escapeHTML = str => str.replace(/[&<>"']/g, 
        tag => ({
            '&': '&amp;',
            '<': '&lt;',
            '>': '&gt;',
            '"': '&quot;',
            "'": '&#39;'
        }[tag] || tag));
    function highlightTextNodes(element) {
        $(element).contents().each(function () {
            if (this.nodeType === Node.TEXT_NODE) {
                const $this = $(this);
                const text = escapeHTML($this.text());

                // 使用正则替换并保留原始大小写
                if (regex.test(text)) {
                    const replaced = text.replace(regex, '<mark>$1</mark>');
                    $this.replaceWith(replaced);
                }
            } else if (
                this.nodeType === Node.ELEMENT_NODE &&
                !$(this).is('script, style, noscript, textarea')
            ) {
                highlightTextNodes(this);
            }
        });
    }

    $('section').each(function () {
        highlightTextNodes(this);
    });
});

(2025.04.28更新:解决了一个潜在的解析问题)
我测试了一下,非常符合我的需求,各种情况都能按照我的预期工作,虽然说功能非常简单,但是能正常运行,AI写的还是挺不错的。

近期的其他修改

除了对搜索功能的优化,我还做了些别的功能:

随机跳转文章

前段时间我看到有其他人的博客增加了一个随机跳转文章的功能,不过他的博客是动态博客,实现也比较奇葩,是渲染页面时就已经决定好要随机的文章,也就是说无论用户想不想随便看看,程序都已经随机好了。当然用着静态博客的我来说,从原理上也做不到这一点,不过既然我之前在做相似文章推荐功能时已经对搜索功能的数据进行了缓存,那么直接用缓存的内容直接随机就好了吧……所以就随便写了写,代码也极其简单:

<a href="javascript:getSearchJSON(function(data){window.location = data[Math.floor(Math.random()*data.length)].url})">Random</a>

给文章内标题添加锚链接

最近在修改我的博客的时候我更新了一下给文章生成目录的组件,在这时候我想看看它还有什么有意思的组件可以用,然后就发现了jekyll-anchor-headings,它可以像GitHub展示Markdown文件一样在标题上添加点击后就可以直接跳转到对应标题的锚链接,而且示例里也给出了怎么做可以像GitHub的风格。看起来挺有意思,所以就给自己加上了😆。

添加能跳转到原始Markdown的链接

在修改博客的时候我参考了一下Jekyll的官方文档,在这个时候发现了page.path这个变量。我想了一下这个变量可以用来链接到我的文章内容,然后就在文章标签位置的右侧加上了这个链接,为了能让它显示在右侧,我用的是float: right,但是这样会导致和文章标签不在同一行,查了一下才知道用了浮动就会强制将元素转换成块级元素,而文章标签用的是行内元素,所以对不齐,没办法就只能把这一整行都转换成块级元素了……于是代码如下:

<span style="float: right;"><a href="{{ site.github.repository_url }}/tree/master/{{ page.path }}">查看原始文件</a></span>

感想

多看看其他人的博客看来也挺不错,可以看看其他人的想法,说不定就有可以参考的价值呢……不只是文章内容,网站本身的一些功能也是作者的想法啊……而对于那些只套别人模版,没什么自己的改动的博客,那就没什么意思了(当然不会代码的那就没办法了~)。有些人说博客中只有文章才是最重要的,但我觉得对于技术博客来说网站的代码也是展示自己的部分,所以折腾博客本身也是很重要的!

在UTM中使用苹果虚拟化的各种尝试

2025-03-25 00:00:00

用官方的方式做非官方的事!

起因

在几年前刚收到MacBook Pro的时候,我曾安装过虚拟机软件UTM。但是因为我的Mac内存很小,用虚拟机的体验很差,所以就把UTM卸载掉了。不过以前还我还装过一台黑苹果,在上面也安装了UTM。
最近正好由于某些原因我需要在macOS上安装虚拟机,既然有UTM用就继续用UTM了。当然正常情况就是按正常的方式安装系统然后正常的用,这并没有什么意思。所以我想整点有意思的事情,想试试不太正常的使用UTM😝。

在UTM中使用苹果虚拟化框架安装Windows

如果用过UTM的话应该知道,UTM有很多选项,比如底层的虚拟化框架可以用QEMU或者Virtualization.framework(VZ),而QEMU的后端可以选TCG或者是Hypervisor.framework(HVF)。它们有很多特色,像TCG的兼容性最好,可以模拟任何架构的CPU,但是性能最差,HVF使用硬件虚拟化加速,只能运行宿主机架构的程序,但是性能比较好,而VZ经过了苹果官方优化,性能最好。
那么现在我想安装Windows,又想有最好的性能,那我应该选择VZ吧?可是UTM不允许我这样选择,如果选择安装Windows就会强制使用QEMU……只有Linux或者macOS(在ARM处理器)才能使用VZ……那我应该如何绕过这个限制呢?
我想起来之前让没用的主机感染木马的文章中使用了一键DD/重装脚本把我服务器的Linux系统重装成了Windows系统,那么我能不能用相同的方式先按照正常的方式用VZ安装一个Linux系统然后使用这个脚本重装成Windows?我觉得理论上应该没问题,所以就尝试了一下。
我在这之前已经安装过了一个用了VZ的Ubuntu虚拟机,新建比较费时间所以就直接把这个虚拟机复制了一份。然后下载了重装脚本准备重装系统,但是看说明现在不能让脚本自己查找系统镜像安装了,不过没关系,前段时间我下了一份Windows 10的镜像,接下来我只需要在镜像所在目录执行

python3 -m http.server

开启一个文件服务器,然后在虚拟机中执行

bash reinstall.sh windows --image-name "Windows 10 Pro" --iso "http://192.168.64.1:8000/windows.iso"

就可以了,执行后重启就可以在UTM的虚拟机界面中看到脚本执行的一系列操作。在这期间都很顺利,然而在它执行完之后,虚拟机的屏幕就黑了,而且重启也没有任何变化,看来是实验失败了?不过也可能是因为苹果整的虚拟显示器在Windows中识别不出来,所以显示不出东西,因为我看活动监视器中CPU的占用率也在跳变,虚拟机应该仍然在运行,于是我下载了Windows App(以前的远程桌面),使用虚拟机之前的IP进行连接,结果连接成功了😆。看来苹果的虚拟化框架是能运行Windows的嘛,居然没有一个人尝试一下。
不过屏幕不能亮是真的没有驱动吗?我看了眼设备管理器,搜了一下那个没有安装驱动的视频控制器的设备ID“1af4:1050”,好像是Virtio GPU,这个驱动我记得在virtio-win里是有的,而且重装脚本也会自动下载这个驱动,为什么会没有自动安装呢?可能是设备ID和驱动不一致吧……不过不影响,我选择更新驱动,在列表中选择“Red Hat VirtIO GPU DOD controller”之后UTM的虚拟屏幕中就可以看到画面了,虽然分辨率只能是1024*768……不过能用就很不错了。
再接下来我就需要验证一下它的性能是不是最好的,我把这个虚拟机的硬盘复制了一份,新建了一个使用HVF后端的QEMU虚拟机,把这个硬盘挂载上,然后使用国际象棋跑分,看了一下VZ的跑分相比HVF的跑分高了大概5%-10%,还是挺厉害的。
至于其他方面,我看了一眼用HVF的QEMU虚拟机CPU不能显示正确的型号,而VZ是可以的,另外VZ的‌SMBIOS信息中也可以看到Apple的字样,证明这个Windows确确实实是跑在了苹果的虚拟化框架。不过以上的测试都是基于x86架构的macOS,等回头我的Mac Studio到了之后再在ARM架构的macOS上再测一下,看看能不能用相同的方式安装,如果可以的话,说明VZ的虚拟机没什么兼容性的问题,UTM应该放开使用VZ安装Windows的选项,让我们测测苹果的技术才对。

在macOS 12中的UTM使用苹果虚拟化框架安装Linux

虽然在刚刚的测试中,用VZ安装Linux就和其他普通的虚拟机安装Linux一样简单,但是之前的测试是在macOS 15上测的。现在我遇到了一个新问题,我现在有一台2016年的Mac,上面运行着macOS 12,而且不能用OCLP升级到macOS 15(因为不是我的电脑)。现在我想在这台电脑上用苹果虚拟化框架安装Linux,虽然用QEMU更简单,但是感觉没意思。在macOS 12中不支持UEFI bootloader,所以我需要手工准备内核镜像之类的东西。
当然从零开始有点难,我打算先用QEMU安装一遍Ubuntu Server。在创建虚拟机之后需要注意,要把刚创建好的虚拟机的硬盘删掉,因为那是qcow2格式的,在VZ中只支持img格式的硬盘,所以删掉之后需要创建一个“RAW映像”,然后按照正常的方式安装系统。
安装好之后从“/boot”目录中把“vmlinuz”和“initrd.img”复制出来,作为Linux内核和初始Ramdisk,我看说明上要未经压缩的Linux内核映像,但是好像是压缩的也能用🤔。随后关机把在QEMU中的硬盘映像复制出来,作为根文件系统映像。
至于启动参数,可以看“/boot/grub/grub.cfg”中内核后面跟的那串,然后再加上“console=hvc0”,因为macOS 12中使用VZ没有虚拟屏幕,只能用虚拟串口连接。在一切准备好之后就可以开机了,在一串内核信息不停滚动后,显示出了登录的提示符,实验就成功结束了。
不过这样启动的话在系统中所有对内核以及对initramfs的更新就全都不会生效了,毕竟虚拟机根本读不到内核了……这倒是影响不大,反正不更新也不是不能用,更何况macOS都不打算更新,虚拟机不更新又能怎样呢🤣。

感想

看来苹果的“不支持”不代表真的不支持,想想既然是虚拟机,当然就不应该限制系统类型啊,毕竟虚拟机虚拟的是硬件,又不是软件。不过倒是也能理解苹果不需要声明支持自己的竞品,所以也没必要做相应的兼容和测试,但居然没见到有人尝试一下,也挺奇怪,明明用Mac的人也有不少对技术很有探索精神的人啊……
不过随着macOS的更新,像这些非官方支持的办法估计也很有可能出问题,毕竟苹果并不对这些情况进行任何形式的保障,也许以后苹果的哪次更新这个方法就用不了了呢……