mermaid.js 效果相册

mermaid 是一款 javascript 库,能够轻而易举地通过文本代码绘图。

作为普通用户,将其理解为一种绘图的语言即可,集成它之后就可以在 markdown 的轻松插入特定语法编写的各类图示了,而且不需要像 plantuml 一样需要外部服务器,目前 notionobsidian 等都已原生支持该特性,许多博客主题也支持该语法。

使用它,可以轻松在各类 md 编辑器中绘图,方便修改和传播。

具体语法请查看 mermaid 官网,本文展示一些在互联网发现的比较优秀的示例:

网络拓扑图

graph TD
 linkStyle default interpolate basis
 wan1[
<center>DSL 100/10 Mb<br><br>10.100.102.1</center>]---router{<center>EdgeRouter-X<br><br>10.20.30.1</center>}
 ip((
<center><br>IP<br><br></center>))-.-router
 dns((
<center><br>DNS<br><br></center>))-.-router
 wan2[
<center>LTE 50/20 Mb<br><br>192.168.1.1</center>]---router
 router---|100Mb|ap[
<center>RT-AC1200<br><br>10.20.30.3</center>]
 router---|1Gb|pc(
<center>PC<br><br>10.20.30.190</center>)
 router---|1Gb|switch[
<center>TL-SG105E<br><br>10.20.30.2</center>]
 subgraph red1
 ap-.-cam1(
<center>Camera<br><br>10.20.30.171</center>)
 ap-.-cam2(
<center>Camera<br><br>10.20.30.172</center>)
 ap-.-phone(
<center>Phone<br><br>10.20.30.191</center>)
 ap-.-ir(
<center>IR<br><br>10.20.30.180</center>)
 end
 subgraph red2
 switch---|100Mb|pi1(
<center>RPi 3B<br><br>10.20.30.150</center>)
 switch---|1Gb|pi2(
<center>RPi 3B+<br><br>10.20.30.151</center>)
 switch---|100Mb|nvr(
<center>NVR<br><br>10.20.30.170</center>)
 switch---|1Gb|laptop(
<center>Laptop<br><br>10.20.30.192</center>)
 end

参考文献

Juice FS 初探 | 一种为 VPS 提供无限磁盘空间的解决方案

JuiceFS 是一款面向云原生设计的高性能分布式文件系统,在 Apache 2.0 开源协议下发布。提供完备的 POSIX 兼容性,可将几乎所有对象存储接入本地作为海量本地磁盘使用,亦可同时在跨平台、跨地区的不同主机上挂载读写。

使用 JunicsFS 将云厂商的 S3 对象存储挂载到本地,就得到一个几乎无限容量的 VPS 空间了。目前 Juice 支持大部份主流厂商提供的 s3 服务,具体请查阅官方文档。

本文以 腾讯云 COS + 腾讯云轻量服务器,演示一下基本使用。

挂载 COS 到本地

使用以下命令即可创建一个基于 COS 的文件系统,下面演示基于 sqlite 和 redis 的创建、挂载、卸载命令。

# Jfs With Redis
juicefs format \
    --storage cos \
    --bucket jfs-redis-******** \
    --access-key ******** \
    --secret-key ******** \
    "redis://127.0.0.1:6379/1" \
    jfs-redis
# 挂载
juicefs mount -d "redis://127.0.0.1:6379/1" /mnt/jfs-redis/
# 卸载
juicefs umount /mnt/jfs-redis/

# Jfs With sqlite
juicefs format \
    --storage cos \
    --bucket jfs-******** \
    --access-key ******** \
    --secret-key ******** \
    "sqlite3:///opt/jfs/jfs.db" \
    jfs
# 挂载
juicefs mount -d "sqlite3:///opt/jfs/jfs.db" /mnt/jfs/
# 卸载
juicefs umount /mnt/jfs/

自动挂载

具体使用时,可以配置一下自动挂载,方法如下。

首先创建一个从 /sbin/mount.juicefsjuicefs 可执行文件的软链接,操作系统解析 fstab 时会调用 /sbin/mount.juicefs 命令。

$ which juicefs
/usr/local/bin/juicefs
$ ln -s /usr/local/bin/juicefs /sbin/mount.juicefs

新增以下内容到 /etc/fstab 使得开机自动挂载,这里以上文 sqlite 为例:

sqlite3:///opt/jfs/jfs.db    /mnt/jfs       juicefs     _netdev,max-uploads=50,writeback,cache-size=204800     0  0

使用 mount -a 使配置生效

限制容量和文件数

没有限制的行为可想而知,JuicsFS 的默认限制较高,可以手动限制一下文件系统的容量和文件数量。

# 限制文件系统容量 (GiB)
$ juicefs config "sqlite3:///opt/jfs/jfs.db" --capacity 102400
# 限制文件数量 (inode 数)
$ juicefs config "sqlite3:///opt/jfs/jfs.db" --inodes 100000

限制容量举例,可以看到设定前后可以看到挂载点容量的变化:

# 示例
$ df -h | grep jfs
Filesystem      Size  Used Avail Use% Mounted on
JuiceFS:jfs     1.0P  8.0K  1.0P   1% /mnt/jfs

# 设定容量上限为 128 GiB
$ juicefs config "sqlite3:///opt/jfs/jfs.db" --capacity 128
2022/11/20 21:07:08.832094 juicefs[2253158] 
<INFO>: Meta address: sqlite3:///opt/jfs/jfs.db [interface.go:402]
  capacity: 0 GiB -> 128 GiB

# 再次查看发现大小为 128GiB
$ df -h | grep jfs
JuiceFS:jfs     128G  8.0K  128G   1% /mnt/jfs

限制文件 inodes 数量举例,可以看到设定前后可以看到挂载点容量的变化:

# 示例
$ df -i
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/vda2       3901440 367127  3534313   10% /
JuiceFS:jfs    10485762      2 10485760    1% /mnt/jfs

$ juicefs config "sqlite3:///opt/jfs/jfs.db" --inodes 3901440
2022/11/20 21:13:30.977616 juicefs[2255902] 
<INFO>: Meta address: sqlite3:///opt/jfs/jfs.db [interface.go:402]
    inodes: 0 -> 3901440
$ df -i
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/vda2       3901440 367128  3534312   10% /
JuiceFS:jfs     3901440      2  3901438    1% /mnt/jfs

性能测试

文件系统怎么能没有性能测试呢,下面分别使用 dd 和自带 bench 演示性能。

dd 简单读写测试

# 本地文件系统 io 性能
$ sync; dd if=/dev/zero of=/tmp/tempfile-12138 bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.563 s, 193 MB/s

# JuicfFS sqlite 元数据驱动性能
$ sync; dd if=/dev/zero of=/mnt/jfs/tmpfile bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.97672 s, 154 MB/s

# JuicfFS redis 元数据驱动性能
$ sync; dd if=/dev/zero of=/mnt/jfs-redis/tmpfile-12138 bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.59675 s, 192 MB/s

juicefs bench 测试

本地文件系统成绩

# juicefs bench -p 4 /tmp/
  Write big blocks count: 4096 / 4096 [==============================================================]  done
   Read big blocks count: 4096 / 4096 [==============================================================]  done
Write small blocks count: 400 / 400 [==============================================================]  done
 Read small blocks count: 400 / 400 [==============================================================]  done
  Stat small files count: 400 / 400 [==============================================================]  done
Benchmark finished!
BlockSize: 1 MiB, BigFileSize: 1024 MiB, SmallFileSize: 128 KiB, SmallFileCount: 100, NumThreads: 4
+------------------+------------------+--------------+
|       ITEM       |       VALUE      |     COST     |
+------------------+------------------+--------------+
|   Write big file |     153.98 MiB/s | 26.60 s/file |
|    Read big file |     148.60 MiB/s | 27.56 s/file |
| Write small file |   2064.9 files/s | 1.94 ms/file |
|  Read small file |   3150.8 files/s | 1.27 ms/file |
|        Stat file | 111847.4 files/s | 0.04 ms/file |
+------------------+------------------+--------------+

juicefs + sqlite 成绩

$ juicefs bench -p 4 /mnt/jfs
  Write big blocks count: 4096 / 4096 [==============================================================]  done
   Read big blocks count: 4096 / 4096 [==============================================================]  done
Write small blocks count: 400 / 400 [==============================================================]  done
 Read small blocks count: 400 / 400 [==============================================================]  done
  Stat small files count: 400 / 400 [==============================================================]  done
Benchmark finished!
BlockSize: 1 MiB, BigFileSize: 1024 MiB, SmallFileSize: 128 KiB, SmallFileCount: 100, NumThreads: 4
Time used: 72.0 s, CPU: 35.5%, Memory: 704.1 MiB
+------------------+------------------+---------------+
|       ITEM       |       VALUE      |      COST     |
+------------------+------------------+---------------+
|   Write big file |     148.25 MiB/s |  27.63 s/file |
|    Read big file |     144.29 MiB/s |  28.39 s/file |
| Write small file |     40.5 files/s | 98.83 ms/file |
|  Read small file |    715.9 files/s |  5.59 ms/file |
|        Stat file |   3759.0 files/s |  1.06 ms/file |
|   FUSE operation | 71735 operations |    2.99 ms/op |
|      Update meta |  4773 operations |   27.18 ms/op |
|       Put object |  1424 operations |  443.33 ms/op |
|       Get object |     0 operations |    0.00 ms/op |
|    Delete object |     0 operations |    0.00 ms/op |
| Write into cache |  1424 operations |  281.82 ms/op |
|  Read from cache |  1428 operations |  556.68 ms/op |
+------------------+------------------+---------------+

juicefs + redis 成绩

试着跑了一次,结果跑崩了,想玩的自己跑一跑吧。

由于 redis 是内存数据库,跑这种没有上限的测试一定要谨慎。在实际使用中,也要根据自己的需要选择,否则机器很容易 gg。

垃圾清理

juicefs 默认有回收站机制,删除文件默认在回收站保留一天。

可以去挂载目录下执行这条命令彻底删除:

$ find .trash -name '*.tmp' | xargs rm -f

总结

本文介绍了 JuiceFS 的基本用法,为“大盘鸡”需求提供一种新的思路,展示了使用对象存储挂载到机器作为文件系统的基本效果。

目前看来是解决系统盘过小问题的好方案,但具体是不是采纳这种方案,等我明天看看账单再做决定。

第二天看了下账单,跑了大概 10 轮测试,账单 0.02¥ ,初步看还能接受:

至于元数据引擎的选择,在单节点服务器的需求上我还是偏向 sqlite 或 mysql 集群的方案,redis 虽然性能强劲,但实在有点吃不消。

最后,这一定是一个很棒的项目,在对接 docker、k8s 之类的容器设施非常方便,提供了插件,可以像操作默认存储卷一样使用,还可以直接使用挂载在本地的路径,总之,在一些方面 JuiceFS 做的已经很好了,下面就是等待时间的检验了。

参考文献

2022 年注册美区 Apple ID 方法概述(使用美区 Paypal)

有些工作需要用到的软件只有美区 Apple Store 才有,还有一些想玩的游戏也是在国区无法下载,因此注册一个自己的美区 Appid ID 就能方便很多,这里记录一下注册方法。

本方案越需要花费 9/35 RMB,且需要 VISA(国区即可)信用卡,介意者绕道。

注册美区 Appid ID 主要的难点在于付款地址和付款方式的认定。本文主要也是解决这两个问题。

付款方式

苹果帐号要求绑定的付款方式必须是本区域的,也就是说我们在国区申请的信用卡,即使是 VISA 也是无法绑定使用的。

在这里通过 Paypal 的方式绕过,美区 Paypal 可以绑定国区 VISA,最近亲测可用,而且还能够正常付款。

现在问题就转移为美区 Paypal 的注册,美区 Paypal 注册难点在于手机号认证,必须使用美区手机号,而且不能使用网络号码(如 Google Voice)。

在这里使用 SMS-Man 解决,该平台至少充值 35¥,接码美区 paypal 服务需要 1.14$ ,差不过 9¥,剩下的钱也可以用来帮助他人,或是其他用途。不知道能不能退。

使用方法就不多说了,正常操作即可,注册 paypal 选择美国,电话选择 sms-man 生成的,之后点击接码。一次不行,就多试几次,五分钟还接不到,就删掉换一个再试。

此方法亲测可用。

付款地址

注册好苹果帐号,之后国家和地区选择美国,账单地址建议填写免税区,否则买东西都是有税的。

这里贴一张知乎大神整理的:

我这里选择了俄勒冈州,具体地址可以使用下面这个工具生成一个:

打开就可以获取到一个可用的地址,根据需要填写即可。

注册 ID 地区为美国,账单地址为上文生成的,付款方式使用上文注册的 Paypal ,这样一来就大功告成,可以在美区 Apple Store 使用国区 VISA 愉快的购物了。

最后,本方法仅用于学习研究之用,切勿用于非法用途。本站不承担任何连带责任。

希望本文介绍的方法对你有用。

参考文献

Nginx Proxy Manager – Docker 建站最佳伴侣

很长一段时间中,我都在思考容器建站的可行性。

容器有诸多益处,各类好处就不一一列举了。

在企业场景下,K8s 几乎一骑绝尘,可以完成大规模集群统一管理,完成几乎所有 Web 资源的自动调度。

但强大功能的代价,就是系统本身势必占用一部分资源,这就不适合大部分小网站、小企业去使用了。

传统建站一般是使用虚拟主机的形式,使用宝塔、AppNode、cPanel 之类的面板管理单节点站点,流量大了给服务器扩容、负载均衡、数据库外挂之类的也就解决了。

这种方案很适用于 LAMP 组合场景,可以让自己的想法快速成为现实。

在当代,各种新式编程语言大行其道,PHP 的时代似乎已经过去,容器成为更复杂运行环境的最佳载体。

作为个人站长,近几年部署应用都会优先考虑使用容器,还尝试过 k3s 组建轻量 k8s 集群的方案,使用近一年下来总有种大炮打蚊子的感觉。

说了这么多,就是想引出一种适用于当代 WEB 服务部署,容器化,但又不需要多台服务器的容器方案。

方案的关键技术为 Docker + Nginx 的组合。

上层采用 Portainer + Nginx Proxy Manager , 满足 UI 管理的需求。

部署方法

下面简单讲一下部署方法:

Docker

因为 Docker 的部署方法网上资源较多,这里就不列举了,下面默认已安装 docker .

Portainer

Portainer 是当下比较好用的一款 Docker Web GUI ,使用起来可以满足大部分需求了,部署方法也很简单,类似这样:

$ docker run -d
--network myDefault
--restart=always
--name="portainer" -p 9000:9000
-v /var/run/docker.sock:/var/run/docker.sock
-v portainer_data:/data 6053537/portainer-ce

其中的 myDefault 是自定义网桥,为兼容 docker-compose 等应用的外部访问,在这里不建议使用 Docker 默认网桥。

如果没有报错,就可以通过 9000 端口访问了,后面可以使用 nginx 反代此端口就可以关闭 9000 端口外部访问了。

Nginx Proxy Manager

这是一款 nginx web gui,使用下来体验不错,貌似内嵌了 openrusty,基本可以满足 Docker 反代、HTTPS 访问等的 GUI 配置需求了

使用如下 docker-compose 部署,可以直接在 portainer 操作:

version: '3'
services:
  app:
    hostname: nginx-proxy-manager
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
networks:
  default:
    external: true
    name: myDefault

打开后台:

http://127.0.0.1:81

默认管理账户:

Email:    admin@example.com
Password: changeme

效果展示

我在这里使用的是某位大佬汉化的 Portainer,为的是熟悉一下界面,简化操作,等熟悉了还是建议切回官方版本。

后面部署应用就在这里一站式搞定了,暴露外部访问时,就用 Nginx Proxy Manager:

反代配置界面如下:

以后在这里部署 Docker 应用,就可以很方便的暴露外部访问了,配了 Portainer 较好的生态和灵活的配置,几乎没有什么限制。

总结

本文介绍了一种轻量(1C2G 足矣)、容器化(Docker+Portainer)、自动化(Nginx Proxy Manager 自动 Https)的个人网站搭建方案,该方案几乎可以适应所有场景,更重要的是一台 1C2G 的服务器就足矣支撑数十个小应用。

自己使用或是外部访问都极其方便,再也不用纠结使用哪家面板,再也不用担心面板安全问题了。

我自己的图床、博客、Miniflux、网站统计、数据库以及一些自己开源的应用未来都计划部署在这里。

这就是今天分享的内容了,希望对你有用。

最后提醒一句,本文涉及的部署命令和配置文件随时有可能过时,请以官方文档为准。

参考文献

OpenEuler 防火墙放通端口 (以 8084 为例)

最近使用 OpenEuler 部署项目,发现防火墙放通端口的方法找不到,因此在这里记录:

[root@localhost Porting-advisor_2.5.RC1_linux-x86-64]# firewall-cmd --query-port=8084/tcp --permanent
no
[root@localhost Porting-advisor_2.5.RC1_linux-x86-64]# firewall-cmd --add-port=8084/tcp --permanent
success
[root@localhost Porting-advisor_2.5.RC1_linux-x86-64]# firewall-cmd --reload
success
[root@localhost Porting-advisor_2.5.RC1_linux-x86-64]# firewall-cmd --query-port=8084/tcp --permanent
yes

kali linux 配置 xrdp 远程桌面服务

xrdp 的配置让我充满疑惑,今天误打误撞完成了 kali 下的 xrdp 配置,能够顺利远程桌面进入 kali,这里记录一些可能必须的步骤,以备后用。

首先按照 kali 官网给出的 xrdp 配置脚本:

#!/bin/sh
echo "[i] Updating and upgrading Kali (this will take a while)"
apt-get update
apt-get dist-upgrade -y

echo "[i] Installing Xfce4 & xrdp (this will take a while as well)"
apt-get install -y kali-desktop-xfce xorg xrdp

echo "[i] Configuring xrdp to listen to port 3390 (but not starting the service)"
sed -i 's/port=3389/port=3390/g' /etc/xrdp/xrdp.ini

保存后 sudo 执行,自动配置 xrdp。

如果下载慢可以配一下 USTC Kali 软件源。

之后设定默认命令行启动,否则无法加载远程桌面:

# 命令行启动
$ systemctl set-default multi-user.target

# 图形界面启动
$ systemctl set-default graphical.target

之后使能 xrdp 服务:

$ systemctl enable xrdp
$ systemctl start xrdp

避免 ssl 证书无法验证,将 xrdp 用户加入 ssl-cert 用户组:

sudo adduser xrdp ssl-cert

之后可以重启试一下能否成功,记得官方配置端口为 3390 而非 3389:

$ reboot

如果不行配置一下这个再重启尝试:

# To set the system default to xfce4:-
$ **sudo update-alternatives --config x-session-manager**
There are 3 choices for the alternative x-session-manager (providing /usr/bin/x-session-manager).

  Selection    Path                    Priority   Status
------------------------------------------------------------
* 0            /usr/bin/gnome-session   50        auto mode
  1            /usr/bin/gnome-session   50        manual mode
  2            /usr/bin/startxfce4      50        manual mode
  3            /usr/bin/xfce4-session   40        manual mode

Press  to keep the current choice[*], or type selection number: **3**
update-alternatives: using /usr/bin/xfce4-session to provide /usr/bin/x-session-manager (x-session-manager) in manual mode

Try that

然后应该就可以了。如果不行欢迎留言。

参考文献

macOS 使用 arping 扫描 ip 冲突

最近工作网络不稳定,多个常用 IP 出现冲突,就连 DHCP 获取到的 IP 也会立刻冲突,原因等待相关人员去解决,今天简单记录 macOS 下 IP 冲突检测的原因。

一般检查 IP 是否被占用的方法是使用 ping

$ ping 119.29.29.29
PING 119.29.29.29 (119.29.29.29): 56 data bytes
64 bytes from 119.29.29.29: icmp_seq=0 ttl=50 time=14.477 ms
64 bytes from 119.29.29.29: icmp_seq=1 ttl=50 time=15.033 ms
64 bytes from 119.29.29.29: icmp_seq=2 ttl=50 time=15.330 ms
^C
--- 119.29.29.29 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.477/14.947/15.330/0.354 ms

但是这种方法看不到ip冲突,如果出现多个机器占用同个 IP,可以利用arp协议查一下 MAC 地址:

# macOS 下这样安装
$ brew install arping
# 使用 alias 定义快速使用别名
$ alias arping='sudo /opt/homebrew/opt/arping/sbin/arping'

另外发现 m1 下的 brew 安装 arping 默认不会进入 PATH ,因此在这里手动设定一个别名,方便使用。

之后扫描,如果出现 IP 冲突,可以看到有多个 MAC 地址回应:

$ sudo /opt/homebrew/opt/arping/sbin/arping 192.168.5.79
Password:
ARPING 192.168.5.79
60 bytes from 6a:f2:77:bd:bf:16 (192.168.5.79): index=0 time=463.000 usec
60 bytes from 6a:29:af:20:80:7f (192.168.5.79): index=1 time=1.002 msec
60 bytes from 6a:f2:77:bd:bf:16 (192.168.5.79): index=2 time=582.000 usec
60 bytes from 6a:29:af:20:80:7f (192.168.5.79): index=3 time=1.182 msec
60 bytes from 6a:f2:77:bd:bf:16 (192.168.5.79): index=4 time=658.000 usec
60 bytes from 6a:29:af:20:80:7f (192.168.5.79): index=5 time=1.117 msec
60 bytes from 6a:f2:77:bd:bf:16 (192.168.5.79): index=6 time=772.000 usec
60 bytes from 6a:29:af:20:80:7f (192.168.5.79): index=7 time=1.096 msec
^C
--- 192.168.5.79 statistics ---
4 packets transmitted, 8 packets received,   0% unanswered (4 extra)
rtt min/avg/max/std-dev = 0.463/0.859/1.182/0.257 ms

还可以通过 arping 来查看是否 IP 被占用,有些机器会禁止 PING 检测,使用 arp 这类二层协议检测占用情况会更准确些。

参考文献

macOS12 使用 UTM 体验 macOS 13 Ventura (多图预警)

UTM 是苹果 IOS、macOS 生态下的一款开源的虚拟机软件,底层基于 QEMU 或 Apple 虚拟化,能够在苹果操作系统上以半虚拟化(同 CPU 架构)或全虚拟化(异构 CPU 系统)的形式运行 Linux、Windows 以及 macOS。

macOS 13 (Ventura) 是苹果公司用于麦金塔桌面操作系统macOS的第19个主要版本,于2022年6月7日的苹果全球开发者大会(WWDC)上发布,成为macOS 12 Monterey的继任版本。此版macOS命名自加州南部的滨海旅游胜地范朵拉市

基于此前苹果系统的一些历史丑闻,导致本人在内的许多人对苹果推送的新固件保持谨慎态度。作为生产力存在的 macOS 更加需要小心谨慎了。

但一味的观望总是毫无进展的,还是上手体验一番最有说服力。虽然在 macOS 12 下使用 UTM 不可以直接启动 macOS 13 虚拟机,但是可以通过安装 macOS 12 虚拟机然后再更新到 macOS 13 的形式体验到最新的 macOS。

下面介绍方法和效果展示,多图预警!!

材料准备

为了安装 macOS 12 虚拟机,需要至少准备以下资源:

  • UTM
  • macOS12 IPSW 文件(约14GB)
  • 大约 64GB 的磁盘空间

其中 UTM 用于启动虚拟机,按照官网的流畅安装即可,非常简单。

IPSW 文件可理解为苹果生态下的 ISO 镜像,其中包含所有系统资源,可通过 这里这里 下载到 macOS 12 系统镜像。

IPSW(iPhone软件)是一种文件格式,用于为装有Apple芯片的设备安装iOS,iPadOS,tvOS,HomePod和最近的macOS固件。

需要注意的是,macOS 13 无法直接在 macOS 12 下启动,因此即使能够获取到 macOS 13 的 IPSW 文件,也无法启动。

磁盘空间需要预留至少 64GB,因为本人在尝试分配 64G 硬盘后,发现安装过程中几乎全部耗尽,如果空间不足会导致虚拟机卡死。

一切准备就绪,就可以开始了。

开始 Ventura 之旅

以下使用图片加注释的形式进行,按照图示一步一步走过来即可,赶时间也可以直接看图片效果:

这一步载入 macOS IPSW 文件

建议磁盘选择 64GB,32 GB 无法安装 macOS 13

等待系统安装

登入 macOS 13

系统信息

软件展示

台前调度

总结

使用 UTM 足以体验所有 macOS13 的所有新功能,用来评估是否可以用于自己的日常工作,以及个人喜好,避免降级。

本文介绍了 UTM 配置 macOS 12 虚拟机并升级到 macOS 13 的全过程,展示了 macOS 13 变动较大的设置、时钟、天气以及台前调度等功能,希望对大家起到一些参考意义,若有问题欢迎留言。

参考文献