WWDC25中苹果发布了全新的设计语言Liquid Glass。

苹果声称Liquid Glass是“跨平台的通用设计让内容更受关注，并带来全新活力，同时保持 Apple 软件的熟悉感”。

“全新材质 Liquid Glass 具有半透明特性，其表现如同现实世界中的玻璃。它的颜色由周围内容决定，并可在明亮和黑暗环境中智能地调整。Liquid Glass 源于设计团队和工程团队的紧密合作，采用实时渲染技术，并能通过镜面高光对运动做出动态反应。”

Liquid Ass

可是观众很快就会发现，Liquid Glass在当前iOS 26上的实际运行效果并不自然，而且设计完全无法“让内容更受关注”。

尤其是控制中心，前景和背景重叠显示，功能开关是否激活无法确定，什么都看不清。

什么是磨砂玻璃

不论Liquid Glass这个名字听起来有多高级，我们都要先从磨砂玻璃讲起。

我们在物体前遮挡一块磨砂玻璃，会对我们观察物体造成三种改变：

清晰度降低

清晰度降低，简单来说就是模糊。

普通透明玻璃表面光滑，光线可以平行地穿过，从而形成清晰的图像。然而，磨砂玻璃的表面是粗糙、不平的，当光线照射到其表面时，会被向四面八方不规则地散射开来。

亮度变化

一般来说，磨砂玻璃造成的亮度变化就是亮度降低。光线透过磨砂玻璃，不仅部分光线被反射，还会有很多亮度在经过粗糙表面后消耗在折射的过程中，因此磨砂玻璃一般会造成明显的亮度降低。

与此同时，当我们给磨砂玻璃的边缘加上一个光源时，整个磨砂玻璃都会被照亮，形成一种类似背光的效果。

饱和度降低

磨砂玻璃在成像时会导致景物的饱和度降低。

磨砂玻璃的粗糙表面，使得光线经过时发生多方向的散射，这种散射会让来自不同方向、不同颜色的光线混合在一起，原本清晰的色彩边界被模糊、平均，导致色彩不再鲜明。

Liquid Glass出了什么问题？

清晰度不够低

磨砂玻璃的模糊效果，不仅可以降低背景对前景的干扰，还可以降低景深，打造更好的层次感。

而Liquid Glass的模糊效果并不强，我们甚至可以隐约在控制中心阅读到背景中的文字。

可以说Liquid Glass产生的模糊并不像磨砂玻璃，而是硫酸纸。

亮度没对比

正如上面说的，一般情况下磨砂玻璃会造成亮度降低，也就是我们在控制中心看到的背景变暗的效果，但此时前景的控件一样很暗，用户甚至无法一眼确定哪个元素是前景的内容。

而有时界面的背景和前景又都很亮，比如锁屏通知。

饱和度太高

我觉得这个才是最严重的问题。

背景的饱和度看来比前景还高，尤其是控制中心中，背景色会严重影响用户对控件是否激活的判断。

怎么改？

不多说，看效果：

对于很多小型企业和工作室而言，用好公网IPv6地址都是非常重要的。

但是很多小型企业和工作室通常只能负担动态地址的互联网宽带，而动态公网IPv6地址对于多子网的企业网络非常难以应用。终端直接使用公网IPv6地址，不仅配置复杂，地址管理也麻烦，安全性也少一层保护。

本文就将通过NAT66为核心的技术解决企业局域网IPv6 ULA的问题。

TL;DR

1. 在核心交换机中配置SLAAC或DHCPv6为局域网各子网设备分配IPv6 ULA地址
2. 出口网关设备配置NAT66

局域网ULA配置

本段基于Cisco交换机的SLAAC和RA RDNSS功能编写。

局域网内终端设备需要通过SLAAC或DHCPv6方式分配unique local address (ULA)地址。

如果终端设备较多，需要增强管理，则应该使用DHCPv6方式；如果终端设备少、管理松散，使用SLAAC方式的分配更加简单。

SLAAC方式需要解决DNS分配问题，方法有两种。一种是引入DHCPv6仅分配DNS配置，有点是几乎所有设备都支持，缺点是配置相对复杂，不如干脆用DHCPv6把地址分配也解决掉；另一种方法是RA中直接附加RDNSS信息，配置非常简单，单有很小一部分设备不支持RDNSS。

Cisco交换机的SLAAC配置非常简单，设备默认启用RA。启用RDNSS只需要ipv6 nd ra dns server一条命令。

典型配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

ip name-server A_IPv6_DNS_ADDR                   #为交换机配置IPv6 DNS
ipv6 unicast-routing                             #启用IPv6路由功能
!
interface GigabitEthernet0/48                    
 description 上联互联接口
 no switchport
 ip address 172.16.1.2 255.255.255.252           #互联IP地址
 ipv6 address FD08:111:222:1::2/64               #互联IPv6地址
!
interface Vlan4
 description 办公终端
 ip address 192.168.250.254 255.255.255.0
 ipv6 address FD08:111:222:4::1/64
 ipv6 nd ra dns server A_IPv6_DNS_ADDR           #DNS地址分配
!
interface Vlan80
 description 内部服务器
 ip address 192.168.80.254 255.255.255.0
 ipv6 address FD08:111:222:80::1/64
!
ipv6 route ::/0 FD08:111:222:1::1                #IPv6静态路由

出口网关配置

这一部分的配置以MikroTik RouterOS为例。

实际上配置方法与NAT基本相同，只是帮大家熟悉一下NAT66的做法。

PPPoE

出口网关设备需要通过PPPoE进行拨号，并获取IPv6地址和默认路由。

这部分非常简单，几个截图看看就好：

唯一需要注意的是DHCPv6 Client这里的前缀长度，可以找一个普通家用路由器拨号之后看看之际给的长度，写到这里就好。

NAT66

首先解决上网问题。

在IPv6防火墙中新建一个源NAT策略，设置出接口为pppoe接口或设置出接口组为WAN，action为masquerade。

服务器映射

在IPv6防火墙中新建一个目的NAT策略，设置出接口为pppoe接口或设置出接口组为WAN，同时配置好协议和端口，action为dst_nat，并填写内部服务器的ULA地址和端口。

DDNS解析

DDNS解析通过ddns-go这类的项目解决。

由于出接口上有众多全局IPv6地址，内部终端最终映射到的全局地址可能不一样，建议web应用使用统一的反向代理对外服务，其他应用则每台主机部署一套ddns-go。

总结

其实整个方案没有技术难度，只是很多人并不太清楚ULA是什么，以及NAT在IPv6中的作用。

这个Hexo原先是直接部署在Github Pages上的，但是Github Pages不允许免费用户使用私有repo，自定义域名要用4个A记录又太不优雅，又赶上最近Cloudflare免费服务白嫖上瘾，就直接把Hexo重新部署在Cloudflare Pages中了

简单几步完成部署

第一步：搞个repo

不要用.io的那个repo了，新建一个并设置为私有

把你的hexo传上去，当然是要用git push的方法

同时注意 / 里一定要有package.json文件（正常来说会有），里面的内容也要看一下，有没有定义好的scripts，例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "name": "hexo-site",
  "version": "0.0.0",
  "private": true,
  "scripts": {
    "build": "hexo generate",
    "clean": "hexo clean",
    "deploy": "hexo deploy",
    "server": "hexo server"
  },
  "hexo": {
    "version": "6.3.0"
  },
  "dependencies": {
    "@waline/hexo-next": "^3.0.1",
    "hexo": "^6.3.0",
    "hexo-deployer-git": "^3.0.0",
    "hexo-generator-archive": "^2.0.0",
    "hexo-generator-category": "^2.0.0",
    "hexo-generator-feed": "^3.0.0",
    "hexo-generator-index": "^3.0.0",
    "hexo-generator-searchdb": "^1.4.1",
    "hexo-generator-tag": "^2.0.0",
    "hexo-renderer-ejs": "^2.0.0",
    "hexo-renderer-marked": "^6.0.0",
    "hexo-renderer-stylus": "^2.1.0",
    "hexo-server": "^3.0.0",
    "hexo-theme-next": "^8.15.0"
  }
}

第二步：搞个Page

去Cloudflare的Worker & Pages页面新建一个应用，通过Connect to Git完成授权

接着进到最关键的配置环节，注意一下几个设置：

这里要特别强调Build command这块

古早的Cloudflare Pages是可以在Framework preset里选择Hexo的，于是Build command可以直接设置为hexo g

后来Cloudflare Pages取消了Hexo的Framework preset，但是很多文档里依然通过hexo g可以正常生成页面

我不清楚是Cloudflare Pages有了新的变化，还是Hexo有了变化，当前环境中直接执行hexo命令是找不到文件的，必须要根据package.json中定义的scripts来执行npm run build才可以正常生成页面

第三步：定个域名

如果一切正常，你的hexo已经可以通过pages的域名访问了，这时候你可以把你自己的域名加进去

我相信你已经在用Cloudflare Pages的话，DNS肯定也在Cloudflare上，它会自动帮你处理CNAME记录和证书

So what?

折腾一圈下来，唯一解决的就是私有repo的问题

• cloudflare的线路并不比github更快
• 除非直接在github上写文字，否则还是需要本地操作
• git使用比hexo还更复杂

就是脱了裤子放安静的屁

上回书说到，与其加价购买树莓派，还不如直接在x86平台找方案。

这次我们就来说说x86架构主机做HomeLab基本都要用的Proxmox VE的一些小贴士。

无法启动安装器问题

安装镜像引导后长时间卡在Starting the installer GUI see tty2 (CTRL+ALT+F2) for any errors，在tty2可以看到无法进入framebuffer模式的描述

我的N100主机遇到了这个问题，原因是X11并不认识这个核显，GUI就不会启动。

解决起来很简单。

首先执行lspci| grep -i vga找到显卡的BusID，例如：

1
2

# lspci| grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Device 46d1

接着在/usr/share/X11/xorg.conf.d/目录里新建一个配置文件，写入以下内容：

1
2
3
4
5

Section "Device"
    Identifier "Card0"
    Driver "fbdev"
    BusID "pci0:00:0:2:"
EndSection

检查无误直接xinit就可以正常启动安装器。

CPU频率过高

Proxmox VE装好，一个vm都没有，风扇已经呼呼的吹，再看CPU完全是满载的温度。

通过cpufreq-info一看：

1
2
3
4
5
6
7
8
9
10
11

analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 4294.55 ms.
  hardware limits: 700 MHz - 3.40 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 700 MHz and 3.40 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2900 MHz.

完全不慌，我们把governor改成powersave不就好了？

不好，没有用。

那我们把turbo boost禁用了看看：

1

# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo

1
2
3
4
5
6
7
8
9
10
11

analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 4294.55 ms.
  hardware limits: 700 MHz - 3.40 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 700 MHz and 3.40 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.

是不是好多了？

不好，频率上不去了。/sys/devices/system/cpu/cpu*X*/cpufreq/scaling_min_freq和/sys/devices/system/cpu/cpu*X*/cpufreq/scaling_man_freq两个参数居然一样

我们还是先回到启用turbo boost和powersave的情况，然后只需要做一件事：安装acpi

好了，你的p-state调度又如丝般顺滑了。

别问我为什么，按说intel_pstate驱动是不依赖acpi的。

注：有一些文档建议直接禁用intel_pstate驱动，因为acpi_cpufreq驱动有类似ondemand的governor可选，我觉得大可不必，只要能调度就行，intel_pstate的powersave本身就是干这个的。

异机迁移

如果你有vm需要从旧pve主机迁移至新主机，而你又不信任pve的集群功能，pve提供了一个非常实用的异机迁移命令qm remote-migrate

准备新主机

首先新主机的PVE应该安装妥当，存储容量要够，网络要通。

执行pvenode cert info记录主机的fingerprint。

创建一个API Token，记录好令牌信息。

准备vm

• 删除全部快照
• 移除各种直通

开始迁移

直接来看命令怎么说

1
2
3

qm remote-migrate <vmid> [<target-vmid>] <target-endpoint> --target-bridge <string> --target-storage <string> [OPTIONS]

Migrate virtual machine to a remote cluster. Creates a new migration task. EXPERIMENTAL feature!

这里面最复杂的就是<target-endpoint>部分：

1

<target-endpoint>: apitoken=<A full Proxmox API token including the secret value.> ,host=<Remote Proxmox hostname or IP> [,fingerprint=<Remote host's certificate fingerprint, if not trusted by system store.>] [,port=<integer>]

我们需要提供新主机的IP地址，API Token和fingerprint

搞好的命令就应该是这样子：

1
2
3
4
5

qm remote-migrate 源vmid 目的vmid \
  'host=192.168.6.250,apitoken=PVEAPIToken=root@pam!你定义的令牌名称=令牌,fingerprint=主机fingerprint' \
  --target-bridge vmbr0 \
  --target-storage local-lvm \
  --online

–online参数只在在线迁移时使用。是的，vm是可以主机不在同一个集群并在线迁移的。

收尾工作

迁移完成后，旧主机上还会显示这些vm，但是带有一个提醒你已经迁移的图标，这个时候你就可以删掉这些vm了。

在新的主机上重新配置那些直通。

Windows的vm在线迁移大概率会蓝屏，记得重启。

硬盘直通

如果你只是准备把一块硬盘直通给vm，并不打算直通整个SATA控制器跑一个TrueNAS：

1

qm set 102 -scsi2 /dev/disk/by-id/ata-SanDisk_SDSSDXPS480G_xxx

-scsi2也可以用别的总线和序号，只要Guest OS支持就行。

答应我，好吗，别通更多硬盘了，别在PVE里跑黑群晖，再在黑群晖里跑docker。

• 包括第四代在内的Raspberry Pi设备，应该只适用于小负载、无加密、多线程的生产和实验环境
• 不适合高速网络环境中的透明代理、高负载的https服务、各种VPN网关、NAS服务、桌面环境
• 更适合作为终端而不是服务器

设备弱点

CPU性能羸弱

BCM2711性能不足是有目共睹的，落后的制程又让其在高负载运行中温度难以控制，需要类似Argon Neo的这种全金属外壳甚至主动散热来释放温度。

RPi 4的整体性能并不足以支撑一个LXDE环境和各种桌面应用，你甚至很难流畅观看FHD的弹幕视频。

缺少AES-NI

BCM2711并不带有AES硬件加速功能，AES性能可以用不堪一击形容，4核AES-256性能被i3-8100T单核虚拟机吊打。

当然还有chacha20系的算法可以用，性能要比AES好非常多，可是依然比x86弱不少。

因此，包括传统VPN、wireguard、负载均衡、代理服务器在内的所有涉及加解密的场景，Raspberry Pi都很难提供足够的性能。

缺少PCI-E扩展能力

除了CM4有一个PCI-E x1的接口以外，所有RPi都没有可以直接可见的PCI-E。

因此，NVMe SSD就不用想了，有线网卡最多可以上2.5Gbe，还会抢占其他USB设备的带宽，并且造成2.4GHz的干扰

供电困难

按照官方指导文件里的描述，RPi 4应该通过一个至少5V/3A的适配器供电，在USB设备总电流不超过500mA时可以使用2.5A适配器，但不支持USB-PD协议。

然而市面上不支持USB-PD但能提供超过3A电流的5V适配器并没有很多选择，大多数通用的适配器和插排都只提供2.4A最大电流。

NTFS问题

这个问题是整个Linux的问题，但RPi受到的影响尤其明显。

5.15内核并入了NTFS3驱动，可以在低性能的设备上替代NTFS-3G驱动，提供更好的读写性能和更低的开销。但是NTFS3本身还有非常多问题，缺少配套工具、大量bug和兼容性问题、缺少文档。

我手里的三个NTFS设备，有两个可以通过NTFS3挂载，有一个死活不行，找不到任何的文档可以处理或解释这个故障，就算有patch修复这个问题，可又不会并入现有5.15内核，安装新内核还要去backports，这有可能会带来其他问题。而NTFS-3G的性能又非常堪忧，x86设备的性能足够硬扛NTFS-3G，RPi则很容易在高强度读写的情况下挂死。

价格

这本不是一个问题，Raspberry Pi 4本应该是价格最划算的单板计算机之一，但是Covid-19改变了一切，现在一块4GB内存的RPi 4要价近1k，在这个价格上好的选择非常多。

正确的姿势

DNS服务器

旁路DNS服务器可能是老款RPi的正确使用姿势，家用环境下DNS不管多少请求都不会消耗太多性能，也不需要很大的吞吐，不管是PiHole还是AdGuard Home都可以轻松应对。

但是要注意上游DNS如果是TLS的，这负载就要再算算了。

Home Assistant

直接部署HAOS，自带WiFi和蓝牙，无脑连接大量家居设备，还可以对接homekit，打通多方协议。

透明代理

前面提到了RPi并不适合作为高带宽环境中的透明代理，但是在一个500M以内家用宽带的环境中，RPi 4跑一个chacha20的代理还是可以提供一个令人满意的性能。

独立设备跑透明代理的好处就是可以充分利用clash的自动路由，不需要考虑容器、虚拟化网络的特殊性。

商用

只要成本划得来、性能跟得上，RPi依然是非常无脑的嵌入式主机。

你猜猜一个RPi 4+显示器套一个铁壳子，插上RFID读卡器，这样一套东西卖给用户几万比较合适？

我想要HomeLab

是的，我知道很多人在用RPi做轻量的HomeLab主机，甚至感觉还不错。

但是当你的HomeLab出现对第二快RPi的需求的时候，RPi就已经不合适了，这个时候不如搞一套x86的电子垃圾，把家里那些旧电脑留下的DDR4内存、SATA SSD用起来，只需要一块4GB RPi4的预算，你就有机会得到一套至少拥有4核x86内核的全闪存无头主机，而它可以提供的性能和功能都远远超过4GB RPi4。

有x86架构，你可以从容的运行所有可以在RPi上运行的应用，同时还有余力跑一个Windows虚拟机来专门对付各种网盘客户端。

经过几天的调整，这个使用Next主题运行的GitHub Pages上的Hexo系统基本上可以正常运行了。

环境介绍

Hexo是静态blog系统，简单来说就是这东西会先把你写好的东西渲染成html文件，再交给httpd监听。Hexo本质上是一个后台，最终展现出来的效果大量依赖主题和各类第三方模块。

Next是Hexo的一个很著名的主题，在配置文件中内置了大量的功能，让用户可以在尽量少接触代码的情况下完成站点管理。

GitHub Pages给用户提供了一个简单的httd实例，允许用户运行简单的网站。

接下来就简单讨论一下整体建站体验和一些使用细节。

Hexo优缺点

优点

• 静态页面确实快
• 支持很多部署方式
• 文档非常成熟
• 利用GitHub Pages建站可靠性好
• 生态系统不错

缺点

纯粹为工程师服务

不论是github建站、vps上面跑git还是其他部署方式，本地操作-部署-在线运行的模式对于站长来说无异于脱了裤子放屁。

而对于只是想找个环境写写字的用户，这种操作逻辑根本无从下手。

不存在多用户创作

Hexo根本没有考虑多用户，有一些旁门左道的办法可以实现，但是相信我，能看懂怎么做的人都自己建站了。

核心功能缺失

大量对于blog来说非常基础的功能都要依赖第三方的插件或服务，甚至连评论系统都欠奉。

一方面，一个系统引入的外部组件越多，各组件之间的版本兼容关系就越复杂，集成需要的调试也越多，后续需要编写的文档就更多。

另一方面，依赖第三方服务，整个系统的可靠性就会受到更多单点的影响，而且产生的数据也很难集中管理和保护。

没有可视化后台

这是纯粹为工程师设计的结果，没有所见即所得，更没有文章、页面管理的功能，你要做的是版本管理。

重点讨论

评论系统

由于Hexo不存在评论系统，很多外置的评论系统应运而生，这些评论系统分成三个阵营。

GitHub Issues类

这类评论系统，会把所有评论作为issue处理。

这样做的好处是GitHub作为一个可靠的环境，你的评论数据是很难丢失的。

但是很明显，这些系统是依赖GitHub的，同时读者没有办法进行匿名评论。从某个角度说，利用issues存放评论算不算对GitHub的滥用？

无后端类

以valine为代表的无后端类评论系统，虽然提供更强大的功能，但同时会引入更多后端。

以waline为例，官方快速上手文档使用LeanCloud创建数据库，并在Vercel中部署server，最后在Hexo中引入客户端，就这样，一个无后端的东西就给你增加了两个后端和一串html代码。

当然你也可以选择其他的serverless服务或利用vps独立部署，但是这并不会减少运维成本。

第三方服务

用过blogspot的朋友一定还记得disqus，功能强大，可以更好的管理评论，同时用户很少需要考虑运行状况。

但是这类服务就怕跑路，万一哪天它不干了，你还要考虑系统迁移。

放弃

当然你也可以选择放弃。

放弃这种方式，具有无数据、无后台的巨大优势，适合不打算听别人怎么说的用户。

主题

不仅是视觉效果，Hexo的前端功能全部依赖主题实现，搭配不同主题，Hexo就是完全不同的维护和阅读体验，因此选择主题可能才是一切的开始。

优秀的主题应该具有以下特征：

• 通过配置文件实现快速自定义
• 基于data files进行深度自定义
• 自带常见评论系统集成
• 持续更新
• 文档全面

数据存放

很显然，如果你是在GitHub Pages上部署Hexo，你不应该把媒体文件一并上传到repo里，这不仅是因为容量限制，也是对免费服务的滥用。

因此，如果你的文章中经常用到图片、音频、视频文件，你可能就要找图床、对象存储、视频网站来解决问题了。而这些服务又会引入非常多运维工作量。

小技巧

我有很多电脑怎么办？

把你电脑上的目录同步起来吧，群晖、OneDrive什么的都好，其他电脑上只需要把环境搭好就行了。

当然你也可以选择在每个电脑上搭好环境，把source目录放进另一个branch，每次切换之后做一整套git操作。

相信我，不管用哪一种方法，几次之后，你就不会再想用不同电脑创作了。

注意鉴别文档

不管是Hexo还是对应的主题，不同版本的变化都很大，查询文档的适合一定要注意对应的版本。

你还要小心鉴别作者自己都没搞懂的文档。

很多文档都告诉你，每次写完新文章，要用hexo clean hexo g hexo d完成部署，实际上hexo clean更多是在主题样式需改后才需要使用。启动服务器命令hexo s也根本不需要事先静态，这个命令不仅会把source里的东西立刻渲染给你看，还是实时监控source里的更新。

还有一个文档甚至建议在vps上独立部署的hexo直接用nginx反向代理hexo s的监听端口，一堆静态页面你反代它干啥？你还真打算拿Hexo当动态blog用？

总结

Hexo就像Raspberry Pi，你折腾它的时间一定超过使用的时间。

如果你只是一个想写写字的人，不打算做一个工程师，请立刻绕行，不要再多看一个Hexo的文档。

原有WordPress数据被放弃，直接利用Hexo重新建站。

目前本blog还只是个人实验性质的玩具，短期内不会有实际内容产出。

当然，目前也没有评论系统，因为我还没想好要用那个套件。

Have fun!