注意本文仅适用于2025年年底的当下
开篇明义，如果要给NixOS Desktop的体验打分，
在写为什么现在相从 NixOS Desktop 迁移回 MBP 作为workstation
那么首先要说明当时为什么要从 MBP 迁移到 NixOS Desktop
https://chatgpt.com/c/692ab83e-9730-8322-94b7-69fdcbc36a4d
# https://www.reddit.com/r/niri/comments/1nwufq9/have_you_tried_two_or_more_shells_exo_noctalia/
- |
【2025-10-14】昨天白天一直在弄Desktop Shell相关工具。简单写点当前的相关认知。比较主流的就是这4个（按照star排序）：【DMS】、【Noctalia】、【caelestia】、【debuggyo/Exo】。我自己先后体验了Noctalia和DMS，最后选择了DMS，目前在用。我说下自己的看法。
1、DMS确实比noctalia更成熟。无论是bar还是DMS settings本身的UI都更好。功能也更全面。
2、noctalia确实有很难用语言表达的lagging，不多（可能不到3ms），但是确实影响体验
3、帖子中有人提到，“DMS的操作逻辑是mouse-based”，跟niri这种原生触控板逻辑冲突。这点我没体会到。可以通过设置快捷键来解决该问题，不是吗？已查证，确实如此。***可以认为shortcut作为中介（即把触控操作（在niri）映射为shortcut），可以保证触控还是键鼠两套逻辑都独立存在，互不干扰。***
4、DMS的问题：支持NixOS，但是并非类似noctalia那种NixOS为first-class，体现在：1、noctalia的文档有很完善的配置项说明（也就是nix的常规流程，先照着文档写配置，然后rebuild即可），而如果想在NixOS上使用DMS，最佳工作流程是直接安装，什么配置都不要修改，在界面上设置自己想要的配置，然后把settings.json转nix，这样才能拿到想要的nix配置（再作为 default-settings.json）。DMS只有README和discord，官方文档是关于IPC和theme设置的，没有任何配置项相关的。2、另外，关于配置项，还有一点不得不说DMS不如noctalia的点，就是DMS的配置项完全没有按照不同feats做抽象，基本上都是一维数组，配置项设计有点差，被人认为是“bugged but one-time setup”。这两项只是吐槽，属于可以忍受的缺点。“又不是不能用”。
【2025-10-17】把 DMS、noctalia这些都移除掉了。两点原因：１、开销太高，拿DMS举例，quickshell内存占用 350~450MB, DMS cli 20MB. ２、有很多用不到的功能。比如 wallpaper, weather, MenuBar, Dock, Launcher, Gamma Control, Clipboard 之类的，很多功能多有重复。比如说launcher，DMS的launcher无缝集成于DMS，相应的，其workflow无法迁移到其他工具，DMS的workflow通过QML/js实现（且接收数据格式为plaintext，而非JSON）。说白了，这些bundled到一起的工具，肯定不如别人精心打磨的好用。
- 【2025-11-13】类似键位映射工具很多，比如。kinto和toshy不支持（也不会）wayland，那么wayland是否有类似mac-like免配置键位工具？wayland下主流工具是 keyd 和 xremap，相比keyd，xremap更灵活。具体来说，YAML配置更易读，支持序列映射，模态层。还有【gnome-macos-remap-wayland】这种。【2025-11-27】移除掉【kinto】，也不再考虑 # [Wayland/X11 support? · Issue #420 · rbreaves/kinto](https://github.com/rbreaves/kinto/issues/420) kinto是mac-like keyboard layout的最佳方案，kinto基于xkeysnail实现，而xkeysnail目前也已兼容wayland。但是 “but it can’t dynamically change the keymap based on the app or app type until someone fixes the app detection.”
前情提要
关于nix，先标记几个重要milestone
从今年 2025-07-11 初试 nix（主要是 nix-darwin）
到 2025-09-20 开始从 MBP -> NixOS，尝试玩 NixOS Desktop，并把其作为日常 workstation 使用。没有使用任何类似KDE, GNOME 之类的DE，所有东西都是从0到1自己glue (比如说用 niri+mako搓音量键的音量notification 之类的)
再到最近，每天日常使用也有整整三个月了，从整个 Linux Desktop生态磨了一圈，基本上也心里有数了
所以写下这篇blog，作为这个阶段的
注意
有哪些问题？
我尝试使用了一段时间的 nixos desktop 作为 workstation
感觉确实有一些问题，并不如 MBP 好用，尤其是很多细节，不一而足
对我来说比较难受的几个点：
- 【wayland】尚不成熟，带来很多问题（比如说 goland 就有wayland和） # [Wayland Takes Window Positioning Somewhat Seriously](https://www.youtube.com/watch?v=_qU7PyViHOU)
- 【linux的内存机制】（以及没有对于workstation场景做CPU调优）并不适合作为workstation使用 # （比如说在毛刺场景下，cursor会直接卡死不动）
- 【日常软件】wechat等常用软件差点意思，包括 截图工具、剪贴板、输入法
- 【硬件素质】显示器、音频之类的硬件。这些windows机器本身素质就不如mac，软件层面更不必说了。
- 【键位设计问题】不多说。
- 还有更多细节问题，比如说触控板之类的
- 【文件管理器】没有类似finder这种 Column View 以及 Quicklook的 File Manager # 怎么做出以上结论的？在刚切换到NixOS desktop时，以为可以100%只用yazi替代，但是之后发现在两个经典场景下仍然需要GUI File Manager，所以找到了thunar，但是thunar也并不好用，只提供一些基本功能。所以放弃。
- WM niri
- launcher
所以我是否可以使用 MBP 作为workstation?
注意这个问题的核心并非在于可否，有很复杂的context，所以需要综合分析。问题在于：
1、公司机器：入职后公司会提供机器。我之前都不会去用，而是直接用自己的MBP，现在向来就很亏。对于这个问题，我之前的想法是把公司机器刷成 nixos desktop，直接使用，但是正如上面所说，nixos desktop的使用体验并不好。
所以我的方案是，直接把公司的机器刷成 nixos minimal
所有重服务都直接跑在公司机器上，我的MBP来作为日常使用，使用体验会更好。
2、但是如果把公司机器作为nixos，会存在一个问题
我目前使用 colmena 来简化部署。 那么最简易的是，直接使用nixos作为 workstation
但是如果使用macos作为workstation之后，必然会丧失这种便利。那我如果想把配置deploy到公司的nixos里，那就需要把另一台nixos机器作为主nixos机器（这是colmena的要求），对吗？
需要你解答以上两个问题，以及除了这两个问题以外，还可能存在哪些问题？
graphical更用户友好（UI设计），但不代表是对的，有两条路，一条正确但艰难，另一条容易但错误。但是，问题的关键在于，怎么界定对错？谁能界定？
clipboard tool
看了 clipse, ringboard
clipse 不支持search
ringboard不支持直接list latest
Nushell 现在是有自己的 background jobs 的（job spawn 系列），但偏「Nu 内部并发工具」，不是传统意义上那种“登出后还帮你守护进程”的方案。
goland & fcitx5
我发现在goland里启动fcitx5，输入法就可用了
一会尝试一下直接wayland模式启动goland
然后执行 fcitx5
看看是否能用
mac-like keymap
https://chatgpt.com/c/69168d3f-d870-8323-8f6c-92bc117baf45
我的想法其实挺简单的，就是希望可以把 Mod(也就是win键)映射为mac的cmd键
这样各应用下，不都可以直接用 Mod+C/V 来复制粘贴了吗？ 而不是像现在命令行下 必须要 Ctrl+Shift+C/V，而普通
应用下就是 Ctrl+C/V
很容易搞混，不是吗？
当然上面也只是举个例子，其实就是让Ctrl键回归到mac下的（或者说本身的原始逻辑），只是用来控制命令行相关操
作（之所以设计ctrl键，本身不就是为了处理命令行吗？只不过windows的设计有问题，把ctrl做成了系统操作键，从
这点来说,mac的键位设计是更符合开发者的直觉的，不是吗？）
你觉得呢？我不确定你是否理解我的context和需求了。
仍然来对齐需求
• 我理解你的目标：希望物理 Win 键扮演 macOS 的 ⌘，无论终端还是 GUI，按 Mod+C/V 就能复制粘贴；而物
理 Ctrl 只保留“类终端/命令行”用途（SIGINT、nano/Emacs 控制等）。要做到这一点，需要把系统视角下“逻辑
Super（Mod）”与“逻辑 Ctrl”调换或分流，然后保证 niri 的窗口管理仍然可用。结合你当前配置，有两条可行路径，
我们需要先确定你想走哪一条：
1. 彻底交换 Ctrl ↔ Super（全局 remap）
- 在 xremap 里用 modmap 把物理 Win → 逻辑 Ctrl，物理 Ctrl → 逻辑 Super。
- 结果：应用里 Mod+C/V 自动变成 Ctrl+C/V；niri 的 Mod+… 组合则要改成“现在的逻辑 Super”（也就是物理
Ctrl）才能继续工作。
- 代价：所有窗口管理快捷键都要换成“按 Ctrl”（例如 Ctrl+Q 关窗、Ctrl+1/2 切 workspace），肌肉记忆需要
重新训练。但实现最简单，也最贴近你说的“Ctrl 回归命令行，Cmd 才是系统操作键”。
2. 保留 Super 做窗口管理，只把常用组合映射（组合级 remap）
- 不改 modmap，在 keymap 里把 Super+C → Ctrl+C、Super+V → Ctrl+Shift+V（针对终端）等列出来。
- 结果：niri 的所有 Mod+… 按键保持不变；在应用层你仍然按 Win 键完成复制粘贴等。
- 代价：需要手写一份较长的 config.yml（终端/GUI 要区分），但对现有窗口管理习惯零影响。
你说“就是希望 Mod 映射成 mac cmd”，我倾向于理解为方案 2（保留 Mod 作系统快捷键，但把它的组合映射成
Ctrl）。如果你真想照搬 mac，甚至让 niri 的 Mod 也换到物理 Ctrl，那就是方案 1。
为了避免再“做了几次没成功”，我建议我们先把这些前置问题定下来：
- 你更想要哪种模式？
- 1 = 完全交换 Ctrl/Win，连 niri 的窗口管理都跟着换；
- 2 = 只做组合映射，保持 niri 的 Mod 键不变。
- 需要覆盖的应用类型：终端（kitty/ghostty）、浏览器、JetBrains、VS Code、文件管理器……越具体越好，我好在
config.yml 里写 application 过滤。
- 是否愿意把配置做成模块：我准备在 home/nixos/gui 下新建 xremap/，由 home-manager 安装 config.yml +
systemd --user 服务；之后任何主机启用 modules.desktop.niri 时都能复用。
先确认这些，我就能列出具体会动的文件和改动点（modules/nixos/desktop/peripherals.nix、home/nixos/gui/niri/
config.kdl 是否要改、home/nixos/gui/xremap/config.yml 新增等），再开始动手。
- url: https://github.com/Smithay/wayland-rs
qs:
- wayland相较于X11的优势？ EQC三角全面提升，之所以xxx，X11是1980年的老东西了，历史包袱太重。随着硬件提升、软件需求，需要全新的现代桌面架构。
- 【XDG协议（X Desktop Group）】FreeDesktop 跨桌面环境标准化协议
# XDG_CONF_HOME ~/.config
# XDG_CACHE_HOME ~/.cache
# XDG_DATA_HOME ~/.local/share
# XDG_STATE_HOME ~/.local/state
Answer
一、MBP 作为 workstation：是不是一个「正确」的选择？
把 Linux 从「桌面操作系统」降级为「远程开发 / 服务平台」，把「交互体验」交给 macOS。
二、colmena + NixOS minimal：是否一定需要「主 NixOS 机器」？
about ...
那还有个问题，后者的这个push 具体 push 了哪些呢？nix配置，还是啥？
默认：本地 build → push closure 到目标机 → 目标机切换系统
deployment.buildOnTarget = true：本地只 eval + 下发 derivation → 目标机自己 build（顺便就“被 push”了）
deployment.buildOnTarget = true 时
官方文档的描述是：先本地 eval，然后把 derivation 复制到目标机上，由目标机自己 build。
colmena.cli.rs
+1
也就是：
在 MBP 上 eval（这一步和默认一样）：
一样先算出 .drv。
MBP 把 derivations 下发到目标机：
不是把已经 build 出来的 closure 往回推，
而是把「要 build 什么」这套 derivation 信息复制过去。
在目标机上 build：
Colmena 在远端调用 Nix 来 build 这些 derivations。
目标机会自己从 binary cache 拉包 / 本地编译，最后在自己的 /nix/store 里生成系统 closure。
colmena.cli.rs
+1
直接在目标机上激活：
因为结果本来就 build 在远端，实际上已经等价于「push 完再激活」了，所以文档里会说：
build 这个 goal 在开启 buildOnTarget 时和 push 等价。
colmena.cli.rs
所以你说的：
前者是 先本地build + push closure
后者是 push + remote build
可以这么理解，但要注意：
这个 “push” 的内容 不一样（见下一节）。
在 buildOnTarget = true 时，“build” 这个 goal 自身就包含了 “push + remote build” 的效果。
默认：
Mac 负责：eval + build + push closure
目标机：只做切换系统
deployment.buildOnTarget = true：
Mac 负责：eval + push derivation
目标机：build + 切换系统
所以，如果ws不使用nixos之后，就无法直接复用已经build好的closure了。所以是否需要使用homelab的nixos作为“中心nixos”（用来下发本地build好的closure）
所以，换成 macOS 作为 workstation 后，需要搞一台「核心 NixOS 机器」吗？
方案 A：纯粹用 Mac 作为控制端 + buildOnTarget = true
方案 B：搞一台「核心 NixOS」作为控制端 + builder + 推 closure
方案 C：Mac 仍然作为控制端，但把 build 扔给远程 NixOS builder
具体怎么决策？
如果机器不多，那就 方案A，最直观
如果机器很多，需要尽量复用closure，那么方案C最好，mac控制端+远程builder
不需要 mac和 核心nixos机器做配置的双向同步。只需要把配置保留在mac上，这台nixos机器仅用来build，build完成后，把 nix closure 再发回 nixos 的 /nix/store 里。再由mac把这些 nix closure 下发到colmena目标机器。
相当于是 mac 转发 nix build到 remote builder -> 完成后再复制回 mac本地（/nix/store）
再之后就是原本的 本地rebuild然后 push closure 的流程
能这么理解吗？
也就是说 mac本地到时候同时会存 mac 和 nixos 最终的rebuild closure
是这个意思吧。这个就是代价，那相应获得的好处就是，优化了使用体验，直接使用mac作为workstation，而homelab机器则作为build机器。同时也无需再把nix配置在两端同步了。
Remote Builds - Colmena (Unstable)
Deployment Options - Colmena 0.4
三、除了这两个问题，还会有哪些坑需要提前想到？
- 【公司安全合规问题】代码、数据是否允许出现在个人设备上（你的 MBP）？
- 【网络可达性】如果把公司机器作为开发机，怎么保证该机器默认可访问？
- 【单点故障】如果MBP或者公司提供的机器挂了，怎么办？
- 【公司业务相关的secrets管理】否则未来换机器、离职、rotate key 会很麻烦。所以应该怎么处理？
- 【】但是如果把 mac 作为 workstation的话，那我就又要必须每天上下班带着 MBP了，对吗？还是说有什么更好的方案？可以不带着上下班？
这个问题的决策，要看2点：1、在家办公的强度？2、公司能否配mac?