Omarchy：艰涩而自由的 AI-native 之路

一、为什么想到安装 Omarchy?

第一次听说这个系统是在 Lex Fridman 对 DHH 的访谈，这个访谈有5个多小时，但我竟然从头到尾看完了。DHH，全名 David Heinemeier Hansson，在 IT 他是如雷贯耳的 Ruby on Rails 创始人，以严格要求手工撰写优雅代码著称，Rails + Mac + Textmate，吸引了无数开发者“成群结队”地涌向Mac 平台；在赛车场上，他是参加过世界顶级耐力赛、拿过勒芒组别冠军和 WEC 年度冠军的赛车手。

但在访谈开始我并不知道他。吸引我看下去的是 DHH 极富感染力、精神饱满的状态，和清晰准确的表达方式。在访谈的中间，他掏出一台 XPS 14 送给 Lex，上面预置了 Omarchy，DHH强调：它整个系统的安装只需要 45 秒，而“卓越不需要理由”。

可能是这个访谈发挥了作用，也可能是我的“注意力”被 X 捕捉到了：X 上关于 Omarchy 的内容突然多起来。很快我意识到，之前我设想的未来操作系统的形态，它当然应该是基于 Linux 的，而 DHH 干的正是这件事！所有的配置文件化、结构化，所有的软件开源化、可编程可编译，而 AI 作为顶层入口——AI-Native OS 的发端，可能正在发生，而我们正身处其中！

于是让 codex 下载了 Omarchy 4.0.1 的 ISO，嗯，既然是 AI-native，那就从下载开始 Native 吧。

在真正安装之前，我先和 ChatGPT 做了一次“心理建设”。我知道日常软件都有 Linux 的版本，所以我并不是特别在意生态问题。我最关心的是：一个从 3.1 就开始使用 Windows 的人，换到 Omarchy，究竟要丢掉哪些直觉？

ChatGPT 给出的答案是：Windows 是以应用和窗口为中心的 GUI 系统，Omarchy 更像一张以键盘、工作区、终端和可编程配置为中心的个人工作台。其实这些对我已经不会造成太大的担心，近些年没有少捣鼓 Cmd、Powershell、Codex、Python、SSH、文本配置和自动化。也许 Windows 依然不可替代，比如 AutoCAD、Premiere，但它或许可以从“每天生活的桌面”，退回为“专业软件 Runtime”，日常工作则由一个更适合 AI agent 生存的系统来接手。

我最终没有直接在物理机上安装，而是先在 VMware Workstation Pro 17.5.2 里尝试。也许手头的笔记本电脑更新换代后，我会将它重装成 Omarchy。虚拟机后来制造了很多额外问题，但先测试一下自己是否能适应 Hyprland 的平铺逻辑、工作区、快捷键，还是有必要的，终端和包管理倒不是问题，之前在 ubuntu 上已经反复操练过了。

迁移前我最担心的是远程桌面。ChatGPT 一开始说“Windows 无法直接远程 Hyprland”，但后来发现 hypr-rdp 已经出现了，实际测试表明确实可用。它只出现了几个月，这也侧面反映了 Omarchy 当下的生命力。

二、安装完后的第一眼：黑屏

VMware 不识别 Omarchy 的发行版，因此客户机类型需要手动选择“其他 Linux x64”，同时开启 UEFI 和 3D 加速，再按正常流程安装。安装确实很快，只用了1分25秒，然后——黑屏。准确一点说是“黑屏加一个鼠标”。关闭 VM 设置中的 3D 后干脆连鼠标也没了。Hyprland 需要虚拟显卡提供足够的 DRM/OpenGL 能力，但当前 VMware 的加速渲染路径又与 Omarchy 的图形栈存在兼容问题。系统已经启动，只是图形桌面没有被正确画出来。

ChatGPT 告诉我按 `Ctrl+Alt+F2` 或 `Ctrl+Alt+F3` 切到 TTY——这是一个不依赖图形桌面的文本控制台。有了控制台就可以进行操作了，采用的临时办法，是让部分图形路径走软件渲染。它确实把桌面救出来了，但后来也埋下了第二个坑：如果把 `LIBGL_ALWAYS_SOFTWARE=1` 放得太早、作用范围太大，连 Hyprland 合成器自己都会变成软件渲染，鼠标和画面刷新就会出问题。这个配置后来被撤回，并改成只对真正需要的软件生效。

桌面出现后，第一感觉仍然很糟：所有东西又大又傻，连一个基本的终端都显示不全。检查 `hyprctl monitors all` 才发现，虚拟显示器运行在 1280×800，同时 `scale=2`，换算成有效桌面空间只剩 640×400。在 ChatGPT 指导下，用 Omarchy 的快捷键 `Super+Alt+/` 逐级降低缩放，从 1.6、1.25 一路降到 1。桌面终于恢复到正常比例。随后再处理分辨率，把用户配置里的 monitor mode 从 `preferred` 临时改为 1920×1080@60，并保持 scale=1。

这时候宿主机的网页版 ChatGPT 上的内容并不能直接复制到 Omarchy，我不得不一个字一个字地把各种调试命令敲进去，这是好事，我想，哪个 Linux 用户不是键盘狂魔呢？从一开始就慢慢适应吧。

这里也是有坑的，`vmwgfxctrl` 返回成功，屏幕没变化；`hyprctl eval` 返回 `ok`，屏幕仍然没变化。直到修改 `monitors.lua` 后画面真的立刻变大，才证明 VMware 虚拟显卡与 Hyprland 都能输出高分辨率，坏的是 Autofit 到 Wayland/Hyprland 的自动联动。

稍微折腾了一下 Vmware Tools，想要实现“拖一下 VMware 窗口，虚拟机分辨率就实时变化”，意料之中的没有成功。手动输入各种命令确实让人抓狂，很显然应该先解决在 Omarchy 中安装 Codex 的问题。有了本地 Codex，还怕什么牛鬼蛇神？DHH 说了：We can fix everything。

三、Clash Verge：Tun 才是 Linux 的常态

接下来要安装和登录 Codex，科学上网问题必须先解决。先借用另一台机器提供的临时代理，把 Clash Verge Rev 下载并安装到本机。安装后，“系统代理”开关看起来正常，通过 `gsettings` 可以看到系统代理 manual 与 none 的变化。但内置的 Chromium 却不听话起来，浏览器根本没有按预期走代理，在 `auth.openai.com` 遇到区域错误。

原来，Linux 上所谓“系统代理”并不是全系统强制网络层。Clash Verge 修改的是 GNOME/KDE 常用的代理设置；我运行的是 Hyprland，Chromium 根本不走这套设置。在系统代理快捷键上浪费了不少时间后，我意识到 TUN 模式才是 Clash Verge 在 Linux 上的正确打开方式……

四、装上 ChatGPT Desktop，原地起飞

先让 Codex CLI 检查本机，发现当前 Omarchy 软件源已经提供 `openai-codex-desktop`。安装完成后，`chatgpt` 进程通过 Wayland 正常启动，内置 app-server 完成握手。后面的设置节奏完全改变。于是开始逐项配置，Rime、微信、LibreOffice Writer、zerotier、Samba、Resilio、hgfs、hypr-rdp、frpc、mpv……

首先是输入法。那时我甚至还不知道怎样把文件复制进虚拟机，于是曲线救国，把 Windows 上的小狼毫配置文件挂在网站上，然后告诉 Codex 具体网址。Codex 读取了我的 Rime 配置中转页 下的 `default.custom.yaml`、`double_pinyin_pyjj.schema.yaml`、`luna_pinyin.dict.yaml`、`mysymbols.yaml` 和 `weasel.custom.yaml`，从这些文件反推出我的双拼方案、词库、符号和切换习惯，然后依葫芦画瓢修改本地配置。It worked！

这里还有一些微妙的地方。Rime、Fcitx5 与 US keyboard，其实是三层。我最初要求“只留 Rime，不要 US board”，后来明白了：键盘布局负责基础键值，Fcitx5 是输入法框架，Rime 才是输入引擎。删除界面上的 US 输入项，不代表底层不再使用 US 键盘布局；所以按 `Ctrl+Space` 后仍然可以看到 `En`，这是因为整个 Fcitx5 被停用，而不是另一个英文输入法又回来了。

我习惯 Shift L 切换中英文。最初的绑定方案会误伤所有 `Super+Shift+…` 快捷键，因为系统在 Shift 刚按下时还不知道它是不是组合键的一部分。最终 Codex 改成了监听完整的按下—松开动作：期间没有其他按键才切换；只要出现 Super、F 或别的键，就取消。此外，候选框存在时还有一层：输入 `biru` 后显示“比如”，此时轻按 Shift，我想要的是提交原始字母 `biru` 再进入英文。直接停用 Fcitx5 会“错误”地提交中文候选，所以最后必须由 Rime 自己处理状态与原始输入串。

一个有意思的细节是，我习惯输入法界面是微软雅黑字体，于是让 Codex 直接下载微软雅黑。它拒绝了我，因为这个字体受许可限制。后来我手动 copy 进来，那是可以的。

五、微信

提到微信，一定要先从最荒诞的地方说起。它右键点击聊天窗口中的文件，点击“另存为”，这个选择保存位置的窗口竟然只有火柴盒那么大，文件名看不全，目录也看不清，关键边框还没法拉大。很难想象一个如此牛逼闪闪的大厂会退出这样一款官方软件，Linux 虽然小众，但微信事关品牌形象，也不能这么草率嘛。

Codex 把窗口手动调到 900×700，看起来好了，关掉重开又缩回去了。查到窗口规则写了 `xwayland=true`，而 xwayland-satellite 呈现给 Hyprland 的窗口属性实际并不匹配；规则中所有条件必须同时命中，因此那条“永久设置”从来没有真正生效。修正匹配条件、设置合理的最小尺寸并取消错误的最大尺寸限制后，重开窗口仍然保持可用大小，才算勉强解决了这个问题。

其实刚刚装完的时候，微信甚至打不开。安装包与桌面入口都存在，点击后短暂显示“正在启动”，之后就没反应了。它不是 core dump，也不是包没装好，而是启动脚本在创建窗口前退出。最后定位到问题在 VMware 虚拟显卡、Hyprland/Aquamarine 与 XWayland 缓冲区的接缝。用软件渲染的 xwayland-satellite 承载微信，窗口才真正映射出来。紧接着又发现 Fcitx5 候选框消失：微信和候选框必须落在同一个 `DISPLAY` 上。把显示环境统一后，中文输入才恢复正常。

另一个无语是，微信默认运行在 bwrap 沙盒里。它看到的 HOME 不是我的真实 HOME，因此把 PDF 保存到 Documents 后，文件管理器里竟然找不到。最后请 Codex 出马，把微信状态数据留在隐藏目录，然后真实的 Documents、Downloads、Pictures、Music 和 Videos 按需映射进去解决。

六、LibreOffice，最不可能出问题的地方也有问题

LibreOffice 其实已经内置在 Omarchy 里，但我事先不知道。我让 Codex 安装它，Codex 提醒我系统已经有了。然后我犯了一个“错误”：我没有先空启动一下 LibreOffice Writer，而是直接在文件管理器里面双击一个 docx——毫无反应。当时，这个文件又恰好位于 VMware HGFS 的中文路径下，于是嫌疑人范围急剧放大：中文 URI、共享目录、锁文件和文档损坏看起来都有可能导致问题的原因。

Codex 用控制变量把这些猜测逐一排除：DOCX 的 ZIP 结构完整；复制到本地纯英文路径仍然失败；TXT 也失败；全新 LibreOffice 配置仍然失败。真正的分界点是直接执行 `soffice.bin` 可以打开原文件，经 `/usr/bin/libreoffice` 的 `oosplash` 启动链却卡住。原来文档、过滤器和 Writer 主程序都没坏，坏的是启动器握手。

接着进一步抓到退出码 81：LibreOffice 首次配置需要启动器重启主程序一次，当前图形启动链没有完成这一步。异常终止又留下恢复记录，于是每次启动都像第一次，每次又都弹 File Recovery。最终增加用户级兼容启动器，处理伪终端和 81 重启，并覆盖 Writer 的用户级 desktop 入口与 DOCX 关联。

七、mpv 与 imv

系统自带的 mpv 0.41 在第一次打开 MP4 文件的时候就崩溃了。在 Wayland EGL 初始化失败后，回退路径触发内部断言并 `SIGABRT`。Omarchy 会在这时候自动弹出“是否用 AI debug？”体现出 AI-Native 的风范。Codex 一顿分析后，将软件包更换成包含上游修复的 mpv-git 后，不再产生 core dump，接着就来报喜说修复成功。然而再次双击视频，屏幕上还是没有窗口。

进一步日志显示，开发版只是“不再崩溃”，VMware 环境最终得到 llvmpipe 软件渲染器，而 mpv 默认不接受它。设置 `gpu-sw=yes` 后，再从 GIO 的真实默认应用链启动，Hyprland 才报告窗口 mapped=true、visible=true。这又是虚拟机的锅了。

imv 是一个内置的图片浏览器。它本来支持左右键切换上一张、下一张，但文件管理器直接双击图片时，只把被双击的那一张图片传给它，播放列表永远是 1/1。于是让 Codex 把用户级启动包装器改成：单文件打开时加载同目录并定位到目标图片；多选打开时仍尊重显式列表。

图片的显示窗口也小的可怜。我怀疑 DHH 不怎么在电脑上打开图片。Omarchy 默认规则固定为 875×600，我让 Codex 改成了“能放下时接近 1:1，放不下时等比例缩到屏幕 90%”，并预读同目录相邻图片尺寸，让翻页时窗口先调整、图片再完成解码。

它默认情况下，直接滚轮是放大缩小。我强迫症又犯了，为了实现普通滚轮切图、`Ctrl+滚轮`缩放，我一度在 Hyprland 全局捕获滚轮，结果导致所有非 imv 窗口疯狂弹 Lua 错误；第二次又把滚轮与最近一次鼠标单击一起转发，仅仅滚动鼠标就会让网页文字莫名被选中。最终把三条路径彻底拆开：imv 普通滚轮自定义、imv 修饰滚轮交回原生、其他应用接收原始事件。

八、VMware 的第二轮改造

起初，我把屏幕分辨率固定在 1920×1080 只是让机器可用。后来 Codex 写了轻量用户服务，读取 VMware 给出的目标尺寸，再让 Hyprland 应用，拖动宿主窗口后大约 0.2～0.3 秒就能跟随。看起来非常完美，结果系统重启后再次失效。原因是轻量用户服务比 Hyprland 更早启动，拿不到 `WAYLAND_DISPLAY` 和当前会话标识。之前手动测试时成功是因为桌面早已就绪，而自动启动时环境还不存在。最终让 systemd 用户服务等待 Wayland/Hyprland 真正可用，并用日志与重启复测，而不是只验证一次手动命令。

安装初期写入的全局 `LIBGL_ALWAYS_SOFTWARE=1` 一度是救命配置，但放在 UWSM 启动环境中会连 Hyprland 合成器一起影响。后来 VMware DRM 初始化失败，鼠标每移动一次就触发大量软件刷新，体感像“鼠标狂飘”。最终把这个变量从合成器启动前移除，只在某些具体应用需要时单独提供。普通鼠标过快则是另一回事：关闭自适应加速、使用 flat 曲线并降低 sensitivity 即可。把两个症状混在一起，会造成 Codex 误判。

VMware 提供的共享文件夹功能是很好用的，但 HGFS 也存在一个经典的启动竞争：宿主勾选了“总是启用”，来宾重启后 `/mnt/hgfs` 仍然消失；手动禁用再启用又能回来。说明共享能力没坏，只是 `vmtoolsd` 与宿主通告尚未就绪。解决方案是增加系统级挂载服务，等待 VMware Tools，用 `vmhgfs-fuse` 挂载，通告慢时每三秒重试，同时不阻塞系统启动；最终文件管理器加上侧边栏，共享目录变成随手可点的 Works，总算让人基本满意。

九、ZeroTier、Samba、hypr-rdp 与 frp

Samba（文件共享）是配合 Zerotier 的，也是为了方便文件交换。我设置了开机启动，但重启后通过 ZeroTier 地址仍然无法访问。`systemctl` 显示 active，看起来一切正常；实际检查监听才发现，Samba 启动时 ZeroTier 接口尚未出现，因此只绑定了回环地址。等虚拟网络上线后，它不会自动重新绑定。熟悉不？又是一个启动顺序问题。解决办法是让 Samba 等到目标 ZeroTier 地址出现，失败时重试。验证也必须从“服务是否运行”扩展为“端口是否存在、绑定到哪个接口、远端能否列目录”。

hypr-rdp 实际安装后，经测试可用，默认使用的端口也是大家熟悉的 3389。配置里可能踩坑的是监听地址：只监听 `127.0.0.1:3389` 适合本机 frpc 转发，却无法让 ZeroTier 同网设备直连；改为 `0.0.0.0:3389` 后，还应该让防火墙只允许 ZeroTier 网卡访问，普通 VMware 网卡继续拒绝。

hypr-rdp 会默认创建 headless 虚拟输出，即使当前没有活动远程连接也是如此。这在虚拟机里面还引出另一个怪现象：VMware 绝对坐标鼠标按两块屏幕的总范围映射，拖到本地可见边缘释放时会突然跳回。让 hypr-rdp 直接捕获 `Virtual-1`、不再创建隐藏屏幕后，鼠标坐标恢复正常。代价是 RDP 看到并控制本地桌面，而不是一块独立远程屏幕——这在现阶段可能更算是 Feature。

这次还有一个意外的发现。frpc 与 frps 文件里的 Token 逐字一致，服务端却持续报不匹配。进一步检查发现，之前的配置文件混用了新旧格式：`[common]` 让文件按旧版 INI 解析，新版内联 `auth = {...}` 被完全忽略。旧客户端与服务端实际上都在使用空 Token！赶紧把服务端和七八台客户端全部改过来了。

十、Vim

在调试 imv 的时候，我发现 `q` 原来就是退出。一开始为了满足使用习惯，要求把 Esc 也改成退出，配置已经做好、验证也通过，我想想还是让 Codex 撤销了。理由很简单：如果决定体验 Omarchy，就不应该把每个不符合 Windows 肌肉记忆的地方都立刻改掉。

`q`、`/`、`n/N`、`gg/G`、`h/j/k/l` 并不是 Linux 的强制标准，却构成了 Unix 键盘软件的一种共同方言。man、less、top、imv 和 Vim 的具体实现不同，但知道这套语法以后，很多陌生程序第一次打开也不再完全陌生。

Vim 最重要的概念不是 `h/j/k/l`，而是模式。普通模式里，按键是命令；按 `i` 进入插入模式以后，同样的 h、j、k、l 就只是普通字母；按 Esc 回到普通模式，再用 `:w` 保存、`:q` 退出、`:wq` 保存并退出。Windows 文本框默认永远在“输入文字”，Vim 则先问：你现在是在编辑内容，还是在操作文本结构？

`i` 进入插入模式，Esc 回到普通模式；
`h/j/k/l` 在普通模式中移动，`w/b` 按单词移动；
`/关键词` 搜索，`n/N` 跳到下一个或上一个结果；
`gg` 到开头，`G` 到结尾；
`dd` 删除一行，`yy` 复制一行，`p` 粘贴；
`:w` 保存，`:q` 退出，`:q!` 放弃未保存修改。

这些之前就已经有接触（更多是Nano），离真正习惯还有挺远。但它一定会带来更高的效率。

十一、AI-native OS 的理解

如果只看坑的数量，这次迁移几乎可以劝退任何人：安装完黑屏，分辨率惨不忍睹，系统代理对 Chromium 无效，微信保存窗口像火柴盒，Writer 双击没反应，mpv 修完 crash 仍不出窗口。

但在这些痛苦的折腾里，网页版 ChatGPT 先把我从黑屏带到 TTY；ChatGPT Desktop 安装后，Codex 又能读取本机状态、修改用户覆盖、调用 systemd、检查 Hyprland 窗口，并把过程留成可复盘的记录。

传统桌面状态分散在 GUI 里；但 Omarchy（或 Linux，一切皆文件） 的大量状态是文本、命令和服务，更容易被 agent 理解与操作。但 AI 也会把命令返回 0 当成成功，会把 systemd timer 做成聊天任务，甚至为一个应用污染全局配置。所以 AI-native OS 必须同时可观察、可授权、可回退、可验证。

Omarchy 还不是一台插上电就能工作的家电，但它已经展示了一种可能：未来的个人电脑，不只是被人操作，也可以让 AI 在明确授权和可验证边界内参与维护。那不是“桌面里有 AI”，而是操作系统开始为 AI 与人共同工作而设计。未来操作系统的形态可能是各种软件逐渐淡出前台，AI 占据了全部的交互。用户提出需求，AI 调用工具或现场制作工具完成任务，用户无需详细了解过程中使用了什么工具和软件。

正如 2004 年，DHH 编写的 TextMate 引爆了 Mac 开发狂潮，22年后，他和全世界的新一轮“狂热分子”们或将开启一个新的纪元。

P.S. 本文在 Omarchy 中编辑并发布。